Re: [tsvwg] fairness topic at IRTF open meeting this week

Sebastian Moeller <> Thu, 19 November 2020 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E41A3A1280 for <>; Thu, 19 Nov 2020 13:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PO1yJ1iUj-P8 for <>; Thu, 19 Nov 2020 13:23:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B99A3A127D for <>; Thu, 19 Nov 2020 13:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1605820981; bh=GbtvHHwp0aiFKFchA9Xy1e+9x7nszjhTyWcvXTLbVHM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=d8Uw9zjELZL6k46igMOuanK/1m+NNBvKLGNN3xoQCtTqlQzcv8HnnNlmKkl3evjXt Y4d4o4/1R7GbRzV8DV0OuHH8eUzc2xENSSOuKTlSPdlsQjEYmPuOwELIZestnMBPqp xU010LZgnd594jloW4dVCXrSzXlxwjwT6w64MD9I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MUXtY-1koYZZ2MXQ-00QWXv; Thu, 19 Nov 2020 22:23:01 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Thu, 19 Nov 2020 22:23:00 +0100
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Wesley Eddy <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:9ddHfQhKRdUGFkxGJlh/UVU6R+d8Vt4UEAOgnSvr+SJ4Errd5RK Ppz0yObMF+kTNxoNMPZ2pohCW0zGWabddYAhpbs+vOCoj3yAv32TxdyJmokV8i3vIk5/0s4 Ci9hnh9hKtqJIQ/VDBX2LYqS+uUt/DEYjzmveHWg360AULa95rulNYTxx/eDnCYeZ/j5pvi ser8a2nYuonlpOYnuqAwg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Jb2meXcTjwE=:zhpQhjQMkidEn+PDEZmKK+ A9kFyVhQb8O2tDVq4bSpW1PJpC3bQ74AQLac+0VRDJWP6hZO7erkBHWt6DT9xkktKnSh58ziJ VlKcxU2f3X2IQuGKMUZomcjRMflKGCa5ymimPUnGwe+JtHvhv5dDXyWQKQv/1Z+GEC/OV0vZT kt//Ry3z373sGjHT9XxDJqin37BvR7par9aLytmbw66d7IEyrqDkshmKy0HQHzuyaLoBQe3gG rokugRz3pNnWdDgxSlY2fpLjyojyyYlPKNJ9HnmxBsBHx/qZCkHdMfHQc+6LGrZLg1w7pBeBG aIUo6Dd57WHisTUr4rc6b7aHLEjQ3QtLaDFdEl6CCwWSFz+6VpbJLyaWhdtk1Sq6IqWZwYnP5 J0VUh89CWDBRn0eUi1g776Rkp1VkyTanupaP3VuNHJ+9j8YlK5aJeYbQQR4ZBi0dlPPHYcS9i Z3QKJ4JBoBatvdbGIEy6lCndA86RKBCA2W3xx528pMC1YyP4l6klWdPSX8CdHRleZI6xcF87k D9GpLgCiPioiooDjKOG2Q682BpSbxy7q5T1bBQkhCcoRCeL5hNOyzUySOhAkInLhQKcsx3WIs 8UY6mofffwYZ0KQJAYny1LmH3aXQe4QF1GEnBoXOCmV+DinTd792XPuldjpFkO4zPQJPmDTTk AAGfgwhAdvYlCrbE0ueL/t51cguU/vHGRgLaIBSk0VtKb04iaov96UZxoKOezdW+c8qxUmBT7 stp9pubXA9Q9OGWvm6Nt4H02R9b3J7sRdsFbJk+HPfqX2gMpQnYrQQgCE0dMZ/iFHbnKiuRAN cnTkuG8hAXaFhhIuYSX5KBzcULqCsARm6dmdm401Y6LercLB5YGeA8VbQuF2LZwF3PKsTsLqZ lP8XalS5NzkJJH7mMWlA==
Archived-At: <>
Subject: Re: [tsvwg] fairness topic at IRTF open meeting this week
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: Thu, 19 Nov 2020 21:23:09 -0000

Hi Wes,

thanks for posting this. Interesting.

Here is the gist in one sentence:

If the amount of harm caused by flows using a new algorithm α on flows using an algorithm β is within a bound derived from how much harm β flows cause other β flows, we can consider α deployable alongside β.

This is pretty much what Pete's recent data demonstrated that TCP Prague + DualPI2 does NOT compared to CUBIC + DualPI2. The systematic biases pro L4S in both rate and latency make it clear that L4S flows will "harm" non-L4S flows more than non-L4S flows will harm each other. 
	Sure, harm is slightly more flexible than simple equitable rate sharing, but since for normal bulk flows throughput still seems the most relevant metric, and latency wise we know for a fact that TCP Prague will get latency priority, at the expense of Cubic (in my simple comparison). It is hence clear that L4S does harm to the existing CCs. But even without a new way of describing this, it was clear that L4S is not competing fairly...
	The question is, is the amount of harm acceptable for the WG or not. And how is the rest of the internet going to react to the WG's decision after deployment starts.

Best Regards

> On Nov 19, 2020, at 19:25, Wesley Eddy <> wrote:
> Relevant to some of the recent discussion around RTT fairness, safety, etc., there is a paper being presented at the IRTF meeting this week that may be of interest.
> Ranysha Ware will be giving an ANRP talk on Friday, on the paper "Beyond Jain’s Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms” from HotNets 2019.