Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S

Jonathan Morton <> Tue, 06 August 2019 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A4151203A4; Tue, 6 Aug 2019 08:28:03 -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 J4aK3rpH9GwZ; Tue, 6 Aug 2019 08:28:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8ADAD120398; Tue, 6 Aug 2019 08:28:01 -0700 (PDT)
Received: by with SMTP id x25so82660773ljh.2; Tue, 06 Aug 2019 08:28:01 -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=LDVNk5CIszTLYhXZlWoUlmNKVSzg0p4CiHpvy4vDb24=; b=GMYDW3D10wwq0MOkCrjYXwK7xeV0eKa0TDUSjtcTpZoOVTaluXkgqRqjgrmqwr2gW7 U5p/+3ztaUmyVUmAZU9pI08mXDaQJFUjYxSBMFN+4KS6qtXTf+lDMBworKxeYEYaYpvj t+UQnWFxeRXaUfYk6N3c/oOOxA0CofBC1dUsGLLtLwY88O41M+z0n5Dsq5k8CXdEg1T8 UjfpABgj3wFEMJfTV0fcOjh+9KtFn1v2b9l8Q8sPxmTUu+sem9tIUFbHvCyYn8kGHqzB DayZ4aRXFHwf0gb/BUxbzuqCeTGrM5TX19mDFoyyVVFBfYXHG9fHpkxfrllGJ4l5Q4RN eGpg==
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=LDVNk5CIszTLYhXZlWoUlmNKVSzg0p4CiHpvy4vDb24=; b=PVPfOkOGv3oVq4dzv0Simaf5onvHYIc7DlpiW8WSuXscIWx5cpdtVv4L9eQh5eFuuI 2HVj1DyHiajF1CeY76a/Z+6CAGC5VPBASgQxOn9FXp5AXccvBEgXyR/gpBCnxwJjfKxS 6qegdWUJQNygP4SUF7hbgTXQah4c4ZvV22FaPtRJ60XhMqg9HBI+TqivPzYAs9da0wRM O+rCLZI8AJVcRCAJSWVfs11K6SjmRZUFMWe1lg0Ids/rx74UL7SUfk6ZqhdShDg9ki/b o9aGTV1zoNN+P2B2yc8A+5bjWRPq6U27/MkyofRyxDKNdPRYZeRWYcDXAZdx/Y9+sTWb 9ohA==
X-Gm-Message-State: APjAAAWWU0XYF2qZE9cFvVCcQfXAg9E9m8s4VQ4mATUstAsNX9SMXq34 6zlUamd+srmvUJBjXIOz3As=
X-Google-Smtp-Source: APXvYqz7++ILXp7EDkOZAC9Vu/eq+WI0NLYJ3CThuouLYgu/U/lS7XorfZBUYBpLWJyUiU/HtBN61g==
X-Received: by 2002:a2e:2993:: with SMTP id p19mr2037147ljp.202.1565105279816; Tue, 06 Aug 2019 08:27:59 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id 189sm17589130lfa.0.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 08:27:58 -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 <>
Date: Tue, 06 Aug 2019 18:27:57 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Aug 2019 15:28:03 -0000

> On 6 Aug, 2019, at 5:34 pm, <> <> wrote:
> Public peerings and not well dimensioned networks may suffer from regular congestion. I'm not sure to which extent technical standards can significantly improve service quality in that situation. IP transport must work as good as possible also in such a situation, of course. 

Obviously the application of AQM will not magically improve total throughput.  What it can do, however, is reduce latency and packet loss, and thereby improve perceived reliability of the service.  It may even improve goodput for the same throughput - an increase in efficiency.

This is especially true under emergency overload conditions, which is when people most desperately want a functioning network, but it is most likely to collapse under the strain.  Often a disaster will incidentally knock out some proportion of network infrastructure in the area, turning a previously well-proportioned network into an under-proportioned one, simultaneously with a sharp increase in demand as people try to find out what is going on or communicate with friends and relatives, and emergency response teams also try to coordinate their essential work.

So IMO networks should be designed to work well when congested, even when they are also designed to never *be* congested.  Technical specifications already exist and are well tested for this purpose.  Having them built in and turned on from the factory would be a great step forward.

 - Jonathan Morton