From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 44B9921F2A4 for ; Tue, 24 Feb 2015 10:00:45 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id g201so20720858oib.10 for ; Tue, 24 Feb 2015 10:00:44 -0800 (PST) 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=NO6TTAELrjpc0hvlF7p+SbzU2qpWkpbZHYVogryMno4=; b=hapkM9T+GAsjUSHjFhUdtLykM8bheexavMinQScaCu8Pj9Ib1393cLvCuCfr2mAsdg +a5c/8BdQQddhGLfjf8we1IHIC1qnXlXAY91rP7K4JOABirAVVgMyV6KTjUb9pIDZ4On LJcBdteu1kNg72W7gAqB2YwQb8AjwQWU9lXJwVZWjFDqsBdcNr20Zmn8NCNrIksDEOGY JFJFN7mImruOUH67ARUQfWYCVePir7+e2T3nLQnAGoWzKiUalkC1I81HyS53CBTOKQNR tOuQRHz0eZcVSPP37O4BalaoY0EZf/iqUVLZmgUe8iejD6SrqwnzZjQx5jaThU1zrsVH U6GA== MIME-Version: 1.0 X-Received: by 10.202.111.131 with SMTP id v3mr11332127oik.133.1424800844140; Tue, 24 Feb 2015 10:00:44 -0800 (PST) Received: by 10.202.51.66 with HTTP; Tue, 24 Feb 2015 10:00:44 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 10:00:44 -0800 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sahil grover , "codel@lists.bufferbloat.net" Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. 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: Tue, 24 Feb 2015 18:01:13 -0000 On Tue, Feb 24, 2015 at 8:32 AM, Jonathan Morton wr= ote: > Most of us on this list believe that to be true, in many cases after > performing experiments ourselves, or at least looking through data genera= ted > by others' experiments. > > However, if as I suspect you are investigating various AQM algorithms as > part of your education, you should probably examine the data yourselves a= nd > come to your own conclusions. You may even get extra credit for being abl= e > to describe the difference between AQM and Fair Queuing, and how they can= be > combined (as in fq_codel) to give the benefits of both types in one go. B= ut > for that, you ARE going to need to read some boring papers like "RED in a > different light". It is not particularly easy to keep up with the onslought of AQM literature since the bufferbloat effort started, but a review of stuff since 2011, or even as late at 2013 via google scholar should be illuminating. Many papers use RED as a reference, but nearly all of them miss the major points in the original bufferbloat experiments. Those experiment, long ago documented on Jim=C2=B4s earliest writings on the subject, available in video form, in various papers etc. One example: https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstration-videos/ where jim performed an upload and a ping, at the same time, on a network optimized for downloads and and obviously not tested for uploads. The later rrul test suite (in netperf-wrapper, open source, anybody can use it, and I really wish they did) was designed to exercise both directions of the link with tcp data, and do a latency measurement, at the same time. Either experiment is consistently not replicated by experimenters *to date*, it frustrates me, and the only thing that gives hope is the slow progress in science of resolving the problems in this experiment: http://en.wikipedia.org/wiki/Oil_drop_experiment#Millikan.27s_experiment_as= _an_example_of_psychological_effects_in_scientific_methodology But I am not willing to wait 70 years to get it all sorted out! The core observation I have is : Drop tail queues and AQMs do not do well in the face of cross traffic, (a mixture of small ack packets and larger data packets at saturating loads). This is apparently one of those problems that most aqm-ers (but not van and kathie!) wish to sweep under the rug, as if having a car that can steer on a downhill run only, was acceptable and safe to society at large. I made for-damn-sure that there was a rrul-like test for that scenario in the ns3 code now being mainlined, in the hope that new experimenters and designers of new algorithms would rigorously test for circumstances with cross traffic. I think I should also have got around to doing one in ns2. Moving on, codel was co-designed by the RED guy - van jacobson - and if you don=C2=B4t believe him when he explains how RED was flawed, please stay away from my networks. http://www.pollere.net/Pdfdocs/QrantJul06.pdf There is no information in average queue length. The whole story about red in a different light, is sad and amusing at the same time, when someone finds he has made a mistake, and tries to retract it, and cant get published, and the pile on and noise level since by folk since writing RED related papers, even since we managed to get the correctly contradictory information on RED out there, is annoying. If *all* future aqm oriented papers made sure to address the cross-traffic problem - that mixture of big and small packets under saturating loads - with their latest-aqm-idea-de-jure as part of their *core criteria for worthiness* - it would be a better world. While I certainly believe that you can make an AQM that works better with cross traffic - and actually have some revisions for codel that do so - You cannot predict the traffic load or traffic types going in either direction in most environments and thus you *must* handle it at peak load in both directions, well, in order to have a deployable solution. For all the aqm-related papers of DASH and web traffic down, there are nearly none that test torrent/scp/dropbox or videoconferencing traffic up, at the same time. I would like to be in a world where I could refuse to read any paper that did not address the cross traffic problem, AND such papers were summarily rejected before publication. So, thus, codel is a AQM that combines well with FQ, unlike all other AQMs published to date - and nearly nobody that uses it, uses it without also doing FQ. As it is, fq_codel is deploying rapidly across the edge where it was designed to go, and I see nearly no implementations of RED in the field from extensive talks with operators and firmware makers around the world. *None*, in my last poll at the New Zealand network operators group meeting. Some form of fair queuing, on the other hand, was deployed by over 1/3 the network operators there. (Convincing advocates of FQ that AQM is also needed, has often been a frustrating exercise as well!) Lastly, if you have trouble reading english, there is always google transla= te. > - Jonathan Morton > > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb