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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 18 March 2020 03:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE383A0FFF; Tue, 17 Mar 2020 20:53:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-fragment-recovery@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, Carles Gomez <carlesgo@entel.upc.edu>, carlesgo@entel.upc.edu
X-Test-IDTracker: no
X-IETF-IDTracker: 6.121.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158450363103.32151.8329303852608424231@ietfa.amsl.com>
Date: Tue, 17 Mar 2020 20:53:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/FZx3PFOBO3Mp-ghOTEQoTpWS8mA>
Subject: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-fragment-recovery-16: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 03:53:52 -0000

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