[6lo] recoverable fragments: should we adapt the fragment size to ECN?
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 21 May 2019 13:05 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 AB32B120144 for <6lo@ietfa.amsl.com>; Tue, 21 May 2019 06:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=C3naaveZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T1POrT3B
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 Uf-pTUyFtuZw for <6lo@ietfa.amsl.com>; Tue, 21 May 2019 06:05:50 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE6F120118 for <6lo@ietf.org>; Tue, 21 May 2019 06:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4245; q=dns/txt; s=iport; t=1558443950; x=1559653550; h=from:to:subject:date:message-id:mime-version; bh=dmMAquotilYVdCm32lpx8BzDxP9+Zi7LZ8qh0U8AuBU=; b=C3naaveZOIeUzfLiVNSNrJCsFDLKKGN5QELPREWO0/iNSR6BZpfacWl8 O/QI+KQNPBuA5yrYhYM+tlSC4fziQ3zItngpnDS47D3cvAuAL7Tj3nS3g VOlMvRaC51MKrjybYzyZjE+H/abac+uhkNJG0RIlfxE8RRiNAnxtED7dx E=;
IronPort-PHdr: 9a23:UaTtlRHXXVAfh91lIEk0d51GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DrAAAC9+Nc/4sNJK1lHQEBBQEHBQGBUwYBCwGBDi9QA2lVIAQLKIdaA450kjOCfYROgS4UgRADVAkBAQEMAQEtAgEBhEACgiYjNgcOAQMBAQQBAQIBBG0cDIVjGxMBATgRAQx0JgEEARoagwGBHU0DHQECm1gCgTWIX4IggnkBAQWFBhiCDwmBNAGLUBeBQD+BV4JMPoQMOoM6giaSWJVPCQKCDYpvgX+GLZYsjFaVSAIEAgQFAg4BAQWBVgIvgVdwFYMngg8MF4NMilNygSmNEwEB
X-IronPort-AV: E=Sophos;i="5.60,495,1549929600"; d="scan'208,217";a="562240887"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 May 2019 13:05:48 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4LD5mAa008246 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2019 13:05:48 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 08:05:47 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 08:05:46 -0500
Received: from NAM04-BN3-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; Tue, 21 May 2019 09:05:46 -0400
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=KIldPfZoS3Y9reMdX10nE3HRpKIO3YTiLezWazLpgyo=; b=T1POrT3Bk2TtZnwAKaf16g//RC76Ld2UixR9rXMMO0sKVRfsFHTlGW96kF1vn3EQRbdJYBYqgZp59Em70gyDgVImuSgjXxbg90qSMUifUqJil9D8FwA8pjcNBfHzZYi/nqNztGpJPJhcJToBZ5NioZq+zdK8+JDYKzeHSTVBjaw=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3757.namprd11.prod.outlook.com (20.178.253.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.17; Tue, 21 May 2019 13:05:46 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1900.020; Tue, 21 May 2019 13:05:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6lo@ietf.org" <6lo@ietf.org>, Laurent Toutain <laurent.toutain@imt-atlantique.fr>
Thread-Topic: recoverable fragments: should we adapt the fragment size to ECN?
Thread-Index: AdUO3DwC5kjlMWRXRmiFCmgkOgERBA==
Date: Tue, 21 May 2019 13:05:33 +0000
Deferred-Delivery: Tue, 21 May 2019 13:05:27 +0000
Message-ID: <MN2PR11MB356527AB2145A9416CE536C2D8070@MN2PR11MB3565.namprd11.prod.outlook.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: [2001:420:44f3:1300:552f:ff32:b86:aad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 812a406f-28a0-4ca3-53b1-08d6dded09d9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3757;
x-ms-traffictypediagnostic: MN2PR11MB3757:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB37572686FBDFFD35CC831E34D8070@MN2PR11MB3757.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(39860400002)(346002)(136003)(199004)(189003)(64756008)(76116006)(73956011)(66946007)(66446008)(66476007)(66556008)(46003)(7696005)(316002)(2906002)(110136005)(99286004)(71200400001)(71190400001)(186003)(6506007)(6116002)(256004)(33656002)(790700001)(6666004)(102836004)(74316002)(14444005)(478600001)(4744005)(68736007)(7736002)(52536014)(5660300002)(14454004)(9686003)(81166006)(486006)(54896002)(6306002)(25786009)(8676002)(8936002)(476003)(53936002)(6436002)(55016002)(2501003)(86362001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3757; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: zJsCmBQJsiUsAjh5hqw3FcPsqM+DQfpXGYM36QYLtPcKV4M4BUyB83CXoU+CWJnjmcI+yttsXWTazdw4hE2W8ydzi+utyH7s1Bweo6i8279ERG80jW+L6s9leOo2qGMtGecw0aWXt0VjNabv403VaaMQTcI3f7Q7Pe+gibSiQJvv57yqOIoJ/XJSTNKUIK9irsIXyXitMo1MSUFQjDw1ud4OiAVYHQDzlHjcBeSxxU3inox3bNkVPsxhoSK2p0EL+KR/KeqkI+d16eooh/pqDQOFWtKi5G+NEHKU2STMc69Ct1ajSUFs28uIUbgMyP1pB1a/WXH7fDDZSw/e8cBJMflYoxb9YFqvziSs1o4NIdHqVkMi7ggH9M3bpq0MfmSaXwhJx+I7EiwWL+Vle+/FnSRqy1zMeKmV6cXN/i767JQ=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356527AB2145A9416CE536C2D8070MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 812a406f-28a0-4ca3-53b1-08d6dded09d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 13:05:45.9870 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3757
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/gNyNJSqT4nMNNgvMpNxV1gU2Oi8>
Subject: [6lo] recoverable fragments: should we adapt the fragment size to ECN?
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: Tue, 21 May 2019 13:05:52 -0000
Dear all: During the review by Laurent, a question came up on we could change the fragment size when transmitting a datagram. As it goes we can, because the offset and size are indicated in each fragment. If the MTU goes down and a fragment must be resend, we can also resend a smaller piece with the original fragment sequence and send other fragments with unused sequences for the rest of the original fragment. This is made possible because the sequence is sequential in the bitmap but not in the order of fragments. That being said, a reaction to an ECN is to reduce the window. At the same time a node could also reduce the datagram size and enable a more streamlined transmission for all. What do you all think? Pascal
- [6lo] recoverable fragments: should we adapt the … Pascal Thubert (pthubert)
- Re: [6lo] recoverable fragments: should we adapt … Abdussalam Baryun