Re: [tsvwg] Prague requirements survey

Sebastian Moeller <moeller0@gmx.de> Sun, 18 April 2021 14:00 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17DE3A190B for <tsvwg@ietfa.amsl.com>; Sun, 18 Apr 2021 07:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC_oHyuehL7A for <tsvwg@ietfa.amsl.com>; Sun, 18 Apr 2021 07:00:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF5C3A1909 for <tsvwg@ietf.org>; Sun, 18 Apr 2021 07:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1618754424; bh=fWJHLtZRwVp/eY6M5iLn2xOkPSn5bR09WGVH63hhfhs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=BZZ8OU2F06R4AAGUsp7xwpWViO8l4vJfNmAsGbcm0ubPNvMcmZoCiD1lAITLHUnYa yd1Dg3PPKtJr79BFJr/njJT6eedzTf1Y4wlLYHWKzoQWTIM/Xg1LvQw5qD+UQXwhPK iYZqhMFw+qDHKe4HH++NfpRU4S5z9yHgFS7AWSgc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.6.14.20]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZTmY-1l2nZG2CcY-00WW98; Sun, 18 Apr 2021 16:00:24 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <AM8PR07MB7476F513E7A6551F27DC7295B94A9@AM8PR07MB7476.eurprd07.prod.outlook.com>
Date: Sun, 18 Apr 2021 16:00:22 +0200
Cc: Vidhi Goel <vidhi_goel@apple.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E50BC9F7-7871-4269-B521-E7DC28FF7512@gmx.de>
References: <AM8PR07MB7476A907FDD0A49ADBD7CA7EB9BD0@AM8PR07MB7476.eurprd07.prod.outlook.com> <SN2PR00MB017475FC0E8C13754E531E17B6B69@SN2PR00MB0174.namprd00.prod.outlook.com> <AM8PR07MB7476FAE559719D241375A816B9B19@AM8PR07MB7476.eurprd07.prod.outlook.com> <HE1PR0701MB22999C8C05ECA3D995FA7FFEC28F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <AM8PR07MB7476E0EB3FC368D3C69A5466B98F9@AM8PR07MB7476.eurprd07.prod.outlook.com> <DBBPR07MB7481E1026CDE30D494856F15B9989@DBBPR07MB7481.eurprd07.prod.outlook.com> <AM8PR07MB7476FAEF53518DBFE457AC62B9949@AM8PR07MB7476.eurprd07.prod.outlook.com> <AM8PR07MB747629F14C5AEC5B47F40F56B94C9@AM8PR07MB7476.eurprd07.prod.outlook.com> <92C476A6-3E60-498B-A088-EF24E4B077AC@gmx.de> <83EC2DB8-C42F-4B1D-80C0-F01C2D393A9F@apple.com> <BB1A6362-FB51-471A-BF50-18C882C303E5@gmx.de> <DB7101BA-839C-44E2-B76E-C04F7963B5E5@apple.com> <AM8PR07MB7476F513E7A6551F27DC7295B94A9@AM8PR07MB7476.eurprd07.prod.outlook.com>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:KFOXqOJ9BLmq+sI3ndP5FtAc8rw/YvvptSo6feodOiRO/5nS6Eq rtPYg+lylYWrUlVPwRFxHMuxtMusDBivJFQ+BFgrF21bQjNy/AYX0q4Jy7IQuMNO2b4D/Bl ZaiTEnQit5R8bzJsYh192Fzh3IqjvHftzqA/9sPnbdlCT5AjdOz4zDgngQFZ13Hkrgyuy+6 6RopoZOXEOFo5sal6QcQQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:oDi5wacZuTQ=:oPjVIyNb2nSUEfXAbsDfBD YhhWRhuYUWgi23iWvXP0VeA5dPh+6o/gu30r1PJJYLmSXlX60WMgxg9u7CuLZqya092HhwZEz FgFAAbtiqKsWli+Bh1XA8Zs0YSbL+cmsI0MEIMLXeOP49nHLXtKJTIk7olojwqob+VuERAG1I HAkvEZ2SDUrb8aCv1jO2MDepsc5sZb32YU1/aj6JqFHNm+nnEZ0h0mjwMa3nmYExtCNtu8wUu 1PuS8qSFA858JZmXT3e7/X161DvubHRPAeAHuYZwsJIcaDzxAyYV/dUWyZSOAyBWKFmE26Ipx Ub7XoGOiICnkgLt7uF+XVhjRfXRIi3Ai5Xvaihrmt6uSBO6mGhzpcPEWqyiQI9GbG/Po33lv4 YMGyL2MZzus4an3uehWm6JoQ8JuuuQl+/A63/ciH2yhme6kterKF9LRfDl3ERsdBarsSq0e51 pnRV0d89tzRDhBVvLbUON8dMvIIbPmexmuKy/q8eclyzcrwn8WrhqtaGK8a39zHsC5JLKV5O7 nBnfseD1bZWAJwmJQ/l1oQEwKKJ8VjuB/JQKrLjIl/bo5biVuCgt9ceuSnQ9pz/C2aN4FIv+4 p3bqbJ/qWQln7Zj+d42OnEewNj6d+HxgHrrDO5hyNSWVNUWxLkAuRjD90hPr6LdT+jB6A3Im7 xZ8wwwSiBtT8uEPfXWdd+29rsoasCiz5PXyIQbC4r5gpubB9sxhCZah73iqqndAXqz1EmFGmU k44bbp5TYJr1iK6PZ3+yJlkouK7Z615lx+ZSBFXjlhtrRpSbkI0VJW7w1hXUVx+s9PeU0NzUI b4+mn+MuMdr3KUJW9pozXfr2GRSuJVwLYC974UXxWfjjU9rfROQ5XXLJHQoOWCtHxYP0w03bP wMXy2HLIiMbpImwm448cTQy+ZUwo0AeS11D0HTr1tKI7eZAp1CNG+II1BAAu8Vd253VO1Tk5A HTVdC/odxV3WQi0fTEeVsHJxMN6FkMjfrQG9sLuiJPGoZ+jebLYbtSPlivXSyMSfNXLKKzQFM JUT+sKXf+WEwAJP6dvVlY6Grd1LDZRDOMa85xeedDZCdzIxjID4MA/jBifqe8LOmWmzqRmzHU HskYw6yiQnL0Jow8dEXVZzzjsTntCcwqbcl0w8EhyG2/69WFFiEqi1VJtipWmFDzM+1guq0V+ 0HviUJKTQ3qvf+SeOnupDtkn7v9CiE3xyJDTLZpXUKR1KPidsZttGpOSg8+FkuKZp6GTE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pNJKkqmZ-G5FGg9pI40rsTw-zks>
Subject: Re: [tsvwg] Prague requirements survey
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2021 14:00:37 -0000

Dear list:


> On Apr 18, 2021, at 12:11, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:
> [...]
> As a final remark, converging to a steady state rate in the past was always seen as a property of a single mechanism (AIMD of +1 and /2 for Reno, and +cubic(t) and *0.7 for Cubic). I believe we are past simple single ACK response mechanisms (see BBR, ...) where models based on measurements and different states adapt the response and selects appropriate mechanism. When we detect we are out of steady state (0% or 100% marking for a while), the selected mechanism can be RTT dependent (getting up to speed, avoiding latency, ...), once back in sync with the steady marking rate, the RTT independent response can be selected (whatever the mechanism is).

[SM] According to for example https://arxiv.org/pdf/1706.09115.pdf BBR actually suffers from a reverse RTT unfairness, in which longer RTT flows overwhelm shorter RTT flows. While this is intriguingly hinting the possibility of a control loop design that might fall in between the traditional shorter RTT wins and BBR's longer RTT wins, it also demonstrates that RTT-bias is still not a solved problem, even for modern TCP CC as sophisticated and clever as BBR. I take this as support for my hypothesis, that the end-points alone simply are not well suited to solve this problem; no matter how convenient that would be.


Best Regards
	Sebastian