Re: [tsvwg] Review comments on a careful read of the L4S ID (#3: Ultra)

[Gorry Fairhurst <[e-mail]>]

Thanks for doing this. For me, this is all OK.

Gorry

On 13/05/2021 21:31, Bob Briscoe wrote:
> See [BB]...
>
> Please confirm this one is acceptable.
>
> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>>
>> =================================================================
>>
>> *3. The Abstract can be seen as marketing. In the past the IESG has 
>> taken exception to “claims” in an abstract of a standards-track 
>> document by marketing of “ultra-low”.*
>>
>> Abstract text says:
>> so that _ultra-low and consistently low_
>> queuing delay (typically sub-millisecond on average) becomes possible
>> for L4S traffic without compromising link utilization.
>>
>> ⁃Please avoid the assertion of “ultra-low” since this seems like a 
>> marketing brag.
>
> [BB see end]
>
>> ⁃The abstract is still long, and some of the comparison with ‘Classic 
>> ECN’ could be moved
>> ⁃into the Introduction.
>
> [BB] OK. We can take out sentence 2 onwards, until 'Nonetheless' 
> (inclusive).
>
>
>> =================================================================
>> *9. More marketing at the end of the Introduction*
>>
>> This text:
>> “It gives an incremental migration path so that suitably modified 
>> network bottlenecks can
>> distinguish and isolate existing Classic traffic from L4S traffic to 
>> prevent the former from
>> degrading the ultra-low delay and loss of the new scalable 
>> transports, without harming
>> Classic performance.”
>>
>> ⁃This is better than the corresponding Abstract text (see item 2 
>> above), but still contains marketing – “ultra-low” needs to be 
>> changed to either “low” or “consistently low”. I suggest toi add  “at 
>> the modified network bottlenecks” after “without harming Classic 
>> performance.”to avoid the implication that the absence of harm is 
>> global (which is known not to be the case).
>>
>> =================================================================
>>
>
> We'll change ultra-low to very low throughout, including in the title.
>
> I would like to explain why we had left 'ultra' in when we went 
> through de-hyping the document previously. 'Ultra-low delay' was used 
> throughout as a defined term. We figured it would be hard for a reader 
> to recognize that 'very low delay' is a defined term, because it just 
> looks like some vague words. However, this is a price we have to pay 
> to make progress.
>
> We'll also make the additional changes below.
>
> CURRENT:
> ultra-low and consistently low queuing delay (typically 
> sub-millisecond on average)
> PROPOSED:
> very low (typically sub-millisecond on average) and consistently low 
> queuing delay :
> REASON:
> There seems to be some confusion whether we're talking about very low 
> delay or consistently low delay. The answer is both.
>
> And to the Introduction:
> CURRENT:
> “It gives an incremental migration path so that suitably modified 
> network bottlenecks can
> distinguish and isolate existing Classic traffic from L4S traffic to 
> prevent the former from
> degrading the ultra-low delay and loss of the new scalable transports, 
> without harming
> Classic performance.”
> PROPOSED:
> “It gives an incremental migration path so that suitably modified 
> network bottlenecks can
> distinguish and isolate existing Classic traffic from L4S traffic to 
> prevent the former from
> degrading the very low delay and loss of the new scalable transports, 
> without harming
> Classic performance at these bottlenecks.”
> REASON:
>    As requested but less clunky than suggested.
>
>
>
> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/