> A marginal link is simply one that has a measurable amount of packet loss.
Ok, re-reading this exchange, it looks like I may have wrongly assumed
that people are aware of background. I'll need to put that into the
routing comparison document, this is as good a place as any to draft my
text.
Carrier and enterprise routing protocols are optimised for wired networks,
where a link is either down (drops all packets) or up (drops one packet in
10^10).
Home networks usually include link technologies that have an intermediate
"marginal" state: a link that drops a non-negligible fraction of packets.
With 802.11, in particular, marginal links have fairly unpleasant performance
characteristics. For example, if the BER is 10^-4,
- multicast packets are dropped at roughly the nominal rate (10% for 120
byte packets, 90% for 1500 byte packets);
- unicast packets are dropped at a much lower rate, but the efficiency
suffers (0.9 for 120 byte packets, 0.1 for 1500 byte packets).
- unicast packets have a high probability of being duplicated (no
figures given, I'm too lazy to look up the size of an ACK frame).
This is of course a very naive analysis -- in practice, errors tend to
come in bursts, and furthermore 802.11a/g/n implements some very complex
lower-layer magic. Don't believe any results from computation or
simulation, with radio, only actual testing in real-world networks is
trustworthy.
This has two consequences for routing protocols:
(1) the routing protocol must be able to prefer solid links to marginal
ones when there is enough redundancy;
(2) control data may fail to be propagated in a timely manner,
especially if it is sent over multicast.
1. Prefer solid links
This is pretty obvious. If you can choose between an Ethernet link and
a wireless link with heavy packet loss, choose the Ethernet. But there
are more subtle cases that are extremely common in practice:
Internet --- A --- B....C --- is Ethernet
. . ... is WiFi
........
A is your CPE, B is the router in your living room, connected by Ethernet
to the CPE, and C is the wireless router in the guest room. Yeah, it's
a large house.
Suppose now that the wireless link B..C is rock solid, but the longer A..C
link is marginal. Murphy's law dictates that the link A..C will have huge
packet loss, but it will be just good enough for the routing instances on
A and C to become neighbours. If the routing protocol performs hop-count
routing, even if it is smart enough to prefer wired to wireless, it will
prefer the highly marginal route A..C to the rock solid route A-B..C.
Note that this is easily fixed by a competent administrator: just disable
the wireless interface on A. But this is Homenet, and we're assuming
there's no administrator.
In the mesh community, the hop-count metric is known as "worst-path routing".
2. Control data may be delayed
Since multicast has such massive packet drops, the routing data may be
dropped or delayed. Using a reliable sub-protocol for propagating
critical data, as is done by OSPF, IS-IS and EIGRP might work if the
reliable protocol can cope with the weirdness of the 802.11 MAC. If it
cannot, it might (or might not, I don't know) suffer from routing
pathologies, such as routing loops in OSPF and IS-IS, inconsistent DR/DER
election, and SIA in EIGRP.
Of course, people have managed to get link-state protocols to work on
wireless networks, even on highly marginal mesh networks, but they had to
design new mechanisms. OLSR, for example, doesn't use reliable flooding
and DR election, but instead uses unreliable flooding and MPR election,
together with a mechanism that drops marginal links. I refer you to
RFCs 3626 and 5449.
Babel uses different mechanisms. Babel uses a feasibility condition
similar to that of EIGRP, which means that it avoids loops even when
control data is delayed. Unlike EIGRP, however, it doesn't rely on
a reliable subprotocol, and it doesn't have an active phase. End-to-end
synchronisation is achieved in a softer manner, and a single router that
fails to propagate requests doesn't prevent reconvergence if there are
alternate paths available -- look Ma, no SIA, even with massive packet
loss. (This is not meant as a critique of EIGRP -- I rather like EIGRP,
and I'm pretty sure it could be adapted to home networks if somebody spent
a couple of years of their life doing that.)
I'd like to finish this slightly lengthy message by stating that the
current implementation of Babel does not work well in networks where all
links are highly marginal; in other words, Babel really wants a solid
backbone to be available. In particular, Babel tends to aggregate control
data into large packets, which have a higher probability of being dropped,
and tends to drop links that have more than 90% pre-ARQ drop rate for
full-size frames. There exist specialised, highly tuned protocols that
are able to deal with topologies that rely on such very marginal links,
notably bmx6, BATMAN-adv, and the highly tuned version of OLSR-ETX used by
the Berlin and Vienna meshes.
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
