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

[Ingemar Johansson S <[e-mail]>]

Hi Jake
Please see inline

/Ingemar

> -----Original Message-----
> From: Holland, Jake <[e-mail]>
> Sent: den 18 november 2019 01:46
> To: Ingemar Johansson S <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; Ingemar Johansson S
> <[e-mail]>
> Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-
> tsvwg-sce
>
> 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.

[IJ] One can see things differently, the work to address the need of latency 
sensitive applications that also drive high demands is happening now in 3GPP. 
If the IETF finds it-self in a situation where it offers two conflicting 
solutions , using the same bits, then I would expect that none is selected. 
Instead IETF will get future work with the standardization of some other 
technology to address the same issue, call it rate recommendation or whatever. 
These ideas have been proposed before and have so far not fared well in the 
IETF.

>
> 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).

[IJ] Following the discussion, the only burning issue that persistently pops 
up is the 0-RTT issue and it should by now be quite obvious that this is a 
manifestation of the RTT unfairness in existing congestion control algorithms. 
This use case gives L4S flows a 1ms RTT and classic flows a 15ms RTT. This was 
addressed early on in the L4S work and there is an effort to fix this in TCP 
Prague. One can end up in discussions like the 15ms target gives Cubic CC 
flows a disadvantage and that this is a proof point that L4S is flawed. 
However..
FQ-CoDel is not problem free either see 
http://dl.ifip.org/db/conf/networking/networking2017/1570335770.pdf , which 
later on led to the alternate recommendations in RFC8511, in other words the 
unfairness issues are to be addressed in the endpoints.
It will never become perfect however. If you want 100% fair fairness, then you 
need QoS, and sometimes not even that will help you if one flows is 
occasionally application limited and the other is not.

And finally.. My observation is that there is a lot of concern that classic 
flows will get an unfair treatment and that L4S flows will do better, to a 
large extent I see it as that there are flaws in classic congestion control 
than L4S can fix. Perhaps then better to use L4S instead ?.


>
> 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.
>