Re: [tsvwg] Reasons for WGLC/RFC asap

Jonathan Morton <> Sat, 21 November 2020 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 894283A0CEB for <>; Sat, 21 Nov 2020 06:32:21 -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 kxTnCBdw2p3A for <>; Sat, 21 Nov 2020 06:32:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3D643A0CD9 for <>; Sat, 21 Nov 2020 06:32:19 -0800 (PST)
Received: by with SMTP id f11so17616299lfs.3 for <>; Sat, 21 Nov 2020 06:32:19 -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=2+LlCqHB815LMBRmT5QPPNqeh3ueSJgQYTOA8pKq/3E=; b=l1hFAG4RQAaCDJ4dtPqU5u45tRjbR2L65K2wxa8cApxOynsC1fZWMZsjb6cdD1zQfS hwzUZaj+yoDA2AnX4qpqP4CXHMjLpEGfYC75vL6+LdRn01LVHpME1Ps0rUkTDCmaGhMA YvLZVtJ/vilTkCkY0WMG9RXaq5/X8gERaTE++8wbdRBPJvxBCMOKWnC1tDznsGd3qS7a E+1R90FPlX3fVKnHkKJ9ew1clVnddU5zJT5XykayL502mYQLJMwhCNNxJVQBo3o8x2m8 pRCqZX1oGoJdSN6G7I0PdhJBqWR8lcWSL4RzgckdyLLaJ8Fcx2E4KZwzGjb/jCndlq9x zx7A==
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=2+LlCqHB815LMBRmT5QPPNqeh3ueSJgQYTOA8pKq/3E=; b=bdtbiCkJKOo1cNN+His8lR64Dm/h2lZjquLG3Wr2knK9TiKaFU7G/tHsR8fmCthH2x Zkq027+4XhagrSVAfuFrXfpUMiL4TpGlVqytM5hsFIhxe5InujUgI0VaDtuXalm+5Uxs Fn1dorG5/wg5Aj7qQ3QB2hM7MNHUc5dQCLPI6VHuqZ5oOXe3WO7pSWuYbFIBxYEWYn1m WI7RzX63hjyK4Tho03FAU4eZ8KrbnUEfQ3rRHRn3gsy7LX70uWBkophndgwT153AY2h4 jLJ8x5ucr2XRv8tYUiX78fMT3phsZYc/teGrLPqCvBcyOPdtHDuclleFvyyw4mR0XOU0 HxpA==
X-Gm-Message-State: AOAM531TXIf4MwKmuKV0wk1zLzzk88GShHtjm77UpKiftQ+1s4AgKenT V5Pz/SttAWRlegTG0g2sbdA=
X-Google-Smtp-Source: ABdhPJzOVt/bG9n4p5iyjsixHRu0zjW+PfWX1s/KuZ/vyhuUu0UGpEw+ydETrcEdW6ILWcxrBvRG2Q==
X-Received: by 2002:a19:ac07:: with SMTP id g7mr9876444lfc.125.1605969138095; Sat, 21 Nov 2020 06:32:18 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id u1sm728113lfk.65.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Nov 2020 06:32:17 -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: Sat, 21 Nov 2020 16:32:15 +0200
Cc: Greg White <>, Ingemar Johansson S <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Sebastian Moeller <>
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: Sat, 21 Nov 2020 14:32:22 -0000

> On 21 Nov, 2020, at 10:25 am, Sebastian Moeller <> wrote:
>> In my personal opinion, strict adherence to zero-harm is too constraining, since it doesn’t provide any way to assess the upside potential of a new algorithm.
> 	[SM] +1; but current L4S' issue is not that it is not given leeway to do a bit more harm, but that ATM its harm on rate in some conditions realy seems bound by TCPs unwillingness to reduce its congestion widows below to segments...
>> *
> 	[SM] Yes, great link from Wes, but I am sure we will end in weird food-fight immediately, as team L4S will try to trade the harm done on the rates of non-L4S flows with the benefit to the latency under load for the L4S flows. Ignoring the fact that in both cases the harm-benefits are pro L4S and contra non-L4S. 

As the Ware paper already points out, the "harm" metric deliberately *ignores* the benefit to the newcomer CC's traffic, and focuses on the harm done to status-quo CCs' traffic.  In this respect, merely glancing at the test data posted by myself and Pete Heist over the past few weeks (and indeed the past year) shows that L4S and TCP Prague are capable of inflicting substantial harm on existing CUBIC traffic, which has been established as being quite prevalent in today's Internet.

The acceptable threshold of "harm" to permit deployment is not zero, but some function of the harm done by the same workload added using the same status-quo CC.  The precise form of that threshold function is not yet fully established, but it is possible to obtain objective numbers describing "harm" and begin to analyse them.  I predict that when such analysis is published, L4S and TCP Prague will not come out of it looking good.  But it may take some time to rejig our test suites to generate accurate harm metrics.

 - Jonathan Morton