Ballot for draft-ietf-6lo-deadline-time
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Thanks for addressing my DISCUSS items ---- (2) Section 5. Per the description of the D flag, how would a forwarding device “suspect that a downstream node might find [a packet] useful”? (3) Section 6. Is there normative language about the behavior of forwarding entities when encountering the Deadline header in this section? If not, I’d recommend adding explicit text to that effect.
Firstly, thank you very much for the: "3. 6LoRHE Generic Format Note: this section is not normative and is included for convenience." It's really helpful to include stuff like this for newcomers and reviewers. I support Barry's DISCUSS - I was going to ask the same thing, but he beat me to it. I suspect that more context might also be helpful - one of the few times I can think of when I'd rather have a packet dropped than delivered late is for things like VoIP, where delayed / out-of-ordered packets are of no use, but I feel I might be missing more examples?
Thanks for the work everyone has put into this document. I have only a small number of comments and some nits. Comments: - section 1, are the different timezones really a problem? I would assume that all those devices are using a common reference such as UTC or does 'time zone' in this document does not refer to EST, PST, CET, .. ? If so, then it should be specified to ease the understanding - section 3, should explain why it starts with 0b101, if there is no meaning but it is just an identifier for the option, any reason why there is no IANA registry for this ? (and I understand that the IANA registry should have been created in the master document) - section 3, seems to imply that there is nothing after type but with a variable length. Suggest to add 'options' - section 5, DTL is "unsigned 4-bit integer, encoding the length of the field in hex digits" can you clarify whether it is the number of 8-bit bytes or the number of 4-bit nibbles ? The rest of the text seems to imply the latter but it would be nice to introduce it earlier IMHO. Also, if odd number of nibbles, then the figure 3 is not really correct as it implies a 8-bit boundary. Or is there some padding ? Then it should be specified and explained why simply not counting in 8-bit bytes. - more generally, I wonder whether having a mechanism to prioritize 'soon to expire' packets would be doable and benefitial. In the same vein, a description of the forwarding node decision would be welcome rather then implied in the D flag description Nit: - abstract contains very long sentences which makes it hard to parse (esp the last sentence) not to mention acronyms that should be expanded even if well-known (M2M for example)
In Section 4: There are multiple ways that a packet can be delayed, including queuing delay, MAC layer contention delay, serialization delay, and propagation delays. Sometimes there are processing delays as well. For the purpose of determining whether or not the deadline has already passed, these various delays are not distinguished. Not distinguished from what? Do you mean "not counted"? In Section 5: o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, encoding the length of the field in hex digits. If OTL == 0, the OTD field is not present. The value of OTL MUST NOT exceed the value of DTL plus one. * For example, DTL = 0b0000 means the deadline time in the 6LoRHE is 1 hex digit (4 bits) long. Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits. OTL = 0b111 means the origination time is 7 hex digits (28 bits) long. Is my math wrong or is your example wrong? 0b111 == 7. So (7 + 1) * 4 would be 32 bits. o Binary Pt (6 bits) : If zero, the number of bits of the integer part the DT is equal to the number of bits of the fractional part of the DT. if nonzero, the Binary Pt is a signed integer determining the position of the binary point within the value for the DT. * If BinaryPt value is positive, then the number of bits for the integer part of the DT is increased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly reduced. This increases the range of DT. * If BinaryPt value is negative, then the number of bits for the integer part of the DT is decreased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly increased. This increases the precision of the fractional seconds part of DT. It would be good if you specified how negative values are represented (Ok, maybe it is obvious) and the range for positive and negative values.
Thank you for addressing my DISCUSS and COMMENT.
The changes to the Security Considerations on version -05 address my concern about abuse of the deadline time. Thanks for that, and I'm clearing my DISCUSS now. Editorial comments that are still relevant in version -05: In the Introduction, please expand “BLE” on first use. In “Terminology”, you’re citing RFC 8174, but not using the new BCP 14 boilerplate from there. Please copy/paste the new boilerplate. — Section 5 — 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? Do you really need the extra size that the extra bit provides?
Agree with others, it would be helpful to have more description on the context/use. Mirja noted this sentence: “The packet SHOULD be delivered to the Receiver before this time.” What happens if it is not delivered before this time?
Looking at this mechanism it appears to me as something that should fit into a frame work, but that is not explicitly given. The main reason I am raising that is that it appears to not care about a number of interesting and challenging questions for a mechanism like this. Questions that a particular framework can take care of, or which any user of this mechanism would need to consider in their deployment before they can determine if they can safely deploy it. It might be that some of the questions have answers and I missed. In that case please straighten me out. And if you have some additional document that provides more detailed usage which discuss any of these issues I would appreciate a pointer. So quesitons that I got when reading this specification: 1. Are there any mechanism to provide feedback if the packets reach the receiver in time? If the sender sets the deadline shorter than the minimal one-way path delay, then all packets will be late. Will any feedback be provided that this is happening? In cases D=1 this appear to be a recipe for a black hole for the traffic. One can also end up in situation where a large fraction of the packet are late. 2. Any mechanism that exist to determine what the expected latency are from sender to receiver? 3. Are there any type of admittance or policy approval to use this mechanism? 4. What is the relationship between traffic with a dead-line and other traffic without a dead-line. Are traffic with a dead-line implicitly allowed to pre-empt other traffic or at least to delay it in its queue? 5. As Barry noted, what are the protection against missuse? These are issue that a framework or architecture would consider, I note that https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ include some discussion of these topics. Still DETNET architecture appear more constrained when it comes to usage than what this mechanism through its examples.
I support Magnus and Barry's Discuss. I would also like to see at least more text in the security consideration section about potential attacks or risks that can follow when the provided information is altered by another node or provided in a mal-intended way. Also it would be good to provide further information on how this deadline is supposed to be used by the network as well as by the endpoint. How does an endpoint decide about the right deadline? Does the endpoint need to know the RTT? How can this impact routing and scheduling? Of course these things don't have to be normatively specified, however, providing more information about the intended use and assumption would probably be helpful for implementors to do the right thing as well. One more comment: The following normative statements should probably rather use non-normative lower-case "should": “The packet SHOULD be delivered to the Receiver before this time.” and “All nodes within the network SHOULD process the Deadline-6LoRHE in order to support delay-sensitive deterministic applications.” as they are rather implicit goals than an actionable requirement.