Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency

[Lars Eggert <[e-mail]>]

Hi,

On 2020-11-17, at 15:25, Ingemar Johansson S <[e-mail]> wrote:
> I see Prague as work on a congestion control algorithm that can exploit L4S.
> Other work is done on e.g. BBRv2 that can use L4S as well, and then we have
> SCReAM that is likely to be updated to make better use of L4S. Like with
> other congestion control I don't foresee a one size fits all here, for
> instance realtime media has different dynamics than bulk transfers

thanks for explaining! I agree.

> I see all these algorithms as work in progress and I don't see it explicit
> in the charter that there must be a fully functional L4S capable congestion
> control available.

Here, I disagree. IMO an existence proof of a CC scheme that derives some benefits from L4S in at least some realistic/common scenarios without suffering from issues is *key* - why else would we do even do L4S (or any other queueing scheme)? How would we even know that we got the queuing part right?

> I see that the Prague work addresses many of the issues, among then the RTT
> unfairness issue. It is still not perfect I guess but all this is a matter
> of brain cycles in --> results out. Prague is an initial design and I
> imagine that it will be improved over time. Also I see it likely that L4S
> capable CCs can draw attention among academics in the future but for that to
> happen we need to move forward to give the signal that we move forward, to
> make it worthwhile to engage in the work.

The future may bring advanced CC schemes that optimize their use of L4S, delivering large benefits without suffering from any issues. But, it also may not. An existence proof of a CC scheme that managed to deliver some benefits for some key scenarios *now* without regressions in others would go a long way to convince me that such advanced schemes are on the horizon.

> The RTT unfainess.. I believe that it has been discussed to death by now. To
> be honest I don't believe that additional discussion will do anything more
> than consume energy. Feel free to disagree.


Maybe it's been too long, but I can't recall the WG having anything like agreement on the question whether less RTT fairness compared to "standard" TCP is OK or not. And I don't have a strong opinion here. What we do need though is agreement in the WG what kind of regressions/changes in behavior from current TCP we're OK with for this new variant of TCP, and which ones we're not. Have we had that discussion?

Thanks,
Lars