On Sat, Jun 7, 2014 at 12:20 PM, Mike O'Dell <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
