Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

["Holland, Jake" <[e-mail]>]

Hi Ingemar,

If fragmenting the space will prevent other SDOs from prematurely
adopting the unproven L4S technology, that seems like exactly the
right thing to do at this stage.

I think we've seen strong evidence that L4S may still contain
show-stopping problems.  Also that we have not yet seen strong
evidence that the problems stemming from the ambiguity in the
L4S signaling design can be fixed.

This carries a demonstrated potential for breaking existing
ECN deployments by under-responding to the already widely-deployed
congestion feedback systems.

Certainly L4S's implementation was demonstrated to contain an
issue that would have wrecked the latency of existing ECN
deployments, and it had not previously been detected, despite the
years of lab evaluation and repeated requests from reviewers to
test such scenarios earlier.

Although a fix was found for the specific initially-demonstrated
case, no fix has yet been demonstrated for what looks to be a very
similar issue occurring with staggered flow startup, which can't
be attributed to a wrong alpha starting value:
https://trac.ietf.org/trac/tsvwg/ticket/17#comment:8

The proposed pseudocode fix (with up to 5 tuning parameters, IIRC)
may or may not be able to address this for specific cases, and it
may or may not be possible to discover a set of tuning values that
can address a wide range of conditions, but it seems appropriate
to have some skepticism, at least until demonstration of successful
operation under a wide range of conditions, given the history of
such proposals.  This suggests that we do the opposite of
encouraging other SDOs to move broadly forward with L4S at this time.

I share your concern that we might lose the codepoint (and the low
latency functionality), and I acknowledge that a persistently
fragmented space introduces a risk that it never happens, or takes
an extra decade.

But the risk that concerns me even more is if L4S gets rolled out
and then these kinds of issues are discovered in production, after
other SDOs have prematurely standardized on this experiment, and it
therefore gets shut off with prejudice against future solutions.
That outcome also would lose the use of the codepoint, probably
even more permanently.

(Or even worse: if it does not get shut off in spite of the problems
it causes, which loses even the low-ish latency solutions we already
have, and adds to the congestion control aggression arms race.)

IMO, those would be even worse outcomes than a somewhat delayed
adoption of a fully vetted system (or at least one that can't break
existing deployed networks).

Best regards,
Jake

PS: I still don't understand why the gains available through the
use of regular AQM (especially with ECN) have not been more widely
adopted by the other SDOs that would want to make use of L4S.

It seems possible already to reduce the application-visible delay
spikes from ~200ms to ~20ms (provided that no overly aggressive
competing traffic improperly ignores the feedback, or that
flow-queuing or other queue protection mechanisms are more widely
deployed to prevent excessive damage from aggressive flows to less
aggressive competing flows).

I wonder if whatever would drive SDOs to start using L4S maybe
could instead be leveraged to drive adoption of the much more well-
proven existing ECN solutions, which at least already have a lot
of endpoint support deployed.

The endpoint support is a critical component to making this useful,
and I see no reason to believe it'll be any quicker than the existing
regular ECN was.  I'd even expect less so, since the behavior is much
more complicated and hard to test.

PPS: I agree it would be interesting to see paced chirping solutions
to help do better than slow start, and to quickly grow when new
capacity opens on-path.  But I'll point out that's not specific to L4S,
but rather should have application for any CC that can avoid pushing
the network until queue overflow, which to me likely includes regular
ECN-enabled Reno or Cubic, as well as BBR.

However, as yet another unproven TBD, I'll suggest it's not very
useful as a strong influence on this debate, in spite of the early
demos using L4S.  Regardless of the ultimate low latency solution,
that part will need further development and might not work.