Esko Dijk <[email protected]> wrote: > For the stateless proxy, it is hard to determine a good rate limit > number. 1% is not good because it would slow down the joining process > of a genuine Pledge to a crawl. Some strategies that could work better:
> 1. Initially allow a (near) unlimited use of "uplink" bandwidth, to get
> a fast enrollment in the common case. When the relayed traffic persists
> for some time (either by same Pledge or other Pledge, no difference)
> apply a stricter rate limit.
Well, you've described a 1% limit with a longer integration time :-)
> 2. Apply a (rough) 'data budget' for upstream traffic to the
> Registrar. Only if sufficient "downstream" traffic comes back from the
> Registrar to Pledge(s), the upstream data is allowed at a high rate. If
> that's not the case, a strict rate limit is applied.
This is a kind of token bucket system where the downstream traffic fills the
bucket.
> 3. Send the radio frames associated to relayed "upstream" traffic with
> the lowest priority. I.e. have a scheduler with packet priority. I
> know e.g. OpenThread has this to prioritize mesh management-traffic.
Yes, as does 6tisch.
I think that this is probably the simplest, because it requires the least state.
> A combination of approaches is also possible.
> Solution 3 seems easiest to implement, if the mesh network stack
> already has a working priority-based scheduler. But it will probably
> need to be combined with some rate-limit approach too.
:-)
> Proxy SHOULD locally schedule the "upstream" IP packets to be sent with
> lowest priority. And Proxy SHOULD apply a rate limit to "upstream"
> data volume to be approximately equal to the "downstream" data volume
> (all that's coming back from the Registrar).
It seems that you have some suggested text.
> Yes, the key part here is that when a Proxy once discovers a Registrar
> it cannot assume that this Registrar will be alive on that IP address
> forever. So it needs to rediscover in case the original discovery
> information expired. If rediscovery fails, it will not forward traffic
> anymore to the old IP address.
GRASP makes this timeout pretty clear.
mDNS does too, I think.
It's just CoAP RD that has the problem, I think.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
