IETF Logo Mail Archive

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

Michel Veillette <Michel.Veillette@trilliant.com> Thu, 17 January 2019 02:04 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 7474D126CB6 for <6lo@ietfa.amsl.com>; Wed, 16 Jan 2019 18:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 F4iTKY7-Y3iy for <6lo@ietfa.amsl.com>; Wed, 16 Jan 2019 18:04:12 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770130.outbound.protection.outlook.com [40.107.77.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8932F12D4EA for <6lo@ietf.org>; Wed, 16 Jan 2019 18:04:12 -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=LrberZGjCemDbShvLdTQrjpaXGEkxI2QuU3NpUY226Y=; b=sVYDr70hhaHqQpG4RraBBSHTzdC4EwybW2yCYHvgBnz195Jad9emDB86VsKD5p6ij0Tgjw2NOwzIQNPkY3mqdpHhrmSe8SiBaSjy21nIDhEyL7Eoo4KKwg2MhZ8dtI1apW6lrByXYLcACMgyqBaRfyU4+aYn5Cy5Jq5s2ybEBB0=
Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4292.namprd06.prod.outlook.com (10.167.179.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Thu, 17 Jan 2019 02:04:09 +0000
Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::2dfb:7cf6:d7f0:25ad]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::2dfb:7cf6:d7f0:25ad%4]) with mapi id 15.20.1537.018; Thu, 17 Jan 2019 02:04:09 +0000
From: Michel Veillette <Michel.Veillette@trilliant.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Dario Tedeschi (dat@exegin.com)" <dat@exegin.com>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: draft-ietf-6lo-fragment-recovery maximum fragment size too small
Thread-Index: AdSndZWR57hFJ4urRuKS4TKoalj4mQABM4YAAAC0UuAAAbWVKwAApCxwAGWIdsABIykngAAXQR4Q
Date: Thu, 17 Jan 2019 02:04:09 +0000
Message-ID: <BL0PR06MB50425B993E8D3521D82C04CC9A830@BL0PR06MB5042.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> <DM6PR06MB50492B36FA25375C52BDDF239A8A0@DM6PR06MB5049.namprd06.prod.outlook.com> <BYAPR06MB50464D18F2D79E4EAF1EB9979A810@BYAPR06MB5046.namprd06.prod.outlook.com> <48f5ac04c1c94585aa3b540c078b8a5a@XCH-RCD-001.cisco.com>
In-Reply-To: <48f5ac04c1c94585aa3b540c078b8a5a@XCH-RCD-001.cisco.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [184.162.192.248]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR06MB4292; 6:FCQMUnoQ0GkihNNebjpH4TkWzRRMXX55oGIJMAXNjLSLCyKp/x1i1rRVXp51YmA2QCmYlzhq8ZvkNSHrHuih8zrUTsuIpVCBLLGdDpscdP++Sfty5x/wLTEyyXtpjMu8CL/W4IVyuJEUWSgapcl9lP3SPdClOyJ5oQBxtwMqRdbFS3zFbf0O8jIZpcDVMLhXpFdiKsQxdddlloXT0mZPmzL+cnCbb5r1fz+vIFJ4GXOnWwhm7FR5V/kIwjm15GliAe1thsOH8BGKREf7BQbNp2oNcmck6nTMkuszR3ZzljrdB2YNN0XbaszNlYYblFWWwn7zeYTPJyXNo8jjy79I1mHhu+xkQY1SJX8rSeDQcQKN2w9hZRJijMi5COXJtMmkc4U1civgVHrPU+CNYXHczW4rRu9JnU+gOKs3ITi1wO1dSs+p4HgTItlRXKCYb24I8teK7la481G1jhEl0V5EFw==; 5:vCxQOfbLeyo4Y4/dztRRZTmMGNpxeqvJNS5TRqB3lvqmjdwtRfT/fW4iygE3KZd1G3qiMj+r/R0q6AxOl/zhmyMSVXYy/zDCZV2H+XVzpgV+O2+L6Cc385hAO5q2UdUYfyr5epSOGopr46nYnkcr4/tddBw4V+mTvay1e9Epas2wwZwjruJuDlwVyMY1ygwyeAoUOj2t98QnNZQRgsg9YA==; 7:x3sixAMGzZQWMN3q352YEbHm3cpflyEQ7OYGxY6dwBKZaWfot8DLt1nTdoO05gTb5khfj+2wU5Exq8g563/DzoPsmXGPwl/aoAIdmmXiGolSDIEY8Pq8opmDfXTIduyH/Pb6xa4op5AtPdgpoZkjtw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9d1c74bd-e36b-48c3-374b-08d67c2011c0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4292;
x-ms-traffictypediagnostic: BL0PR06MB4292:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com;
x-microsoft-antispam-prvs: <BL0PR06MB4292318208CB497B87F3F5BE9A830@BL0PR06MB4292.namprd06.prod.outlook.com>
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(376002)(136003)(39850400004)(199004)(189003)(6506007)(97736004)(3846002)(6116002)(86362001)(25786009)(4326008)(6436002)(102836004)(33656002)(76176011)(316002)(68736007)(5660300001)(7696005)(561944003)(53946003)(53546011)(790700001)(256004)(55016002)(53936002)(6246003)(74316002)(66066001)(236005)(9686003)(54896002)(6306002)(478600001)(71190400001)(71200400001)(229853002)(186003)(26005)(446003)(106356001)(81156014)(81166006)(8676002)(8936002)(105586002)(14454004)(99286004)(7736002)(486006)(72206003)(476003)(2906002)(93886005)(11346002)(110136005)(160913001)(15963001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4292; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: DtwxPOoym5T5F62NgJzxS1CDBA8NFgQWFRG+f+NPP3S+ANroW9l3L6wE39YjcBHCplfbExSf+0zgiraxJCK4QnEJJUvbA5rL5THmqAwzuSWcd1iqjmcBTXCjdnhT67+/XuHp6OgB485xbrfZB5fbbZRdqsF2yNBNnrCEPHE+YFvQAbAjApdH4m1otK6Pp1pejyhsY4ZldM+gZ0IirS15yyN/meep/1FK5Mr5AP8gSUE+NguDDtoEuf0/WIpT9HnIv0aLlOt1HsmHnLrMX8KJPtdC/9WbEi/dixbta/Y3RgwCpTn8B2QBJJvec5GnQc4wVuYvnwU95Lt5mSjhPdbK/tDiN6ICfsLfNiSVKxzjgq3SttvOlAQUvnA3vA8l2RHTebmJMdr+ka5d7QnmsL1h81gICphpGOH8gq62PHGv0lI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB50425B993E8D3521D82C04CC9A830BL0PR06MB5042namp_"
MIME-Version: 1.0
X-OriginatorOrg: Trilliant.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1c74bd-e36b-48c3-374b-08d67c2011c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2019 02:04:09.5923 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4292
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/R6Zox0rcuXzgq2xax6OcFSSZwbM>
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: Thu, 17 Jan 2019 02:04:17 -0000

Using a 4 bytes unit for size and offset doesn't seem to fully solve all issues, this solution is still limited to 8 kB datagram.
About the dual formats proposal, I'm not convinced this problem is such we can't find a single format acceptable for everyone.
If maintaining an overhead of 6 bytes is a must, the solution below might be the best compromise.

                           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| sequence|  datagram_tag   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         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 0|Y| Reserved  |  datagram_tag   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |          RFRAG Acknowledgment Bitmap (32 bits)                |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards,
Michel


From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Wednesday, January 16, 2019 9:59 AM
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

I have not seen a strong argument against saying that the unit for size and offset is 4 bytes if the MTU is larger than 127 bytes. This keeps classical 802.15.4 with 1 octet and allows fragments of 512 with 802.15.4g. that would be the simplest and most economical way of doing it. The only issue is that the last fragment might be less than the fragment_size, but that can be found based on the frame size. This seems to be the best tradeoff to me.

As an alternate we could define both of the formats that you copied below, one as 1 1 1 0 1 0  and the other as 1 1 1 0 1 1 as follows:


                           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 1 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 1 1 Y|         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          RFRAG Acknowledgment Bitmap (32 bits)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


what do you think?

Pascal



From: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>
Sent: mardi 15 janvier 2019 20:14
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hi Pascal

Did we reach any consensus about the RFRAG Dispatch type format?
See the last two formats proposed bellow.

Regards,
Michel

From: Michel Veillette
Sent: Tuesday, January 8, 2019 2:28 PM
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

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

v2.23.0 | Report a Bug | By Email