Re: [tsvwg] Review comments on a careful read of the L4S ID (#2: RTT Variance)

["Black, David" <[e-mail]>]

Going back to the original comment ...

>>    “The two changes counterbalance
>>    each other so that the throughput of an L4S flow will be roughly the
>>    same as a non-L4S flow under the same conditions.”
>>   
>> ⁃          Please insert “comparable” before “non-L4S flow” to avoid bogus flow comparisons.
>> 
>> =================================================================
>> 
> 
> [BB] Isn't 'under the same conditions' already a more precise way of saying 'comparable'?

No, the concern is that "under the same conditions" will be (mis-)read as "under the same network conditions" inviting bogus comparisons between L4S and non-L4S flows with very different RTTs and lifetimes.

Sebastian's concern about DualQ design/behavior is a separate comment, and the appropriate place to address it (if more text is in order) would likely be the dualq-coupled draft.

Thanks, --David

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
Sent: Thursday, May 13, 2021 4:23 PM
To: Bob Briscoe
Cc: Gorry Fairhurst; [e-mail]
Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID (#2: RTT Variance)


[EXTERNAL EMAIL] 

See [SM]

> On May 13, 2021, at 20:09, Bob Briscoe <[e-mail]> wrote:
> 
> See [BB]...
> 
> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>> 
>> ================================================================= 
>> 2 Abstract  RTT variance
>>   
>> Abstract text says:
>>    “The two changes counterbalance each other so that the
>>    throughput of an L4S flow will be roughly the same as a non-L4S flow
>>    under the same conditions.”
>>   
>> ⁃ Please insert “comparable” before “non-L4S flow” to avoid bogus flow comparisons.
>>   
>> ================================================================= 
>> 7. Introduction needs to sidestep RTT variance
>>   
>> This text:
>>    “The two changes counterbalance
>>    each other so that the throughput of an L4S flow will be roughly the
>>    same as a non-L4S flow under the same conditions.”
>>   
>> ⁃          Please insert “comparable” before “non-L4S flow” to avoid bogus flow comparisons.
>> 
>> =================================================================
>> 
> 
> [BB] Isn't 'under the same conditions' already a more precise way of saying 'comparable'?
> 
> Proposed resolution: No text changes.

	[SM] This is still ignoring the fact that L4S itself actively interferes and turns the "same" external condition, like a path's minimal RTT into unequal conditions, by inflating C-queue traffic by >= the C-queues default 25 ms latency taget, while the L-queue only sees >= the default 1ms target. Describing that as "equal throughput under the same conditions" seems misguided at best. What folks will understand is, L and C queue traffic on the same path will share equitably, but that is not what L4S delivers. Let's be exquisitely honest here and add a sentence like:

"Note that due to DualQ's default configuration, classic traffic experiences approximately 25ms more of RTT under load, hence for en equal external path RTT, L4S traffic will get a higher throughput."

IMHO, dualQ needs to be fixed so this behavior disappears, but until that is done the least the IDs need to do is spell this out explicitly, end-users of L4S should be able to make reasonably accurate predictions about how it is supposed to work.

Regards
	Sebastian




> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> https://urldefense.com/v3/__http://bobbriscoe.net/__;!!LpKI!zwOahng_hy4Ex53Fiy_jJ8a4vpQ5LvP38-VOfRUHTTb6TKCwG3MyF7gtaeQ75ePz$ [bobbriscoe[.]net]