[tsvwg] https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03#page-10

[Sebastian Moeller <[e-mail]>]

So the L4S architecture description has the following rationale, why L4S opted for the dual-queue approach instead of mandatinf flow queueing:

https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03#page-10:

 Per-flow queuing:  Similarly per-flow queuing is not incompatible
      with the L4S approach.  However, one queue for every flow can be
      thought of as overkill compared to the minimum of two queues for
      all traffic needed for the L4S approach.  The overkill of per-flow
      queuing has side-effects:

     A.  fq makes high performance networking equipment costly
          (processing and memory) - in contrast dual queue code can be
          very simple;

      B.  fq requires packet inspection into the end-to-end transport
          layer, which doesn't sit well alongside encryption for privacy
          - in contrast the use of ECN as the classifier for L4S
          requires no deeper inspection than the IP layer;

      C.  fq isolates the queuing of each flow from the others but not
          from itself so, unlike L4S, it does not support applications
          that need both capacity-seeking behaviour and very low
          latency.

          It might seem that self-inflicted queuing delay should not
          count, because if the delay wasn't in the network it would
          just shift to the sender.  However, modern adaptive
          applications, e.g.  HTTP/2 [RFC7540] or the interactive media
          applications described in Section 6, can keep low latency
          objects at the front of their local send queue by shuffling
          priorities of other objects dependent on the progress of other
          transfers.  They cannot shuffle packets once they have
          released them into the network.

      D.  fq prevents any one flow from consuming more than 1/N of the
          capacity at any instant, where N is the number of flows.  This
          is fine if all flows are elastic, but it does not sit well
          with a variable bit rate real-time multimedia flow, which
          requires wriggle room to sometimes take more and other times
          less than a 1/N share.

          It might seem that an fq scheduler offers the benefit that it
          prevents individual flows from hogging all the bandwidth.
          However, L4S has been deliberately designed so that policing
          of individual flows can be added as a policy choice, rather
          than requiring one specific policy choice as the mechanism
          itself.  A scheduler (like fq) has to decide packet-by-packet
          which flow to schedule without knowing application intent.
          Whereas a separate policing function can be configured less
          strictly, so that senders can still control the instantaneous
          rate of each flow dependent on the needs of each application
          (e.g. variable rate video), giving more wriggle-room before a
          flow is deemed non-compliant.  Also policing of queuing and of
          flow-rates can be applied independently.



And then cablelabs, the organization closest to deploying L4S, in Data-Over-Cable Service Interface Specifications DOCSIS® 3.1, MAC and Upper Layer Protocols Interface SpecificationCM-SP-MULPIv3.1-I17-190121, Annex P Queue Protection Algorithm (Normative) says:

"This annex defines the Queue Protection algorithm that is required to be supported by the CM in the upstream (see Section 7.7.6.1). It is also the Queue Protection algorithm that CMTS Queue Protection algorithms are required to support (see Section 7.7.6.2). In either direction, this algorithm is intended to be applied solely to a Low Latency Service Flow. It detects queue- building Microflows and redirects some or all of their packets to the Classic Service Flow in order to protect the Latency Service Flow from excessive queuing. A Microflow is defined in Section P.3, but typically it is an end-to- end transport layer data flow."

To me this looks like the introduction of flow-queuing through a backdoor, instead of doing it upfront this tries to measure whether flows behave well enough to keep enjoying the L4S special treatment and demotes non-compliant flows to the TCP-friendly queue. I would be intersted to learn how this mandatory requirement can be implemented without at least having similar cost like flow queueung (at least I fear it will drag the identifies issues A. and B. from above into the system running the L4S-compliant AQM). I would love to learn where my interpretation is wrong.

Many Thanks in advance

Regards
	Sebastian Moeller