Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Pascal,

Merci very much for your response and changes in the text. While my COMMENT were non blocking, I am happy to see that you took the opportunity to improve the document.

Regards (and do not forget the deadline of Monday __)

-éric



-----Original Message-----
From: Pascal Thubert <[e-mail]>
Date: Friday, 6 March 2020 at 19:58
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

    Hello Eric:
    
    Many thanks for your review!
    
    Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14  that I just published 
    
    Let's see below, and please let me know if the proposed changes work:
    
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > == 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 ?
    
    We discussed this in the minimal fragment review. Initially there was no other draft so this really introduced the concept. Now all the normative text moved to minimal.
    So it makes sense to make a change here:
    
    before
    
       This specification introduces a concept of an inter-frame gap, which
       is a configurable interval of time between transmissions to the same
       next hop.  In the case of half duplex interfaces, this inter-frame
       gap ensures that the next hop has completed processing of the
       previous frame and is capable of receiving the next one.
    	
    After
    
       [I-D.ietf-6lo-minimal-fragment] requires that a configurable interval
       of time is inserted between transmissions to the same next hop and in
       particular between fragments of a same datagram.  In the case of half
       duplex interfaces, this inter-frame gap ensures that the next hop is
       done forwarding the previous frame and is capable of receiving the
       next one.
    
    end
    
    
    
    > 
    > -- 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.
    > 
    
    A typical 6LoWPAN node have memory for one or a few packets. Having 256 packets that transit in the fragmented form over a same hop at the same time seems very far from the capabilities of current 6LoWPAN nodes. The trend for new MACs is to support the IPv6 Min MTU, making 6LoWPAN fragmentation a thing of the past. So I believe we're good. 
    
    I'm adding the last sentences of the following text in the introduction:
    "
       "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
       specifies the general behavior that all FF techniques including this
       specification follow, and presents the associated caveats.  In
       particular, the routing information is fully indicated in the first
       fragment, which is always forwarded first.  A state is formed and
       used to forward all the next fragments along the same path.  The
       Datagram_Tag is locally significant to the Layer-2 source of the
       packet and is swapped at each hop, more in Section 6.  With this
       specification the Datagram_Tag is encoded in one byte, and will
       saturate if there are more than 256 datagram that transit in the
       fragmented form over a same hop at the same time.  This is not
       realistic at the time of this writing.  Should this happen in a new
       6LoWPAN technology, a node will need to use several Link-Layer
       addresses to increase its indexing capacity.
    "
    
    
    > -- Section 5.2 --
    > I suggest to mention that the use of the Datagram_Tag field will be described
    > in section 6.
    
    Works for me. In fact, I pushed that up to the introduction, see the text above.
    
    
    > 
    > -- 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"
    
    Yes, done.
    
    > 
    > -- 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".
    
    I got a similar comment in Ben's review on this : )
    
    "
    
       [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint
       stores "the actual packet data from the fragments received so far, in
       a form that makes it possible to detect when the whole packet has
       been received and can be processed or forwarded".  How this is
       computed is implementation specific but relies on receiving all the
       bytes up to the Datagram_Size indicated in the first fragment.  An
       implementation may receive overlapping fragments as the result of
       retries after an MTU change.
    
    "
    
    
    > 
    > -- 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.
    
    I guess the same here, this is per destination for each sender and per sender for each destination.
    
    "
       The management system should monitor the number of retries
        and of ECN settings that can be observed from the perspective of
        both the sender and the receiver with regards to the other end-point.
    
    "
    > == NITS ==
    > 
    > -- Section 7 --
    > Is it "Kbps" or "kbps" ?
    
    Long as the b is lowercase (indicating bit) I believe we're safe. But back to SI, Kilo is uppercase (because it is a multiple of the unlike milli or micro) so I favor Kbps. 
    
    Please let me know if we're good with the above,
    
    Again many thanks, Eric!
    
    Pascal