From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 DE29120099A for ; Mon, 6 Aug 2012 10:50:57 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so1501220wib.10 for ; Mon, 06 Aug 2012 10:50:55 -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=RTWqqpHaqmPQonzJGawWUJLXS6BShX49nDIQRTbZmZQ=; b=sJvSHt3lL+ci7OxTGieWLA1e+E89VnoUHM0fs/4FP5K4R4XfhBEHLeS3Z+NpoBZiQm Mo7cER7/jVymJcLtRLeHeaEy5hLfyuTleSY4zCJ7639AABwwClziQwvFdIgIeYXhj9SY jfLOWbQoMMB4r/jqxoAdJasV+jtpwQMxuWiikdK+aEgze4h/o59YY4exsZkCbE/kqG9a LJX+lTp4ql0ruomeQ5tDYjOR44rAxrij2o1qoOqXK9f2Mz0UyjgGobKDahvmRxoxcfHM xd1lFG8tg1+EQVm335zKDwrAfsO5qFRGE5oHX0EgiBPtKhfaLmefi3NeEMToz39IlIgE JkbQ== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr20276939wib.20.1344275455674; Mon, 06 Aug 2012 10:50:55 -0700 (PDT) Received: by 10.223.167.3 with HTTP; Mon, 6 Aug 2012 10:50:55 -0700 (PDT) In-Reply-To: <1344271579.26674.45.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> Date: Mon, 6 Aug 2012 10:50: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: Mon, 06 Aug 2012 17:50:58 -0000 On Mon, Aug 6, 2012 at 9:46 AM, Eric Dumazet wrote= : > Every time we suspect sender has a small cwnd, we enter the quickack > mode. > > So when receiving CE segments, we should do the same. Thats a flaw in > current linux code to do nothing and expect more packets to come. > > It just works because RTO triggers. A lot of bugs are hidden because of > various timers that take some emergency actions. > This discussion is getting mildly off-track. My intent in posting this patc= h 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 algorithm actually works, and to encourage those that didn't grok it, to read and run the code in whatever scenarios would help more people to grokking in fullness. I hadn't expected to twiddle a bug! In a previous mail eric had written: >link with HTB limit of 100Mbit/s >One netperf TCP_STREAM to a non ECN enabled local target, duration 100s >One netpert TCP_STREAM to a ECN enabled local target, duration 100s >1) Current Codel implementation >non ECN target A : 50.55 Mbit/s (4336 dropped packets) >ECN target B : 45.86 Mbits/s (3239 ecn marks) My assumption is that with the ecn quickack fix in place, that these two streams are now more closely equivalent in throughput. >2) Patch to mark all ecn-enabled packets above 'target' >non ECN target A : 95.43 Mbit/s (2957 drops) >ECN target B : 0.97 Mbit/s (2500 ecn marks) And this was the result I'd expected from the patch regardless. While I would expect the ecn quickack thing to help matters, with the "ietf patch" - not mine! I just decided that a negative proof was the quick= est way to move forward! - I would still expect non-ecn marked streams dropped via the codel drop scheduler to seriously outcompete ecn streams being marked at target. but as I'm on the road, and away from my test rig, I lack numbers to deal with. Eric, could you repost the results from these two scenarios? >It seems few people really understood CoDel 'target'. When a link >is used, almost all packets are above target. Thats OK. If it was not >OK, why would we use the sqrt(count) at all, I wonder. Two of the really brilliant parts of codel are that A) it aims to *eventual= ly* hit an optimum target, while absorbing bursts, and B) does so gently using the invsqrt trick to schedule drops at a decreasing rate until an optimum is found, and to continually re-adjust under varying loads to ensure a minimal queue length. The "finding the optimum" portion of codel is still a matter of research, with something like 6 different variants existing so far, and the version published in the original paper being thoroughly obsolete. The current ns2 code has some promising ideas in it, and I went through the trouble of getting that, and what variants I could find for ns2, up on github last week. https://github.com/dtaht/ns2 The ns3 code is also on github, which has a fq_codel implementation too that doesn't quite match the linux code. If anyone would like commit access, let me know. The ns2 version now ALSO contains a re-implementation of fq_codel, made lighter-weight because it is packet oriented rather than byte-fair oriented. NOTE: I have an email about reconciling each of the variants of codel/fq_codel in ns2,ns3, and linux stacked up behind this email, but I'd like to keep trying to nail this ECN issue to the ground, first. My own concern with ECN is finding a way to use it effectively while making it difficult to abuse in the real world. >Codel intent is not to mark/drop _all_ packets above 'target'. >ECN intent is to replace a drop by a mark, not marking packets that >would not have been dropped at all if they were not ECN enabled. I really, really, really would like more folk to run themselves through the behavior of codel in various scenarios, particularly under contention from multiple streams, and in the fq_codel case as well. In part it's a shame that we removed some of the scaffolding that existed in earlier, less optimized versions of the Linux implementation, which lent more insight as to what happened, when. The ns3 code has remnants of that, tracking the major states in codel in a way that's mildly easier to understand. I've had to look at a lot of traces and a lot of captures to get a grip one what actually happens in each variant. --=20 Dave T=E4ht