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

[Sebastian Moeller <[e-mail]>]

Hi Koen,



> On Nov 17, 2020, at 14:32, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi all,
> 
> The RTT-independence was implemented, available and demonstrated several meetings ago already and as presented working very well according to our tests. The following parameters are now set as default, so can be tested out of the box:
> 
> All Prague flows with an RTT below 25ms will now converge to the same rate, independent of their real base RTT. This means that flows with a bigger RTT than 25 ms will never have to compete against smaller than 25ms RTT flows. 

	[SM] Mmmh, so all my complaining about a 15ms hack resulted in you changing the number to 25ms... hardly an improvement, and hardly an increase in RTT-independence (which in general would imply a change that affects fairness at any RTTs).

> 
> Now the defaults are set, I'm looking forward to independent evaluations.

	[SM] How is that going to meaningfully change the abysmal sharing between TCP Prage at 20 and at 160ms in DualPI2's shallow queue? Could you speculate how the imbalance is going to look in that case.

Best Regards
	Sebastian


> 
> Hope this helps??
> Koen.
> 
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Lars Eggert
> Sent: Tuesday, November 17, 2020 1:33 PM
> To: Ingemar Johansson S <[e-mail]>
> Cc: 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
>