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
From: Pascal Thubert (pthubert) <[email protected]>
Sent: Tuesday, January 8, 2019 1:58 PM
To: Michel Veillette <[email protected]>
Cc: [email protected]
Subject: Re: draft-ietf-6lo-fragment-recovery maximum fragment size too small
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 protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>>
Sent: Tuesday, January 8, 2019 1:01 PM
To: Michel Veillette
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>> On Behalf Of
Michel Veillette
Sent: mardi 8 janvier 2019 18:38
To: [email protected]<mailto:[email protected]>
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%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
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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
