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

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Jan 2019 17:38:15 +0000

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jan 2019 18:00:31 +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 <[email-masked]> On Behalf Of Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: [email-masked]
Subject: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small

For example:

                           1                   2                   3

                           1                   2                   3

R = reserved

Regards,
Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Jan 2019 18:29:20 +0000

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
                      |1 1 1 0 1 0 1 Y|         datagram_tag          |

Regards,
Michel

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Tuesday, January 8, 2019 1:01 PM
To: Michel Veillette <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hello Michel

All the best

Pascal

From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: [email-masked]<mailto:[email-masked]>
Subject: [6lo] draft-ietf-6lo-fragment-recovery maximum fragment size too small

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%7C12cb3a341d5e45a5b05308d67593338f%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636825672601917911&sdata=CNsPQhDxOFFzB7zOCgfDxZXeZjdoerKCmezSouL0EOE%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%7C12cb3a341d5e45a5b05308d67593338f%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636825672601917911&sdata=%2FPLtWrX8XdGvLHacKuSRb%2FMfIcxE%2BXV%2BCMFg2CNhTHc%3D&reserved=0>)
to allow larger fragments?

For example:

                           1                   2                   3

                           1                   2                   3

R = reserved

Regards,
Michel Veillette

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jan 2019 18:57:46 +0000

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 <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal

For example:

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 8, 2019 1:01 PM
To: Michel Veillette <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hello Michel

All the best

Pascal

For example:

                           1                   2                   3

                           1                   2                   3

R = reserved

Regards,
Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Tue, 8 Jan 2019 19:28:23 +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

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Tuesday, January 8, 2019 1:58 PM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hello Michel

Regards,

Pascal

For example:

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

Hello Michel

All the best

Pascal

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

                           1                   2                   3

R = reserved

Regards,
Michel Veillette

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Jan 2019 14:59:21 +0000

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

                           1                   2                   3

vs.

                           1                   2                   3
                      |1 1 1 0 1 1 0|X|         datagram_tag          |

                           1                   2                   3
                      |1 1 1 0 1 1 1 Y|         datagram_tag          |

what do you think?

Pascal

From: Michel Veillette <[email-masked]>
Sent: mardi 15 janvier 2019 20:14
To: Pascal Thubert (pthubert) <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hi Pascal

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

---

From: Michel Veillette <[email-masked]>
Date: Thu, 17 Jan 2019 02:04:09 +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

                      |1 1 1 0 1 0 1 0|Y| Reserved  |  datagram_tag   |

Regards,
Michel

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Wednesday, January 16, 2019 9:59 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hello Michel

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

what do you think?

Pascal

From: Michel Veillette <[email-masked]<mailto:[email-masked]>>
Sent: mardi 15 janvier 2019 20:14
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hi Pascal

Regards,
Michel

From: Michel Veillette

Hi Pascal

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

---

From: Michel Veillette <[email-masked]>
Date: Thu, 17 Jan 2019 17:55:31 +0000

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

                           1                   2                   3

Regards,
Michel

From: Michel Veillette
Sent: Wednesday, January 16, 2019 9:04 PM
To: 'Pascal Thubert (pthubert)' <[email-masked]>; Dario Tedeschi ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

To: Michel Veillette <[email-masked]<mailto:[email-masked]>>

Hello Michel

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

what do you think?

Pascal

Hi Pascal

Regards,
Michel

From: Michel Veillette

Hi Pascal

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jan 2019 11:57:57 +0000

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 <[email-masked]>
Sent: jeudi 17 janvier 2019 18:56
To: Pascal Thubert (pthubert) <[email-masked]>; Dario Tedeschi ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

Hi Pascal

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

From: Michel Veillette
Sent: Wednesday, January 16, 2019 9:04 PM
To: 'Pascal Thubert (pthubert)' <[email-masked]<mailto:[email-masked]>>; Dario Tedeschi ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small

                           1                   2                   3

                           1                   2                   3

Regards,
Michel

Hello Michel

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

what do you think?

Pascal

Hi Pascal

Regards,
Michel

From: Michel Veillette

Hi Pascal

                           1                   2                   3

                           1                   2                   3

vs.

                           1                   2                   3

                           1                   2                   3

Regards,
Michel