Hello Barry and all, I have made some follow-up to your comments below...
On 5/12/2019 6:54 AM, Barry Leiba via Datatracker wrote:
Barry Leiba has entered the following ballot position for draft-ietf-6lo-deadline-time-04: Discuss
...
The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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.
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.
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.
---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the Introduction, please expand “BLE” on first use.
Will do.
In “Terminology”, you’re citing RFC 8174, but not usng the new BCP 14 boilerplate from there. Please copy/paste the new boilerplate.
Will do.
— Section 5 — The definition of “TU” is out of order; please move it so it’s in the same order in the definitions as in the block.
Will do.
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.
Regards, Charlie P. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
