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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Nov 18, 2020, at 12:13, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi Jonathan, Sebastian,
>  
> Thanks for sharing these tests results again.
>  
> Indeed, a detailed study can be performed to define the optimal behavior. It probably will also depend on the applications using it. I think it is commonly accepted that it is beneficial to prioritize short flows and that we don’t want to spoil the benefit of having a lower latency  (being able to respond faster) we only enabled the RTT fairness after a currently reasonable and easy to implement number of RTTs.  Improvements could be to do this more gradually, … Also if applications stop sending data, and start again, it can be considered to restart the (gradual) RTT independence.
>  
> I guess the basic issue (too aggressive Short RTT flows due to the 0 to 1ms L4S queue latency target) is solved with this,

	Is it? We still see a consistent bias towards Prague over CUBIC, all we need to do is set the low RTT to 26ms... IMHO you "solved" that one test case, but you did not solve the root cause of the issue.



> and I encourage everyone to share data/experience, further study and define more optimal behavior. We can easily change this.

	[SM] As expected I disagree. The proof will basically be whether any other protocol aiming for L4S compliance will pick up that hack or not. Since a WG last call seems inevitable we can revisit this discussion in say 2 years.

Best Regards
	Sebastian

>  
> Regards,
> Koen.
>  
>  
>  
> From: Jonathan Morton <[e-mail]> 
> Sent: Wednesday, November 18, 2020 7:45 AM
> To: Sebastian Moeller <[e-mail]>
> Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency: defaults ready for testing
>  
> On 18 Nov, 2020, at 8:21 am, Sebastian Moeller <[e-mail]> wrote:
> 
> The changes that Oliver submitted to TCP Prague not only increase the fudge RTT to 25ms, but they also, as Koen mentioned, increase the time it takes for Prague to switch to the new fairness mode to 500 RTTs, or 5 seconds at 10ms RTT.
> I really wonder how that affects fairness if the shallow queue is used by a bunch of short flows with 10ms RTT. As far as I can tell the consequences of this delayed engagement have not been described properly. 
>  
> Yes, that engagement delay is clearly visible in a time-series plot.  I think it may even be more than 5 seconds in practice:
> 

>
>
>  - Jonathan Morton