Hi Pascal, I see a few underlying issues in this discussion. First is whether or not route-over implies complete reassembly at every hop. In my view, it doesn't. A node could simply cache the datagram tag when the first fragment arrives and forward the subsequent fragments accordingly. Note that this also saves header overhead because the mesh header doesn't have to be included in every fragment. When forwarding between different links, reassembly has to happen anyway.
The second issue is whether or not we constrain forwarding fragments of a given datagram to a single path. This is where mesh-under and route-over diverge. But to me, there are a lot of advantages to constraining delivery of a datagram to a single path. Hop-by-hop recovery can ensure in-order delivery. Hop-by-hop congestion control becomes much more meaningful. It's unclear to me what end-to-end congestion notification means in a mesh-under setting. We can also take advantage of link optimizations to increase throughput and decrease latency. And, as mentioned before, reduces header overhead by not needing addressing information in subsequent fragments. The third issue is whether or not end-to-end mechanisms should be used for recovery and congestion control. I think we agree that hop-by-hop mechanisms are required regardless. They increase reliability and can provide effective congestion control and mitigation. To me, hop-by-hop mechanisms are generally much more effective than end-to-end ones because they react to local conditions and can quickly provide back- pressure all the way to the source. From a reliability standpoint, we've seen solutions deliver >99.9% without end-to-end recovery. So one question is how much more reliability do we really need? and does it justify the added energy overhead and code size? -- Jonathan Hui On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > We do agree on the problem. > > Per-hop reassembly, though, comes at the expense of that traffic > fluidity that was so desirable to the ATM designers. In other words, > because per-hop reassembly forces each intermediate node to store and > forward a full packet, it is augmenting the latency of the flow and > the > memory requirements on the forwarding nodes on the way. > > This is why I had in mind to couple a few per-hop recovery with a more > solid end-to-end recovery and flow control mechanism between the > LoWPAN > endpoints. > > Now I wonder what this discussion becomes in route over v.s. mesh > under. > In route over, it seems that the forwarding node terminates a link > so it > has to reassemble before it forwards on a different link that might or > might not be a LoWPAN; so maybe we end up doing the same thing in that > case. > > Jonathan, what do you think? > > Pascal > >> -----Original Message----- >> From: Philip Levis [mailto:[EMAIL PROTECTED] >> Sent: vendredi 23 mai 2008 19:46 >> To: Pascal Thubert (pthubert) >> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); > [email protected] >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi JP: >>> >>> I see your concern. >>> >>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>> that >>> the basic operation is pretty simple: emulate a packet loss in RED > but >>> save the packet. So the real problem is not ECN itself but what RED >>> becomes in a LowPAN forwarding node. And that is something that the >>> node >>> will have to define whether it does ECN or RED. >>> >>> If we do not have ECN then the LowPAN forwarding nodes will have to >>> destroy frames which might be fragments. Considering the cost of >>> energy >>> and bandwidth to getting the frame up to that forwarding node, the >>> latency introduced by transport layer time out, and the risk of >>> congestion collapse introduced by resending the whole segment, I'd >>> suggest that ECN is actually a good idea. >> >> This gets back to the point I brought up December 14, 2006. In lossy >> networks, end-to-end fragmentation and assembly is a real problem. It >> makes much more sense to do per-hop fragmentation and assembly. In >> the >> former, the number of retransmitted fragments is exponential in the >> number of hops; in the latter, it is linear. >> >> Phil _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
