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

[Sebastian Moeller <[e-mail]>]

Ingemar,


> On Nov 17, 2020, at 14:25, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Hi
> 
> I see Prague as work on a congestion control algorithm that can exploit L4S.

	[SM] Fair enough, it really does not matter which protocol is used to demonstrate that L4S' promises can be reached in a way that does not endanger the existing internet. So far TCP Prague is the only contender though, so it will have to carry the lift to demonstrate that L4S is safe to deploy.


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

	[SM] None of these are done and can be tested today, and none of these actually try to implement the Prague requirements that are essential to L4S' safety (IMHO a harebrained decision, protocols gain nothing by implementing the Prague requirements, and hence will not do so, the AQM does not enforce much, so we end up with L4S as a drag race track for CDN to eyeballs, where the only hurdle o admission is going to be to set ECT(1)).


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

	Well, if L4S would retract its proposal to a) exclusively use the ECT(1) codepoint, and b) to redefine how a flow should respond to CE markings, all of that would be reasonable arguments. But L4S is not free of nasty side-effects that need to be considered when weighing its cost and benefits. And without a properly working protocol neither functionality not safety can be fully assessed, Case in point, the fact that protocols are, under the misnamed moniker reduction of RTT-bias, expected to make up for DualPI2's inability to equitably share between the two queues. If protocols do not do this, L4S' operational safety goes to hell, and we are back at ECT(1) flows getting 16 times the rate that non-ECT(1) flows get. If the AQM would be properly designed without such a glaring failure mode the onus on protocols would be reduced.

> I see that the Prague work addresses many of the issues, among then the RTT
> unfairness issue.

	[SM] It does not, as I have posted multiple times, TCP Pragues RTT fairness is considerably worse the e.g. Cubic's. The only thing that is potentially solved (if the repositoeries defaults are adjusted) is the 15ms fairness hole, but labeling that an RTT fairness issue has always been an attempt at smoke and mirrors to deflect from the root cause of the issue by the misdesigned AQM.


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

	[SM] Sure, by all means take your time and iterate until you get it right, but please pause the L4S internet draft process until that point has been reached.


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

	[SM] Well, what is missing is that team L4S offers a theory how RTT bias actually realizes itself and how it can be meaningfully and generally addressed by the end-points. Trying to eliminate RTT-bias without first understanding its root causes seems like a sub-optimal use of everybody's time.


Best Regards
	Sebastian


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Lars Eggert <[e-mail]>
>> Sent: den 17 november 2020 13:33
>> To: Ingemar Johansson S <[e-mail]>
>> Cc: Jonathan Morton <[e-mail]>; tsvwg IETF list
>> <[e-mail]>
>> Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency
>> 
>> Hi,
>> 
>> On 2020-11-17, at 13:46, Ingemar Johansson S
>> <[e-mail]> wrote:
>>> I imagine that, as Prague is work in progress, then the original
>>> authors of this mail thread could have considered to try out the
>>> different options that address the RTT bias. Or at least consider to
>>> re-run the experiment instead of digging down in long discussions on
>>> what is default and not. Prague is work in progress after all, I don't
>>> think that this is unreasonable to ask and it could have saved us a few
>> roundtrips in in this mailthread ?
>> 
>> I've long ago given up trying to follow the blow-by-blow of this overall
>> discussion. And maybe that means I've disqualified myself from having an
>> opinion. But I don't quite know what to make of your statement.
>> 
>> If "Prague" (I guess you mean a TCP variant taking advantage of L4S?) is a
>> "work in progress", why are we then pushing towards finalizing the L4S
> part of
>> the overall scheme?
>> 
>> Maybe I'm naive here, but I always thought the queuing scheme and a TCP
>> variant for it would necessarily go together. That TCP variant might be an
> initial
>> design that maybe doesn't take full advantage of all the benefits the
> queueing
>> scheme might offer, but surely it should demonstrate some significant
> benefit
>> without significant downsides?
>> 
>> And we can of course have a discussion on whether RTT unfairness (or any
>> other property or lack of one) is a significant downside or not, but I
> don't think
>> we've had that discussion?
>> 
>> Basically, I'm trying to re-engage here for a bit to see if there is *any*
> hope
>> for this entire area of work, if I should just ignore it again or even
> start arguing
>> we should abandon it all, given how wedged the discussion between the
>> camps has been for a long time.
>> 
>> Thanks,
>> Lars