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
