From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B2209200034 for ; Wed, 22 Jun 2011 14:45:31 -0700 (PDT) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p5MMCELK017315 ; Thu, 23 Jun 2011 00:12:27 +0200 (CEST) X-Ids: 168 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 67E23C2E53; Thu, 23 Jun 2011 00:12:13 +0200 (CEST) Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.76) (envelope-from ) id 1QZVef-0001A6-8r; Thu, 23 Jun 2011 00:12:13 +0200 From: Juliusz Chroboczek To: Dave Taht Subject: Re: [Babel-users] QoS for system critical packets on wireless References: Date: Thu, 23 Jun 2011 00:12:13 +0200 In-Reply-To: (Dave Taht's message of "Wed, 22 Jun 2011 09:17:35 -0600") Message-ID: <7iboxpldmq.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4E0268BE.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4E0268BE.001/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: bloat-devel , babel-users@lists.alioth.debian.org X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:45:32 -0000 Dave, My points below are tainted by the fact that I deeply dislike classification -- I'm hoping for solutions in which there's no higher layer knowledge in the routers. > 1) System control and 'MICE' are < less than 1% of all packets. Mice > includes a bunch of messages like ARP, NTP, UDP, and most of the icmp6 > portion of the stack, in what I'm doing currently. Once you've fought the bloat, there's hopefully no further need to classify these packets. On a working network, you should be able to achieve less than 5% packet loss, even without ECN, and all protocols should be able to support that level of loss. > A) wireless devices are currently making heroic efforts (deep > buffering, exorbitant retries) to get packets through. Seeing a big > delay between transmit time and reception is more an indicator of > congestion than actual packet loss is right now. By the time you see > actual packet loss, the network has often already collapsed > completely. Not for multicast -- there's no link-layer ARQ for multicast in 802.11. That's why RFC 6126 says that you MUST send hello TLVs over multicast only. > C) QoS, Packet marking and prioritization of any sort makes babel > control packets jump closer to the head of the internal queues of the > transmitting clients, thus speeding up routing change propagation. Yes. However, Babel is designed to support loss rates up to 80% or so, and therefore should normally only collapse when your network has already collapsed. (The reason for that? Julien used to have a couch in his office, where the pre-ARQ loss rate to the closest Babel router was well above 50%. We put a lot of effort into ensuring that Julien could read mail on his couch.) > I've also written elsewhere about the effect of multicast traffic on > wireless and am trying hard to stop bridging gigE (1000Mbit) and > Wireless (a,b,g,n) together wherever possible, Hear, hear. (Somebody please bring that up with the OpenWRT folks.) -- Juliusz