Re: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 08 January 2019 18:00 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 5D32B130F4C for <6lo@ietfa.amsl.com>; Tue, 8 Jan 2019 10:00:43 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, 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, 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
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 K2SfQivZ4yHg for <6lo@ietfa.amsl.com>; Tue, 8 Jan 2019 10:00:41 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89F0130F46 for <6lo@ietf.org>; Tue, 8 Jan 2019 10:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15305; q=dns/txt; s=iport; t=1546970440; x=1548180040; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MUVShM6NcbN90lYpXbPdUxdKbegzz78IR31vFjcO7BY=; b=SJOILX4ks9OK/pk9Xfu7N84V0MuJ7H1B4SsdMOEfKG/J6CAxSycObEml ms6uGYyp3wiWaoQVlgsIpCiYKg9H/X/HPxc8niiL12snUVLPVX4Hdczpm KM0SbGHSmc/Yda1BQm5t4OSPmpMaawaA2hIiSmk8aCoZzrcEbs+mlQpIk 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADl4zRc/5NdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1ILmaBAicKjBCLbIINkg6FYoF7CwEBJYRHAoISIjQJDQEDAQECAQECbRwMhUoBAQEELVwCAQgRBAEBLzIdCAEBBAEJCQiDG4EdZA+pYIorBYw/F4FAP4Qjgx4BAQIBhz0Cj1SROVoJAocWilggkXWJaoUIizUCERSBJx84gVZwFYMngiQaiF+FP0ExAYl4gR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,455,1539648000"; d="scan'208,217";a="503300484"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 18:00:39 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x08I0dtO009615 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Jan 2019 18:00:39 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 8 Jan 2019 12:00:38 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Tue, 8 Jan 2019 12:00:38 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michel Veillette <Michel.Veillette@trilliant.com>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: draft-ietf-6lo-fragment-recovery maximum fragment size too small
Thread-Index: AdSndZWR57hFJ4urRuKS4TKoalj4mQABM4YA
Date: Tue, 08 Jan 2019 18:00:31 +0000
Deferred-Delivery: Tue, 8 Jan 2019 18:00:24 +0000
Message-ID: <2637fc068daa40c09fe7927eb1e4f444@XCH-RCD-001.cisco.com>
References: <DM6PR06MB5049F52372AE45566A20A6ED9A8A0@DM6PR06MB5049.namprd06.prod.outlook.com>
In-Reply-To: <DM6PR06MB5049F52372AE45566A20A6ED9A8A0@DM6PR06MB5049.namprd06.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.4]
Content-Type: multipart/alternative; boundary="_000_2637fc068daa40c09fe7927eb1e4f444XCHRCD001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/80FhSe40z-U7WcvQooRm6itnF1M>
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 18:00:43 -0000

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> On Behalf Of Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: 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)
and corresponding RFRAG Acknowledgment Dispatch type (https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-00#section-5.2)
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