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

[Bob Briscoe <[e-mail]>]

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

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 Briscoe                               http://bobbriscoe.net/