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

[Bob Briscoe <[e-mail]>]

David,

On 14/05/2021 16:05, Black, David wrote:
>
> Top posting to make this quick to read – this concern is resolved by 
> the following revised Section 5.1 text (in -16):
>
> A network node that implements the L4S service:
>
> o  MUST classify arriving ECT(1) packets for L4S treatment, unless
>
> overridden by a another classifier (e.g., see Section 5.4.1.2 
> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-16#section-5.4.1.2>);
>
> o  MUST classify arriving CE packets for L4S treatment as well,
>
> unless overridden by a another classifier or unless the exception
>
> referred to next applies;
>
> The use of "another classifier" allows use of other criteria to 
> include/exclude ECT(1) and CE packets for L4S treatment. The exception 
> that follows is use of a flow-aware mechanism to distinguish CE 
> packets for L4S flows from those for non-L4S flows and only apply L4S 
> treatment to CE packets for L4S flows.
>
> Nit: "a another" -> "another" (twice).
>

[BB] Done.

Thx

bob

> Thanks, --David
>
> *From:* Bob Briscoe <[e-mail]>
> *Sent:* Friday, May 14, 2021 9:47 AM
> *To:* Gorry Fairhurst; Black, David
> *Cc:* [e-mail]
> *Subject:* Re: [tsvwg] Review comments on a careful read of the L4S ID 
> (#14. network node)
>
> [EXTERNAL EMAIL]
>
> 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 Briscoehttp://bobbriscoe.net/ [bobbriscoe.net]  <https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!1enWVfZ8juwUTPZhR8eDn_Cawae1UGNlkNx5uU75k0CGy_jA23R8zDakSDZR4KwS$>

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