From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 460F220016F for ; Thu, 23 Jun 2011 08:23:18 -0700 (PDT) Received: by iyi12 with SMTP id 12so2550190iyi.16 for ; Thu, 23 Jun 2011 08:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xzN+ZH3UcWDmjoLE5UIY7nHrF4x7hEyG7HOOtQQ3Lbg=; b=CniXz7jLzUEJB/wy/HHmWTkTU7lK+OnT8l28bLCgQvPKqfHkyNs2AMVBVV0ZtXII7q L4fpE0IZf+OHQ2qrbxCDKRLqkqTOzkzMNBzF79vgPBOA9G8Ynp8QEjuYIy9dOAPthaa/ Si1rG2IIZXgkXvGZda17jEgyYLg66qxrHNnIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MWVFfsbngtUr49FnrcI1Tht6KICyCEV99N4dF8LXho9osEHfhnL+vJ6THg1tWnlD9f LFgOy0k1fjj48gL2cfUQFh5Muytf2eDHPXgUNe10dHJiis10doJDvCFX/QTtg41k3s/E rFhRtHC+DRF0VrcPRvRTcRGAjnKpnKlqyw4yo= MIME-Version: 1.0 Received: by 10.231.119.209 with SMTP id a17mr1769407ibr.88.1308844251901; Thu, 23 Jun 2011 08:50:51 -0700 (PDT) Received: by 10.231.13.76 with HTTP; Thu, 23 Jun 2011 08:50:51 -0700 (PDT) In-Reply-To: <7iboxpldmq.fsf@lanthane.pps.jussieu.fr> References: <7iboxpldmq.fsf@lanthane.pps.jussieu.fr> Date: Thu, 23 Jun 2011 09:50:51 -0600 Message-ID: Subject: Re: [Babel-users] QoS for system critical packets on wireless From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 23 Jun 2011 15:23:18 -0000 On Wed, Jun 22, 2011 at 4:12 PM, Juliusz Chroboczek wr= ote: > 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. It was seeing even the minm > >> 1) 'ANTS' are < less than 1% of all packets. ANTS includes system contro= l and >> 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. =A0On 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. I have always needed some minimal level of QoS on all networks I shared with other people, even prior to bufferbloat. As for classification, with asymmetric networks, the canonical example of some level needed is moving interactive packets up in priority over uploads. Once you admit there is some need for classication, you rapidly head down an Aristotelian rathole. Believe me, I'm feeling that - a couple hundred protocols, two mutually sort-of-similar classification schemes in linux (tc, iptables)... the chain of functions a linux box has to call to get a packet from point a to point b is 3 pages long, even before you start trying to classify things. Minimal, ad-hoc classification methods as they exist today are insufficient to handle enough 'normal' cases to accomplish their intent. Wedging everything into Ants, Mice, and Elephants seems a more reasonable approach by the day, although I admit some fondness for diffserv... An example, also taken from the above - no common shaper script out there accounts properly for ipv6 packets, and you can clobber upload bandwidth easily without prioritization for interactive ipv6 packets, too. I struggle with the need for any level of classification, but I reluctantly have given up, and begun to assume that it needs to be done way better and more consistently in the general case. As it is, here's a tidbit from last night... after poking into how 802.11e is supposed to work (mac80211 basically treats values in the skb->priority field in the range 256 0..7 as a map from 802.1d) I went looking into how 802.1p (vlan prioritization, based on d) worked in Linux... from linux-2.6/net/8021q/vlan.h /** * struct vlan_priority_tci_mapping - vlan egress priority mappings * @priority: skb priority * @vlan_qos: vlan priority: (skb->priority << 13) & 0xE000 * @next: pointer to next struct */ At which point I decided to go drinking. (guess what else skb-priority is used for?) I can't believe anybody is actually using this stuff, the details are too deeply buried. >> 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. The problem is that all the packets in the queues ahead of babel can be delayed with deep buffering and exorbitant retries. (I am intensely curious as to the effect of 802.11e on n - if it was modified to support transmitting in the short windows assigned to VI and VO....) > >> 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. =A0However, 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? =A0Julien 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.) Heh. Pre-n, I imagine. > >> 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.) I have. But I don't want to talk about this now, because then I'd want to go drinking again. I do think in the long run that better tools and unifying concepts need to show up that would make routing and firewalling easier and more effective and performant than bridging and ebtables... but if I could toss the bridge code out of the cerowort effort right now, I would. I have got 3x the performance out of the wired side of it by doing pure routing, without DoSing the wireless side, and I get working multicast throughout, too... All I need is a way of generating a unique local mac for the second ethernet interface on first boot. I'm tempted to buy my own mac address range - I'm that frustrated. > > -- Juliusz > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com