Re: [tsvwg] plan for L4S issue #29

[Sebastian Moeller <[e-mail]>]

Hi Jonathan,

let me chime in below in-line

> On Oct 1, 2020, at 15:08, Jonathan Morton <[e-mail]> wrote:
> 
>> 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,

	[SM] This seems driven by the fact that according to the RFC the dual queue coupled AQ actually is set up with a 1:16 or 1:15 worst case split between the L4S and the non-L4S queue. The idea seems to be to have that as a backstop to avoid "starvation", but only for very peculiar definition of starvation. IMHO differences >= 1:8 over the expected equitable share are clear cut cases of starvation and need to be avoided. 
	The 1:16 rationale falters pretty quickly, because on a massively overloaded link this still does not really guarantee any flow forward progress and simply does not work at low absolute link rates... I note that this is at the core of the whofully under-discussed issue #28...



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

	[SM] +1

> 
> - Jonathan Morton
>