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.
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 protected]> *On Behalf Of *Dario Tedeschi
*Sent:* vendredi 18 janvier 2019 23:34
*To:* [email protected]
*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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
