Re: [tsvwg] FW: path forward on L4S issue #16

Jonathan Morton <> Mon, 08 June 2020 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 339AA3A0B24 for <>; Mon, 8 Jun 2020 07:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8aLiMQ0sB-6 for <>; Mon, 8 Jun 2020 07:31:02 -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 D68483A0B0A for <>; Mon, 8 Jun 2020 07:31:01 -0700 (PDT)
Received: by with SMTP id z9so20727057ljh.13 for <>; Mon, 08 Jun 2020 07:31: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=LfLtWGnkN6hP5w286IXojYlr1vkxaq8wLGxA/9wP0vE=; b=dfibR70Rss6vtSuewxnE58OIaK7A4B0k23OECNDbW7niDb+3k3EDQckF9LGdfD65Md x2PeHNV60ZIm99urPtJCKtNomrtUn8+tRuxLBcKob1QhWeYq1pzOhZPS3TfSCM09O8eU eA0zGOLl5JzK5vfoOuHOPR03wAe/OkP8Fwb6aPiDQBgmgSXEusjxQZtVqg64JrEF5tKb X/vPfx83wMXGfvDdODaeZR4Hf481KFxGXsihamjHP03S7P89EtuNvpuRyEisOuIl5Wzz R0TlYjpmpqLIraQIt1XAZVcmi8ceycHSznv6kBJW9/l0YvMfFPdo2tihjo7H82r7602Y aKRg==
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=LfLtWGnkN6hP5w286IXojYlr1vkxaq8wLGxA/9wP0vE=; b=aVIGh+LPI7HaBjBkkZb8KGPoqNVPU8YUQxp2jyKy8WiivtrM7h2B6R3PgTfXs5bPeJ JRVWJQ7Pl8O/vtFu4sc9SilZdIGgwWn2Aafda15bIFgOGtH4I4Oa2nh2u2o/e6PvU1oT 5cdD+DOdLk545rZ8LiUP8mn95pcnAfksOakQ2WKCwvMnNpCcDEXsKlR7nO+MG36HoLol fIdjFm89tSwkeLkdXheGSYKXbkrwfswWyvvr3Z4kbdcAAFU5AsgLAd4iAR8aRWXMUrpe HTPvo2qQikljv1vyxxQ/pFRP7GtoHY2B6cFMmTnLd8HFi1K6NlZ1jMMfeEfa5rOIy8cK ZSfw==
X-Gm-Message-State: AOAM530nDefvd4YUQ7StRFZlOo6pnCqeg9LBOiCnPVQO/FZQKce81y2C pXUqp1ICOo60EBB8N+ryhmg=
X-Google-Smtp-Source: ABdhPJyxTElcsnis6g97Glxc3Eeki+gW41dMlCI4eYz7uaurG1zw+74qIDtG87TLk+mO81JT6tPgJg==
X-Received: by 2002:a2e:6804:: with SMTP id c4mr1147635lja.422.1591626659746; Mon, 08 Jun 2020 07:30:59 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id f12sm3729096ljk.44.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 07:30:58 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Mon, 8 Jun 2020 17:30:56 +0300
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [tsvwg] FW: path forward on L4S issue #16
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: Mon, 08 Jun 2020 14:31:04 -0000

> On 8 Jun, 2020, at 4:32 pm, Black, David <> wrote:
> This TCP Prague work on bottleneck detection and problem avoidance has been going on for a year, and while it's produced some very interesting results and I'm sure that more progress will be made, I'm skeptical that relying on it to close issue #16 will yield much more than rounds of finding new problems in the next five versions of TCP Prague.   Beyond that, I'd expect to see quite a bit of L4S low latency traffic from protocols whose endpoint implementations have not been scrutinized to anything approaching the degree of attention that has been recently devoted to TCP Prague, and hence are at more risk of getting into trouble.

I think some concrete evidence of this possibility was provided by the experimental adaptation of SCReAM to use L4S signalling, which was discussed here fairly recently.  The implementation took a very bare-bones approach, copying only the use of the ECT(1) marker and the DCTCP response algorithm from whatever original source they used.  The result was summarily declared a success by its author without any analysis of how it might interact with conventional traffic; I assume he relied on the L4S team proper to have done their homework in that respect.

So we can indeed expect endpoints to behave like TCP Prague or like SCReAM, within the L4S ecosystem as presently defined.  Network operators will be expected to deal with the fallout.  I think we should also expect most network operators to be blissfully unaware of anything we're doing here; most, indeed, will be fully occupied in simply maintaining reliable connectivity to their own little patch of the Pacific, or Africa, or Asia Minor.

That is the context in which L4S must find a solution to proceed.  The solution must be demonstrated, tested, and documented in the appropriate drafts before it can be accepted.  I think it is a Hard Problemâ„¢, requiring genuine further innovation to solve - or, alternatively, a change to the signalling method in order to remove the ambiguity at the root of the problem.

 - Jonathan Morton