Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Dave Taht <dave.taht@gmail.com>]

What frustrates me most is that the IETF doesn't "get" wireless either,
and the IEEE is busy designing overly reliable, slow wireless networks
because EE types like never to drop packets, and they got retries
in their toolbox now to make it so. FEC belongs in their toolbox.
Retries, not so much. I keep thinking I have to start attending
IEEE meetings, particularly on the upcoming 802.11ak standard,
to knock some heds.

And: retries is partially my fault, based on the work we were doing in the
late 90s (see my mit talk for some
history) - but I never imagined we'd see 10s or 100s of retries built
into the layer 2 protocols as a result!

There is NO other good reason why
modern wifi should exhibit 100s of ms of latencies under load now that
we have fq_codel to shed it, but a whole ton of buffering, not just
retries, but aggregation buffers and re-order buffers, need to get
knocked out of the wireless
and wifi devices, in order to get back to sanity. First up is somehow
getting tools like veriwave to actually show latency in addition to
reliability...


On Sat, Jun 7, 2014 at 12:41 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Jun 7, 2014 at 12:20 PM, Mike O'Dell <mo@ccr.org> wrote:
>>
>> look at what John Moy did in the Cascade 9000s back circa 1997
>> he used OSFP, of course, instead of ISIS and he did full constraint
>> resolution path identification along with with per-flow (aka VC)
>> ingress rate monitoring which allowed completely distributed load shedding
>> (policing) subject to a precedence lattice. once the path was identified
>> the only rate management was at the ingress points, and that's only per-port state.
>>
>> extending the model it to carry ethernet MAC addresses isn't very hard.
>
> I googled for a couple pages and didn't find anything relevant. I'll gladly
> read up on it...
>
> A problem here, that many miss, is that sensor networks, wireless and
> wifi behave
> fundamentally differently that ethernet does. Wires, at least in the home, are
> going the way of the dodo, so optimizing for the none-wired case is critical.
>
> Multicast is particularly damaging
> on wifi (running at the 1998 1mbit/sec rate where the overlying network can
> now run at a gbit). Protocols like batman fold as many arp requests as possible
> into a single packet, in order to deal with it, but overall,
> minimizing multicast
> is a goal until wifi improves it's multicast behavior.
>
> Wireless/wifi/etc are also more like early ethernet in that they are
> not full-duplex.
>
> Most (all?) networking protocols have lousy metrics for determining
> paths in a mixed
> wireless/wired environments, and few have the ability to make
> intelligent decisions
> based on ingress/egress load at a gateway. Some things - like shortest path
> routing - actually don't make a lot of sense in a mixed wireless,
> wired environment.
>
> Take a path like this
>
> host A - Router B -> wireless ---long slow, unreliable hop
> ----->Router C-> internet
> Host A - Router B -> wireless - short hop -> short hop -> ethernet ->
> Router C-> internet
>
> Despite the 2 shorter hops probably offering 10x the
> bandwidth/reliability of the shorter path,
> most routing protocols will select the "shorter" path. The "ETX"
> metric is not horrible that
> tries to mix in "quality" to the choice, but it is still not good.
> Babel doesn't solve this
> well either, presently.
>
> Then there is the problem of channel selection. If you have this choice:
>
> Host A - Router B -> wireless - short hop chan 36 -> short hop chan 36
> -> ethernet -> Router C-> internet
> Host A - Router B -> wireless - short hop chan 40 -> short hop chan 44
> -> ethernet -> Router C-> internet
>
> The second route above is superior to the first because the transit
> will be non-interfering,
> and scale as a full duplex link would rather than a half duplex one. A
> string of half duplex links
> on the same channel degrades rapidly.
>
> There's two names for this feature, one is "diversity routing"
>
> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/wbmv4.pdf
>
> And batman calls it something else, but specifically knowing the
> channels on a path is
> a really huge win that nothing else I know of currently thinks about.
>
> I note that these are problems that can be solved at layer 2 as well,
> but so far as I know,
> nobody has solved them, and 802.11s was a disaster.
>
>>
>>         -mo
>
>
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article