Hi Pascal,
Thanks for the clarification.
I agree that offsets in compressed form make more sense, if one
considers RFC 8138.
Regards
Dario
On 1/22/19 2:10 AM, Pascal Thubert (pthubert) wrote:
To your last question Michel, also as an answer to Dario:
I think that the biggest contributor is the source and destination
address, since the source may be elided on the first hop and the
destination may be elided on the last hop. In intermediate hops, the
source and destination (that are global addresses as opposed to your
example) are not mapped on the MAC addresses thus not compressed, at
least statelessly.
Also note vs. your example that I’d use RFC 8138 for the routing
header; the cool thing is that the size can only go down. Else you
need to allow an additional slack as discussed below.
For Dario: the slack is basically done by leaving enough room for both
source and destination to go uncompressed or compressed worst case
(e.g., within a subnet the prefix can be coming from the context all
the way through). Same goes for hlim if it is compressed on the first
hop, which I would not recommend if multihop is expected.
Slack is done by sending a first fragment that that does not fill the
MTU. E.g. if the MTU is 127, and you compressed IID of the source
address based on EUI-64 and the hlim, then build the first fragment as
if the MTU was 118…
Note that a datagram_offset based on the uncompressed form expects
the exact same packet out of the compressor, and that RFC 8138 removes
the consumer routing headers. To Dario’s question this is an exception
to RFC 8200. If we use the offset in the original packet and a
fragment is routed with source routing, we’ll need to reassemble at
each hop, which defeats the purpose.
All the best;
Pascal
*From:* 6lo <[email protected]> *On Behalf Of * Pascal Thubert
(pthubert)
*Sent:* lundi 21 janvier 2019 22:57
*To:* Michel Veillette <[email protected]>
*Cc:* Dario Tedeschi ([email protected]) <[email protected]>; [email protected]
*Subject:* Re: [6lo] draft-ietf-6lo-fragment-recovery compress size
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
<[email protected]
<mailto:[email protected]>> 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) <[email protected]
<mailto:[email protected]>>
*Sent:* Monday, January 21, 2019 6:58 AM
*To:* Michel Veillette <[email protected]
<mailto:[email protected]>>; Dario Tedeschi
([email protected] <mailto:[email protected]>) <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*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 <[email protected]
<mailto:[email protected]>>
*Sent:* jeudi 17 janvier 2019 18:56
*To:* Pascal Thubert (pthubert) <[email protected]
<mailto:[email protected]>>; Dario Tedeschi ([email protected]
<mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*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)' <[email protected]
<mailto:[email protected]>>; Dario Tedeschi ([email protected]
<mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*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) <[email protected]
<mailto:[email protected]>>
*Sent:* Wednesday, January 16, 2019 9:59 AM
*To:* Michel Veillette <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*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 <[email protected]
<mailto:[email protected]>>
*Sent:* mardi 15 janvier 2019 20:14
*To:* Pascal Thubert (pthubert) <[email protected]
<mailto:[email protected]>>
*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 protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
