Hi Daniel, Richard and Owen: There are a number of reasons why the fragmentation in RFC 4944 is broken. Richard has just identified a new one. The traditional problem of loss of fragment is another that might actually hurt a lot sooner. It is time that we rework the fragment in the light of this experience and without the need to be backward compatible but rather forward compatible. We did that for HC already.
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover y already has the sequence that Owen has been asking for, for the purpose of recovering fragments. It also has an all zeroes ack bitmap that enables the receiver to let the sender know that the packet is dropped so stop sending fragments for it; this can be used if the receiver fails to parse a compressed header. It is compatible with a route over model where fragments are forwarded without full recomposition ( see http://www.mail-archive.com/[email protected]/msg01828.html ). So my suggestion would be to work on that draft to make it achieve what you're looking for. What do you think? Pascal -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Gavelle Sent: Thursday, February 18, 2010 1:34 PM To: Richard Kelsey Cc: [email protected]; Wayne Ellis Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions 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
