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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 8, 2019 1:01 PM
To: Michel Veillette <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: [e-mail]<mailto:[e-mail]>
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%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
       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