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

["Black, David" <[e-mail]>]

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).

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 Briscoe                               http://bobbriscoe.net/ [bobbriscoe.net]<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!1enWVfZ8juwUTPZhR8eDn_Cawae1UGNlkNx5uU75k0CGy_jA23R8zDakSDZR4KwS$>