Re: [tsvwg] L4S vs SCE

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

It should be fairly simple for an explicit and very frequent congestion signal, isn't it? This is basic stuff, where you can find a lot of information and papers on already...

Agreed that for delay based CCs this is another issue... but this is not the case here at all.

Koen.

-----Original Message-----
From: Jonathan Morton <[e-mail]> 
Sent: Wednesday, November 20, 2019 4:01 PM
To: Sebastian Moeller <[e-mail]>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; G Fairhurst <[e-mail]>; [e-mail]; Ingemar Johansson S <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tsvwg] L4S vs SCE

> On 20 Nov, 2019, at 10:18 pm, Sebastian Moeller <[e-mail]> wrote:
> 
>> One of these opportunities here is to make L4S_TCP less RTT dependent. There have been many working implementations for less RTT-dependent CCs in the past. One that is widely deployed is Cubic, which is doing this for getting more throughput for longer RTTs. The only reason why it didn’t fly for lower RTTs on the current Internet is that they would hurt themselves (get lower throughput, competing with Reno).
> 
> 	[SM] Looking at the pfifo_fast results in Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. For Cubic/pfifo_fast (linux former default combination), I fail to see a strong indicator that cubic is RTT invariant or getting more thoughput at longer RTTs (except for the 10ms versus 50ms "hump"). What paper/data should I be looking at instead?

CUBIC is more RTT-invariant than Reno is, and achieves more throughput on high-BDP paths than Reno does, which I think was the meaning here.

Examining the formulae for calculating steady-state average cwnd from marking probability, and converting to throughput by dividing cwnd by RTT, it's clear that any CC algo that depends only on marking probability for cwnd evolution will converge to an RTT-invariant cwnd and will thus have the same RTT-fairness of throughput with itself as Reno does.  This is in fact true for TCP Prague and all of SCE's response functions thus far.

But CUBIC includes an RTT term in its steady-state formula which partially compensates for the conversion to throughput, such that CUBIC's self-competitive throughput in its high-BDP regime is proportional to the reciprocal quartic root of RTT, rather than to the plain reciprocal.

So I think that to meet Prague Requirement #5 - reducing RTT dependence - one must first achieve at least as good performance as plain old CUBIC in this respect.  Is there work towards this in progress within L4S?

 - Jonathan Morton