[tcpm] Last Call: <draft-ietf-tcpm-alternativebackoff-ecn-09.txt> (TCP Alternative Backoff with ECN (ABE)) to Experimental RFC

Dave Taht <dave.taht@gmail.com> Fri, 17 August 2018 02:32 UTC

MIME-Version: 1.0
From: Dave Taht <dave.taht@gmail.com>
Date: Thu, 16 Aug 2018 19:32:09 -0700
Message-ID: <CAA93jw7_HoZceymx-QASc+_oUR4RYeVA-QDeSUxoO_i8JOJj8g@mail.gmail.com>
To: tcpm@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/fffKG7HrI90JB6kbLpsarI3DnQg>
Subject: [tcpm] Last Call: <draft-ietf-tcpm-alternativebackoff-ecn-09.txt> (TCP Alternative Backoff with ECN (ABE)) to Experimental RFC
Precedence: list

For the record, I do not support this draft.

This group insanity about ECN and ever more relaxed responses to it,
is why I quit the IETF. I'm busy fixing bufferbloat everywhere I can,
with running code, running on real linux and real bsd systems, and
real results[0] - and the only thing I lose sleep over with that
deployment[1] is the thought of y'all making an *already not a big
enough reduction* for ecn response in modern tcps, even worse. [2]

Having left the room, and having realized that few pay attention
anyway to this standards body anymore, *please* feel free to pass it
over my objection. I realize it's just an experimental draft. However,
if there is a future version of this draft, please take my name off
the "thanks" page.

My suggestion, for an "experiment", would be to CE mark to .5, return
linux cubic to .5, and in the presence of both loss and CE marks in an
RTT, back off even harder than that, as you've completely
overestimated the RTT usually at that point.

And then test the hell out of it on the hundreds of flows/minute
typically never exiting IW10 slow start on a your typical edge link,
against a few long running tcp flows, not the other way 'round. I've
had many other suggestions over the years as to valid tests - (many
now in flent) against other forms of traffic, videoconferencing, voip,
etc, loads, against new forms of DDOS made possible by ECN, etc, etc,
all ignored by those afflicted by the ECN madness.

The *deployed* aqms I'm most familiar with, fq_codel, and to some
extent pie, in the crazy overbuffered[3] world we live in, respond
much better to rfc3168-style behavior, in this, typical environment,
where we have to inbound shape 680ms of inherent delay in your typical
CMTS down to something sane.

I have no idea why you need an experimental draft to do this
experiment in the first place. Just do the experiment. On your own
network, not mine, please.

[0] https://github.com/pfsense/pfsense/pull/3941
[1] https://github.com/systemd/systemd/issues/9748
[2] We already, in the sqm-scripts reference distribution, disable ecn
universally for outbound, by default, for fq_codel. Recently, we
enabled it universally for sch_cake, and as an experiment that's not
going particularly well. Please feel free to try these aqms in your
experments as they are widely available in openwrt and the current
linux kernel.

[3] http://www.dslreports.com/speedtest/results/bufferbloat?up=1

PS Better yet, redteam ECN. Simplest experiment, one that blows up
many ecn assumptions, is just hit your aqm of choice with ECT(0),
ECT(1), and CE floods across 1000 udp ports. It's a really hostile
internet out there...

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

[tcpm] Last Call: <draft-ietf-tcpm-alternativebac… Dave Taht