Re: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-fragment-recovery-16: (with COMMENT)

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

Hello again Benjamin:

Continuing based on rev 16...

As usual, the state of both of today's threads is published as https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-17 for your convenience 😊


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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"

Applied

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

Applied

> 
>    fragment will be acknowledged.  A basic implementation of the
>    fragmenting endpoint is NOT REQUIRED to variate the size of the
> 
> nit: s/variate/vary/

Applied.
Guess what, I actually looked it up and could not find a clear definition of the difference so I picked one.


> 
>    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/
> 

Applied

> Section 5
> 
>    This document specifies an alternate to the 6LoWPAN fragmentation
> 
> nit: s/alternate/alternative/

Applied

> 
> 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,


Let's see:  If the fragment seq=0 is too big the path is never built. Retrying it will fail. 
It's actually a good idea not to subfragment with the samle datagram tag. 
Seems a good idea to allow to form a whole new path with a new datagram tag.

What about relooking 6.1. ?

"

6.1.  Forwarding Fragments

   This specification inherits from [FRAG-FWD] and proposes a Virtual
   Reassembly technique to forward fragments with no intermediate
   reconstruction of the entire datagram.

   The IPv6 Header MUST be placed in full in the first fragment to
   enable the routing decision.  The first fragment is routed and
   creates an LSP from the fragmenting endpoint to the reassembling
   endpoint.  The next fragments are label-switched along that LSP.  As
   a consequence, the next fragments can only follow the path that was
   set up by the first fragment and cannot follow an alternate route.
   The Datagram_Tag is used to carry the label, which is swapped in each
   hop.

   If the first fragment is too large for the path MTU, it will
   repeatedly fail and never establish an LSP.  In that case, the
   fragmenting endpoint MAY retry the same datagram with a smaller
   Fragment_Size, in which case it MUST abort the original attempt and
   use a new Datagram_Tag for the new attempt.
"

Note: This is a first step into the PMTU that I did not want to specify 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).

In which case the offset, not the sequence, is 0. Does the last paragraph above clarify?

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

True:

What about :

"
                                                                  While the support of echoing
   the ECN at the reassembling endpoint is mandatory, this specification
   only provides a minimalistic behaviour on the fragmenting endpoint,
   that is to reset the window to 1 so the fragments are sent and
   acknowledged one by one till the end of the datagram.
"

Many =