Re: [tsvwg] plan for L4S issue #29

[Jonathan Morton <[e-mail]>]

> On 1 Oct, 2020, at 3:42 pm, Mikael Abrahamsson <swmike=[e-mail]> wrote:
> 
>> To be clear, is there a "safety" concern with respect to congestion collapse from overload, or is it an issue concerning relative fairness between flows?
> 
> I don't know where the cut-off is between these, but my worry is that one type of flow might only get few single digit percent of available bw which at slower connections (few megabit/s range) might mean the application using these flows might become unusable.

I think "congestion collapse" would be characterised by the *total* goodput of the network falling off a cliff.  Absent the sort of implementation bug that we uncovered in Spring this year, I don't think we're very likely to see that - though I think we should all be concerned that it took third-party testing to uncover that problem.  IMHO it points to inadequate testing by the L4S team themselves, and I would sincerely hope that they've taken steps to remedy that by now.

The major practical concern is with relative fairness.  A ratio of maybe 2-3x goodput between flows with different congestion controls is probably tolerable, especially since that is already accepted for CUBIC versus Reno in the regimes where Reno is suboptimal.  When that increases to 10x, concerns should be raised.  Meanwhile slides presented repeatedly by the L4S team during IETF sessions show a 16x ratio over some range of conditions, with the implication that this is normal, expected behaviour for L4S versus CUBIC.  Certainly it's about what is expected from a theoretical analysis of the dynamics, and experience with DCTCP which has essentially the same response to CE marks.

By all means, put me in the camp where accepting a 16x goodput penalty to existing traffic when an L4S flow starts up is unacceptable.  The "classic detection heuristic" was presented as a solution to this problem, but I think we can agree that it did not succeed.

 - Jonathan Morton