Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 20 March 2020 18:25 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 5C3463A0E10; Fri, 20 Mar 2020 11:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=TFxcZBJw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T70Px27f
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 Qr_YadHBO1eI; Fri, 20 Mar 2020 11:25:50 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1190B3A0C4C; Fri, 20 Mar 2020 11:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9036; q=dns/txt; s=iport; t=1584728750; x=1585938350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9xENp0IxZuL47zEAAe8JRoUV7liwJo5VmirN9K2i97Q=; b=TFxcZBJw4iW5lHR6nRM44YmviMyCLHKMI2nxfSA2ISF6edyC2p8Wb+mR A/2HhkuniU9l9Arc9ksirVPOaSSoaCLmtNVUhI3suQo1mbIxs7W+GetZN rsedLrW7sR0oLwgJas6/3IHie4OEABStDEddORyQ9Lt4Dpk9vChwSzWWR o=;
IronPort-PHdr: =?us-ascii?q?9a23=3ANsANbRIVTavvxWaAFNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQD/CXVe/4QNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FUUAVsWCAECyqEGINFA4pwToIRiWqOMoFCgRADVAk?= =?us-ascii?q?BAQEMAQEjCgIEAQGERAIXgg0kOBMCAwEBCwEBBQEBAQIBBQRthVYMhWMBAQE?= =?us-ascii?q?BAxIREQwBASUGDAELBAIBBgIOAwQBAQECAiYCAgIfERUFAwgCBA4FCBqDBYJ?= =?us-ascii?q?LAy4BDpEmkGcCgTmIYnWBMoJ/AQEFgTMCg2MNC4IMAwaBDiqFIIcPGoFBP4E?= =?us-ascii?q?RR4JNPoIbSQICGoEUAQwGAQgbgw8ygiyOK4INO58URAqCPI0qhRiEWYJLiCq?= =?us-ascii?q?MDIRUg1GNCIlskCsCBAIEBQIOAQEFgWkiZ3FwFYMnUBgNjh04gzuFFIVBdAK?= =?us-ascii?q?BJ4sngkIBAQ?=
X-IronPort-AV: E=Sophos;i="5.72,285,1580774400"; d="scan'208";a="735293021"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2020 18:25:48 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 02KIPmj6013914 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Mar 2020 18:25:48 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Mar 2020 13:25:48 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Mar 2020 14:25:47 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 20 Mar 2020 14:25:47 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DBzYg/+t5/L4gJO8F8CnWNHnjEYrqXO/ECtILf7L0fyRJ1TPIxoDS2biE5Tq+/?= =?utf-8?q?YMZaRyiKvstRO+t8dOVfC/dlBJae4bQjvsnyq4ImArRYWsc61maWlwP34MXYPvOtt?= =?utf-8?q?zwy2F9MqpoP4rwVYaVF8a6nNzfEUbhLKYiRVBBplk2cMua6mnZQX5+U+VHkByOEyZ?= =?utf-8?q?77DSqo7C53JkGghvtl1PFPIqFd77qmIpo8xg43e8Loz9zn75xO9FpxXWjBN/Soqfd?= =?utf-8?q?0VkJTjh8IGPmGr53kGqGchssbF2C6yqTbwcvUwlbT82bUfXYDbWZ+/TwoO46x6XYY?= =?utf-8?q?Um4sFY+jraQbtwGlxPCyw=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=3D9xENp0IxZuL47zEAAe8JRoUV7liwJo5VmirN9K2i97Q=3D=3B_b=3DTmWNfq?= =?utf-8?q?11ZuFnGnht5fARR3XAmje6FsulIX/GeUd2OqWVo66RbaVd7SisYb4TNgRyR3/2kS4?= =?utf-8?q?l7NSGrVk3C6wcAz8fAVkiDGLMBslgEDknxONdLa3k+qRxxz360r2hdIrnWq1YkFhp?= =?utf-8?q?7TorD55Pxc/TaCluZPgiBkIDV0s69CAT5OzegMoT+w0NIg7wfDagYoeefj2vDeOHO?= =?utf-8?q?fqqt6zKcWjTRegtpCZmeaUMc/P9CqJEa+vSzZwr/VLOp8JlDfx1ALOuF186Aa5BJR?= =?utf-8?q?iML39tb08cwitK73v+9fHFIY9JNHElovTEuIhiyFH/QPpMCmD6tfK74yGVe+w/luc?= =?utf-8?q?2hEQ+kpC97A=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=3D9xENp0IxZuL47zEAAe8JRoUV7liwJo5VmirN9K2i97Q=3D=3B_b?= =?utf-8?q?=3DT70Px27fy0p0QxRoNamyDSfJsY13aU66te9qut+OPZGV7zFo/C/DpzkudmPNsC?= =?utf-8?q?Fr2ZkzmFfCTerywpswYPFs+UvqooDfeusdTxucs++Fb2AO6MpxGmvp4bD7XE/4AMH?= =?utf-8?q?4QF/2Abf1GukXK2YcmEwhrlhEssVw8tmC+SoPINf2vKc=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4335.namprd11.prod.outlook.com (2603:10b6:208:18d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Fri, 20 Mar 2020 18:25: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; Fri, 20 Mar 2020 18:25:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, The IESG <iesg@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Martin Duke <martin.h.duke@gmail.com>, "Benjamin Kaduk" <kaduk@mit.edu>
Thread-Topic: Mirja =?utf-8?q?K=C3=BChlewind=27s_Discuss_on_draft-ietf-6lo-f?= =?utf-8?q?ragment-recovery-13=3A?= (with DISCUSS and COMMENT)
Thread-Index: =?utf-8?q?AQHV5yxvQMp3kJRXD0SmWqJXtHBMvqg7nFTwgBQ3dgCAABdRMIAA?= =?utf-8?q?cc0AgAAZUYKAATf0AIAAEAyAgAAoqoCAABPskA=3D=3D?=
Date: Fri, 20 Mar 2020 18:25:34 +0000
Deferred-Delivery: Fri, 20 Mar 2020 18:25:29 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB35651B894A5B29455B4033A8D8F50=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB356540107CC4FC7F9CB9F412D8E30=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C7D77F80D-9D2C-4AF7-AB7E-4EDF58A9258A=40kuehlewind=2Enet=3E_=3C?= =?utf-8?q?MN2PR11MB3565C75A4707268047E1F90ED8F40=40MN2PR11MB3565=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= <9823A19B-CA7D-47D1-92FE-8AA436240BD4@kuehlewind.net> <C3771F28-264D-4D0D-9864-D40711EBA0FD@cisco.com> =?utf-8?q?=3CD3F4ECB5-3E1D-48EF-83D9-71F3F14629C4=40kuehlewind=2Enet=3E_=3C?= =?utf-8?q?MN2PR11MB3565B3E9A05CF5D10D125407D8F50=40MN2PR11MB3565=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= <14C773BF-09B3-43A9-893C-8CC8A03E7159@kuehlewind.net>
In-Reply-To: <14C773BF-09B3-43A9-893C-8CC8A03E7159@kuehlewind.net>
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:5d45:efff:9b86:8052]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0155dcad-7218-4a05-f6f8-08d7ccfc1ba1
x-ms-traffictypediagnostic: MN2PR11MB4335:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB4335F7BBA1A95901E34CEF14D8F?= =?utf-8?q?50=40MN2PR11MB4335=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03484C0ABF
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDM0NjAwMikoMzk2MDAzKSgxMzYwMDMpKDM3NjAwMikoMzk4?= =?utf-8?q?60400002=29=28199004=29=2866556008=29=2866446008=29=2864756008=29?= =?utf-8?b?KDY2NDc2MDA3KSg1MjUzNjAxNCkoMjkwNjAwMikoNjY2NjAwNCkoODkzNjAwMiko?= =?utf-8?q?76116006=29=2866946007=29=28478600001=29=2833656002=29=2881156014?= =?utf-8?b?KSgzMTYwMDIpKDU2NjAzMDAwMDIpKDgxMTY2MDA2KSgxODYwMDMpKDIyNDMw?= =?utf-8?q?3003=29=28966005=29=2871200400001=29=2854906003=29=2886362001=29?= =?utf-8?b?KDk2ODYwMDMpKDU1MDE2MDAyKSg2OTE2MDA5KSg0MzI2MDA4KSg2NTA2MDA3KSg1?= =?utf-8?q?3546011=29=287696005=29=2866574012=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4335; 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?HtCcmrsVtKzqGn8JTsYx0srj4C6anIe?= =?utf-8?q?trQiNLjPoTN/UD+WTSn3czVPlmANowMgMQZPuGGOjp+GrddERmp79Q2tkHZ6Ykt9y?= =?utf-8?q?mkWb9MCQOhna1rRQeNs9onD8xnthvg25jibfFxQE52qiiSGz84ZY+LghxCD3SXM5n?= =?utf-8?q?u4kE7DHcZVMKw51L3MMpx2dOFe6P7kaBkNFIE66/I51KsGwdqS6ZEECukGfChNiIe?= =?utf-8?q?b/QnN2JzoJSA80dCa5AMHFuYhDOl7ciXFZEmt/eFh+CSlhATLkP8quw7kNpxrkvcz?= =?utf-8?q?AH0h9WKcRix1ivnkke4pypb9hxs/YC3Div3nU0vHfXJwfZ8+ibq+ckREvsGHmrbMr?= =?utf-8?q?admuk+a52ayz3ik1qNlZfhJjSJWABsI0KWuyEhtERj72Tp3Iyg4MBZPwPc/TRe1K5?= =?utf-8?q?RGaVswBXkCTnCM8hXco0uhuo5b55An5a67eOH8Z3TDFaLEonbqy0E0Jbl+shaBIgZ?= =?utf-8?q?yfNz9TKbxR5u3RaTjtNRyeFTnnfmPvujbyBbEgMQ4UKZAFkg=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?7HkaGI0oQzNna4bUfbmlhRtMr0ptYQ?= =?utf-8?q?yji8jXH+5BbQBOGDaJmajmnLh6cdydkNHeaS/y7hsnowct5z9rhoc9VoFn7N/JPr2?= =?utf-8?q?rW/ntGJpyCZCBBpGLnB24zjrAi8T8qYENR4ep3Lxc5pT3G6HWMlGrkdbHGPOYImQE?= =?utf-8?q?eUP1m3hPXTQKQ5fEFiQ94/cOBLTqeTEUM9nYuA4GSUkCB3E+1HxFQQ=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: 0155dcad-7218-4a05-f6f8-08d7ccfc1ba1
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 18:25:46.1789 (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?T9W/o2e0zVHsdPjO9Assa?= =?utf-8?q?9PNKkIDVhu4vk/E3BxvXe28Ianz0kTJ/DTRFrJn5XwhHt6i0HhgI8rqsof+zs0D3w?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4335
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/B0Q-3qM6aSey_r9ZHFTEOPBDPZs>
Subject: Re: [6lo] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6?= =?utf-8?q?lo-fragment-recovery-13=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Fri, 20 Mar 2020 18:25:55 -0000

Hello Mirja:

I published 20 with this addition.

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-20

I guess we're close to be done by now. In that case, I must thanks you again and deeply.

Be safe,

Pascal



> -----Original Message-----
> From: Mirja Kuehlewind <ietf@kuehlewind.net>
> Sent: vendredi 20 mars 2020 18:12
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: 6lo-chairs@ietf.org; The IESG <iesg@ietf.org>rg>; 6lo@ietf.org; draft-ietf-6lo-
> fragment-recovery@ietf.org; Carles Gomez <carlesgo@entel.upc.edu>du>; Martin
> Duke <martin.h.duke@gmail.com>om>; Benjamin Kaduk <kaduk@mit.edu>
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13:
> (with DISCUSS and COMMENT)
> 
> Hi Pascal,
> 
> The proposed text below and in your previous email look good! Thanks!
> 
> I would appreciate and recommend to add also a shorter version of your good
> explanation below to make the reader better understand which factor is the
> limiting one when using a certain parameter setting and respectively which
> factor could be tuned if any dynamic adaptation is implemented.
> 
> Thanks!
> Mirja
> 
> P.S.: Off for today but will check for an update tomorrow in order to clear my
> discuss!
> 
> 
> 
> > On 20. Mar 2020, at 17:15, Pascal Thubert (pthubert)
> <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> >
> > Hello Mirja
> >
> > I missed this while working on yesterday's message.
> >
> > Let's see below:
> >
> >
> >> Okay! :-)
> >>
> >> About the use of ECN, I agree as you say there should only be a few
> >> fragments and not increasing might be okay. However, you would need
> >> to clarify that the window is reset for each new datagram, I guess, right?
> >
> > Agreed. Let's change appendix C, more below;
> >
> >> Also I don’t think you
> >> necessarily need to reduce to 1 on CE marking but maybe halve the
> >> window or something. Or you leave this open like “If an E flag is
> >> received the window SHOULD be reduced, at least by 1 and at max to 1.
> >> Halving the window for each E flag received, could be a good
> >> compromise but needs further experimentation.”…
> >
> > Thanks for this text! Appendix C now becomes:
> > "
> >   Congestion on the forward path can also be indicated by an Explicit
> >   Congestion Notification (ECN) mechanism.  Though whether and how ECN
> >   [RFC3168] is carried out over the LoWPAN is out of scope, this draft
> >   provides a way for the destination endpoint to echo an ECN indication
> >   back to the fragmenting endpoint in an acknowledgment message as
> >   represented in Figure 4 in Section 5.2.  While the support of echoing
> >   the ECN at the reassembling endpoint is mandatory, this specification
> >   only provides a minimalistic behaviour on the fragmenting endpoint.
> >   If an E flag is received the window SHOULD be reduced, at least by 1
> >   and at max to 1.  Halving the window for each E flag received, could
> >   be a good compromise but needs further experimentation.  A very
> >   simple implementation may just reset the window to 1 so the fragments
> >   are sent and acknowledged one by one.  Note that the action on ECN
> >   only applies till the end of the datagram and the next datagram uses
> >   the configured Window_Size again.
> >
> > "
> >
> > I'd like to fully converge before I publish again
> >
> >> I wonder if it would be good to say a bit more about the recommended
> >> values for the window size, as I think 32 will usually in most
> >> network not limit transmission (and the limiting value will be IFG)
> >> while with a size of 3, that's very conservative to not overload the
> >> network (and will be slow than the limits induced by IFG). Is my
> understanding correct?
> >
> > I'd believe so:
> >
> > Note that the exact use of the ack and the window_size is left to
> implementation. The optimistic one could send all the fragments up to
> window_size and ask for an ack only on the last one, wait for the bitmap, which
> means a gap of RTT/2, and resend the losses.
> > Then again we want to leave room for learning. The pessimistic
> implementation could set the bit on the first fragment to check that the path
> works and open the window only upon receiving the ack. It could then set an
> ack bit again on the second fragment and then use the window as a credit to
> send up to window_size before it is blocked. In that case, if the ack comes back
> before the window starves, the gating factor is the IFG. If the ack does not
> arrive in time, the window_size is the gating factor.
> >
> > If the sender uses the window_size as a credit, the window of 3 will be the
> gating factor that starves the sender and causes gaps longer than IFG as soon
> as you have more than 3 hops in a TSCH network and 5-6 hops in a single
> frequency mesh. I guess that's what you mean by slower. The more hops the
> more it will hurt.
> >
> > I initially used nb_of_hops as a rule of a thumb. That was an approximation of
> RTT/(XMIT+IFG) in the case one fragment needs to progress only to the second
> hop before the next can be sent (case of TSCH).
> >
> > The assumptions behind are that an rfrag_ack takes the same path and the
> same time as the rfrag, which is mostly correct. So if we spread the fragments
> with IFG, keeping busy one hop out of 2 on both directions means aligning the
> window_size of the nb of hops. As you pointed out this is not a congestion
> control measure, it is just the window that is not "slower" than IFG, per your
> expression. The text that uses RTT/(XMIT+IFG) being equivalent I'm happy
> either way. Because knowing the RTT is the same problem as knowing the
> number of hops so we do not need to indicate both.
> >
> > 3 is when you h	ave no idea of either RTT or nb of hops. it is
> conservative and will starve the TSCH sender if we have more than 3 hops. It
> also protects the intermediate node that can be very constrained, to at most 3
> fragments per datagram that it relays. Note that I'm not aware of any full
> duplex radio available in LLNs (though there are prototypes for 5G). So this is
> really a corner case.
> >
> > As written 32 indicates the last fragment of the datagram, which is usually
> way less than 32. When used, as you understood well, the only protection is
> IFG, and I'm must say I'm quite happy with the progress we made on that text
> together.
> >
> > Please let me know, should I change something more?
> >
> > Pascal
> >