On Thu, Feb 19, 2015 at 11:45 AM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: >> 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).
Um, er, ah, an ideal low latency drop or mark rate is about .01-.02% of big packets on 100mbit links, I dont remember what it is for gigE. It is much higher at 10mbit. I should just go out and draw the nearly linear relationship between drop rate and bandwidth for fixed latency from the data I have... > Home networks usually include link technologies that have an intermediate > "marginal" state: a link that drops a non-negligible fraction of packets. I have over the past year become a reluctantly enthusiastic user of homeplug powerline technologies. For stuff rated at 600Mbit () I typically get throughput in the range of 12-140mbits in a small apt and latencies in the 30-140ms range under load. They degrade enormously with more than 2 in use and dont work worth a damn in larger houses... but are still generally faster and less jittery than present day wifi, when you have an electrical system that they work on. These sort of devices would be ideal to add aqm/fq to but public firmware is non-existent, as near as I can tell. And, as layer 2 bridging devices, they supply no indications to layer 3 routing protocols that they are weirder than ethernet. I do like the idea of using RTT based metrics as an abstraction for determining link quality, but it would be rather nice to also have a way to get their actual bandwidth and actual load statistics somehow, for smarter usage. > 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 Well, ethernet runs at different speeds and there is no abstraction for that in babel... > 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 > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
