[tsvwg] L4S ECN marking: MUST be immediate vs SHOULD NOT be delayed

[Bob Briscoe <[e-mail]>]

List, chairs,

It has been pointed out (offlist) that the normative text on smoothing 
delay at the end of this section:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#section-5.2
could be expressed as a MUST rather than SHOULD, if stated the other way 
round, which would make it less open to interpretation.

Current:

    Also, L4S CE marking needs to be interpreted as an unsmoothed signal,
    in contrast to the Classic approach in which AQMs filter variations
    before signalling congestion. An L4S AQM SHOULD NOT smooth or filter
    out variations in the queue before signalling congestion.  In the L4S
    architecture [I-D.ietf-tsvwg-l4s-arch  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#ref-I-D.ietf-tsvwg-l4s-arch>], the sender, not the network,
    is responsible for smoothing out variations.

    This requirement is worded as 'SHOULD NOT' rather than 'MUST NOT' to
    allow for the case where the signals from a Classic smoothed AQM are
    coupled with those from an unsmoothed L4S AQM.  Nonetheless, the
    spirit of the requirement is for all systems to expect that L4S ECN
    signalling is unsmoothed and unfiltered, which is important for
    interoperability.


Proposed:

    Also, in the L4S architecture [I-D.ietf-tsvwg-l4s-arch  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#ref-I-D.ietf-tsvwg-l4s-arch>], the sender,
    not the network, is responsible for smoothing out variations in the
    queue. So, an L4S AQM MUST signal congestion as soon as possible.
    Then, an L4S sender generally interprets CE marking as an unsmoothed
    signal.

    This requirement does not prevent an L4S AQM from mixing in
    additional congestion signals that are smoothed, such as the
    signals from a Classic smoothed AQM that are coupled with unsmoothed
    L4S signals in the coupled DualQ [I-D.ietf-tsvwg-aqm-dualq-coupled  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#ref-I-D.ietf-tsvwg-aqm-dualq-coupled>].
    But only as long as the onset of congestion can be signalled
    immediately, and can be interpreted by the sender as if it has been
    signalled immediately, which is important for interoperability


This also needs a tweak to the earlier text in §4.4.  "Filtering or 
Smoothing of ECN Feedback" that refers forward to here:

Current:

    Section 5.2  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#section-5.2>  below specifies that an L4S AQM is expected to signal L4S
    ECN without filtering or smoothing.

Proposed:

    Section 5.2  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#section-5.2>  below specifies that an L4S AQM is expected to signal L4S
    ECN immediately, to avoid introducing delay due to filtering or
    smoothing.



Imminently, I shall prepare a new revision of the draft to wrap up the 
few changes subsequent to draft-22, which were mainly push-back against 
changes intended to address WGLC comments. I'll include the above 
hopefully uncontroversial change, unless someone can give a good reason 
not to.


Bob

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