Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

Martin Duke <> Fri, 19 March 2021 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D6EB3A166F for <>; Fri, 19 Mar 2021 07:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2yBXgubzM-VG for <>; Fri, 19 Mar 2021 07:20:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 612993A167A for <>; Fri, 19 Mar 2021 07:20:44 -0700 (PDT)
Received: by with SMTP id c17so8181035ilj.7 for <>; Fri, 19 Mar 2021 07:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ey7JQm8noNTr5M8f+fFI3SIYHzr6TfV+bea71uizHQY=; b=GHKt71Y7w5a3rCfY+nm6ebLnwKfidBeC9p1SwuevzDsHW/RO4Z2PZMIfXfdE4w/Kf1 JaTmEAs+nFoyaBLO39u+0KkRljT0CEo98X88xYCNqv8iXz03D0sG8VUMBnJIXK4Mnkr3 Qi1mVK/69FFy5M0Fun82ff3U3PFcZnKZiBvikwsqgq5aHTQ9cWRoc/SJbPPZRnCicDr9 sVlTxrZY+GInodSgCr0BYkGVLJjbFQNb3at03IbAPw3J9vLqriLnQ737GXDtmshHKJXa sU//Dez7N4sDjeC6dmQyiUcBZHzJbho5pcePI0TFX9KNxJlm/J3D3WIh/tadzgcNDoZa 1utg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ey7JQm8noNTr5M8f+fFI3SIYHzr6TfV+bea71uizHQY=; b=iqquhbOsLxbnnaL4YxqFGzLWRJ2vp8M1DCKGMXnsZkpvYx7+G1I/S4D+8jKmStIANh gDwUpc6laivuLS+/ex5iP98tf1CjchWXAtKTmDWpsRmSVyfqlGFIKSRUCPFqSButiQ0w RMFzVloOrOClo7AMRDyfpa1+LMX38o8tiBaVek1KJoryVxgPhx2yT8WJl10b+MvEUMoi ScNlmS45oFOhTpXolNPctz4jlAwdMyy3Tz9Lo5a6KL/nnmXXu7aNk4UbhciqgAL1taF7 yZP/Vdc2tNYd/Ue/86Zgwf36EJ8zAcYw9+V4X92uDCa2nfxKJFsuqBzhEMEl/CfEea80 10Dw==
X-Gm-Message-State: AOAM531vy6GnL0ZAXH45mBnMmsfWCG5PqpOpMTHBc+u8aslJAqy1Pk+L rR0HkJ5kCrkKfXAFvYZw7e4bmfDcaMti9YeYLoE=
X-Google-Smtp-Source: ABdhPJyZ/gv5PkvgccWibbsMHnjcyo55rT9moEXCbOHwv5ma0cF5kmmaNrZldhmdrcxHZBNftHAcHVhTOCBnNhFRtss=
X-Received: by 2002:a92:c541:: with SMTP id a1mr2816198ilj.249.1616163641554; Fri, 19 Mar 2021 07:20:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 19 Mar 2021 07:20:31 -0700
Message-ID: <>
To: Greg White <>
Cc: Jonathan Morton <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c0fe5e05bde46b72"
Archived-At: <>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Mar 2021 14:20:54 -0000

As an individual, I support adoption.

On Mon, Mar 15, 2021 at 2:17 PM Greg White <> wrote:

> Hi Jonathan,
> This is an adoption call, not a call for approval of the text.  In my
> view, the question is whether the working group members are interested in
> providing guidance to L4S experimenters to address the issue of
> compatibility with RFC3168 bottlenecks.
> I'll respond to some of your points below in a separate thread so as not
> to disrupt the adoption call.
> -Greg
> On 3/15/21, 4:35 AM, "tsvwg on behalf of Jonathan Morton" <
> on behalf of> wrote:
>     I do not think this document is ready for adoption in its current
> form.  Let me explain why, and suggest some ways it could be improved.
>     L4S has a fundamental incompatibility with conventional AIMD traffic
> in the presence of RFC-3168 ECN AQMs, just like DCTCP upon which it was
> based.  L4S therefore requires mitigations to ensure that the harm caused
> by this incompatibility is minimised to an acceptable level.  Since the
> harm is primarily caused to "innocent bystanders" rather than "involved
> participants" or "interested observers", the acceptable level of harm and
> risk is especially low, and the mitigations need to be correspondingly
> robust.
>     However, robust mitigations are not what l4s-ops currently describes.
> Most of the measures described fall into three categories:
>     1: Reliance on detecting an RFC-3168 AQM and disabling the L4S
> behaviour, using heuristics that have not yet been shown in a reliably
> working state, even under lab conditions.  It is impossible to state that
> such a heuristic can be relied upon until such a showing has been made.  A
> previous attempt at implementing such a heuristic was unsuccessful and is
> now disabled by default in the reference implementation.  Hence, the
> reliability of such a heuristic would necessarily be a subject of the
> experiment, not the primary safeguard.
>     2: Requirements placed upon "innocent bystanders" to avoid the harm,
> mostly by reconfiguring, replacing, or disabling their RFC-3168 AQMs
> (sometimes in an RFC-ignorant manner).  This is obviously unworkable, since
> by definition "innocent bystanders" are unaware of the experiment, and even
> if made aware, are disinterested in doing work to accommodate it.
>     3: Recommendation to deploy L4S hosts on networks that have been
> prepared to receive it.  Which is a step in the right direction.  But this
> is not accompanied by a corresponding requirement to *contain* L4S traffic
> to each prepared network.  Without such a requirement, it would be very
> easy for L4S hosts on different networks, which may individually have been
> prepared, to communicate over the path between those networks that has
> *not* been prepared, and upon which the risk of disrupting bystander
> traffic therefore exists.
>     It is perhaps noteworthy that gaps in the second and third classes of
> mitigation are proposed to be covered by the first class of mitigation.  I
> also note that there is still an assertion in the text that RFC-3168 AQMs
> are "rare", which is refuted by recent data.  Finally, in the context of a
> CDN-ISP pairing for an experimental deployment, the ISP subscribers' LANs
> and WLANs are technically separate networks that would be difficult to
> "prepare" for L4S in advance; it would be wise to consider the
> ramifications of that.
>     I also note in passing that a modification of tunnel encapsulation
> semantics is also proposed.  Given that tunnel implementations are more
> diverse than RFC-3168 AQM implementations, I also consider this unlikely to
> be practical, though I haven't studied in detail whether it would be
> effective if achieved.
>     I am currently aware of four theoretical methods of robustly
> mitigating the risk posed by L4S.  I think that l4s-ops would be
> considerably improved by proposing that at least one of them be employed as
> a prerequisite to the L4S experiment actually taking place:
>     1: Develop, implement, demonstrate, and open for scrutiny an RFC-3168
> detection heuristic that is reliable and prompt enough to serve as a
> primary safeguard for the experiment.  In my opinion this will be difficult
> and will take significant time, but is not impossible to achieve.
>     2: Deprecate RFC-3168, or amend it to remove drop-equivalent marking
> of ECT(1) packets, and require the removal of all unmodified ECN AQMs from
> the Internet.  This is unlikely to get much support given the increasing
> deployment rates of RFC-3168 AQMs at the present time.  In any case it
> would take a very long time to eliminate existing RFC-3168 AQM deployments
> at Internet scale, so I consider this impractical.
>     3: Explicitly contain L4S traffic to networks that have been prepared
> or designated for the experiment.  That could be done by marking all L4S
> traffic with a designated DSCP at origin, and blocking traffic carrying
> that DSCP from traversing border gateways into unprepared networks.  This
> has the effect of making users and administrators of these networks at
> least "interested observers" and isolating L4S traffic from "innocent
> bystanders".  Within the designated networks, observing the practical
> interactions between L4S and conventional traffic would be part of the
> experiment.
>     4: Redesign L4S to shift the risk burden away from "innocent
> bystanders".  The most obvious way to do so is to implement unambiguous
> signalling by the network, so that the receiver knows for certain whether
> it is receiving congestion signals from an RFC-3168 AQM requesting an
> immediate MD response, or from an AQM of the new type requesting a new type
> of response.  The risk of performance trouble is then restricted to network
> nodes that produce the new signals and transport endpoints that understand
> them - in other words, to the relatively small number of "involved
> participants" who have the knowledge and incentive to study the problem and
> find solutions.  The incentives are thus aligned correctly and risks are
> not "externalised".
>     The SCE proposal does exactly that, in a manner that is totally
> transparent to existing RFC-3168 endpoints and middleboxes.  It becomes
> practical, for example, to use a Differentiated Services Code Point to
> differentiate a low-latency service onto a second bearer and provide a
> single-queue SCE AQM there, while providing a single-queue RFC-3168 AQM
> (without SCE) on the primary bearer.  Because of the unambiguous
> signalling, SCE traffic missing the DSCP would still compete on equal terms
> with conventional traffic, instead of dominating it or being dominated.
>     I realise that this last method is not strictly in scope for the
> l4s-ops draft (and that mentions of SCE tend to raise hackles among L4S
> proponents), but I include it because it appears to be the most robust
> mitigation method available.  It also has the advantage of running code
> being available to try it out immediately.
>     I am not hugely optimistic that the l4s-ops draft will incorporate the
> above advice before the adoption call ends.  But unless and until it does,
> my position is that it SHOULD NOT be adopted.
>      - Jonathan Morton