Hi Carsten > In this scheme, you don't have that option if the fragments > arrive out of order. > With 6lowpan's fragmentation, you get the correct offset for > free. That was the idea. > But it only works very well if you don't try to compress > non-initial fragments.
Out-of-order reception should be recoverable with the proposed fix. After all we are just talking about a (different) constant offset to the rest of the fragments? - Anders > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Carsten Bormann > Sent: Thursday, March 04, 2010 13:27 > To: Anders Brandt > Cc: 6lowpan > Subject: Re: [6lowpan] closing on update to HC draft > > Anders, > > the issue is that we are not in a green field position here. > 6lowpan already has a fragmentation scheme that I maintain works well. > > Indeed, 6lowpan fragmentation does not address: > -- per-L2-hop ACKs on fragments (what Pascal's draft is about) > -- compressed headers outside of the first fragment (only the > first fragment has a dispatch). > > On the other hand, if you don't need either, the somewhat > weird layering of 6lowpan's fragmentation is a better fit to > constrained nodes than a more strict > (fragment-the-compressed-PDU) layering. > > > Other PHY/MAC technologies may have shorter frames than 128 bytes. > > Ah, but that wouldn't be 6lowpan, or would it? > Tell us more about the use case. > (For smaller cell-sizes, fragmentation may not be the right > model; there was more than one reason that IPv4 had a minimum > MTU of 68 bytes. See RFC3819) > > > Add L2 security and you may have an issue even before. > > I'd still like to see the use case. > The about 70 bytes of L2 payload you get for maximum security > in 6lowpan is fine for just about any compressed(!) header. > If RPL stuff is larger than that (oh my), just don't try to > compress it in HC. > (On the contrary, I think that the ability to independently > decompress/recompress HC per-fragment is a *major* win.) > > > The main point is the two other issues: > > * Fragment offsets affected by header compression > > Doesn't happen in 6lowpan header compression. > (What does happen is that more than a fragment's size > logically fits into the first fragment, but that is kind of > inevitable in compression.) > > > * Fix does not (seem to) introduce new problems. > > 1) I haven't seen the fix. Do we have text to look at? > 2) The one obvious new problem would be to invalidate > existing implementations. > > > 3) Load fragments in receive buffer. Option: Start at an offset into > > the buffer so that you do not have to memcpy the IP payload. > > 4) Decompress header. > > In this scheme, you don't have that option if the fragments > arrive out of order. > With 6lowpan's fragmentation, you get the correct offset for > free. That was the idea. > But it only works very well if you don't try to compress > non-initial fragments. > > Sorry to cause pain here. > Fragmentation is probably the most boring subject on earth. > It is still hard to get right. > > 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
