Michael Richardson <[email protected]> wrote: > Pascal Thubert (pthubert) <[email protected]> wrote: >> Yet not sure the MAY on the return path is a good idea. Either make it >> a SHOULD or a no no. Otherwise we do not know what to expect in a given >> network with mixed implementations.
> I can live with SHOULD.
> SHOULD means that a co-located JRC which has access to the scheduling APIs
> can do the right thing and not have to spend a byte on DSCP.
> As I say, the 6LBR can also have an ACL to recognize the join
> responses.
okay, here is the new version of Join response tagging:
5.3. Identification of Join Response Traffic
Join Response traffic from the JRC to the proxy (and hence to the
pledge) SHOULD be marked with a DCSP code AF42. AF42 has lower drop
probability than AF43: if the JRC will respond at all, then dropping
the response traffic would cause the pledge to have to retransmit,
using even more bandwidth.
When the JRC is not co-located with the DODAG root (6LBR), then the
code point provides a clear indication to the 6LBR that this is join
response traffic. (There are other mechanisms that the 6LBR could
use, in particular it could use an ACL to recognize the join traffic)
Due to the converging nature of the DODAG, the cells immediately
below the 6LBR are often the most congested, and from that point down
there is progressively less (or equal) congestion. If the 6LBR paces
itself when sending join response traffic then it ought to never
exceed the bandwidth allocated to the best effort traffic cells. If
the 6LBR has the capacity (if it is not constrained) then it should
therefore provide some buffers in order to satisfy the Assured
Forwarding behaviour.
> Please realize that the tagging that we do for 6tisch-minimal-security
will
> also be identically used for 6tisch-zerotouch-join, and that traffic
might be
> larger, and it will take some additional round trips before we know that
the
> node is legitimate. (many RTTs if we have to use DTLS, two if we can
> have EDHOC)
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
