Subject: [6lo] draft-ietf-6lo-fragment-recovery: fragment_offset

From: Dario Tedeschi <[email-masked]>
Date: Fri, 18 Jan 2019 14:33:30 -0800

After considering how one might go about implementing 
draft-ietf-6lo-fragment-recover, I came across a problem with the 
fragment_offset field.

Since the value in the fragment_offset field is based on the compressed 
version of a datagram, this field would potentially need to change for 
all fragments of a single datagram as it traverses the network.

Consider a datagram of length L{D}. On the first hop the datagram is 
compressed and fragmented into 2 fragments A and B with lengths L{A} and 
L{B} respectively. The total length of the "compressed datagram" C is 
therefore L{A} + L{B} = L{C}. It is also true therefore that the offset 
of fragment B within the compressed frame is Offset{B} = L{A}

Assuming the datagram is being forwarded, the next hop would likely need 
to re-compress the first fragment (because the link-layer addresses in 
the 15.4 packet would change). In turn L{A} would also likely change to 
L{A`}. This means that the frame_offset value in the second fragment 
would no longer be correct, since Offset{B} != L{A`}.

As I see it, this problem makes the current draft unusable, because the 
originator of the 6LoWPAN fragments can't allow for slack in the first 
fragment to accommodate for re-compression changes at each subsequent hop.

In RFC4944, the datagram offsets were based on the uncompressed 
datagram. This gave us two advantages:

 1. The receiver of any fragment would immediately know what buffer size
    to allocate to store the entire uncompressed datagram
 2. The originator of the 6LoWPAN fragments would by default provide
    slack in the first fragment for subsequent hops, because the offsets
    of fragments were based on the uncompressed datagram.

Could the RFRAG format  be changed so that fragment_offset be based on 
the uncompressed datagram (similar to RFC 4944) or have I misunderstood 
the draft?

Regards
Dario Tedeschi

---

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

Hello Dario :

his change was done long, long ago as a usability improvement. I have to refresh my mind on why people wanted it, but I remember they complained.
I’m open to roll back on that if implementers prefer.

For your question: the forwarder that modifies the fragment size would have to modify the datagram_size and _offset on this and all subsequent packets.
It is doable since the node needs to do that only on the first fragment and it has a state for forwarding where the update can be stored. I should add words on that.

Note that this problem is a bit different from the slack that is still needed in the first fragment to be able to play games with its size on the path even if the offset is in the uncompressed packet.

What do people think?

Pascal

From: 6lo <[email-masked]> On Behalf Of Dario Tedeschi
Sent: vendredi 18 janvier 2019 23:34
To: [email-masked]
Subject: [6lo] draft-ietf-6lo-fragment-recovery: fragment_offset

After considering how one might go about implementing draft-ietf-6lo-fragment-recover, I came across a problem with the fragment_offset field.

Since the value in the fragment_offset field is based on the compressed version of a datagram, this field would potentially need to change for all fragments of a single datagram as it traverses the network.

Consider a datagram of length L{D}. On the first hop the datagram is compressed and fragmented into 2 fragments A and B with lengths L{A} and L{B} respectively. The total length of the "compressed datagram" C is therefore L{A} + L{B} = L{C}. It is also true therefore that the offset of fragment B within the compressed frame is Offset{B} = L{A}

Assuming the datagram is being forwarded, the next hop would likely need to re-compress the first fragment (because the link-layer addresses in the 15.4 packet would change). In turn L{A} would also likely change to L{A`}. This means that the frame_offset value in the second fragment would no longer be correct, since Offset{B} != L{A`}.

As I see it, this problem makes the current draft unusable, because the originator of the 6LoWPAN fragments can't allow for slack in the first fragment to accommodate for re-compression changes at each subsequent hop.

In RFC4944, the datagram offsets were based on the uncompressed datagram. This gave us two advantages:

  1.  The receiver of any fragment would immediately know what buffer size to allocate to store the entire uncompressed datagram
  2.  The originator of the 6LoWPAN fragments would by default provide slack in the first fragment for subsequent hops, because the offsets of fragments were based on the uncompressed datagram.

Could the RFRAG format  be changed so that fragment_offset be based on the uncompressed datagram (similar to RFC 4944) or have I misunderstood the draft?

Regards
Dario Tedeschi

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 21 Jan 2019 17:59:06 -0800

Hi Pascal,

Thanks for the quick response.

So yes one could store more state in the VRB, in the form of an "offset 
adjustment" value for the next hop, but this seems overly complex and 
susceptible to failure and requires more memory.

Using the current draft, I don't know how one can provide "slack" in the 
first fragment, without potentially causing a gap in the uncompressed 
data at the final hop. How would this work?

Using the datagram size on which to base fragment offsets actually helps 
in providing this "slack", because it allows the compressed version of 
the first fragment to change in length without affecting the offsets of 
subsequent fragments. The compressed length of the fragment is allowed 
to change without affecting the uncompressed length of the fragment, 
which in turn means that the subsequent fragment's offset does not 
change. The source of the datagram only need choose the 2nd fragment 
offset such that it covers the compressible portion of the datagram 
(i.e. the IP header, Extension headers and UDP header).

I'm assuming that the datagram should not change length as it traverses 
the network, since RFC 8200 says that Extension headers cannot be 
inserted or deleted along a delivery path. Would you agree?

Regards
Dario

On 1/21/19 3:51 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Dario :
>
> his change was done long, long ago as a usability improvement. I have 
> to refresh my mind on why people wanted it, but I remember they 
> complained.
>
> For your question: the forwarder that modifies the fragment size would 
> have to modify the datagram_size and _offset on this and all 
> subsequent packets.
>
> It is doable since the node needs to do that only on the first 
> fragment and it has a state for forwarding where the update can be 
> stored. I should add words on that.
>
> Note that this problem is a bit different from the slack that is still 
> needed in the first fragment to be able to play games with its size on 
> the path even if the offset is in the uncompressed packet.
>
> What do people think?
>
> Pascal
>
> *From:*6lo <[email-masked]> *On Behalf Of *Dario Tedeschi
> *Sent:* vendredi 18 janvier 2019 23:34
> *To:* [email-masked]
> *Subject:* [6lo] draft-ietf-6lo-fragment-recovery: fragment_offset
>
> Since the value in the fragment_offset field is based on the 
> compressed version of a datagram, this field would potentially need to 
> change for all fragments of a single datagram as it traverses the 
> network.
>
> compressed and fragmented into 2 fragments A and B with lengths L{A} 
> and L{B} respectively. The total length of the "compressed datagram" C 
> is therefore L{A} + L{B} = L{C}. It is also true therefore that the 
> offset of fragment B within the compressed frame is Offset{B} = L{A}
>
> Assuming the datagram is being forwarded, the next hop would likely 
> need to re-compress the first fragment (because the link-layer 
> addresses in the 15.4 packet would change). In turn L{A} would also 
> likely change to L{A`}. This means that the frame_offset value in the 
> second fragment would no longer be correct, since Offset{B} != L{A`}.
>
> As I see it, this problem makes the current draft unusable, because 
> the originator of the 6LoWPAN fragments can't allow for slack in the 
> first fragment to accommodate for re-compression changes at each 
> subsequent hop.
>
>  1. The receiver of any fragment would immediately know what buffer
>     size to allocate to store the entire uncompressed datagram
>     slack in the first fragment for subsequent hops, because the
>     offsets of fragments were based on the uncompressed datagram.
>
> the uncompressed datagram (similar to RFC 4944) or have I 
> misunderstood the draft?
>
> Regards
> Dario Tedeschi
>