Subject: [tsvwg] a WGLC review and support for draft-ietf-tsvwg-l4s-arch

From: Neal Cardwell <[email-masked]>
Date: Sun, 8 Aug 2021 23:04:32 -0400

Regarding the L4S architecture draft:
   https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/

I support moving this draft to RFC status.

Below are some editorial comments from reading the most recent version of
the draft, draft-ietf-tsvwg-l4s-arch-10, dated July 1, 2021.

These are all minor editorial or wordsmithing suggestions. I do not have
any technical objections to the draft.

Comments:

---

current draft text:
  "The L4S architecture is intended to enable
   _all_ Internet applications to transition away from congestion
   control algorithms that cause queuing delay"

Taken literally, describing the goal as to "transition away from congestion
control algorithms that cause queuing delay" seems perhaps unintentionally
strong, since AFAIK any practical congestion control scheme, including L4S,
will still cause some non-zero queuing delay. :-)

I'd suggest:
  "The L4S architecture is intended to enable
   _all_ Internet applications to transition away from congestion
   control algorithms that cause large queuing delays
   (where "large" includes, for example, delays on the order of
   the unloaded round-trip time or longer)"

---

current draft text:
   It must be said that queuing delay only degrades performance
   infrequently [Hohlfeld14].  It only occurs when a large enough
   capacity-seeking (e.g. TCP) flow is running alongside the user's
   traffic

AFAICT [Hohlfeld14] is based on tests in "laboratory-based testbeds", so
I'm not sure it's the best support for a claim that queuing delay only
degrades performance infrequently. Agreed, queuing delay only degrades
performance in specific conditions, but those specific conditions may be
quite common, and only large-scale measurements of real production/user
workloads could quantify how frequently those conditions arise. Given the
mindshare that the problem of bufferbloat has captured over the past
decade, and the numerous AQM and congestion control schemes that have been
offered to fight it, I think it's fair to say that queuing delay degrades
performance frequently enough for it to be considered a significant concern.

I'd suggest:

   Queuing delay degrades performance [Hohlfeld14] when a large enough
   capacity-seeking (e.g. TCP) flow is running alongside the user's
   traffic

---

current draft text:
      Section 4 gives a high level explanation of how FQ and DualQ
solutions work

I'd suggest making it more clear that the "FQ" approach here is FQ plus L4S
support, e.g.:
      Section 4 gives a high level explanation of two
      kinds of L4S network solutions, FQ and DualQ,

---
current draft text:

   2.  L4S Architecture Overview

   There are three main components to the L4S architecture; the AQM in
   the network, the congestion control on the host, and the protocol
   between them:

   1) Network:  L4S traffic needs to be isolated from the queuing
      latency of Classic traffic.

AFAICT the architecture overview section on the network only discusses
isolation. It doesn't mention ECN, and doesn't mention that the L4S network
component needs to do some kind of shallow-threshold ECN marking, both of
which IMHO seem important enough to mention in this section.

---
current draft text:
   4.  L4S Architecture Components

In section 4 on "L4S Architecture Components" I was expecting to see
(probably in section 4.2., Network Components) an explicit definition of
what L4S ECN marking behavior or semantics are allowed in (or considered
consistent with) the L4S architecture. Or, put another way, in this doc
it's not explicitly clear to me what an ECN mark "means" in the L4S
architecture. The draft text mentions queuing delay of roughly 1ms several
times: "Very low queuing latency means less than 1 millisecond (ms) on
average and less than about 2 ms at the 99th percentile."; "the additional
queuing delay of roughly 1 ms"; "The consequent smaller amplitude sawteeth
fit between an empty queue and a very shallow marking threshold (~1 ms in
the public Internet)". However, I didn't notice any text that specified
that ECN marks must or may happen when queuing delay reached the 1ms level.
Nor did I see text saying that bottlenecks may use any marking threshold
they want, or should use a threshold in some range, etc. Similarly I didn't
see any text that characterized whether randomized/smoothed marks were
required or permitted or disallowed, or whether step marking is required or
permitted or disallowed, and whether step marking may or may not be based
on sojourn time, queue length in octets, etc. Maybe I missed these aspects.
Or maybe this document is not where that is intended to be defined; but in
that case I still expected to see a clear sentence pointing the reader to
another document that would define these aspects.

---
current draft text:
   c.  A network operator might wish to include certain unresponsive,
       non-L4S traffic in the L4S queue if it is deemed to be smoothly
       enough paced and low enough rate not to build a queue. ...
       This traffic would need to be tagged with specific identifiers,
       e.g. a low latency Diffserv Codepoint such as Expedited
       Forwarding (EF [RFC3246]), Non-Queue-Building
       (NQB [I-D.ietf-tsvwg-nqb]), or operator-specific identifiers.

For tagging such traffic with specific identifiers, is marking as ECT(1)
also an option? That would seem to be more practical than DSCP to carry
end-to-end. But maybe that has gotchas. Either way it might be nice to
mention this option, if only to clarify why it's not a good idea.

---
current draft text:
   Figure 1: Components of an L4S Solution:

I'd suggest phrasing this in a way that explicitly mentions it's for a
DualQ bottleneck and differentiates it from the FQ-based L4S bottleneck,
since the diagram seems to only apply to DualQ:

   Figure 1: Components of a DualQ L4S Solution:

---
current draft text:
       within each queue of an FQ-CoDel
       system, as well as a CoDel AQM, there is typically also ECN
       marking at an immediate (unsmoothed) shallow threshold to support
       use in data centres

Since the ce_threshold feature defaults to disabled in Linux, I'd suggest
wording this as:

       within each queue of an FQ-CoDel
       system, as well as a CoDel AQM, there is typically also
       the option of ECN
       marking at an immediate (unsmoothed) shallow threshold to support
       use in data centres

---
current draft text:
   4.3.  Host Mechanisms

   The L4S architecture includes two main mechanisms in the end host
   that we enumerate next:

   a.  Scalable Congestion Control at the sender: Data Center TCP is the
       most widely used example.  It has been documented as an
       informational record of the protocol currently in use in
       controlled environments [RFC8257].

Given this is the meat of an architecture document, I would suggest
starting 4.3.a with a high-level definition of what a scalable congestion
control is, then perhaps pointers to the docs giving a more detailed
definition, before mentioning that DCTCP is an example.

---
current draft:

  Figure 2: Likely location of DualQ (DQ) Deployments in common access
                                  topologies

In this figure it would be nice to include a depiction of a case where
there is a downstream DQ deployed in the wifi AP, since I imagine there are
many homes with a downstream DOCSIS link that is faster than the wifi, so
the downstream bottleneck is the wifi link.

---

best regards,
neal