Michael, With class 100, I was referring to the (common) 3 most significant bits in AF43, AF42 (and AF41) values.
If I can summarize, by tagging join request with AF43 and join response with AF42, we achieve that: (1) join requests do not trigger cell allocation (2) join responses may trigger cell allocation (3) join responses have priority in nodes’ buffers over join requests (2) would be achieved by simply not tagging join responses. (3) can only be achieved with join requests and join responses being tagged within the same class, but different codepoints, in order to be compliant with RFC2597. The advantage of having a separate codepoint for join response is therefore (3). Since the most implementation effort goes to implementing a class, adding a codepoint within shouldn’t be a big deal, so I am ok with it. A couple of questions: - Any particular reason why you chose class 100 i.e. (AF43 and AF42) and not any other class from RFC2597? - What should the zero-touch traffic be tagged with? Zero-touch traffic refers to *all* packets exchanged *before* minimal-security is executed. Having (3) for zero-touch does not seem to make much sense since both upwards and downwards packets could be induced by an attack. With that, I don’t see the need of differentiating between upward and downward. Should it all be tagged with AF43? Mališa > On 1 Dec 2017, at 19:07, Michael Richardson <[email protected]> wrote: > > > Mališa Vučinić <[email protected]> wrote: >> 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. > > There were many debates in diffserv about trying to define a traffic class > that was lower than best effort. It was repeatedly pointed out that this was > a contradiction. > > In the end what most people really wanted was to map traffic class 000 > (untagged) to a level of service which was actually above "best effort". > Any ISP or home user who uses PIE or *FQ*CODEL is in fact doing this > already. > > I'm not sure what class 100 is, I'm guessing it might be typo? > >> 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. > > I take your point about the buffers. That could change over time. > > The advantage of tagging response traffic with AF42 now is that we might want > to permit join response traffic to allocate cells. > >> 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. > > It depends on many things. Perhaps we could mark some of the response > traffic AF43, and then switch to AF42. > >> My proposal would be to use AF42 for both upstream and downstream join >> traffic. > > AF42? or AF43? > > -- > 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
