Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Jonathan Morton <[e-mail]>]

> On 6 Nov, 2019, at 6:23 pm, Greg White <[e-mail]> wrote:
> 
> - the main result of concern was due to a bug in initializing the value of TCP Prague alpha, which has been fixed and demonstrated to resolve the latency impact that was spanning multiple seconds

Assuming this is still the same Alpha variable as in DCTCP, I take it that you are pre-loading the EWMA over the observed CE marking rate so that, upon first exiting slow-start, you're guaranteed to have a sharp reduction of cwnd.

If I'm understanding that correctly, I would characterise it as treating the symptom rather than the cause.  I do see the Flent graphs you've produced from the new version, and I find it interesting that you apparently now need a period of linear cwnd growth to converge on the actual path capacity after exiting slow-start, indicating a large negative-going overshoot.  I think this sort of artefact is illustrative of a poor match of solution to problem.

SCE's approach to halving the send rate immediately on slow-start exit is to tune the pacing scale factors, as described in the final slide from my Montreal presentation.  It strikes me that this would have the same effect for you, without needing to initialise Alpha to an unnatural value.

May I now draw your attention to the two-flow tests from Pete Heist's collection, in which the two flows are started 10 seconds apart?  I don't immediately see how this particular class of workarounds deals with the problem of needing to sharply reduce send rate in the first flow when the second flow starts, as this is not marked by an exit from slow-start, and by then the EWMA will have decayed to a relatively low steady-state value.  In this case the traffic collecting in the dumb FIFO will be a mixture of both flows.  SCE's approach to this problem utilises the original definition of CE, which SCE preserves but L4S does not.

Since I see that this workaround has been applied to the public TCP Prague repo a few days ago, we should be able to check this behaviour ourselves fairly soon.

> - the remaining short duration latency spike in the FIFO queue is seen in *all* congestion control variants tested, including BBRv1, NewReno, and Cubic, and is not specific to Prague

This is true, and we don't hold that against you.  It's an unfortunate property of this particular network topology.  The aim is to avoid making it worse or introducing additional problems.

> - if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.

This is not relevant, since the point of this exercise is to establish the extent of L4S' compatibility with existing, unmodified networks, in which Codel happens to be the most widely deployed AQM.  You cannot reasonably expect the entire Internet to "upgrade" to L4S compatible AQMs before you can safely begin deployment.

With that said, SCE behaves similarly when the FQ-AQM is SCE enabled.  Note that the AQM doesn't need to know whether the traffic is SCE-aware in order to safely apply the SCE signal, because the SCE and CE signals are not mutually ambiguous.

> We invite a thorough review of the work, but believe that this closes issue #17.

I think that remains to be established with more thorough testing, since a theoretical regression still appears to exist, and we need to be sure whether it's real or not.

Of course, if you are able to robustly solve issue #16, then it is likely that issue #17 will also go away.  I've skimmed your paper on the subject in the past couple of days, and I'm honestly surprised that you are only tackling that problem so late in the development cycle.  Again, we stand ready to test your solutions when they are properly implemented and thus testable.

 - Jonathan Morton