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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 18 March 2020 13:49 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298C3A162E; Wed, 18 Mar 2020 06:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hatNrwMi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yoz88Lf/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgztU8nPsNOE; Wed, 18 Mar 2020 06:49:50 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799CE3A162B; Wed, 18 Mar 2020 06:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6676; q=dns/txt; s=iport; t=1584539389; x=1585748989; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gTvDuin6nVy/weUjNM0jC7yJvm53KzYWDTUzfOnnSe0=; b=hatNrwMiRZcl2IFFmf909AXdr6sKREtXUFd3KJvLaZejhYa0PzIyZshR G1wUQW5RfTHUdw0X8Cr3mWdBrrmz1JCL5510HQIsfDqrDhsVRnC6rbMoU 5KixTnQXq/rOE8PvpsJW9tdgGN0stZu90Kn26vZFyieYxXW65wus2cPt/ g=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ajf6ZhhFRWzIxHpZP5som251GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZBQDBJXJe/49dJa1mDg4BAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVRQBWxYIAQLKoQWg0UDinKCX5gYgUKBEANUCQEBAQwBASM?= =?us-ascii?q?KAgQBAYRDAheBfyQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECARIREQw?= =?us-ascii?q?BATcBBAsCAQYCGgImAgICMBUQAgQBDQ0agwWCSgMOIAEOkgGQZwKBOYhidYE?= =?us-ascii?q?ygn8BAQWBMwKDTBiCDAMGgQ4qhSCHDhqBQT+BEUeCTT6CZAICGoEwG4MPMoI?= =?us-ascii?q?sjXsvgkifUwqCPJcVm0mPBptfAgQCBAUCDgEBBYFpIoFBDwhwFYMnUBgNjh0?= =?us-ascii?q?MFxWDO4UUhQQ9dIEpjiwBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,567,1574121600"; d="scan'208";a="449168282"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Mar 2020 13:49:48 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 02IDnmNJ008724 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Mar 2020 13:49:48 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Mar 2020 08:49:48 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Mar 2020 09:49:47 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Mar 2020 09:49:46 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DXnVFL9QDBzMPnTOA3/8im2D7uz5IYdpOL2aE6C8RuwUNG7TPC6plGQfvBKCma?= =?utf-8?q?oCnACQ5r+csS9Q2Pr12JNStEP6Pu9zPoZ6UfvURjiEKIp/UXA0RsVMMwdsHY4gxkC?= =?utf-8?q?dB0is1+4Ga2FIHkKk3B9J2HHEk0/Q4G0y7VCv7lRwO1mo3kl5MZuL+1J3m0qveRUo?= =?utf-8?q?oby3DwPbdZKpvSfHCglZ2iufCU1YoSgzSFapEBbRw9P1rf2iY/DCEJfg2ZlArwNyq?= =?utf-8?q?GC0CFQeES39vSL6Wu4oBO3yBm9kiTUKX6S+r1R03j9t60gywM8UG24oJfqt5DA/6W?= =?utf-8?q?78BmcxIMsk/e1stC1C3rA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DgTvDuin6nVy/weUjNM0jC7yJvm53KzYWDTUzfOnnSe0=3D=3B_b=3DP2Yicw?= =?utf-8?q?LDAXiGeKDBsC3jpuWn3B17QrxNhD7GWmkslqo81A2rvQFyDzqKcsE9W4S8kI8Z8KL?= =?utf-8?q?ieMPf8ZGUZUJaAS/ySc/YbrK5+zOqHJ0SIDOfNnx9+H4Mxlbp3JHAMuJeHmN/C+r5?= =?utf-8?q?BxzuuHl/wfADF68vN4BRyfErZuUNN6R451FiZ7giIbQbdGPV5iZWtErL4LzfY99NP?= =?utf-8?q?b4I7lPJXhWjjMcmvHp4/g1H26nWR7sxmk7IMo1RQB68yOfqmDE4O2Fqtl0p4yJQon?= =?utf-8?q?gqdRlAD2/5gJJHFVzNcHX5CXoamARf5C2RJegOoAWp24UlO6cDPWXMhR6lCP6Q0Xc?= =?utf-8?q?FIv9O+Z25lw=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DgTvDuin6nVy/weUjNM0jC7yJvm53KzYWDTUzfOnnSe0=3D=3B_b?= =?utf-8?q?=3Dyoz88Lf/hkXJMYIn4RDX+gNN1IG0UtuT8EJE4pIlx49yc+n1SWGuucZr5F0AMC?= =?utf-8?q?YY8rZNEHvuHS6z7GIZVtZoFP23o2YH0LO8hGkRfk2p6qsMVoc2uW25u18fx7WfU41?= =?utf-8?q?B7OlVDqO4ACSOyj3WU/98c0w1X/al6jhNEFq7R6RiGpY=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3759.namprd11.prod.outlook.com (2603:10b6:208:f2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Wed, 18 Mar 2020 13:49:46 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2814.021; Wed, 18 Mar 2020 13:49:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-fragment-recovery-16: (with COMMENT)
Thread-Index: AQHV/Njhj6pXyY8QX0GOwXCCi+nr36hOTFLQ
Date: Wed, 18 Mar 2020 13:49:18 +0000
Deferred-Delivery: Wed, 18 Mar 2020 13:49:01 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB3565BC0E43F1A18BC897F6B2D8F70=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158450363103.32151.8329303852608424231@ietfa.amsl.com>
In-Reply-To: <158450363103.32151.8329303852608424231@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:5549:5ee1:795c:1e25]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 04f32e8d-4a44-46b8-eb0e-08d7cb43383d
x-ms-traffictypediagnostic: MN2PR11MB3759:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB375986770F99C23AD6A68068D8F?= =?utf-8?q?70=40MN2PR11MB3759=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzOTYwMDMpKDM5ODYwNDAwMDAyKSgzNzYwMDIpKDM0NjAwMikoMTM2?= =?utf-8?b?MDAzKSgzNjYwMDQpKDE5OTAwNCkoNTUwMTYwMDIpKDk2ODYwMDMpKDUyNTM2?= =?utf-8?q?014=29=2871200400001=29=288936002=29=2866446008=29=2881156014=29?= =?utf-8?q?=2876116006=29=288676002=29=2881166006=29=2866946007=29=286655600?= =?utf-8?b?OCkoNjY0NzYwMDcpKDY0NzU2MDA4KSgxODYwMDMpKDY2NjYwMDQpKDc2OTYwMDUp?= =?utf-8?q?=284326008=29=2886362001=29=285660300002=29=28966005=29=283365600?= =?utf-8?b?MikoNTQ5MDYwMDMpKDExMDEzNjAwNSkoNDc4NjAwMDAxKSgzMTYwMDIpKDY1?= =?utf-8?q?06007=29=282906002=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3759; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?dDOHqJrTD+3/ZnB3+3eryyW00fpw8wv?= =?utf-8?q?rY0u4HMdwa+f6ixAJBXvu5p6NuRV4mdObe1pqVpv166RehdmV7QdIyEW6r6VaAV98?= =?utf-8?q?k3JVHXyiqlPfYo7h837fmbdYe9kDMhwoEYz4m5FhHgNNpRXYpaMMGeLeAY5/4PuKk?= =?utf-8?q?GixhPueQ0prBzaBw9U6L3qWiNAYnMNmygRgcByriMuTevOSZLh7gYTb6ogaISxC7P?= =?utf-8?q?uZ+SW3esGvhL0Zj8QraoeMY0YbQjoKmLCKPdLn57iONVvlaXpUu7cko74UhXRIAqJ?= =?utf-8?q?CUliBnfrQc1Kj19vbM1gCEeuTxvQ9R9eUGBPTk+L62p6NymSN5YvMQdvuH52Re0Lw?= =?utf-8?q?wiGPRj1enY7RCQuydLJbqX9GsvL7hSxemx01MyKdWL3r5GBrhBYUNKXqsJqLLPvGc?= =?utf-8?q?xIUyFyxMTLWFQmoCX0NN8/oOwCfA4M0AHOm4FFjvkduj2FfF3z+fxsMikAbTDSQO1?= =?utf-8?q?bSn8UhBd+Cn694oZtV+4TzG3+1NZMG9yU7ud6LK0aHKVF0NA=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?dpZyvguW9zCSkTJ0InyTdGezgpizn5?= =?utf-8?q?saxHG9ZArNhXwsNAV55Fj/601pqZP8WrEtxJkJ+f+WuE69SHNE+vfgMqD0ubZarCA?= =?utf-8?q?G+ILLlQ2qsV0XK9mM+++1ksIighaSas1zjtuZab48MCxgmQLIDYaaoC3G0xSVLhTh?= =?utf-8?q?Nc0WhOUre7IJ/HmVki2j7WYeWzzgGRnz07zDuNdzN6cQTpdiCNdSBg=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 04f32e8d-4a44-46b8-eb0e-08d7cb43383d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 13:49:46.1234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?6k3FgzDkPSdQ1EhQb/P1F?= =?utf-8?q?8j8C96A/EuZh+/mGQ7ckTQt/5C2k6Qj1wNt6svOSgv+bRk+ox+ayj+EuECa7iNrxQ?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3759
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/-tdhhnvwRWv04Ig8j7KTJQMMJ-A>
Subject: Re: [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
Precedence: list
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 13:50:04 -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 😊


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