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

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

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