[tsvwg] dave taht's rationale for option 3 on ect(1) (more testing)

[Dave Taht <[e-mail]>]

The codebases, simulations, etc, for the l4s and SCE approaches
are still in a very raw state. With these early implementations,
many problems have been identified, and only a few resolved. The
internet drafts and codebases are out of alignment, with new
bugs landing in the codebases and operating systems every time
someone takes them out for a spin.

Nearly all the tests bufferbloat.net considered basic in the
development of the original pie,
codel, and fq_codel aqms in the aqm working group as of 2004 have yet to be run.

Participants may weight the results differently, but adversarial tests
of all kinds
need to be run, regularly, in response to every change to the
specification and code,
in order to retain an accurate picture of the problems found, fixed, or ignored.

(I confess that much of my interest in lossless congestion control
comes from longer
 RTT near earth orbit, geo, and gto - and even more distant space-born
applications,
 which is a from-orbit viewpoint I suspect few here share)

To the greatest extent possible, tests to be performed in simulation
AND on a variety
of real hardware, AND in virtualized environments.

The recent bugs found in encapsulations need to be evaluated against more tunnel
types and operating systems. More shipping switches and hardware based
need to be tested and configured using ect(1) -> CE transitions, in
particular, to
see what happens.

Problems with legacy uses of the IP stack, for private and industrial
and embedded
r/t control use, have not been explored either. Examples include 6lowpan, and
other relatively unknown services in the ietf you can find in all the
other ethernet
packet types known to man.

The potential side effects on classic traffic, have been barely explored,
if at all. The impact on conventional udp and classic gaming, voice,
and DNS traffic
of the pie side of the l4s solution, (with the initial exploration of
the rrul_be test
showing up bugs galore), is largely unknown.

The true effects on the internet of senders such as the increasingly
available BBRv1 with RFC3168 ecn accidentally enabled deployment
needs analysis, as do the effects of a modestly or truly lying senders.

The costs and methods required to mitigate ECN-enabled DDOS attacks, also
is absent from analysis.

The side effects of essentially deprioritizing classic routing
protocols and other essential oam and maintenance packet types
(such as rip v2 (used on cable), ospf, Babel, ISIS, RA, ND and ARP),
needs to be explored.

The effects on existing deployed RFC3168 compliant multicast file
transports such as
uftp[1], needs to be tested.

Recognising “loss and mark” as an even stronger signal than either,
not thought about.
There's a long list of other more trivial things - dynamically
reducing mss size at cwnd 2 or less,
improving packet pacing to cope with sub cwnds, more fully exploring l4s-style
behaviors on unreliable, jittery networks such as wifi and lte, and chirping.

In short:

I see no reason for the IVTF to allocate the ECT(1) codepoint at this
time without
a ton more simulation and testing.

With a lot more robust, repeatable testing, good software engineering practices,
complete with regression tests, and continuous integration, and source code that
matches the internet drafts (and vice versa), perhaps we can all find
a way forward
closer to the goals of low latency and high throughput and the most
viable, safest,
use for this last half a bit in the IP header.


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

[e-mail] <Dave Täht> CTO, TekLibre, LLC Tel: [phone]