Hi, Charlie, and thanks for the response. > > This should be easy to explain and clear up, but I have to ask, as I don’t > > see > > anything about it in the document: what deters entities from using this > > with a > > short deadline time in order to get expedited delivery, when they don’t need > > it? How does this help a network if, ultimately, every transmission > > specifies > > a very short deadline time? > > As mentioned in other email, I agree that we should discuss this > problem, and I guess the right place would be in the Security > Considerations. I think the problem only occurs if pre-emption is > allowed. So one possibility would be to mandate that implementations > SHOULD NOT pre-empt.
That would help. There's still the issue that an attacker (or just inconsiderate use) could basically make this option useless (as you note below) -- in such case it wouldn't actually be *worse* for the network, but it would kill the benefits of asking for a short deadline when you really need it. > Designs for gaining some latency advantage by signaling often seem to > have this problem. Maybe there is already language we can borrow for > clarifying the issue in our draft. The way we often deal with this is by defining options that allow voluntary downgrading of service, but *not* elevation. Clearly, that's not what you're looking for here, but that works in many situations. You're right, of course, that allowing requests for elevated service always prompts requests for elevated service. > If pre-emption does not occur, then I don't think the network is > impacted in the way that you suggest. If every transmission specifies a > short deadline time, then many or most packets will simply be dropped. So, in the end, I don't know what more can be said about this other than the "SHOULD NOT pre-empt" bit... and maybe a note that if this gets gamed, its value will approach zero, and that's just the way it is. > > Why is DTL the length *minus 1*? Doesn’t that invite mistakes? Is there a > > reason not to make it the length, and to say that 0 is not a valid value? > > The reason is to allow 16 hex digits for the deadline time, or 64 bits. > You are right that this makes implementation more vulnerable to error, > but I believe the danger here is small. If this is a minority opinion > and most people want to have the maximum to be 15 hex digits, we can do > that. I don't feel strongly about this, and it's not at DISCUSS level, but you can see from Alexey's question in his review, we already see confusion. And it's not so much that DTL starts at 0 for length one (though it is that, somewhat) as it is that the two fields are *different*: one starts at 0 and one starts at 1, and it seems like the start of the rules for Fizzbin. Clearly, because OTL needs to represent 0, it needs to start as 1 = one. So the question goes to DTL: what range do you really expect to need? Is it important enough to get the extra 2x that it's worth adding the confusion? If so, if you really need the extra power of 2, then thanks for having the discussion, and carry on. But if it's just an issue that the extra power of 2 was possible, so y'all did it "just in case", then please consider opting for a lower chance of confusion. Again, your judgment: I've made my comment, and it's down to you now. Thanks again for the response and for addressing my comments. Barry _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
