Re: [tsvwg] Review comments on a careful read of the L4S ID (16.17.18. Prague Reqs)

[Gorry Fairhurst <[e-mail]>]

On 14/05/2021 14:56, Bob Briscoe wrote:
> Gorry, David, all,
>
> The text of all these requirements was changed, in some cases 
> significantly, at draft-15 & -16.
> So this email reinforces my request during the interim for people to 
> please check whether the normative wording is now acceptable. If not, 
> pls suggest improvements. If it is good, praise is always welcome too ;)
>
>
> Bob

Yes indeed, thanks! The original comments from me were addressed. I'll 
review the entire document at the next stage.

Gorry

>
> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>>
>> =================================================================
>> *16. RFC 3168 coexistence*
>> **
>> This text:
>> “oA scalable congestion control MUST implement monitoring in order
>> to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
>> On detection of a likely ECN-capable bottleneck it SHOULD be
>> capable (dependent on configuration) of automatically adapting its
>> congestion response to coexist with TCP Reno congestion controls
>> [RFC5681] (see Appendix A.1.4 for rationale and a referenced
>> algorithm).”
>>
>> ⁃This will have to be resolved in the WG, including details of what 
>> “coexist” means.
>> =================================================================
>> *17. RTT Bias: **implementation requirements to documentation 
>> requirements*
>>
>> This text:
>> “A scalable congestion control MUST eliminate RTT bias as much as
>> possible in the range between the minimum likely RTT and typical
>> RTTs expected in the intended deployment scenario (see
>> Appendix A.1.5 for rationale).”
>>
>> ⁃A writing style that says: must... as hard as possible style is very 
>> hard to accept for me. Use of an RFC 2119 “MUST” is not appropriate 
>> here.Please do change “MUST” to “is expected to” as used in the last 
>> bulleted item. One possibility that would work for me is some 
>> rephrasing to say “needs to eliminate” and “specifications are 
>> REQUIRED to include methods that limit RTT bias, although I have no 
>> problem with saying “is expected to …”.
>> =================================================================
>> *18. Loss detection in time-based units.*
>>
>> This text:
>> “oA scalable congestion control SHOULD detect loss by counting in
>> time-based units, which is scalable, as opposed to counting in
>> units of packets (as in the 3 DupACK rule of RFC 5681 TCP), which
>> is not scalable.As packet rates increase (e.g., due to new and/
>> or improved technology), congestion controls that detect loss by
>> counting in units of packets become more likely to incorrectly
>> treat reordering events as congestion-caused loss events (see
>> Appendix A.1.7 for further rationale).This requirement does not
>> apply to congestion controls that are solely used in controlled
>> environments where the network introduces hardly any reordering.”
>>
>> ⁃Please replace with text agreed to on the list.
>> =================================================================
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/