Re: [tsvwg] Reasons for WGLC/RFC asap

Jonathan Morton <> Wed, 18 November 2020 11:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E2923A17B6 for <>; Wed, 18 Nov 2020 03:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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, URIBL_BLOCKED=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 Es58VJqS7CRD for <>; Wed, 18 Nov 2020 03:16:33 -0800 (PST)
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 D37713A1032 for <>; Wed, 18 Nov 2020 03:16:32 -0800 (PST)
Received: by with SMTP id l10so1919706lji.4 for <>; Wed, 18 Nov 2020 03:16:32 -0800 (PST)
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=dZoOmLk6XV97zmm/sWiY7vbD2pAFhKEdFu1bdIfWCz0=; b=Sv3XJIK7gfAQUzSEoiihVPEqFCf3GkuiHi5ziHyvTIFABsqCArS2jJazTtajNT+No4 R4XWyWDx2x+5H/4mdpNkTld40C8Ti7YH5JCoLg4TmiFeGa3FynNGU5wOwia8Ef7+jNGo Z/i2R3sBr2OwRPuXp/sOuovSBfF+ojC1FoYXjeGmPSnfMxGlNFrmksnB2oFK/X/emYRe KxyIF4FKTzf/Qbm2zPIKopRaaDUZWIofBg22rZoOX561dHB+RJ3sSoQJVMT2H0h2Wbir dnj2XCqJVgE3Xs6Du+WrAOINXzVWUa9XJMvzGH+85hw5RYcibtOrcsf9Y9/BaTGXtYI5 iqpQ==
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=dZoOmLk6XV97zmm/sWiY7vbD2pAFhKEdFu1bdIfWCz0=; b=R4ykf4jrfliJ30XLA/bnHym71QlOItZwsGjl2Wh/vX8RmYbWORyvzJor4eTE8M66Yt 9fGUCPE8nVtQqi5X+JWtHROrmV4MRPQcT8vWED3KBCsa8584VKlSfdeNJsIU0Joeo+N/ B8rdmfmOppJcVx6S+F9/XrAiKhKGsI3dnX99Ujf6e24grHXHtnRg22bSl4Uw3wKs+WGO xqAKQdOhXFW8D6KrHz+o33FlLBIhUw1/jewrhQx2mJ2yFtKUQpTvMGK3Ph5MECQMUB0k 6hViXODCHAtb9faEv8TDtSJeNCUB+LRTakD/TyPf9muGOV7Eef6Nbmf2G02401JK86Lh UaCQ==
X-Gm-Message-State: AOAM533FeWpbKyngxjxMnGmH6GcAzec1QvMlQANvC7YWOI0hWfSS8OIs 5TUphGXyFYKtDAVerAGcCf4=
X-Google-Smtp-Source: ABdhPJzeiu34/rP6+WInFjcOtLNOeezhfdhigSE0GuaEwZuKhF/8jbQIuc7YTeqILCljuvXXPyMWUA==
X-Received: by 2002:a05:651c:107:: with SMTP id a7mr3751977ljb.463.1605698191147; Wed, 18 Nov 2020 03:16:31 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id a26sm1411919ljn.137.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 03:16:30 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 18 Nov 2020 13:16:29 +0200
Cc: tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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: Wed, 18 Nov 2020 11:16:34 -0000

> On 18 Nov, 2020, at 12:31 pm, De Schepper, Koen (Nokia - BE/Antwerp) <> wrote:
> • There is NOW a big need for solutions that can support Low Latency for new Interactive applications

I've heard this argument several times in recent WG sessions, usually phrased as "strong interest in L4S".  I think it is worth clarifying whether it is *actually* an interest in L4S specifically, or rather an interest in high-fidelity congestion control in general, of which L4S is the example that happens to be most active in the IETF.  The two might possibly be conflated in some minds.

I would hope that if there genuinely is interest in high-fidelity congestion control, with all that it can potentially enable, then the WG should look for a mechanism that is likely to succeed, and to be robust in the face of future developments.

So, I ask the following question:

Assume that L4S is shown to be unable to meet one or more of the Prague Requirements, and/or is unable to present a suitable safety case for approval as an Internet Experiment.  Should resources and support formerly allocated to L4S development be redirected to some alternative High Fidelity Congestion Control proposal which can rapidly meet those tests?  Yes or No.

 - Jonathan Morton