[Pascal] >> Seems a good idea to protect it. Do I have that wrong? > By ‘protect it’, do you mean give downstream join traffic higher priority in > the buffers over data traffic? If so, that’s already taken care of just by > using a non-zero TC. And the same holds for upstream join traffic, since it > uses a non-zero TC.
[Pascal] I'm not sure that the join and the response should have the same precedence. In a forming network there may be a bunch of both and the responses should win in case of a collision in a node's buffer. Conversely I'm not too sure that the initial join is better than a data packet. It may be a DoS attack. Intuitively I'd say that a join message on the way out of the network is below best effort and that a response back is above best effort. Do you mind consuming 2 TC values? Note that both values could be used for other packets with shared characteristics. Note also that instead of not adding slots, an intelligent SF may allocate some shorter-lived ones if it sees more than one join in a relatively short period of time. This covers for network startup and limited restart after a outage. Take care, Pascal _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
