From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1C19421F2E4 for ; Sat, 7 Jun 2014 12:41:13 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so4278531wes.15 for ; Sat, 07 Jun 2014 12:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DLNrmoOvsa6/yetnqn/PKynCP21o8vAiKjtm9GhN5og=; b=pwlHKgOTKMXxS1nL8NHpDyCUpFShmAMOBspsfc77FaLl1C5qyqET41G2PekTIxFQws yo3RjdbTMaRGhlCZ6PxlIHPxu1cGdn+x8nXLLxUEQX9Yaz0ag1C5+FkBhek7E7E7Wkzk 2TFQuH5xJR7n8f6UogX21FaXpMzhcgFXBLloPnamGxjL9oDaOUAMAvfCnjqW6va/S9dx Qy9hZr/k/1ChC+JdXApk7FXexZFXOi8qF8YRqbBjfXdus8ZDLlLABv3LoJZpp6StW5O6 GtntDWwYY1qTKhxmnqEDs7urPVwUTKpV+0MuK15+dZfGvmEkIMXiBlXSB0r7uYWydkde OpEA== MIME-Version: 1.0 X-Received: by 10.194.220.100 with SMTP id pv4mr17754573wjc.3.1402170072363; Sat, 07 Jun 2014 12:41:12 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Sat, 7 Jun 2014 12:41:12 -0700 (PDT) In-Reply-To: <20140607192049.8206C119C54@ccr.org> References: <20140607192049.8206C119C54@ccr.org> Date: Sat, 7 Jun 2014 12:41:12 -0700 Message-ID: From: Dave Taht To: "Mike O'Dell" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:41:14 -0000 On Sat, Jun 7, 2014 at 12:20 PM, Mike O'Dell 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 sheddin= g > (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-p= ort 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 critica= l. 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 poss= ible 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 --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article