Certainly Mališa. The reason for a different TC is to treat them differently. The join response represents an investment of resources in the network and an acceptance by the JRC (so it's not an attack, is it?). Seems a good idea to protect it. Do I have that wrong?
Pascal -----Original Message----- From: Mališa Vučinić [mailto:[email protected]] Sent: vendredi 1 décembre 2017 14:13 To: Pascal Thubert (pthubert) <[email protected]> Cc: Michael Richardson <[email protected]>; 6tisch <[email protected]> Subject: Re: [6tisch] Tagging join traffic 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
