Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation

Pete Heist <> Sat, 27 March 2021 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E1113A2BCD for <>; Sat, 27 Mar 2021 07:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Status: No, score=-0.938 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.16] 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 ITB79BuPSlnV for <>; Sat, 27 Mar 2021 07:41:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C46EE3A2BCC for <>; Sat, 27 Mar 2021 07:41:22 -0700 (PDT)
Received: by with SMTP id z2so8404964wrl.5 for <>; Sat, 27 Mar 2021 07:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=NcjmxUQsh4+X3t+jomEM8JQb0pR9yXJ3V5Tn/Q+r0i4=; b=CjrriQE0nXExbHZviKU09bU1ECKAANTCrekM7jnXlM4SIe0SA5AKynNJuBEY8kHeWp o/Uh+QhRiVH23ZJOcbF2W9eQnNDGfUe7UlKUO18oLD8Nt63AbwpMQXdjkWNasjxXyTmv VHa6gitnFy+8lwmG9lJ6Jjpz9SnnRlXJ4ROG4+u0Dk19bJPoEpgklpiOG59TBLxKRkp+ 4swiXxPR6W5hu0lCjbNEH8NCfCvGEegMUKqsMuW1bsVTZWQHC5cntP9+pQpTPAKn2zCX lIzgZ0T+8s1Ydz+10+9LxML3ruQE27alei9aMzPR6tWUnbxvsV4DACpMazwRptJATXIp pBiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=NcjmxUQsh4+X3t+jomEM8JQb0pR9yXJ3V5Tn/Q+r0i4=; b=ER9NDDTlwg0qv6UBVXF7ORPDaJUXr5V+OfP3RmwohGo6Mlwkjt83jEEoGnMnNpBK7u xEn5AGjMxxUoYe2NrQbVtsO6gr8F6IS/LSfyQR5IuNGkXV2TwIqBAW0U7IPrOdWJs32p qZg2ZU8jfFdRtFSvSJFNxXmXzRHYHg9PLjBXn3NaCl5HiPuOO3242pL+yYcS9liy7Jhb UFhxk5CsTb21uBKHve/PEvcC9b/U7rDle7TkzYmxezsWiyYRrVDhgKlp5o/kJyGD2Vfy Jn1F0jlxPp2hYerKLYsdcGdnZdxyYtHPPjBD9/gowSTb3anQxAod8tY22nWWZpPZJVe1 0Lvw==
X-Gm-Message-State: AOAM531GubrXwy7LyElFOzJTSsQ+zAISnQDRCkzRvZqGx3l7L+YrT5Hn DwPcIerwkBUS9qwXWfQ9uPsfmg==
X-Google-Smtp-Source: ABdhPJxagNENgLPnOOIyjwgZWdD3hGH/+deDCAzkRa5aIr+8zhR3DWjhSXVHUxnhjsAVYmwCHCHYeQ==
X-Received: by 2002:a5d:570b:: with SMTP id a11mr19752381wrv.281.1616856079768; Sat, 27 Mar 2021 07:41:19 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u9sm15992495wmc.38.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Mar 2021 07:41:19 -0700 (PDT)
Message-ID: <>
From: Pete Heist <>
To: Steven Blake <>
Cc: "" <>
Date: Sat, 27 Mar 2021 15:41:18 +0100
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
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: Sat, 27 Mar 2021 14:41:28 -0000

I agree overall. If we want to introduce a proposal that's incompatible
with RFC3168, we should first make it historic.

Before we do that though, we should make sure that the current CE is
not actually useful. Figure 5 in this paper suggests some benefit to
two bits of signal as opposed to one:

A second signal provides a harder backoff without packet loss, for
example during capacity changes or flow introductions. It wouldn't be
ideal to deprecate RFC3168, only to find out that another bit of signal
in line with CE, along with ABE in RFC8511, or something similarly
deployable with today's equipment, is still useful.

It's also my position that we can't ignore existing RFC3168
bottlenecks, not just for safety but also for performance. The recent
ISP study we did suggested RFC3168 AQMs may be present on ~10% of
Internet paths there. Prior to that we heard 5% elsewhere. Whatever the
number is exactly, these AQMs do exist and mark in response to both
ECT(0) and ECT(1). If you introduce traffic that backs off much less in
response to CE, the AQMs may operate sub-optimally, since they weren't
designed with that kind of traffic in mind

On Fri, 2021-03-26 at 13:01 -0400, Steven Blake wrote:
> A lot (not all) of the recent arguments revolve around the assumption
> by some that RFC 3168 ECN deployment barely exists in the Internet, and
> the few networks where it does can be safely ignored, or cleaned out,
> or be expected to take proactive measures to protect themselves, which
> may in practice require them to lobby their router vendors to spin
> patch releases to enable (some of) the mitigation measures detailed in
> -l4ops-02 Sec. 5.
> If that is the WG consensus, then I *strongly urge* the WG to do the
> following:
> 1. Push to move RFC 3168 ECN to Historic
> 2. Adopt the following "New ECN" signals for future ECN
> experimentation:
> - Not-ECT
> - ECT
> - CE-a
> - CE-b
> This second step would allow for two sets of experiments. The semantics
> of CE-a and CE-b for the first set of experiments would be as follows:
> - CE-a: "Decelerate"
> - CE-b: "Decelerate harder" (multiplicative decrease)
> The exact behavior elicited by the "Decelerate" signal would be the
> subject of investigation. Since we are certain that any remaining RFC
> 3168 deployments can be safely ignored, then ECT/CE-a/CE-b can be used
> as unambiguous signals to steer packets into a low-latency queue, if
> desired.
> The semantics of CE-a and CE-b for the second set of experiments would
> be as follows:
> - CE-a: "Decelerate"
> - CE-b: "Accelerate"
> An aggressive fraction (100%?) of CE-b marked packets traversing a
> queue not in "Accelerate" state would be re-marked to either CE-a or
> ECT. Any packet discard (or detection of high delay variation?) must
> disable the transport's "Accelerate" mechanism for some interval and
> should cause the transport to revert to "TCP-friendly" behavior for
> some (different?) interval. The exact behaviors of "Accelerate" and
> "Decelerate" signals would be the subject of investigation. Again,
> since we are certain that any remaining RFC 3168 deployments can be
> safely ignored, then ECT/CE-a/CE-b can be used as unambiguous signals
> to steer packets into a low-latency queue.
> The differences between these two sets of experiments hinge on whether
> there is more utility in an "Accelerate" signal coupled with a
> "Decelerate" signal, or with two separate levels of "Decelerate"
> signals. Since it is WG consensus that the RFC 3168 ECN experiment
> failed after two decades, we probably only get one more chance to get
> this right, so careful and exhaustive experimentation which explores
> the design space is in order.
> Obviously, both sets of experiments cannot be run simultaneously on
> intersecting parts of the Internet. I leave the options for safely
> isolating these experiments as an exercise for the reader. Since we are
> certain that any remaining RFC 3168 ECN deployments can be safely
> ignored, I suggest choosing bit assignments for the four signals that
> induce maximum pain in the obstinate minority that might still deploy
> RFC 3168 ECN.
> Now, *if it is not WG consensus* that any existing RFC 3168 ECN
> deployments can be safely ignored, then I *strongly urge* the WG *to
> not adopt* experimental proposals that place burden and/or risk on
> networks that have deployed it.
> TL;DR: Either RFC 3168 ECN exists in the Internet, or it doesn't.
> Decide, and act appropriately.
> Regards,
> // Steve