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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 17 Mar 2020 20:53:51 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Mar 2020 13:49:18 +0000

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 😊

> Some grammar nit(s) here, maybe: "datagrams transit in fragmented form over
> a single hop at the same time"

Applied

> Maybe s/represent/require/?

Applied

>    fragmenting endpoint is NOT REQUIRED to variate the size of the

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

>    more) till the end of this datagram upon detecting a congestion.

Applied

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

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