Works for me Michael. Take care,
Pascal Le 29 nov. 2017 à 19:19, Michael Richardson <[email protected]<mailto:[email protected]>> a écrit : Michael Richardson <[email protected]<mailto:[email protected]>> wrote: Pascal Thubert (pthubert) <[email protected]<mailto:[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]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
