From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 CDCC4200A76 for ; Fri, 10 Aug 2012 10:48:58 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so1175543wib.10 for ; Fri, 10 Aug 2012 10:48:56 -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=z5xoS4Vhp5JXbJw6xWZeKwopqtJAgiVerUrSonkVUic=; b=HU0zswrCoZ8VlSsEvYszf+UzehZfrGWsdwAMY0gmXcTpG24xx97DnClGNqbDiYDTAf lt2RrCXP5E55iQ9NVgyKNr4hdxsW9kr7z86z8Rn3ZN6uWmuRXUh3RvTjAvAYnmulgX/P Cu3ijgv2ejGJQvqbXqGE5/84B0bZm2b3DyvRAX9ntgTC6FSVgVfN4WWrMa6fOjWgpBrI otT3QbyggTpN9tTmSF0cRVPZXXtr8F0xrClzWb2jAdfn+ElFKD0FpdT6dLutK9lXiDni BSZabiqVmflU/0iyvJngQIwBY+Kqe/pcsqYIa0CMa/XRGHTfwXBqXLRfQwnkSH7zQc7D EeaA== MIME-Version: 1.0 Received: by 10.180.98.138 with SMTP id ei10mr7806261wib.1.1344620936181; Fri, 10 Aug 2012 10:48:56 -0700 (PDT) Received: by 10.223.167.3 with HTTP; Fri, 10 Aug 2012 10:48:55 -0700 (PDT) In-Reply-To: <1344283269.26674.62.camel@edumazet-glaptop> References: <1344048299-26267-1-git-send-email-dave.taht@bufferbloat.net> <1344062738.9299.1453.camel@edumazet-glaptop> <501D99C4.20902@pollere.com> <7EB59257-1A8E-4567-8AD3-5016594565CC@gmail.com> <1344144623.9299.1557.camel@edumazet-glaptop> <4A256974B5054317913BC067C4E5FAE1@srichardlxp2> <1344187557.9299.1610.camel@edumazet-glaptop> <1344188112.9299.1614.camel@edumazet-glaptop> <1344192037.9299.1618.camel@edumazet-glaptop> <8860AEB6C5DB43649852D9A8B40E9B9F@srichardlxp2> <1344271579.26674.45.camel@edumazet-glaptop> <441D6067-BC04-4461-BD91-4A988A089866@gmail.com> <1344283269.26674.62.camel@edumazet-glaptop> Date: Fri, 10 Aug 2012 10:48:55 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target 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: Fri, 10 Aug 2012 17:49:00 -0000 On Mon, Aug 6, 2012 at 1:01 PM, Eric Dumazet wrote= : > On Mon, 2012-08-06 at 12:09 -0700, Andrew McGregor wrote: >> On 6/08/2012, at 10:50 AM, Dave Taht wrote: >> >> > This discussion is getting mildly off-track. My intent in posting this= patch >> > was to prove how wrong the "ecn mark at target" idea was by example, >> > and in doing so, shed light on those new to codel, on how the algorith= m >> > actually works, and to encourage those that didn't grok it, to read an= d >> > run the code in whatever scenarios would help more people to >> > grokking in fullness. >> > >> > I hadn't expected to twiddle a bug! I have put eric's ecn quickack patch into what will be the next release of cerowrt. I think I saw another related one go by, too. >> >> Well, so drop at target is wrong wrt deployed TCPs. Ok, fine. >> >> So, instead, how about this: mark instead of dropping, but only for >> the first few iterations around the while loop in dequeue (so that >> huge backlogs can be drained). The question then is, how many is a >> few? I suppose that can be answered empirically. >> >> Andrew > > Lets take the analogy with RED. > > Once a MAX_THRESH was reached, it did a hard_mark. > > So we could choose a threshold to drop instead of marking. > > Possible easy choices : > > 1) A threshold on sojourn time. For example force_drop =3D 2 * target I tried this and the net result was that: as codel doesn't start the drop scheduler until things are wildly out of wack, that a large percentage of ecn marked packets would be dropped at the outset, and only when things got closer to target would CE start to be asserted. Fast convergence is kind of a feature but, arguably, to use ECN most effectively would be to start off marking and switch to dropping if marking was not being effective in reducing the the delay sufficiently. > 2) A threshold on 'count'. For example force_drop if count > 1000 This has the benefit of having not been tried. However how count varies is presently subject to the implementation. So, new proposal: 3) When entering the drop scheduler for the first time, CE mark rather than drop on ecn enabled packets. Over time (an interval?) keep an overall slope (ewma?) of the curve between ldelay and current delay. If that overall slope is downwards toward the target, then great, ECN marking is working, and we're eventually going to get back to target. If it is upwards for greater than (x), then start dropping instead. This has the desirable properties of: A) Trying CE first B) Continuing to apply CE if it works C) In case of overload, drop But you'll note that there is no code in this proposal, and what an "overall slope" is, is a handwave. > > --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!"