Hi Jonathan: I'm trying here to break the thread into components because it's getting unreadable.
>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. > This should be addressed in the architecture very clearly. Whether the path is computed at L2 or L3, there's a need to decide and express clearly in the packet what is the source that does the 6LowPAN compression, and what is the destination that expands the packet. An interface on a router should not have to make assumptions on whether a packet will be routed on another interface of the same type or not. I've been trying to parse another of your mails on the same subject and still fail to understand the model you have in mind for what goes in the mesh header if any and what is uncompressed over a multihop LowPAN path. I believe that a few examples with figures would help a lot and that they should end up in the architecture doc once we agree on them. Fair? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: mardi 27 mai 2008 18:27 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); [email protected] >Subject: Re: [6lowpan] New charter for 6lowpan > > >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
