Pascal, Michael, Since data traffic in the network is treated as DSCP class 000, i.e. best effort, it will necessarily have lower priority over all other classes, including class 100 that we decided to use for join with specific AF43 and AF42 codepoints. This means that both AF43 (join request) packets and AF42 (join response) packets have precedence over best-effort traffic. We just define the rule that this particular traffic class should not influence SF decisions on cell allocation.
The only benefit of differentiating between join request and join response (using AF43 and AF42) is then in case an intermediate router happens to have both packet types in its buffer, in which case it would more likely drop join request than the join response. I am questioning the need for this given that the 6tisch router is a constrained device and will likely have a common buffer for both best-effort and 100 class, and will therefore first drop best-effort traffic. To me, the advantage of differentiating between join request and join response seems marginal, yet it introduces the code complexity of handling an additional case. Plus, we won't be able to reuse the exact same mechanism for zero-touch, as in that case downstream join traffic is still untrusted. My proposal would be to use AF42 for both upstream and downstream join traffic. Mališa > On 29 Nov 2017, at 19:19, Michael Richardson <[email protected]> wrote: > > > 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 =- > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
