Re: [Tsv-art] Tsvart last call review of draft-ietf-6lo-fragment-recovery-11

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 11 February 2020 14:41 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4912012C; Tue, 11 Feb 2020 06:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=PeMRPdC6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v+CZbkz0
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 bWVuM7dzzyDO; Tue, 11 Feb 2020 06:41:40 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19D01200A4; Tue, 11 Feb 2020 06:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11722; q=dns/txt; s=iport; t=1581432099; x=1582641699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ya8K2ICvSVuAcXlRizqVlJxvJ8drOx1rUaxnPfBK18k=; b=PeMRPdC6eD0K1ZtDiScPEs4DNyt9T/fEkTiAnKnn9byPEY3ayKiPgcvV Pgv8hHV1OduTctSWh0GgjPEXjOk/hq2/d0nZO+lG4jDrWk23H9TPr7xSu uNS1WZ2AJfMkTBalr0q+YmpqnwDFQGdfLCHD0DFeN6Zn7Tpw8lhJf24Gg I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AURgrrxVYWm9WcuusNxj6qDtgxSrV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiAMRfXlJ/41mwMFNeH4D1YFiB6nA=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQCGvEJe/49dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVCQsBWxYIAQLKgqEC4NGA4sDgl+YEoJSA1QJAQEBDAEBIwo?= =?us-ascii?q?CAQGEQAIXgjAkOBMCAw0BAQQBAQECAQUEbYULBiYMhWYBAQEDAQ4EEQQNDAE?= =?us-ascii?q?BIxQBBAsCAQgODAImAgICMBUQAgQBDQ0agwWCSgMOIAECAQugDAKBOYhidX8?= =?us-ascii?q?zgn8BAQWBMwKDVhiCDAMGgQ4qhR+HBBqBQT+BEUeBTn4+gmQCAhqBHgMqgw4?= =?us-ascii?q?ygiyNQhg7gkaILYc2jkhwCoI6jRSJU4JIiBGLb4RHjmSbJQIEAgQFAg4BAQW?= =?us-ascii?q?BaSKBWHAVgydQGA2FK4hyg3OFFIU/dIEpin2BMgEwXwEB?=
X-IronPort-AV: E=Sophos;i="5.70,428,1574121600"; d="scan'208";a="719382614"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Feb 2020 14:41:37 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 01BEfa1B032708 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2020 14:41:37 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 08:41:36 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 08:41:35 -0600
Received: from NAM10-MW2-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; Tue, 11 Feb 2020 09:41:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cNz0Ac/+yerB4ppgy2AAaaJuXwWwDonV0aB3a2+gp4PySJDGpfwuRjJUktp6Q9nbhMwH/UKKjjm6QoUfcK6SxdLdA9X8GYDwssHzUNKijQuS8wZf4WjN+ey6+G2vLf3cgfrZNmzSNJkQb1CG5trsugUBPmLtMzEhHmpPOMUssFz1J1LmIsWUREJNKkebf2SEN3kTVqza0yHRImUJ8WOFml5lB6bNC8iTwpkgwkhIGOCNHXfpcfyH7tH2GfWG5VAcw05t4/wuo6oDWxOt+E8QsYJ/Pp7pQXV4BhHZRh0lWxiD+fyrpNQK0ea3WyZzcH3tCPaDw9ulH0OyMWG8ko0cNQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ya8K2ICvSVuAcXlRizqVlJxvJ8drOx1rUaxnPfBK18k=; b=DNLvvOeDhwhvDSiA0ZweW1mVSEdBgRirt5DmrUu+XvczEEw1Nwb+Y222tX/k9u8cJuGPzH45vS3H7JxYPJ4JeCh8u8E4uwZ4mUHUVOOdDWX6gtk02nO9L9xBYsE2++GQhTQC5zF0e7Iiz/mJ426OoTvH3FUNTBNqHQXTcVoM71IKofrPaLwiFMnwntg+3J4yS/KUg28+coIBzqTuzDhhBindFoWaKrib1kY4fWfwBWpi1y97VmPXu9nNUXWcOLAIN6fdOB1JomlgSP56X/HtMo/x+wlPtWMetRAl9o6yqb7uOl19H5eV/1ukYkD7dL8M264uQnw3SrUf8MEfgXtdVA==
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; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ya8K2ICvSVuAcXlRizqVlJxvJ8drOx1rUaxnPfBK18k=; b=v+CZbkz0EdXc1RL9Z6lGzQRNP3DWAryPX+AnGivO9wvH1hNUBCxr7odQSuB/xvQ6/BGGZtdAChclH/jQIThQ22AWI5feXI7ZSDd2tywOWvCz0MRr0jwQ9lDzZKNX8NTgjVAlhYj9DkYpqPltgH1EpN9J1tiNOIazRt8CBcpUOAY=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4063.namprd11.prod.outlook.com (10.255.180.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.25; Tue, 11 Feb 2020 14:41:33 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.030; Tue, 11 Feb 2020 14:41:33 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Colin Perkins <csp@csperkins.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-6lo-fragment-recovery.all@ietf.org" <draft-ietf-6lo-fragment-recovery.all@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-6lo-fragment-recovery-11
Thread-Index: AQHV4D+a9hhz1MEjq0uoUYgwdqLcNKgVo+hA
Date: Tue, 11 Feb 2020 14:41:30 +0000
Deferred-Delivery: Tue, 11 Feb 2020 14:41:22 +0000
Message-ID: <MN2PR11MB3565AE170254E0EC891884A8D8180@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158135915750.3970.15055299184182938182@ietfa.amsl.com>
In-Reply-To: <158135915750.3970.15055299184182938182@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: [2.15.172.153]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 87f40bc9-5900-4083-14ac-08d7af007d68
x-ms-traffictypediagnostic: MN2PR11MB4063:
x-microsoft-antispam-prvs: <MN2PR11MB406351231B2B5F46D4A739DBD8180@MN2PR11MB4063.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(346002)(136003)(39860400002)(189003)(199004)(66476007)(2906002)(316002)(7696005)(71200400001)(55016002)(9686003)(66446008)(66556008)(52536014)(66946007)(64756008)(76116006)(6506007)(33656002)(26005)(186003)(4326008)(5660300002)(86362001)(8936002)(54906003)(110136005)(966005)(8676002)(81166006)(81156014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4063; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; 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: s7qJpi2jrBE7/YCjBGdjkbx319rcxFPKjYvROOQ4tbNyCkWVXLJo5GCGsczdTeK4lPYmklD3VE7kOq5ZipJeiIqohtSgd/nw/5orl7ATeB6Y3vqzESFeWyjzewqTqjk93rR0Sb4VzLhRA7GJn5n8wOkrtTVQcX906ORDhfA1hVvFLbuJZ7wjkqYAMw8l+3vqGinGcwdSaJoxw4MFHN8/Vh5iCACZgUPiPsTq3MPwirUvAHOI5+jAS0QUP1RtocO8iTjVpaUnioiVX7kiS4djDFGWl9022L0WriTjgHQd2xCL+u9sIMTOwYJUS+uguQotpy759Gy9DJjXjtIYbTAlxBhTwsE+ZXOPCt1USdS8SuyXuD6ofmRpZ9in8BH3mY7GM6qKs7t0BeSVwoGfBtKf52So6z/x/ottgTFFzJ6T4fLw7bSloews796KPsKETCQCxq0ML45SRy8ARUbD0ZlKFO0WTOtF+vGpoPMNlkCHmwDJtkpAIj5wO3qTnCGI78H2cGlYUUfut6i9h0Fpx5uGow==
x-ms-exchange-antispam-messagedata: 2M4BC0DcaROy677JqCSaqFdLw6ph4+YpKaZAseJVi2Gvt3O0BWPXjaFtarXdUySm9wZessmrudxUbKHioiV9iKeH9ZgzTCEwgEB7keoRfSJMe/KnvdXGwc1LVhIh8/NiVnoMx9WjatahWkeLTaROvg==
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: 87f40bc9-5900-4083-14ac-08d7af007d68
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 14:41:33.3679 (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: BQZ/AmwsZbDC7KRZYcMxbdjp4GM3K7SavpNMxxGydrbt4GXgTIz3isFj1bCaJlLOEeZRt+BsRRGKP/9SYLBRlw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4063
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ZOCCPaqgI5LjYWIC3qbyCN4AkAM>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-6lo-fragment-recovery-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 14:41:43 -0000

Hello Colin

Many thanks for your review!

I published -12 to make it easier for you to review the changes I'm suggesting based on your review,
The delta is visible here:  https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-12 

Let's see below for the discussion:
 
> The document updates RFC 4944 to provide a selective fragment recovery
> scheme for 6LoWPAN networks. It builds on draft-ietf-6lo-minimal-fragment
> and on the virtual reassembly buffers described in the expired draft draft-ietf-
> lwig-6lowpan-virtual-reassembly.
>
> The mechanism is generally well described and clearly specified. My main
> concern is that the performance of the mechanism will heavily depend on the
> values selected for the parameters described in Section 7.1, but there is little
> guidance provided on how to set these parameters for particular link layers.
> The draft would be improved if it could point to some more detailed guidance
> on parameter choice for particualar scenarios, or to further discussion on how
> to estimate parameters.

Providing values would be neat but not really possible. On the one hand we can add text to indicate why. On the other, we can certainly give more guidance than the close to zero that's in the doc today. 

- For the former, I suggest to add an introduction to section 7:
" 
7.  Management Considerations

   This specification extends "On Forwarding 6LoWPAN Fragments over a
   Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] and requires
   the same parameters in the receiver and on intermediate nodes.  There
   is no new parameter as echoing ECN is always on.  This parameters
   typically include the reassembly time-out at the receiver and an
   inactivity clean-up timer on the intermediate nodes, and the number
   of messages that can be processed in parallel in all nodes.

   The configuration settings introduced by this specification only
   apply to the sender, which is in full control of the transmission.
   LLNs vary a lot in size (there can be thousands of nodes in a mesh),
   in speed (from 10Kbps to several Mbps at the PHY layer), in traffic
   density, and in optimizations that are desired (e.g., the selection
   of a RPL [RFC6550] Objective Function [RFC6552] impacts the shape of
   the routing graph).

   For that reason, only a very generic guidance can be given on the
   settings of the sender and on whether complex algorithms are needed
   to perform flow control or estimate the round-trip time.  To cover
   the most complex use cases, this specification enables the sender to
   vary the fragment size, the window size and the inter-frame gap,
   based on the amount of losses, the observed variations of the round-
   trip time and the setting of the ECN bit. 
"

For the latter, Section 7.1 would become:
"

7.1.  Protocol Parameters

   The management system SHOULD be capable of providing the parameters
   listed in this section.

   An implementation must control the rate at which it sends packets
   over a same path to allow the next hop to forward a packet before it
   gets the next.  In a wireless network that uses a same frequency
   along a path, more time must be inserted to avoid hidden terminal
   issues between fragments.  This is controlled by the following
   parameter:

   inter-frame gap:  Indicates a minimum amount of time between
      transmissions.  All packets to a same destination, and in
      particular fragments, may be subject to receive while transmitting
      and hidden terminal collisions with the next or the previous
      transmission as the fragments progress along a same path.  The
      inter-frame gap protects the propagation of one transmission
      before the next one is triggered and creates a duty cycle that
      controls the ratio of air time and memory in intermediate nodes
      that a particular datagram will use.

   An implementation should consider the generic recommendations from
   the IETF in the matter of flow control and rate management in
   [RFC5033].  To control the flow, an implementation may use a dynamic
   value of the window size (Window_Size), adapt the fragment size
   (Fragment_Size) and insert an inter-frame gap that is longer than
   necessary.  In a large network where node contend for the bandwidth,
   a larger Fragment_Size consumes less bandwidth but also reduces the
   fluidity and incurs higher chances of loss in transmission.  This is
   controlled by the following parameters:

   MinFragmentSize:  The MinFragmentSize is the minimum value for the
      Fragment_Size.

   OptFragmentSize:  The OptFragmentSize is the value for the
      Fragment_Size that the sender should use to start with.  It is
      more than or equal to MinFragmentSize.  It is less than or equal
      to MaxFragmentSize.  On the first fragment, it must enable the
      expansion of the IPv6 addresses and of the Hop Limit field within
      MTU.  On all fragments, it is a balance between the expected
      fluidity and the overhead of MAC and 6LoWPAN headers.  For a small
      MTU, the idea is to keep it close to the maximum, whereas for
      larger MTUs, it might makes sense to keep it short enough, so that
      the duty cycle of the transmitter is bounded, e.g., to transmit at
      least 10 frames per second.

   MaxFragmentSize:  The MaxFragmentSize is the maximum value for the
      Fragment_Size.  It MUST be lower than the minimum MTU along the
      path.  A large value augments the chances of buffer bloat and
      transmission loss.  The value MUST be less than 512 if the unit
      that is defined for the PHY layer is the octet.

   MinWindowSize:  The minimum value of Window_Size that the sender can
      use.

   OptWindowSize:  The OptWindowSize is the value for the Window_Size
      that the sender should use to start with.  It is more than or
      equal to MinWindowSize.  It is less than or equal to
      MaxWindowSize.  The Window_Size should be maintained below the
      number of hops in the path of the fragment to avoid stacking
      fragments at the bottleneck on the path.  If an inter-frame gap is
      used to avoid interference between fragments then the Window_Size
      should be at most in the order of the estimation of the trip time
      divided by the inter-frame gap.

   MaxWindowSize:  The maximum value of Window_Size that the sender can
      use.  The value MUST be less than 32.

   An implementation may perform its estimate of the RTO or use a
   configured one.  The ARQ process is controlled by the following
   parameters:

   MinARQTimeOut:  The maximum amount of time a node should wait for an
      RFRAG Acknowledgment before it takes a next action.

   OptARQTimeOut:  The starting point of the value of the RTO, that is
      amount of time that a sender should wait for an RFRAG
      Acknowledgment before it takes a next action.  It is more than or
      equal to MinARQTimeOut.  It is less than or equal to
      MaxARQTimeOut.

   MaxARQTimeOut:  The maximum amount of time a node should wait for an
      RFRAG Acknowledgment before it takes a next action.  It must cover
      the longest expected round-trip time, and be several times less
      than the time-out that covers the recomposition buffer at the
      receiver, which is typically in the order of the minute.  See
      Appendix C for recommendations on computing the round-trip time.

   MaxFragRetries:  The maximum number of retries for a particular
      fragment.

   MaxDatagramRetries:  The maximum number of retries from scratch for a
      particular datagram.

   An implementation may be capable to perform flow control based on
   ECN, more in Appendix C.  This is controlled by the following
   parameter:

   UseECN:  Indicates whether the sender should react to ECN.  The
      sender may react to ECN by varying the Window_Size between
      MinWindowSize and MaxWindowSize, varying the Fragment_Size between
      MinFragmentSize and MaxFragmentSize and/or by increasing the
      inter-frame gap.


"


> 
> Nits:
> Section 1, 3rd paragraph, typo: "[RFC4944] as no selective recovery and the
> whole datagram fails when" -> "has no"?

Fixed

> 
> Section 7.1: Description of OptFragmentSize refers to MinFragmentSize
> 

Fixed

Again, many thanks Colin. Please let me know if the propose changes work for you.

All the best,

Pascal