Re: [tsvwg] Review comments on a careful read of the L4S ID (#14. network node)

[Bob Briscoe <[e-mail]>]

David, Gorry,

On 06/05/2021 07:52, Gorry Fairhurst wrote:
>
> =================================================================
> *14. Replace “network node”  (part 1)*
> **
> This text:
> “ A network node that implements the L4S service always classifies
> arriving ECT(1) packets for L4S treatment and by default classifies
> CE packets for L4S treatment unless the heuristics described in
> Section 5.3 are employed.”
>
> ⁃Use of “network node” is excessive and over-constrains 
> implementations, e.g., the techniques in Sections 5.4.1.2 and 5.4.1.3 
> conflict with this sentence.Change “A network node that implements” to 
> “An implementation of the L4S service” It would be nice to be at least 
> clear this is marking behaviour, e.g. “An implementation that marks 
> using L4S”, or something similar.
> =================================================================*
> 20.Reduce “network node” scope (part 2)*
> In section 5.1:
> “A network node that implements the L4S service MUST classify arriving
> ECT(1) packets for L4S treatment and, other than in the exceptional
> case referred to next, it MUST classify arriving CE packets for L4S
> treatment as well.”
>
> ⁃Please change to “An implementation of the L4S service MUST classify 
> …”This removes conflicts with at least Sections 5.4.1.2 and 5.4.1.3.
> =================================================================
> *21. Reduce “network node” scope (part 3)*
>
> This text:
> “ For backward compatibility in uncontrolled environments, a network
> node that implements the L4S treatment MUST also implement an AQM
> treatment for the Classic service as defined in Section 1.2.”
>
> ⁃Change to “an implementation of the L4S service that supports the L4S 
> treatment MUST also implement …”This removes conflicts with at least 
> Sections 5.4.1.2 and 5.4.1.3.
> =================================================================
> *23. What about if a sender uses Not-ECT and ECT(0) in combination? 
> Also, reduce “network node” scope (part 4)*
> This text:
> “Nonetheless, if an implementer is
> willing to identify transport-layer flows at a network node, and if
> the most recent ECT packet in the same flow was ECT(0), the node MAY
> classify CE packets for Classic ECN [RFC3168] treatment.”
> ⁃Please tell us if you have thought about when the previous packet was 
> not-ECT. Has this been considered and is it explicitly required to 
> then send a CE mark via the L4S queue? I understand the next para to 
> speak only about when next packet was ECT(1).
> ⁃See other note on “at a network node” and change “the node may” to 
> “the implementation MAY”.This removes conflicts with at least Sections 
> 5.4.1.2 and 5.4.1.3.
> ⁃It would also help to change “if an implementer is willing” to “if an 
> implementation is able”.
> ⁃If the latter is done, change “If an implementer uses” to “If an 
> implementation uses” at the start of the next paragraph.
> =================================================================

[BB] For the record, I believe these concerns were resolved offlist to 
reduce noise, and the resolutions are already included in draft-16, by 
referring forward to exceptions defined later in S.5.1, and in 5.1 
making those exceptions clearer and more complete.

Please confirm whether the text in -16 is now acceptable.


Bob

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