On Comment 1: Reassembly: I don't think we should delay the draft because of this. I think this is an interesting research topic. I notice that there are similarities with the folks applying DTN to sensor networks (projects at UCLA's LECS, SICS, Trinity College, etc). DTN is itself a research group in the IRTF, so similarly, I see such extensions to LoWPAN as possible alternatives once the basic draft in its current form is done. One possible avenue is to reuse AODV to do the discovery of the DTN-capable devices, and integrate with the routing layer such that the proper tradeoffs (end-to-end, hop-by-hop or anything in the middle) are possible. Such an approach was discussed recently at the CHANTS workshop and IRTF DTNRG: paper: http://doi.acm.org/10.1145/1162654.1162659 slides: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf Such functionality should be worked on subsequent to the base spec.
On Comment 2: are NALP values handled by IANA? I think it doesn't need to be. But someone should handle this assignment space if it is to serve its purpose of avoiding conflicts. So IANA *could* maintain the repository, but as a convenience only. This suggests that (from RFC2434) "First Come First Served" is an appropriate policy. I note that there is one remaining item which fell through the cracks: we need to define the format of future dispatch headers. The length of the dispatch headers defined in the base spec is known, so protocol parsing can proceed. For future dispatch headers, we need to include a length field in a well-known place in the header, otherwise proper parsing is not possible. This needs to be in the base spec. Also, there are some remaining notes that should be deleted before progressing. -gabriel ----- Original Message ---- From: Schumacher Christian Peter Pii <[EMAIL PROTECTED]> To: 6lowpan <[email protected]> Cc: Carsten Bormann <[EMAIL PROTECTED]> Sent: Friday, January 5, 2007 1:05:46 AM Subject: RE: [6lowpan] WG last call on Format document Dear 6lowpanners The deadline for the last call has passed. There have been a few comments on the list: Comment 1. Reassembly (Philip Levis and Carsten Bormann): - Carsten assumes a mesh forwarder doesn't need to reassemble. - Philip believes a mesh forwarder must reassemble, as that would be more energy efficient. Comment 2. IANA considerations (Philip Levis): - Is arbitration of the 00xxxxxx values under its purview? (Regarding NALP) To resolve comment 1: I urge the mailing list to respond with your opinions on this matter. To resolve comment 2: I believe it is within the purview of IANA, but can anyone confirm this? A final question, is there anyone who doesn't feel the format document is ready for IESG review? Regards Christian -----Original Message----- From: Philip Levis [mailto:[EMAIL PROTECTED] Sent: 14. december 2006 17:47 To: Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] WG last call on Format document On Dec 14, 2006, at 12:58 AM, Carsten Bormann wrote: >> I still have a concern about the ordering of the fragmentation and >> mesh delivery headers. Can anyone offer a good argument on why >> fragmentation is within mesh and not vice versa? > > I think the general rule is that a node should only have to parse > the subheaders that it is concerned with. > > I'm assuming a mesh forwarder does not reassemble (I don't happen > to know any good reason why it should). Energy. Imagine a theoretical route from N0 to NX of nodes N0, N1, N2, ... NX. Let us suppose that each link (NZ,NZ+1) has a packet loss rate of L. If you have no e2e fragment recovery, then an IPv6 packet P composed of F fragments has a ((1-L)^X)^F probability of successful delivery. The probability of any fragment being delivered successfully is (1-L)^X, and the probability of all of them being delivered successfully is (1-L)^X^F. It decreases exponentially with path length and packet size. With no fragment recovery, you have to resend the entire packet when this occurs. So the cost of a single fragment failure is FX transmissions and the overall cost to deliver a packet successfully is approximately FX + FX * (1-L)^-XF. With multihop reassembly, a single fragment loss requires control traffic to request the fragment, which itself also has a loss rate of (1-L)^X, then the fragment being retransmitted. So the cost of a single fragment failure is 2X transmissions, and the cost to deliver a packet successfully is approximately FX + 2FX * (1-L)^-X. With single-hop reassembly, each hop reassembles the packet as needed. Because losses are locally recovered, you do not have the exponential growth in packet loss. Unlike multihop recovery, where the number of packets transmitted is going to approximately be FX * ((1-L)^X)^-1, (the expected number of transmissions per packet is the inverse of the loss rate), in single-hop recovery the equation is multiplicative: FX* (1-L)^-1. Each link sends only (1-L)^-1 copies of its each fragment, with retransmissions caused by local failures. So the cost becomes FX + 2FX * (1-L)^-1. Recap: F is number of fragments X is length of route L is loss rate on each hop Multihop reassembly with full packet retransmission: FX + FX * (1-L)^-XF Multihop reassembly with fragment retransmission: FX + 2FX * (1-L)^-X Single-hop reassembly with fragment retransmission: FX + 2FX * (1-L)-1 Additionally, if you layer mesh on top of fragmentation, then every mesh packet has a fragmentation header in it. If the mesh header length is M and the fragment header length is G, then each fragment has M+G bytes added to it, for a total of F * (M + G). If you reverse the layering, then only the first fragment has the mesh header, and so you have a header cost of M + FG. Finally, it is (in my experience, others might differ on this) also easier to manage the state and retransmission policies, as reassembly does not have to worry about greatly different latencies caused by route changes between fragments. That being said, if X, F, and L are always going to be small, then the exponents don't matter. But there's a fundamental scalability problem. > So a mesh forwarder is concerned with the forwarding header only; > these therefore should come first. > Only at the L2 destination is it necessary to peek further into the > header, e.g. the fragmentation header for reassembly. > > Compare this with IPv6: The forwarding header (here the IP header) > is in front of the fragmentation header, which is a destination > header (only "opened" at the destination address set in the IP > header). > Two mails ago: I have one concern with the current draft: the ordering of the fragmentation and mesh headers. In his presentation at IETF 67, Jonathan noted that the order followed the model presented by standard IPv6. In IPv6, fragmentation/reassembly must be end-to-end, so the ordering makes sense. However, this is sub-IP. I think that most of the real-world experiments with 15.4 radios, as well as basic loss models, suggest that per-hop fragmentation/reassembly is greatly preferable to e2e, particularly for energy reasons. You don't need to add a mesh header on each fragment, you have fewer retransmissions, and less state maintenance. Including a mesh routing header is essentially to provide IP routing; following the guidelines of RFC 2460 Section 5, I believe the order of these two headers should be reversed: a node fragments and reassembles a mesh packet on a per-hop basis, rather than routing an IPv6 datagram one fragment at a time. Phil _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
