I think that changing offset and length to indicate the *compressed*
values is the best way forward. It is architecturally clean because
it preserves the layering - the only information needed to generate
fragments is the data and length. RFC 4944's use of uncompressed
values requires the fragmentation layer to be aware of the specific
header compression in use and creates dependencies, which is the
primary cause of the issues described by Richard and Owen.
The primary downsides that I see are the following:
- Using compressed values does mean that a memmove() operation is
likely when expanding the payload, but a memmove() on ~1K bytes does
not represent a bottleneck relative to the 15.4 radios in use today.
- The receiver no longer knows how much buffer to allocate in order to
store the fully expanded payload (if that is what the implementation
wants to do). Fortunately, the forwarding nodes are only concerned
with L3 headers and the size difference is currently limited to the
IPv6 header itself. Of course, the size difference on the final
destination could be arbitrary depending on what other upper-layer
compression is in use. We could include a expanded size field in each
fragment, but I'm not sure the overhead outweighs the benefits.
- Breaks existing implementations - I don't think we should be
terribly concerned with this - most of the implementation work going
on in the world is happening right now, standards at all layers of the
stack are still being defined.
I would suggest placing the appropriate text for whatever we decide on
into the 6lowpan-hc draft. The draft already updates RFC 4944 and the
change is relevant to how 6lowpan-hc is defined. I see this as the
quickest way forward even though we would have to reset the WGLC on it.
Another issue that comes up with Richard's forward compatibility
concerns is handling of ICMPv6 errors - specifically, when a forwarder
needs to generate an error, what should it include in the ICMPv6
payload? Though I think this should be left for a different thread.
--
Jonathan Hui
On Feb 18, 2010, at 4:34 AM, Daniel Gavelle wrote:
The main problems with the existing RFC4944 / HC-06 draft when the
compressed data can extend over more than one header are:-
(1) Detecting the subsequent fragments are compressed.
(2) That it is not possible to detect the final fragment by
(dgram_offset + fragment size == dgram_size).
These problems can solved by creating new dispatch codes.
We currently have 11 000 for first fragment FRAG1 and 11 100 for
subsequent fragments FRAGN. A new code can be created for a
subsequent fragment that contains compressed header information,
e.g. 11 101 FRAGC.
The problem of detecting the final fragment does not occur for
implementations that use a bit map manager. A new final fragment
code of 11 110 FRAGF can be added to assist implementations that
detect the final fragment by (dgram_offset + fragment size ==
dgram_size).
Changing the datagram_size and datagram_offset to refer to the
compressed rather than the uncompressed sizes causes the following
problems:-
(a) It would force major changes on existing implementations. It
would also completely break any compatibility with existing
fragmentation code which has already been developed by contributors
on this list.
(b) It will make determination of whether a packet is complete more
difficult for implementations which use a bitmap based on
uncompressed offsets.
(c) Storing the entire packet before decode / forwarding should be
an implementation choice rather than something that is enforced
because of the way the standard is written. Copying from one buffer
to another is wasteful and not a luxury that an embedded engineer
can count on, PC implementations aren't going to feel the pain in
the same way. It is important that 6LP can be implemented in real-
time with a minimum of buffer copies - all that is needed is a
buffer capable of storing 2 (or more) fragments to get the system
working when header creep is detected. When forwarding packets, a
router node may need to deal with several packets at once and may
not have space to fully buffer each IP datagram.
(d) In the most common case, there is only fragmentation in the
first header and then many fragments of uncompressed UDP payload.
The existing method of specifying the uncompressed offset allows
this UDP payload to be stored in the correct location as the
incoming data arrives.
(e) Forwarding unknown headers through router nodes in a route over
implementation can be solved whether the length and offset are
stored compressed or uncompressed. There are different advantages in
this case with either method so we shouldn't let this cloud the issue.
(f) Not knowing the full uncompressed datagram size until the entire
packet has been decoded also has implications for ICMP error
handling, e.g. MTU exceeded.
Daniel.
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
Richard Kelsey wrote:
Date: Tue, 16 Feb 2010 13:04:53 -0800
From: Owen Kirby <[email protected]>
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?).
Owen,
A long source route could quite possibly push the transport
header into the second fragment.
[...] We get stuck in a catch-22: can't
defragment until after decompression, but can't decompress
until after defragmentation.
[...] 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.
This could be tricky because the size of the compressed IP
header and the MAC addressing and security overhead can
change hop-by-hop. What was in the first fragment on the
first hop may not be in the first fragment on a subsequent
hop, which causes a problem if the forwarding node does
not know how to uncompress the entire packet.
I think that the best solution would be to switch to using
the compressed size and offsets in the fragment headers.
This would allow (un)compression and (de)fragmentation to
be done independently.
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.
Would using the compressed size and offsets in the fragment
headers solve this?
-Richard Kelsey
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
