IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-21

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/

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?

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" ?

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.

I support Ben's point about the need for a transition/backwards compatibility story.

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".

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?

Thanks for addressing my discuss and the good discussion!