Re: [tsvwg] Reasons for WGLC/RFC asap

[Jonathan Morton <[e-mail]>]

> On 21 Nov, 2020, at 10:25 am, Sebastian Moeller <[e-mail]> wrote:
> 
>> In my personal opinion, strict adherence to zero-harm is too constraining, since it doesn’t provide any way to assess the upside potential of a new algorithm.
> 
> 	[SM] +1; but current L4S' issue is not that it is not given leeway to do a bit more harm, but that ATM its harm on rate in some conditions realy seems bound by TCPs unwillingness to reduce its congestion widows below to segments...
> 
>> * https://www.cs.cmu.edu/~rware/assets/pdf/ware-hotnets19.pdf
> 
> 	[SM] Yes, great link from Wes, but I am sure we will end in weird food-fight immediately, as team L4S will try to trade the harm done on the rates of non-L4S flows with the benefit to the latency under load for the L4S flows. Ignoring the fact that in both cases the harm-benefits are pro L4S and contra non-L4S. 

As the Ware paper already points out, the "harm" metric deliberately *ignores* the benefit to the newcomer CC's traffic, and focuses on the harm done to status-quo CCs' traffic.  In this respect, merely glancing at the test data posted by myself and Pete Heist over the past few weeks (and indeed the past year) shows that L4S and TCP Prague are capable of inflicting substantial harm on existing CUBIC traffic, which has been established as being quite prevalent in today's Internet.

The acceptable threshold of "harm" to permit deployment is not zero, but some function of the harm done by the same workload added using the same status-quo CC.  The precise form of that threshold function is not yet fully established, but it is possible to obtain objective numbers describing "harm" and begin to analyse them.  I predict that when such analysis is published, L4S and TCP Prague will not come out of it looking good.  But it may take some time to rejig our test suites to generate accurate harm metrics.

 - Jonathan Morton