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

Yuchung Cheng <> Tue, 09 July 2019 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2888E1200F6 for <>; Tue, 9 Jul 2019 16:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.205
X-Spam-Status: No, score=-16.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 0VeC7MluwQea for <>; Tue, 9 Jul 2019 16:08:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD13D1200C3 for <>; Tue, 9 Jul 2019 16:08:50 -0700 (PDT)
Received: by with SMTP id s3so413014wms.2 for <>; Tue, 09 Jul 2019 16:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RFGWIyJ8UomFdQHf8tvoMCGq2s8XebABzhj93IftLec=; b=oSIPvGeR+jIQOcc+MP/gZEPy/IxJhZ+c3VyVaFmD5QvwE12BEcR7NfB3SEYR/JYeKC HPXlwyq41dyQoPReVZs7+mBa1zpVbbImbzDAcRJGAmUmNys068D4iEaNbKknLG5R5Eoe JXJbbFF/PaZCwTIxqdN47cN0t57oWFe2RvHat6EYXSn/49dLHYtNuaL4otDlECWe8l1s ok5uxyNC97FzQAs0UqA0Fm3VrhYJ8NYiyNo2F5Movo3VyYcCgq6nWcp3GI9oBhaekVgE JbDE/nf1gTzdXGNiZDfyybnMz9DvLCnOJMPtnm7JV+FpDTuiPMrYqJ46wolDB+6L4C81 q83Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RFGWIyJ8UomFdQHf8tvoMCGq2s8XebABzhj93IftLec=; b=oGHPT2YHpNwWkrlcdvW0nadFg9eVTwgoYgYMWEY9Rb6+r2lORJJACuID/XlPjw9PzF PkXMn42fd8QK15dU8XJGNUypGfa/dR1FLhseJ1vPKmwJ0o7SR3K0cB9NUgtrdGBQ+D8U akNtn85wZgipbe30QWrbLQl6K7jxH0yjl7+cr9nmffDikP1dDncBz9lAP0FBv2tl9Afn QyZXKXb9joLwSZZ/9FLPVkDHSJoCrctoCTQGELuShSXhBN5ezNSnxPVQdquj3YnTut7j KAThc52FMtvGzr/Y0VfJDjDJDU391sg6Iag5JFY7tB+HaZ+1KAi0EWXv7BKyUGcDXDo0 f7nQ==
X-Gm-Message-State: APjAAAVChaJAxGFZj09KH87gIE8poRuumhLXG2sHC38RZS/Op+hXNefV W2uy5k8xBE2YCiqywctloMHepBtAbWCswPnqngg7dQ==
X-Google-Smtp-Source: APXvYqxAwY5qqyM/Rm+/hPBY+3DaOVS6fwNKmfRjAE31RbwuxWAjMxzuFiEy223ru7PZRpb3Pl4HJWTFMyzrjBt3Zyw=
X-Received: by 2002:a1c:c1c1:: with SMTP id r184mr1663655wmf.9.1562713728808; Tue, 09 Jul 2019 16:08:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yuchung Cheng <>
Date: Tue, 09 Jul 2019 16:08:04 -0700
Message-ID: <>
To: Jonathan Morton <>
Cc: Bob Briscoe <>, tcpm IETF list <>, "" <>, tsvwg IETF list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tcpm] [tsvwg] [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 23:08:52 -0000

On Tue, Jul 9, 2019 at 8:41 AM Jonathan Morton <> wrote:
> > 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.
We (Google TCP folks) are internally experimenting (always) pacing IW.
May hurt very long RTT and short transfers (<=IW), but could be an
overall win.

>  - Jonathan Morton