Hi Anders Yes, I suspect that hearing promiscuously your packet being repeated can be considered an ack in a mesh under network, but that's not the point that the draft addresses - that is a mesh under problem to be solved by the mesh under technology. In route over, you never know what the next hop technology will be.
And what the draft Jonathan and I put together for fragments is a sublayer below the fragmentation, acting end to end over a LoWPAN. That's useful as soon as you carry the packets over multiple hops, which is natural in mesh under but hopefully will be generalized to route over, using the datagram tag as a label to route subsequent fragment along the path selected for the first fragment. Cheers, Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Anders Brandt > Sent: Thursday, March 04, 2010 1:39 PM > To: Carsten Bormann > Cc: 6lowpan > Subject: Re: [6lowpan] closing on update to HC draft > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
