Subject: Re: [6lowpan] WG last call on Format document

From: gabriel montenegro <[email-masked]>
Date: Fri, 5 Jan 2007 10:16:21 -0800 (PST)

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-masked]>
To: 6lowpan <[email-masked]>
Cc: Carsten Bormann <[email-masked]>
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-masked]] 
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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Sat, 6 Jan 2007 13:17:11 -0800

> Such functionality should be worked on subsequent to the base spec.

My point isn't take the document should specify single-hop  
reassembly. It's that, as written, it precludes single-hop  
reassembly. If the spec were, for example, to say that the two  
headers could be in either order, then there would be no problem. My  
concern is that the document -- without any technical justification  
for the decision -- is digging itself into a hole where producing  
efficient (in terms of energy, RAM, and code space) implementations  
will be difficult. It might be that a new mesh2 header emerges that  
reverses the order, with the cost of a few extra bits in each packet.

That being said, there is the point to be made that large packets in  
6lowpan are expected to be very rare and mostly present for complete  
interoperability than for core use cases. So this might in the end be  
entirely irrelevant. Given the lateness in the process and lack of  
forward progress, having something is better than nothing. So I'll  
shelve my concern and am happy to agree on the document.

> This needs to be in the base spec.

I had thought that the discussion went down the road of "if you don't  
know the header type, drop the packet," keeping packet processing  
simple.

Phil

---

From: "Schumacher Christian Peter Pii" <[email-masked]>
Date: Sun, 7 Jan 2007 11:52:15 +0100

Given the feedback, I believe the chairs can submit the documents for IESG review.

Regards
Christian

-----Oprindelig meddelelse-----
Fra: Philip Levis [mailto:[email-masked]]
Sendt: lø 1/6/2007 10:17
Til: gabriel montenegro
Cc: Schumacher Christian Peter Pii; [email-masked]
Emne: Re: [6lowpan] WG last call on Format document

Phil