From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 9BAE621F1A9 for ; Wed, 10 Jul 2013 14:42:16 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so16263180iec.22 for ; Wed, 10 Jul 2013 14:42:15 -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=kdh0iUD/ASXOOAOa+KbY4fyil00iifYfaeCTYojadkA=; b=GZ2mA+T/PfdIuxYZst/kMAOE69m1urM8Vf4iIYKREQ0MPWITycsIoZgxgsOcLwQJkh RbxkedMFYxpX6XBiuqE076WJKV61gCmZ8LGSgER5sM1spqyyhZ5ck5OgEQkBxJhvcphA qWfHSS/mHMF/3fZkPejVAo9SBChIB9GopPDruXtaRBnAp9EqxVPocSMXGyPQWf3VoGd5 Rlcd8GIzRy2OKp0UJ9i8qfMpYNyV/KOnAPVs8hgU9gd5/EZwQ2BxuIpZU+9Aa8ujwr6O AnFr/Qe6y8L6fRXnqZG1/bKVkan2FDnMhxKx0JrqroovJ2GPHtSZ/Xlh00P82guf1dov 04mA== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr445209igs.37.1373492535851; Wed, 10 Jul 2013 14:42:15 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Wed, 10 Jul 2013 14:42:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jul 2013 14:42:15 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Winstein , "codel@lists.bufferbloat.net" Subject: Re: [Codel] sprout X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:42:16 -0000 On Wed, Jul 10, 2013 at 1:46 PM, Jim Gettys wrote: > > > > On Wed, Jul 10, 2013 at 4:41 PM, Keith Winstein wrote: >> >> On Wed, Jul 10, 2013 at 4:38 PM, Jim Gettys wrote: >>> >>> Did you compare with fq_codel? None of us (Van included) advocate CoDe= l >>> by itself. >> >> >> Hi Jim, >> >> In our evaluation there's only one flow over the queue (in each directio= n) >> -- the videoconference. So, yes. >> >> In the upcoming paper where we try and come up with the best end-to-end >> schemes for multiuser traffic, we compare against Cubic-over-sfqCoDel >> (http://www.pollere.net/Txtdocs/sfqcodel.cc). One of my problems with keith's paper is that it is playing against traces that assume the background load will itself not mutate based on available bandwidth. Love the tracing idea tho... > > Great. > > I sure wish we could get together on *fq_codel variants. Kathy thinks th= at > there is no difference between sfq_codel and fq_codel, and Dave thinks th= ere > is a difference. I documented the differences between codels and fq_codels at some point on some web page somewhere. The original ns2 codel code as published in the magazine contained an error and should not be used at all. linux codel uses a more drastic fall-off curve than ns2 codel. The ns2_codel patch I have for linux uses much "tighter" constraints on the interval and in the range of RTTs I was testing at the time (sub 20ms) did a lot better than linux codel. It is based on the "experimental" codel code on the pollere web site, but excludes the floating point hack at highest rates. The nfq_codel patch, based on that, tries to use a compromise between SFQ and DRR, providing single packet SFQ-like service within a smaller DRR-like quantum (usually 300 these days) across the flows. Results of nfq_codel vs fq_codel have been rather inconclusive, and I decided I needed tests that covered the entire range of useful stuff, like web, voip, and video conferencing, which is a lot of work for which we have no funding. There are some hints that nfq_codel does better against voip, in particular, but competes more slowly against reverse traffic than the DRR approach in fq_codel. the ns2 sfqcodel uses the std ns2 model of codel, and something very close to nfq_codel. It has been unclear from reading the code if it actually does the "new flow" idea right relative to the smaller-than-mtu quantum. BUT in summary: In all cases the differences between *fq_codels are pretty subtle, but rather dramatic compared to std drop tail. I'm satisfied at this point that drop tail should die, and that some form of fq_codel be made the default in linux and then we can get around to arguing other points with data at scale. I am unsure if enough of the core linux network devs agree - and there are issues with handling multi-queue devices in particular remaining, and I am unfond of TSO/GSO/GRO as it stands (but eric's got some fixes planned). It would be great to see a patch obsoleting pfifo_fast hit mainline linux... In particular web traffic "cuts through" other sustained flows like butter, and is almost entirely based on the RTT (as are things like dns). My primary nfq_codel deployment with a couple dozen users is pretty darn successful compared to what was running before. It is really astonishing how well it works even against multiple DASH flows and torrent. and in any case, what I'm mostly concerned about these days are dozens of flows in slow start on a given web page vs 1-3 uploads/downloads (and lately, videoconferencing), AND the behavior on wifi access points, which as keith points out, really needs per user queues in order to even begin to think about performing as well as it did a decade ago, prior to N, and has a dozen other "easy" fixes that will take many man-months to develop and test even on a single architecture. I am reluctant to re-join the simulation campaign using ns2, as the deployed TCPs differ rather radically from the models. I prefer measuring reality, which unfortunately is sloppy, buggy, and hard to make repeatable. It does appear that Eric's new netem patches are going to make it possible to run more accurate longer RTT (100ms) live network simulations at higher rates than I ever could before. (THX ERIC) The results I get in the lab with the current (prepatched) version of netem are pretty dismal... http://results.lab.taht.net/delay/rtt_fair_50_netem_10000_fq_codel-100mbit-= 2.svg and unusable at gigabit http://results.lab.taht.net/delay/rtt_fair_50_netem_10000_fq_codel.svg /me goes back to building patched kernels > > Sigh.... > - Jim > >> >> >> Cheers, >> Keith > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html