From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 5764B21F34B; Sat, 21 Mar 2015 22:28:30 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZYR1-00058O-F1; Sun, 22 Mar 2015 06:28:27 +0100 Received: from [38.96.210.190] (helo=[10.1.212.173]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1YZYR0-0006kU-Dr; Sun, 22 Mar 2015 06:28:27 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Sun, 22 Mar 2015 00:28:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 14 sum msgs/h 3 total rcpts 26708 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 19FB97EDEC434F68C35DDDD003D58A4EDCCD2154 X-UiO-SPAM-Test: remote_host: 38.96.210.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 6 max/h 4 blacklist 0 greylist 0 ratelimit 0 Cc: Jonathan Morton , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] please kill the ECN thread from hell here and take it to aqm X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 05:28:59 -0000 > On 21. mar. 2015, at 23.57, Dave Taht wrote: >=20 > On Fri, Mar 20, 2015 at 5:15 PM, Michael Welzl = wrote: >=20 >> I think it's about time we finally turn it [ecn] on in the real = world. >=20 > Please start with turning it on as fully as possible on *your* = networks. >=20 > Advocacy with *actual experience* I approve of, otherwise it's just > religion and a rathole. We, and others, have done many tests with it. > I only once been so tempted to shut a thread down on these email > lists. (the other time was a near-discussion of systemd) >=20 > This thread started off usefully discussing the docsis 3.1 deployment > and other deployment issues and if I could invoke godwins law on ecn, > I would. Hell, let me try that. Only a nazi would inflict such a > controversial technology on others without comprehensively trying it > themselves on all their own traffic. For years. >=20 > The ecn debate is a 21 year old bikeshed from hell. There is no > comprehensive data from actual deployments. >=20 > Start with getting some from yours! And from whoever else you can > convince to try it, at scale, and not in manifestos that have so far > as I can tell, a multiplicity of false premises and wishful thinking, > not backed by any operational experience with the actual code > available. The paper I mentioned in this thread used actual code on actual machines = :-) > Go ahead, convince your org(s) to deploy it, get everyone using your > network to use it on every operating system available, have meet ups > for every new student entering your uni to turn it on, have a black > hat take the existing aqm algs apart, and then write a document > describing those experiences. *Then* write the rfc. >=20 > *I* deployed it. I gave my feedback already. >=20 > My conclusions 3 years back were: >=20 > 1) ECN is safe to deploy given the bottleneck links had fq + aqm > w/ecn, and the links were high enough bandwidth to not slow other > traffic. But at lower rates, it clears congestion fastest, and uses > less memory, to drop packets. >=20 > 2) It might be safe in limited well controlled environments (e.g. in > data center, and especially in long RTT environements in space or > satellites), but a wide range of testing on actual traffic mixes on > things like DCTCP - and what happens when things like DCTCP > accidentally escape the datacenter needs to also be carefully > evaluated. >=20 > 3) It is not safe to deploy on the wild and wooly internet with any of > the pure aqm algorithms currently available. You saw all these three things in your home by watching ECN traffic with = wireshark, or what? 1) might be something you can "experience". The figure in the paper I = mentioned earlier in the thread shows that it's inconsistently sometimes = better, sometimes worse if all you look at is the queue (as opposed to = the actual end-to-end delay at the application layer, which includes = head-of-line blocking). > I have seen no data to come close to challenging these conclusions, > nor tests, nor deployments, and until that happens... Challenging conclusion 1: figures 13 and 14 in = https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434= .pdf?sequence=3D5&isAllowed=3Dy Note that these diagrams show a distribution, not a single test = somewhere. Many tests, using real equipment and the actual totally real = code. In cases with only one flow for example, goodput was slightly lower with = ECN, meaning: less packets, less congestion, less memory usage. 2) is an assumption, talks about DCTCP and has nothing to do with the = current discussion. 3) is also an assumption. Why "not safe to deploy"? Again, did you see = this on your own home connection with wireshark, or how can you conclude = that? In terms of packets successfully passing through the Internet, a = number of recent measurement papers generally find that the situation = has significantly improved. Perhaps the most recent one: = http://www.ict-mplane.eu/sites/default/files/public/publications/311ecndep= loyment.pdf This is only one paper; lots of data does exist. > ...In addition to getting off the aqm mailing list, I am now sending > anything I get with the evil " ecn " in it directly to /dev/null - > until prague or I get way better BP meds. I got way better things to > do. Apologies for taking the liberty to still answer your email :-) Cheers, Michael