From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 215B2202295 for ; Wed, 20 Jun 2012 13:14:09 -0700 (PDT) Received: from 76-10-190-162.dsl.teksavvy.com ([76.10.190.162] helo=kmnmba.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1ShRHz-000O4A-PZ; Wed, 20 Jun 2012 20:14:07 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 76.10.190.162 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/CKCdR3YTq0NfsewQOg9WFVHSZ/mG4doM= Message-ID: <4FE22F10.3060002@pollere.com> Date: Wed, 20 Jun 2012 13:14:08 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: <3455F07C-D677-44CC-B8DD-54070D8CB2E6@gmail.com> <4FE1F1C0.6030808@freedesktop.org> In-Reply-To: <4FE1F1C0.6030808@freedesktop.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Codel] codel "oversteer" 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, 20 Jun 2012 20:14:09 -0000 Good traffic mixing seems to be the answer to ack compression and fqcodel should provide that. I've just started to rerun the reverse traffic scenarios I ran before we wrote the paper, now using (a slight variant of Eric's) fqcodel and it looks better at controlling the queue. It's not that ack compression foils codel; it still works but not as well. Ack compression foils tcp. Kathie On 6/20/12 8:52 AM, Jim Gettys wrote: > On 06/20/2012 06:08 AM, Jonathan Morton wrote: >> Is the cwnd also oscillating wildly or is it just an artefact of >> the visible part of the queue only being a fraction of the real >> queue? >> >> Are ACK packets being aggregated by wireless? That would be a good >> explanation for large bursts that flood the buffer, if the rwnd >> opens a lot suddenly. This would also be an argument that 2*n is >> too small for the ECN drop threshold. > > Yeah, I've been worrying about ack compression... Not sure exactly > what we should be doing about it, as I don't fully understand it. - > Jim > >> >> The key to knowledge is not to rely on others to teach you it. >> >> On 20 Jun 2012, at 04:32, Dave Taht wrote: >> >>> I've been forming a theory regarding codel behavior in some >>> pathological conditions. For the sake of developing the theory >>> I'm going to return to the original car analogy published here, >>> and add a new one - "oversteer". >>> >>> Briefly: >>> >>> If the underlying interface device driver is overbuffered, when >>> the packet backlog finally makes it into the qdisc layer, that >>> bursts up rapidly and codel rapidly ramps up it's drop strategy, >>> which corrects the problem, but we are back in a state where we >>> are, as in the case of an auto on ice, or a very loose connection >>> to the steering wheel, "oversteering" because codel is actually >>> not measuring the entire time-width of the queue and unable to >>> control it well, even if it could. >>> >>> What I observe on wireless now with fq_codel under heavy load is >>> oscillation in the qdisc layer between 0 length queue and 70 or >>> more packets backlogged, a burst of drops when that happens, and >>> far more drops than ecn marks that I expected (with the new >>> (arbitrary) drop ecn packets if > 2 * target idea I was fiddling >>> with illustrating the point better, now). It's difficult to gain >>> further direct insight without time and packet traces, and maybe >>> exporting more data to userspace, but this kind of explains a >>> report I got privately on x86 (no ecn drop enabled), and the >>> behavior of fq_codel on wireless on the present version of >>> cerowrt. >>> >>> (I could always have inserted a bug, too, if it wasn't for the >>> private report and having to get on a plane shortly I wouldn't be >>> posting this now) >>> >>> Further testing ideas (others!) could try would be: >>> >>> Increase BQL's setting to over-large values on a BQL enabled >>> interface and see what happens Test with an overbuffered ethernet >>> interface in the first place Improve the ns3 model to have an >>> emulated network interface with user-settable buffering >>> >>> Assuming I'm right and others can reproduce this, this implies >>> that focusing much harder on BQL and overbuffering related issues >>> on the dozens? hundreds? of non-BQL enabled ethernet drivers is >>> needed at this point. And we already know that much more hard >>> work on fixing wifi is needed. >>> >>> Despite this I'm generally pleased with the fq_codel results >>> over wireless I'm currently getting from today's build of >>> cerowrt, and certainly the BQL-enabled ethernet drivers I've >>> worked with (ar71xx, e1000) don't display this behavior, neither >>> does soft rate limiting using htb - instead achieving a steady >>> state for the packet backlog, accepting bursts, and otherwise >>> being "nice". >>> >>> -- Dave Täht SKYPE: davetaht http://ronsravings.blogspot.com/ >>> _______________________________________________ Codel mailing >>> list Codel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/codel >> _______________________________________________ Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel > > _______________________________________________ Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel >