Re: [tsvwg] path forward on L4S issue #16

Jonathan Morton <> Wed, 17 June 2020 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C9713A0A8C for <>; Wed, 17 Jun 2020 09:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 9GNizqpml8N0 for <>; Wed, 17 Jun 2020 09:54:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F68F3A0A8B for <>; Wed, 17 Jun 2020 09:54:30 -0700 (PDT)
Received: by with SMTP id e4so3747596ljn.4 for <>; Wed, 17 Jun 2020 09:54:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U4Gs2mnVK4ZDshj0o4d0IhQ6bmr8+kMErUPM6AbZIxo=; b=q/1EWQ6LT+LQ3jcWeGWPhMd1899ywI5bSaWBQlDBztAgNCCM8/9N/FaehgCJOER1dS qgKMUMlsYktgY96y3NeFsJ4hBk4hA/HtBbzU6hBxUtcrM3oPHZBflOystYGQUuZrhdFP k+oAqEQqyl5xxGEXw9B5WyuqtPF2QoreHDzv95b7rkKqolew6W29roZi9iHQ8Tm3XLRd pGVlk7AlEmRTxYA+K+WQK3wTH5ZSKLmMB6utRyi3r2VgAXEwVBmasuSv0JqA0wBNfvvx o8pmrtyxGvyuLpUgGIZhCvsKPRq8TgrB7rnCXfQPtPrAytPSpY+KvA3ZfjyFFXsN/w3N 37VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U4Gs2mnVK4ZDshj0o4d0IhQ6bmr8+kMErUPM6AbZIxo=; b=PNPaflXoUYv8/fxfBLAbkpFWxop4rbFIXiCY5ZPM/rws/4LyuEu57P0IvU8cVWue4h gszpraqJ+Usl0Vw2Plw9OOSEcn6jtgO4NsxAUwqb1YSangM6WTLZlw4J194d2uhMeEdR fvEBUT4xmB/Jimnl0VuNw8jzWA+ThvuQdn0mjL7JbtbL7z08mfc+gMrp9JnInKVLX1jW 8xyXwL01T3t62XbW3boQs6zjhGNqUR/LGkkULmT7GPg8p3KUpOnqeI5fR5MaDo3LSBeh cLPbVnHOblb0Pa0p7V7EgvmcTfkws28VnWJgwbjIH80ldU16zMwzm2GAXDfIxgSN3A76 KEDw==
X-Gm-Message-State: AOAM531eiOanaKLrC/W7tUavWdBCvPlx1rCZ0CWsWMjY1q1EC2PoobaD F5tfi0Wxi6lvk/LgdQOaUio=
X-Google-Smtp-Source: ABdhPJxHEJAfwmbo8oWF6v/iUNIomaZjjMgJnUSrJxePf5b/xg08/NXtA2kLC5DuPNWTFxLM/WKzBw==
X-Received: by 2002:a2e:98c4:: with SMTP id s4mr86174ljj.221.1592412868828; Wed, 17 Jun 2020 09:54:28 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id r9sm71048ljj.127.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 09:54:27 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 17 Jun 2020 19:54:26 +0300
Cc: "Rodney W. Grimes" <>, Sebastian Moeller <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Wed, 17 Jun 2020 16:54:32 -0000

> On 17 Jun, 2020, at 7:27 pm, Ingemar Johansson S <> wrote:
> With that in mind, shouldn't it have been on the table to consider the
> possible future existence of L4S in the different realizations of fq-codel
> (and OpenWrt) development? 

Codel and its progeny were developed on the assumption that RFC-3168 was not going to be obliterated by an incompatible protocol overlaid upon the same codepoints.  A reasonable assumption, given that RFC-3168 was well established as an RFC at that time and widely implemented (if not very widely used in practice), and that DCTCP was explicitly known and accepted to be unsafe to use outside of controlled environments.

And I have to say, Codel represented a genuine step forward in the state of the art for AQM.  It is far easier to configure correctly than most of its predecessors, and does not over-react to brief bursts of traffic (ie. shorter than the estimated RTT), unlike most RED derivatives.  I think it's entirely fair to credit the present increase in RFC-3168 ECN deployment to Codel's existence.  I note in passing that Codel was explicitly designed to match TCP AIMD behaviour, not high-fidelity 1/p responses.

IIRC, when L4S first appeared, the idea of deploying DCTCP over the Internet was rightly dismissed as being completely crackpot.  So everyone in the Codel community simply ignored the RITE project as irrelevant, when it became clear that was the approach they were taking.  Unfortunately, the IETF took them more seriously, and now here we are.

If and when the L4S team manage to put forward a workable solution to the basic problem, I'm sure we will be able to have a more fruitful discussion.  For the time being, we can only eliminate certain classes of solution as unworkable.

 - Jonathan Morton