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

[Bob Briscoe <[e-mail]>]

David,

On 13/05/2021 21:38, Black, David wrote:
> 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.

[BB2] OK.  Done.


Bob
>
> 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]

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/