Re: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small
Michel Veillette <Michel.Veillette@trilliant.com> Tue, 08 January 2019 19:28 UTC
Return-Path: <Michel.Veillette@trilliant.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 427F8130FC4 for <6lo@ietfa.amsl.com>; Tue, 8 Jan 2019 11:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
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 g8Y08i99m0OO for <6lo@ietfa.amsl.com>; Tue, 8 Jan 2019 11:28:27 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800100.outbound.protection.outlook.com [40.107.80.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0F9130FBD for <6lo@ietf.org>; Tue, 8 Jan 2019 11:28:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CYkHjWMCc862TLhygQ100NoA/gNwXiN9+eGzF0Smlpk=; b=hFpmshhaM29+MJtqqV2N37eAU95fvhaG82gG69iyeYntD7b5R8jFHsFMdzNc+VMHjm0GekdWrbyKjj0XRUeeRQaBoryXwCqAdbgwG0cfQwcHbOVPOwrAkkXYoG2ZEECNhSB2O04ARa1MPq1fAVGM9XEtl2vQOFDQIK/8DN89xWw=
Received: from DM6PR06MB5049.namprd06.prod.outlook.com (20.176.122.224) by DM6PR06MB5547.namprd06.prod.outlook.com (20.178.31.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Tue, 8 Jan 2019 19:28:23 +0000
Received: from DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::54ec:d7d8:7625:42d0]) by DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::54ec:d7d8:7625:42d0%3]) with mapi id 15.20.1495.011; Tue, 8 Jan 2019 19:28:23 +0000
From: Michel Veillette <Michel.Veillette@trilliant.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: draft-ietf-6lo-fragment-recovery maximum fragment size too small
Thread-Index: AdSndZWR57hFJ4urRuKS4TKoalj4mQABM4YAAAC0UuAAAbWVKwAApCxw
Date: Tue, 08 Jan 2019 19:28:23 +0000
Message-ID: <DM6PR06MB50492B36FA25375C52BDDF239A8A0@DM6PR06MB5049.namprd06.prod.outlook.com>
References: <DM6PR06MB5049F52372AE45566A20A6ED9A8A0@DM6PR06MB5049.namprd06.prod.outlook.com> <2637fc068daa40c09fe7927eb1e4f444@XCH-RCD-001.cisco.com>, <DM6PR06MB504964604648C90B3C1AC7A99A8A0@DM6PR06MB5049.namprd06.prod.outlook.com> <9310ACC9-F99D-49BD-9E69-5CE99AD3B968@cisco.com>
In-Reply-To: <9310ACC9-F99D-49BD-9E69-5CE99AD3B968@cisco.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com;
x-originating-ip: [207.96.192.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR06MB5547; 6:zQqvNpQCPIYYvaQbxbh9umwX1vJnc2691ZO6vDDMZAmV68T71I/k3egw+ZCfvCUjw4itLCUe8aOAEU/iYwfsZgqLyGdEJf8iGM0IUGVpmsFY4UAWzj/gFNiodVQbSkNFBOaCr0RcptpmDxPVb34SKNiF58dx+WKk5V2+vbwCeVC3qBHkWTcR6SUn/4OaE9K/ReZsCPkGcBHLrvX4XSoAu/DH+zJL6ahLBq6bd99W6o6P0kcodq4/Wl+DN3BqNGIbH/tesxgYmMRX61S10yRdlLas3+7+gkvqEZmmPT0AhlrLJR1CW/cbK81XarS3LdVF+2HTjy1liFN8qr8+qMsX7Vr0eW5yIp2rm4V/HbbQfmwfEMxqixR5zkY7OvnAcz8u52ABqYX5UL23P9bybCpthDON7WmOa/2Typbc6o9+bGWvBEiDV8qX9c0XeLhimIGtzaOLBoVcn7Glw1nQr33BWw==; 5:RcXueyTZyM3D/Tgk7RjXxQruku4pqDKkm1zeNY2/adTXy+pNPBuXravXUSo4mlrJwXXf+loiaCT7cnwQ6+qi/hkqDgWwfWCYwz/MUCoWSZxOcguleQ4unKSRa/9bQaYmoHPNo80xbDR/etqRvah3uxBjnXJA9dNMAVpR6Bzmu8bsiDE45So0/2HG3RKqGOds7PgiaTeq83vfQmU/ED7AMg==; 7:1ROlpG3R3jANJB7nUEwO8CficL9Cc77fOLFUCzs90FiutIFc3xKuWvs87xLfUHvVe9FQgM932mf01Aa78UgqQWph6G7seao3f3RRti1SoOIUyOCOfrBb9FvNkHcqRIB663GeQJn+Lb5Kxmx3RJZvFA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a162e898-2d86-49be-072e-08d6759f7459
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:DM6PR06MB5547;
x-ms-traffictypediagnostic: DM6PR06MB5547:
x-microsoft-antispam-prvs: <DM6PR06MB5547C0012B60CDFFF09AEB6A9A8A0@DM6PR06MB5547.namprd06.prod.outlook.com>
x-forefront-prvs: 0911D5CE78
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(396003)(136003)(39850400004)(189003)(199004)(53936002)(476003)(7696005)(229853002)(76176011)(66574012)(26005)(102836004)(86362001)(106356001)(25786009)(93886005)(236005)(8936002)(55016002)(6306002)(54896002)(186003)(68736007)(7736002)(9686003)(316002)(4326008)(3846002)(790700001)(6116002)(66066001)(2906002)(33656002)(14444005)(256004)(71200400001)(71190400001)(14454004)(74316002)(478600001)(6916009)(99286004)(486006)(5660300001)(446003)(11346002)(81166006)(606006)(6506007)(81156014)(6436002)(6246003)(53546011)(105586002)(8676002)(561944003)(72206003)(97736004)(160913001)(15963001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR06MB5547; H:DM6PR06MB5049.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nXgbOiPtl0YUY5GN9Q9pj0BxZ0twpDbLXZaV9Dr5J1d+xUcSwM4XT0VdzwUAQV7R0izNVYvp1IlXftEP8wLSZLSHgDSfYlokFA8xlEE3J8TLBB3fAjT+IECWmYTLTmWdyDO7Z5LtKvPTDnZQx3HGw9q6J9O/DJvrkaoAZI7oeLOMZE6VIRSKhAVMMzcKz/va5uICpGx6y/AXDzNRxbIib8CJbJ/XnoeFWD1iGwIaKV7B0+iAP2vNFzKPLf5EPbXB63McR4ibK5LhEScgIJyTGtv8V+hIxiSl9haO7uNc5uwuq2RyvQR2Xy6NCCMxw3Zn
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM6PR06MB50492B36FA25375C52BDDF239A8A0DM6PR06MB5049namp_"
MIME-Version: 1.0
X-OriginatorOrg: Trilliant.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a162e898-2d86-49be-072e-08d6759f7459
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 19:28:23.0651 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5547
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/wB4r8T5GdXksdNS-4siqQ_rW8nk>
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small
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, 08 Jan 2019 19:28:30 -0000
Hi Pascal
A 8 bits "datagram_tag" is a strict minimum in our case and peoples might have good arguments to keep this field aligned with RFC4944.
I also don't see how to implement a 10 bits or 12 bits "datagram_tag" without adding an octet.
I can go either way but my preference are:
- 16 bits datagram_tag
- 10 bits fragment_size
- 16 bits fragment_offset
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0|X| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| sequence| fragment_size | fragment_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
vs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0|X| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| sequence| fragment_size | fragment_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Regards,
Michel
From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Tuesday, January 8, 2019 1:58 PM
To: Michel Veillette <Michel.Veillette@trilliant.com>
Cc: 6lo@ietf.org
Subject: Re: draft-ietf-6lo-fragment-recovery maximum fragment size too small
Hello Michel
Seems to me that reducing the datagram tag to one octet or 12 bits is enough. Do you see a need for so many outstanding fragments?
Regards,
Pascal
Le 8 janv. 2019 à 19:29, Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>> a écrit :
Hi Pascal
The limit of 2K datagram doesn't hurt us, but can effectively hurt others.
I don't things that this draft need to go as far as supporting Jumbogram but should at least support any standard datagrams.
Adding a single byte to the RFRAG Dispatch type will help to get rid of these limitations.
For example:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0|X| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| sequence| fragment_size | fragment_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Regards,
Michel
From: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Sent: Tuesday, January 8, 2019 1:01 PM
To: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>; 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small
Hello Michel
Your proposal is feasible; the datagram space is probably overly large anyway. But it seems to be tailored around your exact problem as opposed to generic.
There are alternates like use a different unit, e.g., 4 bytes words as the existing text suggests. Maybe we could make the unit dependent on the MTU, like 1 byte under 128, 2 bytes till 256, and 4 bytes above that?
It seems that you are not concerned with the overall IP packet size, which is constrained to 2K by the fragment_offset. Maybe we should also look at that?
All the best
Pascal
From: 6lo <6lo-bounces@ietf.org<mailto:6lo-bounces@ietf.org>> On Behalf Of Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small
Hi authors of "draft-ietf-6lo-fragment-recovery"
I'm currently working on a fragment forwarding implementation based on "draft-ietf-6lo-fragment-recovery".
In some cases, relatively large fragments need to be supported (i.e. minimum MTU transferred using 3 fragments).
However, the current format of the RFRAG Dispatch type limits fragment size to only 128 bytes.
Is it possible to modify the RFRAG Dispatch type (https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-00#section-5.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-fragment-recovery-00%23section-5.1&data=02%7C01%7C%7C60a7c908c54c467fa4aa08d6759b2f30%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636825706711728462&sdata=kzQ9tkSD6XYOWlrc0xJv7UYZY%2FW1yXOXRQX%2FibapWvM%3D&reserved=0>)
and corresponding RFRAG Acknowledgment Dispatch type (https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-00#section-5.2<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-fragment-recovery-00%23section-5.2&data=02%7C01%7C%7C60a7c908c54c467fa4aa08d6759b2f30%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636825706711728462&sdata=ruQvsWxO30Ayyd3wRGUE1Vh3X%2Bn3a9JF%2BszAnerGrnE%3D&reserved=0>)
to allow larger fragments?
For example:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0| fragment_size |X|E| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sequence | fragment_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 Y| R | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R = reserved
Regards,
Michel Veillette
- [6lo] draft-ietf-6lo-fragment-recovery maximum fr… Michel Veillette
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Pascal Thubert (pthubert)
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Michel Veillette
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Pascal Thubert (pthubert)
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Michel Veillette
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Pascal Thubert (pthubert)
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Michel Veillette
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Michel Veillette
- Re: [6lo] draft-ietf-6lo-fragment-recovery maximu… Pascal Thubert (pthubert)