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

Jonathan Morton <> Tue, 09 July 2019 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF47212070F; Tue, 9 Jul 2019 08:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Status: No, score=-0.453 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nWI0L1d1V--T; Tue, 9 Jul 2019 08:41:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D620C120283; Tue, 9 Jul 2019 08:41:14 -0700 (PDT)
Received: by with SMTP id r9so20027866ljg.5; Tue, 09 Jul 2019 08:41:14 -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=2FjdbXAz/FJzIp0q0XX2KwDHU4oS9dOUuy/3LBUrCRo=; b=DyYRn8TxutrLH04/YPnFe6ap32NlyMLhL/A2TzjAYklvAS7BgjA3ZTxPBwYVqKxtJg wJEssU2uRv3ppnc1JSsgXKxp7C5R3kzmDzIZVPSo9i/C9A8ejagXNFvcBIounDVanGc/ 2d40oq0FGALXFcHXxcVCXtsLP25+gIlbMzdJ5yF7olYo1NNpOktnAZ493DJEcg9EPWmc Z0/h3YZZabqL28ELhMoMiQJaMZH93dHjJALe8n5HiRco7esAGBJPahZIOGUgmiWi1sfx G2RxABvA5C8yUUCLffjg8Tx8rnHgCrmCMUMFJbqbWepEbRCA5xswxWNHR0QFgieR5e+I StBg==
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=2FjdbXAz/FJzIp0q0XX2KwDHU4oS9dOUuy/3LBUrCRo=; b=CSRAH1lrKPEupDscda3vEYHStS0m+9SsRavngh3xViwU+qXdN3XpBs5e+8JKZS7iLw LQQ/pTUbpEdC+4qn5nDoheyYqDMCJvbal0EuMMzq7mGM/DgKpmUhf+6wHjcyW6NB/F/6 TEnnuiunFYNcXc0Htdq57ikPeJJopf9rTJxneBu/jUphEfFI0qy1iusKL22gRTLWwRZ8 dE7tei06Nsq8lVcOzim38+nbOfdg2IZggNpJxyyk0Lykl8GvEnv1Lx29GNwhjidgaDUn GQ3v6vF3rO5ApFXTOk2X6QuCZeyz6zpMgcH5KFFunJmMfGbLSYmFk8iERUgKItiz/Zy9 oYYw==
X-Gm-Message-State: APjAAAXmQrIXefvvfxgRxP70u4yDmBykauZK/Qb4+msnn6uimSnVlGss qRZi5NGvLRVOL1QEZu/1h5c=
X-Google-Smtp-Source: APXvYqw3Bh1wcXv3ifpN6COW8NwV9ITaeKmis5u5jAIaM86zFvnjvfdDJ7Ree+RRxpil2NzkCLadlA==
X-Received: by 2002:a2e:8559:: with SMTP id u25mr14094250ljj.224.1562686873072; Tue, 09 Jul 2019 08:41:13 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id u22sm4901510ljd.18.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 08:41:12 -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: Tue, 09 Jul 2019 18:41:10 +0300
Cc: "" <>, tcpm IETF list <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tcpm] [Ecn-sane] 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, 09 Jul 2019 15:41:45 -0000

> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe <> wrote:
>       1.  It is quite unusual to experience queuing at more than one
>           bottleneck on the same path (the available capacities have to
>           be identical).

Following up on David Black's comments, I'd just like to note that the above is not the true criterion for multiple sequential queuing.

Many existing TCP senders are unpaced (aside from ack-clocking), including FreeBSD, resulting in potentially large line-rate bursts at the origin - especially during slow-start.  Even in congestion avoidance, each ack will trigger a closely spaced packet pair (or sometimes a triplet).  It is then easy to imagine, or to build a testbed containing, an arbitrarily long sequence of consecutively narrower links; upon entering each, the burst of packets will briefly collect in a queue and then be paced out at the new rate.

TCP pacing does largely eliminate these bursts when implemented correctly.  However, Linux' pacing and IW is specifically (and apparently deliberately) set up to issue a 10-packet line-rate burst on startup.  This effect has shown up in SCE tests to the point where we had to patch this behaviour out of the sending kernel to prevent an instant exit from slow-start.

 - Jonathan Morton