IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
Comment (2020-02-19 for -13)
I support Ben's point about the need for a transition/backwards compatibility story.
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-03-17 for -16)
Thank you for addressing my comments! Just a few minor notes from reading the diff from -13 to -16: Section 1 each hop, more in Section 6. This specification encodes the Datagram_Tag in one byte, which will saturate if more than 256 datagram transit in the fragmented form over a same hop at the same time. This is not realistic at the time of this writing. Should Some grammar nit(s) here, maybe: "datagrams transit in fragmented form over a single hop at the same time" Section 4.3 is out of scope. In most cases, the expectation is that most datagrams will represent only a few fragments, and that only the last Maybe s/represent/require/? fragment will be acknowledged. A basic implementation of the fragmenting endpoint is NOT REQUIRED to variate the size of the nit: s/variate/vary/ the ECN signal or simply reset the window to 1 (see Appendix C for more) till the end of this datagram upon detecting a congestion. nit: s/till/until/ Section 5 This document specifies an alternate to the 6LoWPAN fragmentation nit: s/alternate/alternative/ Section 5.1 It just occurred to me now that with the change in response to my initial review of "never reuse a sequence number for a fragment with different size", there may be special considerations for the initial fragment (Sequence 0) that gets some special handling. I suspect there are not any real problems here, and in any case the datagram itself could be re-sent, but mention it just in case there are some new problems (e.g., we get stuck in a case where we have to send something that gets treated as a reset even if we don't want it to). Appendix C represented in Figure 4 in Section 5.2. While the support of echoing the ECN at the reassembling endpoint in mandatory, this specification does not provide the flow control mechanism that react to the congestion at the fragmenting endpoint. A minimalistic behaviour could be to reset the window to 1 so the fragments are sent and acknowledged one by one till the end of the datagram. I think we may be suffering from a bit of skew here, since Section 1 specifies the "UseECN=yes" behavior (for this document) as "reset the window to 1".
Martin Vigoureux No Objection
Roman Danyliw No Objection
Comment (2020-02-18 for -12)
Thank you for this easy to read document. ** Section 5.1. Per “There is no requirement on the receiver to check for contiguity of the received fragments, and the sender MUST ensure that when all fragments are acknowledged, then the datagram is fully received.”, the second clause doesn’t parse for me. What must the sender ensure when all of the fragments are acknowledged? ** Section 5.1. Fragment_Size. If this is a 10-bit unsigned integer and the unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)? ** Editorial -- Section 5.2. Editorial. s/A NULL bitmap that indicates that the …/ A NULL bitmap indicates that the …/ s/A FULL bitmap that indicates that the …/ A FULL bitmap indicates that the …/ -- Section 6.1. Recommend replacing colloquial language – “It inherits … using a timer to clean the VRB when the traffic _dries up_” -- Section 10. Typo. s/ot this/to this/
Warren Kumari (was Discuss) No Objection
Comment (2020-03-06 for -14)
Thank you for addressing my DISCUSS issue, clearing... ---- Thank you for a useful and interesting read -- I really enjoyed this document. I do also support Benjamins "I think we should be more clear about whether a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many bits as the sender sent fragments set to one also counts as "FULL". " comment, and had something very similar drafted... [ Original DISCUSS Position for archeology purposes ] [ Be ye not afraid - this should be easy to address.] "datagram_size: The size of the datagram in its Compressed Form before it is fragmented. The datagram_size is expressed in a unit that depends on the MAC layer technology, by default a byte." and: "Fragment_Size: 10-bit unsigned integer; the size of this fragment in a unit that depends on the MAC layer technology. Unless overridden by a more specific specification, that unit is the octet, which allows fragments up to 1024 bytes." I spent quite a while going though the document, looking at the 13 places where you use 'byte' and 3 where you use 'octet', trying to figure out if there is a reason that different terms are used. Normally I'd just say "meh, these are synonyms" and ignore it, but in this particular specification (because of the "by default" / "Unless overridden") I think it is actually important.... Can you standardize on one of the other, or provide more explanatory text if there is a reason?
Éric Vyncke No Objection
Comment (2020-02-19 for -13)
Pascal, thank you for the work put into this document. The idea is simple and smart, I like the fact that all fragments follow the same path, so they should be delivered in the right order. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header Chains" is applicable ? -- Section 4.2 and Section 7.1 -- Should default values for the inter-frame gap be given ? -- Section 5.1 -- With 8 bits in the Datagram_Tag, this means that a node can only transmit/forward 256 packets over a link. While this seems suffisant, did the author make some investigation on this limit? The text should also state what to do when the 8 bits are not enough. -- Section 5.2 -- I suggest to mention that the use of the Datagram_Tag field will be described in section 6. -- Section 6 -- I find it weird to read in the same paragraph "The RFRAG Acknowledgment can optionally carry an ECN" and later "MUST echo that information by setting the 'E'". I am not a native English speaker but may I suggest to replace the first part with "The RFRAG Acknowledgment has a ECN" -- Section 6.1.2 -- "An implementation may receive overlapping fragments as the result of retries after an MTU change." Is this a security risk (RFC 8200 forbids overlapping fragments but this is a different layers) ? I also suggest to make it a normative "MAY" or "MUST accept". -- Section 7.2 -- Should the network observation installs global states or per destination states ? E.g., typical IP implementations maintain a per destination Path MTU cache. == NITS == -- Section 7 -- Is it "Kbps" or "kbps" ?
(Alexey Melnikov; former steering group member) Yes
Yes (2020-02-18 for -12)
Thank you for the well written document.
(Suresh Krishnan; former steering group member) Yes
( for -12)
(Adam Roach; former steering group member) No Objection
No Objection (2020-02-19 for -13)
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.
(Alissa Cooper; former steering group member) No Objection
No Objection ( for -13)
(Barry Leiba; former steering group member) No Objection
No Objection ( for -13)
(Deborah Brungard; former steering group member) No Objection
No Objection ( for -13)
(Magnus Westerlund; former steering group member) No Objection
No Objection (2020-02-18 for -12)
I am uncertain if there is security risk that is poorly noted. I don't think it is significant as an intermediate node will in many other ways be able to interfere with the transmission of the fragments. However, it appears to me that the below formulation potentially allow a fragment sender to go into an interesting state by acknowledging fragments prior to even have received them, causing the sender to abort the transmission prematurely? When all the fragments are received, the receiving endpoint reconstructs the packet, passes it to the upper layer, sends an RFRAG Acknowledgment on the reverse path with a FULL bitmap, and arms a short timer, e.g., in the order of an average round-trip delay in the network. As the timer runs, the receiving endpoint absorbs the fragments that were still in flight for that datagram without creating a new state. The receiving endpoint abort the communication if it keeps going on beyond the duration of the timer. Could the author please comment on this aspect of what would occur in the fragment sender if it receives an RFRAG-ACK will full bitmap prior to having send all fragments, and also what would happen if this is received very shortly after having sent the last fragment?
(Mirja Kühlewind; former steering group member) (was Discuss) No Objection
No Objection (2020-03-22 for -20)
Thanks for addressing my discuss and the good discussion!