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

From: Geoff Mulligan <[email-masked]>
Date: Wed, 13 Dec 2006 17:32:28 -0700

Folks,
  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-format-08.txt, "Transmission of IPv6 Packets over
IEEE 802.15.4 Networks".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-08.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

This Last Call will end on Thursday 4 January 2007 at 2359 UTC.

        Thanks,
                Geoff & Carsten

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

---

From: Philip Levis <[email-masked]>
Date: Wed, 13 Dec 2006 22:40:13 -0800

> whether or not you think this document is ready to go to the IESG.

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?

Phil

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Dec 2006 09:58:24 +0100

> 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).
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).

[WG chair hat on:]

It is exactly this kind of issue that I like to see discussed at WGLC  
-- so please keep up sending in the questions!

Gruesse, Carsten

---

From: Philip Levis <[email-masked]>
Date: Thu, 14 Dec 2006 08:46:30 -0800

On Dec 14, 2006, at 12:58 AM, Carsten Bormann wrote:

> 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.

> 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