Re: [6lo] Tsvart last call review of draft-ietf-6lo-fragment-recovery-11

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Colin

Many thanks for your review!

I published -12 to make it easier for you to review the changes I'm suggesting based on your review,
The delta is visible here:  https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-12 

Let's see below for the discussion:
 
> The document updates RFC 4944 to provide a selective fragment recovery
> scheme for 6LoWPAN networks. It builds on draft-ietf-6lo-minimal-fragment
> and on the virtual reassembly buffers described in the expired draft draft-ietf-
> lwig-6lowpan-virtual-reassembly.
>
> The mechanism is generally well described and clearly specified. My main
> concern is that the performance of the mechanism will heavily depend on the
> values selected for the parameters described in Section 7.1, but there is little
> guidance provided on how to set these parameters for particular link layers.
> The draft would be improved if it could point to some more detailed guidance
> on parameter choice for particualar scenarios, or to further discussion on how
> to estimate parameters.

Providing values would be neat but not really possible. On the one hand we can add text to indicate why. On the other, we can certainly give more guidance than the close to zero that's in the doc today. 

- For the former, I suggest to add an introduction to section 7:
" 
7.  Management Considerations

   This specification extends "On Forwarding 6LoWPAN Fragments over a
   Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] and requires
   the same parameters in the receiver and on intermediate nodes.  There
   is no new parameter as echoing ECN is always on.  This parameters
   typically include the reassembly time-out at the receiver and an
   inactivity clean-up timer on the intermediate nodes, and the number
   of messages that can be processed in parallel in all nodes.

   The configuration settings introduced by this specification only
   apply to the sender, which is in full control of the transmission.
   LLNs vary a lot in size (there can be thousands of nodes in a mesh),
   in speed (from 10Kbps to several Mbps at the PHY layer), in traffic
   density, and in optimizations that are desired (e.g., the selection
   of a RPL [RFC6550] Objective Function [RFC6552] impacts the shape of
   the routing graph).

   For that reason, only a very generic guidance can be given on the
   settings of the sender and on whether complex algorithms are needed
   to perform flow control or estimate the round-trip time.  To cover
   the most complex use cases, this specification enables the sender to
   vary the fragment size, the window size and the inter-frame gap,
   based on the amount of losses, the observed variations of the round-
   trip time and the setting of the ECN bit. 
"

For the latter, Section 7.1 would become:
"

7.1.  Protocol Parameters

   The management system SHOULD be capable of providing the parameters
   listed in this section.

   An implementation must control the rate at which it sends packets
   over a same path to allow the next hop to forward a packet before it
   gets the next.  In a wireless network that uses a same frequency
   along a path, more time must be inserted to avoid hidden terminal
   issues between fragments.  This is controlled by the following
   parameter:

   inter-frame gap:  Indicates a minimum amount of time between
      transmissions.  All packets to a same destination, and in
      particular fragments, may be subject to receive while transmitting
      and hidden terminal collisions with the next or the previous
      transmission as the fragments progress along a same path.  The
      inter-frame gap protects the propagation of one transmission
      before the next one is triggered and creates a duty cycle that
      controls the ratio of air time and memory in intermediate nodes
      that a particular datagram will use.

   An implementation should consider the generic recommendations from
   the IETF in the matter of flow control and rate management in
   [RFC5033].  To control the flow, an implementation may use a dynamic
   value of the window size (Window_Size), adapt the fragment size
   (Fragment_Size) and insert an inter-frame gap that is longer than
   necessary.  In a large network where node contend for the bandwidth,
   a larger Fragment_Size consumes less bandwidth but also reduces the
   fluidity and incurs higher chances of loss in transmission.  This is
   controlled by the following parameters:

   MinFragmentSize:  The MinFragmentSize is the minimum value for the
      Fragment_Size.

   OptFragmentSize:  The OptFragmentSize is the value for the
      Fragment_Size that the sender should use to start with.  It is
      more than or equal to MinFragmentSize.  It is less than or equal
      to MaxFragmentSize.  On the first fragment, it must enable the
      expansion of the IPv6 addresses and of the Hop Limit field within
      MTU.  On all fragments, it is a balance between the expected
      fluidity and the overhead of MAC and 6LoWPAN headers.  For a small
      MTU, the idea is to keep it close to the maximum, whereas for
      larger MTUs, it might makes sense to keep it short enough, so that
      the duty cycle of the transmitter is bounded, e.g., to transmit at
      least 10 frames per second.

   MaxFragmentSize:  The MaxFragmentSize is the maximum value for the
      Fragment_Size.  It MUST be lower than the minimum MTU along the
      path.  A large value augments the chances of buffer bloat and
      transmission loss.  The value MUST be less than 512 if the unit
      that is defined for the PHY layer is the octet.

   MinWindowSize:  The minimum value of Window_Size that the sender can
      use.

   OptWindowSize:  The OptWindowSize is the value for the Window_Size
      that the sender should use to start with.  It is more than or
      equal to MinWindowSize.  It is less than or equal to
      MaxWindowSize.  The Window_Size should be maintained below the
      number of hops in the path of the fragment to avoid stacking
      fragments at the bottleneck on the path.  If an inter-frame gap is
      used to avoid interference between fragments then the Window_Size
      should be at most in the order of the estimation of the trip time
      divided by the inter-frame gap.

   MaxWindowSize:  The maximum value of Window_Size that the sender can
      use.  The value MUST be less than 32.

   An implementation may perform its estimate of the RTO or use a
   configured one.  The ARQ process is controlled by the following
   parameters:

   MinARQTimeOut:  The maximum amount of time a node should wait for an
      RFRAG Acknowledgment before it takes a next action.

   OptARQTimeOut:  The starting point of the value of the RTO, that is
      amount of time that a sender should wait for an RFRAG
      Acknowledgment before it takes a next action.  It is more than or
      equal to MinARQTimeOut.  It is less than or equal to
      MaxARQTimeOut.

   MaxARQTimeOut:  The maximum amount of time a node should wait for an
      RFRAG Acknowledgment before it takes a next action.  It must cover
      the longest expected round-trip time, and be several times less
      than the time-out that covers the recomposition buffer at the
      receiver, which is typically in the order of the minute.  See
      Appendix C for recommendations on computing the round-trip time.

   MaxFragRetries:  The maximum number of retries for a particular
      fragment.

   MaxDatagramRetries:  The maximum number of retries from scratch for a
      particular datagram.

   An implementation may be capable to perform flow control based on
   ECN, more in Appendix C.  This is controlled by the following
   parameter:

   UseECN:  Indicates whether the sender should react to ECN.  The
      sender may react to ECN by varying the Window_Size between
      MinWindowSize and MaxWindowSize, varying the Fragment_Size between
      MinFragmentSize and MaxFragmentSize and/or by increasing the
      inter-frame gap.


"


> 
> Nits:
> Section 1, 3rd paragraph, typo: "[RFC4944] as no selective recovery and the
> whole datagram fails when" -> "has no"?

Fixed

> 
> Section 7.1: Description of OptFragmentSize refers to MinFragmentSize
> 

Fixed

Again, many thanks Colin. Please let me know if the propose changes work for you.

All the best,

Pascal