From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.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 9AC9E200628 for ; Fri, 24 Jun 2011 06:39:47 -0700 (PDT) Received: by iwn34 with SMTP id 34so3767861iwn.16 for ; Fri, 24 Jun 2011 07:07:47 -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=gx/gVw9/6TiSD41EI+Utt/c8Oc/E7U/SGekgk9J8E0s=; b=AT5I/WVbYpcjNXguDIOSWSBHNfIM71wsMaAMaRQrfvwaqp2lLkrvM0xam601cYpsEm zxT0VNJZ/IO6H+UDkp+p1E702vxLZgOUE52FPjgyW+Cg5AJ0AlAQ5PtvoMwTzSAxjJsI fg8eaeZ/AaFW8tHU6QpeA0qGBQ2pm/eiGB2qU= 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=c7Q8ElCnTfHoePYEk5/Cj+c997WgBuFj20TNL05y5ZyMDOTyI6SDlvbsgWe4I6EFw6 djgZN5b0+KPf5yNK6eXm8Hn/7rNPHuEYwKKALnS8MyiGXYoks8GgcM02QgVUa1CTKCMZ Y1pIdmdn5LlnlFU31ejQ+3Zenl3MuNdLxC0DQ= MIME-Version: 1.0 Received: by 10.42.246.131 with SMTP id ly3mr3709272icb.495.1308924467401; Fri, 24 Jun 2011 07:07:47 -0700 (PDT) Received: by 10.231.32.137 with HTTP; Fri, 24 Jun 2011 07:07:47 -0700 (PDT) In-Reply-To: <7iliwrpf1v.fsf@lanthane.pps.jussieu.fr> References: <7iboxpldmq.fsf@lanthane.pps.jussieu.fr> <7iliwrpf1v.fsf@lanthane.pps.jussieu.fr> Date: Fri, 24 Jun 2011 08:07:47 -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: Fri, 24 Jun 2011 13:39:48 -0000 On Fri, Jun 24, 2011 at 6:52 AM, Juliusz Chroboczek wr= ote: >>> Once you've fought the bloat, there's hopefully no further need to >>> classify these packets. > >> As for classification, with asymmetric networks, the canonical example >> of some level needed is moving interactive packets up in priority over >> uploads. > > Unless your network is badly underprovisioned, some form of roughly > fair share scheduling (say, SFQ) should be all you need. That caveat is crucial. On the dark areas of these maps: http://www.google.com/search?q=3Dsatellite+night&hl=3Den&client=3Dubuntu&hs= =3Deu7&channel=3Dfs&prmd=3Divnsm&tbm=3Disch&tbo=3Du&source=3Duniv&sa=3DX&ei= =3DS5kETvjwBeWt0AGWip3oCw&ved=3D0CC8QsAQ&biw=3D955&bih=3D427 most of the dark areas will be underprovisioned for many years to come. Every dense wireless network is underprovisioned. 3G, 4G, wifi, etc. Lastly, bandwidth requests always expand to be in excess of what is available. Once, we did youtube at 320x200. Then bittorrent... Now it's netflix, and HQ video, and facetime, etc. I have some hope that we've reached the end of the S-curve on normal usages of bandwidth and that the technology and infrastructure can now have some time to catch up. Classically under/over provisioning has been cyclical. > >> Once you admit there is some need for classication, > > I certainly don't. =A0We should be simplifying our networks, not making > them even more complex. =A0(Dave, I'm seriously worried you're heading in > the wrong direction.) Classifying traffic and looking at Ants has proved useful and in some ways is a fallout from the background bufferbloat detector idea for ntp of a few months back. For example, I would never have spotted the syn flood limit a few days back had I not been looking at mice and noticing a huge difference between syn attempts and actual connections. Many other examples of productive analysis exist of various forms of tcp streams vs the bufferbloat background radiation, and doubtless, many other 'hacks' exist that are harming the network more than help it. At the moment I can filter against ant-like traffic and quickly produce a scatter plot that at a glance shows the overall health of the network. As for the complexity, the network is already pretty complex as noted earlier, and I would hope that being aware of the ants would lead towards better diagnoses of the root causes of problems. Raising the Ants to the same level of awareness academic analysis as TCP mice and elephants have had would be a very good thing. As for actually doing shaping, I have great hopes that once bufferbloat is licked, and the fallout, and classic means of dealing with great bandwidth disparities are more widely implemented, that shaping techniques such as SFB and SFQ will work well again. But that's all it is. Hope. I figure, at best, I'll have a network as responsive and reliable as the networks I had in the mid 2000s. >> I admit some fondness for diffserv... > > The first step is to admit you have a problem ;-) Heh. Back in the early 80s I was one of the radical packet-heads, in an all out war with the bell-heads. I've come to thinking that although we won that battle, we lost the war. Nearly every voip network uses separate provisioning, and I think that voice quality has degraded significantly over the last decade. I had a long cherished dream of one day being able to have a 'jam-o-phone' - a device that would let me play live music with the housebound old buddy down the street, over the net, but even as bandwidths have grown hugely, our ability to keep latencies and jitter down to low levels has also degraded hugely. > > -- Juliusz > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com