Subject: [tsvwg] dave taht's position on ECT(1)

From: Dave Taht <[email-masked]>
Date: Sun, 26 Apr 2020 10:13:32 -0700

Tsvwg list members,

Speaking for myself (but I and teklibre are one and the same). I agree
with all of luca muscarillo's comments and most of jakes.

I support ECT(1) as a network output.

tl;dr

I would like y'all, stuck at home this month, to be upgrading to the
great aqm, fq, and transport algorithms we already have, without
RFC3168 style ecn (if you must), and to be discussing all these ecn
issues while fully cognizant of how good what we already have, can be.
Who of the participants of this discussion are using what has already
deployed to any extent?

Who among you is bufferbloated? How many are still stuck behind fifos?
IMHO: Only with an informed debate with the participants using what we
already have, can we create stepping stones to further progress.

(My recent PSA on this topic did get 5 ietfers to upgrade, I'll write
about that elsewhere)

The jitter and hardware retry characteristics of wifi in my opinion
make a simple 1/p approach for a transport unviable for that
technology. I think there is a large impedance mismatch between the
perceived demands of wired and wireless technologies in both camps to
date.

In wifi an earlier notification of congestion than permitted by
RFC3168 AND permitted by RFC8311 MAY well prove useful when coupled
with an RTT sensitive algorithm such as BBR, or the congestion control
predominant in webrtc web browsers today - gcc. However the *abrupt*
signal defined for CE in RFC3168 is needed for wifi to rapidly
compensate for changes in bandwidth, and in fact, reacting even more
strongly to a combination of loss and CE and relative to the measured
RTT would be useful.

This is a nuanced statement in that I'm saying that a transport
reacting to RFC3168 style CE needent be by half or 1/p but being RTT
sensitive over a short window and/or other heuristics.

 A world where we could turn safely ect(x) entirely on or off within a
given flow would be good as deltas are ok to drop, in order to hold
the jitter low. (I do not know enough about the current status of nada
or scream, but gcc I have multiple implementations of)

Furthermore, increasingly, elsewhere, there is no "p", for 1/p as bulk
offloads are increasingly the norm, and I've seen no work here (not
that I've been paying much attention), as to how well either the SCE
or L4S approaches can work against such bulked groups of packets. (?).
ASIDE: It was disconcerting to discover that enabling accecn presently
MUST disable most (all?) existing tcp offload engines, recently)

Based on my experiments worldwide I do not believe "tcp" ecn can be
successfully negotiated often enough on the internet, and the
fallbacks and workaround and heuristics required to work around this
are too difficult to deploy. seeing (I forget the paper name,
sorry!, port 80 negotiated ecn but not 433 in others. That one didn't
test things like smb, iot, and other common uses of tcp)

After my extensive testing of the latest OSX, it seems to contain such
a plethora of hacks and workarounds that it is not useful to test ecn
usage and availability using that os until those are fully documented.
example: a two successive runs of the rrul test disable ECN
negotiation entirely. The syn attempts I collected from arins dataset
correlated against the browser type was much lower that expected.
Improvements to the 3way handshake are desirable, but... I give up on
fixing tcp.

As I've observed dscp surviving cloud <-> cloud pretty well, I support
redoubled efforts to make that work e2e, however, declaring that
a given dscp marking indicates "This transport promises to use
different congestion control" I think is unviable in the wild,
and it would be better to improve deployment of CS1/LE, AF42 (google
congestion control), which have more of an application
oriented focus.

I would support shifting this entire debate away from modifying tcp
and onto co-existing of tcp with newer transports like quic and
webrtc, and a renewed focus on the impact of new these approaches on
human perceptible latencies and human QOE for interactive
communications.

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729