Richard,
We've been grappling with this problem internally over the last week or
so, and I'd like to add our take on some of the problems in combining
RFC4944 fragmentation with the draft header compression.
I think the RFC4944 fragmentation was optimized specifically for HC1
compression under the assumption that the compressed headers never
extend beyond the first fragment of the packet. If we assume that all
subsequent fragments are uncompressed then you can quite easily tell
when you have received all of the fragments, and the last fragment will
have (dgram_offset + fragment size == dgram_size). The only oddity is
that you have to decompress the first fragment before you can reassemble
the datagram.
However, I suspect that this assumption is no longer true in the case of
the draft header compression. Especially now that IPv6 extension headers
can be compressed (what do we do if ROLL adds ~160 bytes of routing
headers to a packet?). It becomes substantially more complicated to
determine how to defragment packets since we need to know the
uncompressed length of each header in order to know when reassembly is
done and to detect missing fragments, but we can't decompress the
headers until we have all of the compressed headers. We get stuck in a
catch-22: can't defragment until after decompression, but can't
decompress until after defragmentation.
|First Fragment (F1) |Second Fragment (F2) |Third Fragment (F3)
+---------------------+ +-------------------+ +--------+--------------+
| Compressed Headers | |Compressed Headers | | C Hdrs | Payload |
+---------------------+ +-------------------+ +--------+--------------+
: \ : \ :
: \ : \ :
|Uncompressed Datagram \: \:
+-------------------------:-----------------------:--------+--------------+
| Uncompressed Headers | Payload |
+-------------------------:-----------------------:--------+--------------+
| | | |
|<--- L1 --->|<--- L2 --->|<--- L3 --->|
| |
|<-------------------------- datagram_size ----------------------->|
The only way to reassemble these three packets is to perform
decompression and reassembly at the same time, since the lengths and
offsets of fragments F1, F2, and F3 do not add up to the datagram size,
and leave gaps in the packet that hopefully get filled after
decompression. It also becomes necessary to store the state of your
decompressor across multiple packets, which can get very ugly if header
fields get split across fragments.
Either one of your recommended solutions would work, but if you want to
include the total number of fragments I would recommend that each packet
should also be identified by a sequence number. A simple, but less
efficient solution, could also be to simply state that any headers which
extend past the first fragment after compression should not be compressed.
Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling
my hair out trying to find a way to implement this without throwing away
all of Wireshark's reassembly support and starting from scratch, or
implementing some sort of wild speculative guessing.
Thanks,
Owen Kirby
Richard Kelsey wrote:
There is a forward-compatibility problem lurking in the
fragmentation specified by RFC 4944. In the RFC, fragment
headers include sizes and offsets that are relative to the
uncompressed datagram, and not the compressed version that
is actually being communicated. If a node receives a
fragmented datagram which includes a compressed next header
that the node does not know how to uncompress, the node may
not be able to determine if it has received all of the
fragments. It knows neither the length of the compressed
datagram or the total number of fragments.
Further, the RFC states:
Similarly, when a node first receives a fragment with a
given datagram_tag, it starts a reassembly timer. When
this time expires, if the entire packet has not been
reassembled, the existing fragments MUST be discarded and
the reassembly state MUST be flushed.
This requirement assumes that the receiver is able to
determine when it has received a complete datagram.
My main concern is the possibility of compressing TCP
headers at some time in the future. Pre-existing devices
would not necessarily be able to forward packets with
compressed TCP headers.
This could be fixed in several ways, such as using the
compressed sizes and offsets instead of the uncompressed
ones, or including the number of fragments in the first
fragment header.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
