Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Michael Richardson <[e-mail]>]

Esko Dijk <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-