[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".
- [6lo] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [6lo] Benjamin Kaduk's No Objection on draft-… Pascal Thubert (pthubert)