Hi: The version proposes a compressed fragment Ack. This is still under debate on this ML but the authors thought that I made sense to publish the proposal at least once so it is readily available to all.
If the WG decide we can easily fall back to the uncompressed version. We still need to clarify whether the current charter lets us take fragment recovery and flow control as work items though. Pascal -----Original Message----- From: IETF I-D Submission Tool [mailto:[email protected]] Sent: mardi 30 juin 2009 18:46 To: Pascal Thubert (pthubert) Cc: [email protected] Subject: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-06 A new version of I-D, draft-thubert-6lowpan-simple-fragment-recovery-06.txt has been successfuly submitted by Pascal Thubert and posted to the IETF repository. Filename: draft-thubert-6lowpan-simple-fragment-recovery Revision: 06 Title: LoWPAN simple fragment Recovery Creation_date: 2009-06-30 WG ID: Independent Submission Number_of_pages: 14 Abstract: Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. The IETF Secretariat. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
