IETF Logo Mail Archive

Re: [6lo] draft-ietf-6lo-fragment-recovery compress size

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 January 2019 21:57 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 B9840129B88 for <6lo@ietfa.amsl.com>; Mon, 21 Jan 2019 13:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Level:
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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
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 FVxDsaaU77Qy for <6lo@ietfa.amsl.com>; Mon, 21 Jan 2019 13:57:30 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42157128CF2 for <6lo@ietf.org>; Mon, 21 Jan 2019 13:57:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99939; q=dns/txt; s=iport; t=1548107850; x=1549317450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rtphJ5hJB5e1588N6D4jQ0EPTOnsgNw5+O6HDy1js+o=; b=kyg1SV7sLLYM0NmUFk/ruX45whcIwsB0HcSBB/BPDPO+mRTj7RTCDvVD 9tDzRu4zGY68YY3nk2Lo5y7CVs3Xd2Nlvv8IQ1hCvazibc7amE76lwG67 s/BLL6hF5OMQw8STdyPqv5kkjZ0ThrFVpQCCNE3TiSG3HeMRBKJvfXtZB Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADdPkZc/4cNJK1iGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1ILoFoJ4QBiBqNdJgBFIFnCwEBhGwCF4JKIjQJDQEDAQECAQECbSiFSgEBAQEDGgkKTBACAQgRBAEBIQEGAwICAjAUCQgBAQQOBRuDB4EeZKssgS+FQ4RmjEEXgUA/gREnH4JMhE4BCwEFAgEsCR+CUzGCJgKKE4VekVVaCQKSGRiBZoUuiwCadgIRFIEnHzhlcXAVOyoBgkGCJAMXjh5BMYg9ASWCJwEB
X-IronPort-AV: E=Sophos;i="5.56,504,1539648000"; d="scan'208,217";a="229235004"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2019 21:57:29 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x0LLvS5F002940 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Jan 2019 21:57:28 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 21 Jan 2019 15:57:27 -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; Mon, 21 Jan 2019 15:57:28 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michel Veillette <Michel.Veillette@trilliant.com>
CC: "Dario Tedeschi (dat@exegin.com)" <dat@exegin.com>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: draft-ietf-6lo-fragment-recovery compress size
Thread-Index: AdSxzQ/YxG3Oo2dISXelLjiMPJ6AeAABzzw8
Date: Mon, 21 Jan 2019 21:57:28 +0000
Message-ID: <43C57D1B-FA83-4ED3-9A35-457DB7820867@cisco.com>
References: <BL0PR06MB5042B4BCE08B031015E26F6E9A9F0@BL0PR06MB5042.namprd06.prod.outlook.com>
In-Reply-To: <BL0PR06MB5042B4BCE08B031015E26F6E9A9F0@BL0PR06MB5042.namprd06.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_43C57D1BFA834ED39A35457DB7820867ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/470z_3E566b9zKJgV0qvVIFmtL8>
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery compress size
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: Mon, 21 Jan 2019 21:57:34 -0000

Hello Michel

I already answered that today, actually: )

There is no such assumption but the node that changes the size also needs to change the offset on all fragments.

The expectation is that only the first fragment may change. The delta offset that happens on the first fragment must be applied on all further fragments on both length and offset fields as an additive or substractive constant. I need to write that clearly.

Now if you prefer to go back to using offsets in the uncompressed form please let us know by answering my earlier mail today : )

All the best

Pascal

Le 21 janv. 2019 à 22:43, Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>> a écrit :

Hi Pascal

Draft "draft-ietf-6lo-fragment-recovery" seem to assume that the size of the compressed header stay fix while traveling the RPL domain.

For example:
  "In this specification, the size and offset of the fragments are expressed on the compressed packet."
 "The last fragment for a datagram is recognized when its fragment_offset and its fragment_size add up to the datagram_size."

However, fields HLIM [RFC6282], CmprI and CmprE [RFC6554] may have an impact on the compressed header size if the maximum compression is applied at each hop.

Is this problem addressed in the draft?
Are you aware of other IPv6 fields or options which can cause this issue?
How this issue should be addressed?

I tried to illustrate this problem in the example bellow:

IPv6 packet
  - IPv6 packet header
    - Hop limit = 66 (elided)
    - Source Address      = FE80 0000 0000 0000 0201 4200 0000 0000 (elided)
    - Destination Address = FE80 0000 0000 0000 0214 7700 0000 0001 (elided)
  - RPL routing header
    - CmprI = 15
    - CmprE = 9
    - Addresses = FE80 0000 0000 0000 0214 7700 0000 0002, FE80 0000 0000 0000 0214 7700 0000 0003, FE80 0000 0000 0000 0200 0C00 0000 0004

IPv6 packet
  - IPv6 packet header
    - Hop limit = 65 (elided)
    - Source Address      = FE80 0000 0000 0000 0201 4200 0000 0000 (elided)
    - Destination Address = FE80 0000 0000 0000 0214 7700 0000 0002 (elided)
  - RPL routing header
    - CmprI = 15
    - CmprE = 9
    - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80 0000 0000 0000 0214 7700 1234 0003, FE80 0000 0000 0000 0201 42AB CDEF 0004

IPv6 packet
  - IPv6 packet header
    - Hop limit = 64 (in line)
    - Source Address      = FE80 0000 0000 0000 0201 4200 0000 0000 (elided)
    - Destination Address = FE80 0000 0000 0000 0214 7700 0000 0003 (elided)
  - RPL routing header
    - CmprI = 9
    - CmprE = 9
    - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80 0000 0000 0000 0214 7700 0000 0002, FE80 0000 0000 0000 0201 42AB CDEF 0004

IPv6 packet
  - IPv6 packet header
    - Hop limit = 63 (elided)
    - Source Address      = FE80 0000 0000 0000 0201 4200 0000 0000 (elided)
    - Destination Address = FE80 0000 0000 0000 0200 0C00 0000 0004 (elided)
  - RPL routing header
    - CmprI = 9
    - CmprE = 9
    - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80 0000 0000 0000 0214 7700 0000 0002, FE80 0000 0000 0000 0214 7700 0000 0003

Regards,
Michel


From: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Sent: Monday, January 21, 2019 6:58 AM
To: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>; Dario Tedeschi (dat@exegin.com<mailto:dat@exegin.com>) <dat@exegin.com<mailto:dat@exegin.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Works for me Michel :

So we need answers from the list. The choice on the table is either to reduce the datagram_tag field to 256 as illustrated below or to use a 4 bytes unit for links with large MTUs (more than 127 octets).

What do people think is more appropriate to their needs?

Pascal

From: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>
Sent: jeudi 17 janvier 2019 18:56
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Dario Tedeschi (dat@exegin.com<mailto:dat@exegin.com>) <dat@exegin.com<mailto:dat@exegin.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hi Pascal

I'm sorry, the propose format in my last email doesn't fix the datagram total length limitation.
32 fragments of 512 bytes still limit the datagram to 16 kB.

Based on the following constraints:

  *   Up to 256 active datagram
  *   Up to 32 fragments
  *   Up to  64kB datagram
  *   Up to 2kB fragment (32 fragments of 2 kB = 64 kB datagram)

I recommend the following Dispatch type formats.

Alternatively, the original format with a 4 bytes unit will work for us but doesn't seem to address all potential issues.

                           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: Michel Veillette
Sent: Wednesday, January 16, 2019 9:04 PM
To: 'Pascal Thubert (pthubert)' <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Dario Tedeschi (dat@exegin.com<mailto:dat@exegin.com>) <dat@exegin.com<mailto:dat@exegin.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

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<mailto:pthubert@cisco.com>>
Sent: Wednesday, January 16, 2019 9:59 AM
To: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>
Cc: 6lo@ietf.org<mailto: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