Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs

Jonathan Morton <> Fri, 26 July 2019 23:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2838E1201CF for <>; Fri, 26 Jul 2019 16:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MTgRURtCnKTU for <>; Fri, 26 Jul 2019 16:40:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B7F0120181 for <>; Fri, 26 Jul 2019 16:40:19 -0700 (PDT)
Received: by with SMTP id h18so54285442qtm.9 for <>; Fri, 26 Jul 2019 16:40:19 -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=rQSLGnUa5hSNJkUMZNn2NitWpxzt9dbJ3NEMeTfvwHk=; b=QCPL3k40IzMFkhermlsZNJnt4QFyodH2M5ICx1PQSM1kGcIuWCrkPk7Yvw4vQZqBc0 w3LxR3Q2CLoUQlgGez2C+7nHFmTyI0SVPUR3mpyj73PCENz2xzGUY+4XABmiov180BN3 HLGpIbY9bTynfKCot3IFNDd6pnJ0XM3YHiHGQxQJiXba1YOQLmb+bV2ahLOX42lVWmvf FLXbHPC5XKzETVMotAMXVDdG+XsAggYSyqhk3Cnfgvix5Y+cVoefEa0z/OBZHO+3staJ ANzeA6wZPJut3LV4er8xQxLqzfszftUUpoxnnxBi0VPK7SWS92xh+3M7cYqruBV/Gz4s XA+Q==
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=rQSLGnUa5hSNJkUMZNn2NitWpxzt9dbJ3NEMeTfvwHk=; b=iJsxgIljGSJPv6BR/YfZwPYgndUzP1ZBH+3LPqXio/hp0XFKXcCNrU85nhmYTFXgfb dH7ZSvwqm7QwuETROGPydOjun3FPR7kQObMvue37IxpzNXyQNPeffOtDplsNsoPAWd9b aLRSdwJKbVR96iBOOzsnkYcyq4Pu56d82QZZ6FbSBFVBJQrM397l0EA1GvOHvHEAK/I1 POL7OtPny3DK5JjR4dsruddeJ7kPg5ifGMRHGLVIEzNUHoh8YSB3QFZuQvkXo2uyUoYk kYS+m9ue9wAMSMc8UJCL3J4ccblYx2FpGItzvR06/MOeQQrVsoOMSLqyt2tWkIiiNOAB oB4Q==
X-Gm-Message-State: APjAAAWzGSNg1UXGETAFoA0DggvdfYxTTDshcBd/yA7jKYm3kr8oqk2W 0BGsG7njsmpfKygdFX/55XY=
X-Google-Smtp-Source: APXvYqyooKcmmyYGmv+rGZ3gGjBaP9cAIkTyGs+8G0/PNahoXwo6CfgS/Lxuhx0flRBmhMTb7iDYwQ==
X-Received: by 2002:ac8:2baa:: with SMTP id m39mr69603178qtm.242.1564184418297; Fri, 26 Jul 2019 16:40:18 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id g2sm24974664qkb.80.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2019 16:40:17 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 26 Jul 2019 19:40:15 -0400
Cc: "Holland, Jake" <>, Sebastian Moeller <>, Bob Briscoe <>, "" <>, "" <>, Dave Taht <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs
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, 26 Jul 2019 23:40:20 -0000

> On 26 Jul, 2019, at 4:07 pm, Black, David <> wrote:
>> I believe under this nomenclature, L4S in a queue with RFC3168-style
>> marking at a bottleneck should be classified as a flow that is
>> responsive but not TCP-compatible, and therefore poses a significant
>> threat to internet performance within this context.
>> I'm not sure how best to describe this discrepancy, but I think it's
>> fair to call it an incompatibility between a RFC3168-style marking
>> queue and L4S.
> Based on the L4S slides in today's meeting and related discussion, the L4S folks are starting to deal with this concern.
> I share your technical view that this concern is not safe to ignore.

Based on our post-session discussions, I feel that it may not actually be entirely clear to the L4S people just how serious the situation with L4S and Codel is.

The impression I gained was that they consider *Codel* to be broken, and that *it* should be changed to match what L4S expects.  This is impractical given how widely Codel is already deployed, and the fact that it was carefully designed specifically with RFC-compliant transport flows in mind.  The result of their proposed changes would no longer resemble Codel at all.

Unfortunately contributing to their apparent confusion, TCP Prague is currently broken in such a way as to mask the problem if tested directly.  To experimentally verify our hypothesis, we had to synthesise a pseudo-Prague implementation by inserting a firewall rule (mangling CE into SCE) in front of our DCTCP-SCE implementation, the results of which matched our mathematical predictions perfectly.  We saw no evidence of a Classic ECN detector in our TCP Prague tests.

Codel is itself documented in an Experimental RFC, authored by no less personages than Kathy Nichols and VJ.  The derivative FQ-Codel is similarly documented in an RFC.  The variant I use named COBALT (aka Codel-BLUE Alternate) is not yet in an RFC (nor even a draft), but possibly it should be made into one, as the improvements are at least interesting and are proven by both research and deployment.

 - Jonathan Morton