Hi: I do not think that the current fragmentation is fine. We have a number of issues that deserve attention IMHO:: - How to forward fragments in route over - fragment loss and recovery, - datagram size determination in the presence of unknown compressed headers over multiple fragments - impacts on sniffers, debugability.
So while I'd agree that 4944 is self-sufficient for one hop applications, I think there's a need for a serious second pass on fragmentation. The group as voted that in the past and we've not acted for charter reasons. Does not mean we can never make it. Also: I think that the proposed resolution below is at best a temporary patch. For all I know, we are not chartered to make it, and if we are, then we should address the whole problem. And BTW: This is NOT an HC problem. My reading from the last call thread is that we could add words in HC to limit the compression to the first fragment if RFC 4944 is used there, but that's about it. Cheers, Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Carsten Bormann > Sent: Thursday, March 04, 2010 12:19 AM > To: Geoff Mulligan > Cc: 6lowpan > Subject: Re: [6lowpan] closing on update to HC draft > > > On Mar 4, 2010, at 00:00, Geoff Mulligan wrote: > > >> From what I can tell we appear to be closing in on the idea (from > >> Daniel > > plus others) that the HC draft should only: > > - Allocate a new dispatch value for the "changed" frag offset and > > length value > > - Define the frag offset and length to be the values relevant for the > > actual data in the packet (compresses or not) > > - Strongly deprecate the old frag dispatch value > > > > Agree or disagree? > > I personally believe 4944's fragmentation is fine. > I must have missed a lot of discussion if the above is the resolution. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
