Hi Carsten (sorry - sort of off-topic)
> -- per-L2-hop ACKs on fragments I assume 6lowPan is intended for shared media? In such environments it is waste of good bandwith to send L2 Acks for messages that are going to be forwarded anyway. You can hear the forwarded message just as well as the ack..... Yes, I know: "Layer violation" - but come on! Saving 50% bandwidth can justify quite a bit ;-) This is just to say that maybe fragment Ack'ing needs some more work before we can close that one.... - 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
