Pascal, Yes, it also makes sense from the point of view of an SF, as join is one-shot traffic and we don’t want to allocate cells in response to that, even though the response in the particular case of minimal-security can be trusted.
I am arguing that for this particular behavior to be achieved, we do not need separate codepoints for upstream and downstream. Do you agree with that? Mališa > On 1 Dec 2017, at 13:18, Pascal Thubert (pthubert) <[email protected]> wrote: > > Hello Mališa > > Note that we are overloading the meaning of a TC by making it a tool for the > SF to make cell allocations. If we need the ToS field for real QoS purpose > then we can define which classes we use or use new ones. > Tagging the way back may help completing the join in the face of data. Using > TC as QoS better than best effort, a router will drop a lesser packet to make > room for the join response, so we have not gone through the hassle of the > first half of the join to be destroyed in the way back. > > Makes sense? > > Pascal > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Mališa Vucinic > Sent: vendredi 1 décembre 2017 12:12 > To: Michael Richardson <[email protected]> > Cc: 6tisch <[email protected]> > Subject: Re: [6tisch] Tagging join traffic > > 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
