[Cerowrt-devel] please kill the ECN thread from hell here and take it to aqm

[Michael Welzl]

> On 21. mar. 2015, at 23.57, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Fri, Mar 20, 2015 at 5:15 PM, Michael Welzl <michawe at ifi.uio.no> wrote:
> 
>> I think it's about time we finally turn it [ecn] on in the real world.
> 
> Please start with turning it on as fully as possible on *your* networks.
> 
> 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)
> 
> 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.
> 
> The ecn debate is a 21 year old bikeshed from hell.  There is no
> comprehensive data from actual deployments.
> 
> 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.
> 
> *I* deployed it. I gave my feedback already.
> 
> My conclusions 3 years back were:
> 
> 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.
> 
> 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.
> 
> 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=5&isAllowed=y
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/311ecndeployment.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