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
