Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

"De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com> Mon, 02 November 2020 12:42 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53E3A0EFA; Mon, 2 Nov 2020 04:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 rv5QmNqpZ800; Mon, 2 Nov 2020 04:42:44 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80104.outbound.protection.outlook.com [40.107.8.104]) (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 6522F3A0EF6; Mon, 2 Nov 2020 04:42:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gNoS/IHJDX/fnt+VizSWYPs0cQzPcRDT6UQ3EqoVRdl583PbnwhBZE3D2iJscupn2w5m/TsC1AkKlQaDnE3N+7UY4Lxn4pths/vJIkfamV1MsG3hmL7IW5UtmCoBXkkA2RvGvY10D/3DqnX4Y97pJayzflG/sC5xVG2/w8IcfM7t7Ed8LTDtge7XDO/UtZ74y3hVPl7eERFkjg9lVctbLHxZhu9OBxZeKjR1vruwKWDLkl7yaCZJ3GJuSmEUU+txE5CczpY/C8oe/cbstqkHJgEWbcrIUNrFjKydjJ9a8avsp+1MfduCHvkWgstj2undXt7Frejy9pZ05XRsPvpQvQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=di6f9QS0yHUUgPERN7AAh11pz3hvtqIQ5SLfTaVCDwg=; b=kcRYZ4oe9YSNDboE2t82bfgYkLhnAIUUNNHDxe0UYGq7e5sPx8TZZcQ4cWnRJycBh2Qf5W/nNMlgffKn4F4s+uVtnbzq4UYozzSlbzE2DXKFBQBitXKY/mNdvQQXq7PVrE/K+E3RSIO4IauAgtf1rUYDSVQjPjeyzm/Ov4gSMETtEuB4DuL0/pGj3V8rlfBotA0hySyL9foIJncZB2/FCOtPwIWvvdETeOlL9qOiH17djRJBcskALf6PqrnYLGmn0lFynU1sEvEZehzbJs/P5ryhvycp4LMa/0efE0cLTZ/xL/IsQrxN3pL12qaJLqb5ueV77ngteng9Uyirr+E+4Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=di6f9QS0yHUUgPERN7AAh11pz3hvtqIQ5SLfTaVCDwg=; b=wdlwBXU+UoGke0gHNYea5Tg8R5VGPU8OwgdCeBwv02zdD1RRLTD4sPtmHOXJ9zKLOWAmLaRXAX6NgvlR59WsaKOxgPi2SA3FF76fUnBKe6NKuCiWezifo4OmDFWFot9+1O0K8fUlxaCrNmSXLwLT9A2eAyO1JEQDbAArrjIjDWs=
Received: from AM0PR07MB6114.eurprd07.prod.outlook.com (2603:10a6:208:113::33) by AM0PR0702MB3556.eurprd07.prod.outlook.com (2603:10a6:208:24::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Mon, 2 Nov 2020 12:42:40 +0000
Received: from AM0PR07MB6114.eurprd07.prod.outlook.com ([fe80::a9f4:9199:8226:d6c6]) by AM0PR07MB6114.eurprd07.prod.outlook.com ([fe80::a9f4:9199:8226:d6c6%6]) with mapi id 15.20.3541.010; Mon, 2 Nov 2020 12:42:40 +0000
From: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
To: Jonathan Morton <chromatix99@gmail.com>, Christian Huitema <huitema@huitema.net>
CC: iccrg IRTF list <iccrg@irtf.org>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>
Thread-Topic: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
Thread-Index: AQHWsIfwC/FrblPY50a/ND1AVr6ZVKmzwIVwgAAzdwCAAAQwgIAAC4kAgADEkjA=
Date: Mon, 2 Nov 2020 12:42:40 +0000
Message-ID: <AM0PR07MB6114D5F3F2826A8ABC2173C4B9100@AM0PR07MB6114.eurprd07.prod.outlook.com>
References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> <28247e5f-5df3-1f75-50e6-b4a7e80d5ab0@huitema.net> <61B6E9DC-8786-4CC0-9AC0-7F74E3529A73@gmail.com> <40751956-daa0-5693-d880-c45e8ca262cc@huitema.net> <AM0PR07MB6114083DB6F3FBA98AA2281FB9130@AM0PR07MB6114.eurprd07.prod.outlook.com> <5ba51c98-9600-a55f-5d9f-bff012eb39e4@huitema.net> <fc6f56f1-add4-fdc0-4718-012ee10102bf@huitema.net> <84E29EA3-67DF-4130-8E92-940D5A4B19DA@gmail.com>
In-Reply-To: <84E29EA3-67DF-4130-8E92-940D5A4B19DA@gmail.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com;
x-originating-ip: [2a02:1810:1e00:cb00:106c:a742:663:cd5d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 9c17f3a0-4a92-4d23-ba01-08d87f2cc973
x-ms-traffictypediagnostic: AM0PR0702MB3556:
x-microsoft-antispam-prvs: <AM0PR0702MB3556B91D1FFFA18A03D04980B9100@AM0PR0702MB3556.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3513;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JkvdiZdExfTkc6RWsrPsi0zMRFIAp6Ii67AWxA/n9hAe5T2NaKngJLrQ0/AXwNZGAj/1jWlbuXOTBLr8vt+IuSxvsWgRQ+aIq4ESgZ8jsYvns3d7V2Ychdll/PcfLXzd9Aym3v+Tm+ntaVlYQoj04wh/Oqc4aiwznsuC+h4CJFDXziYRXosP8F43w/AWXonxi/4Q6OSTo+OtMYUw2eJCZkFd16NginLbI0kjwJxGkRl4b1sGs4EfQeJtFg6nkHSqZ7ER/mFXvDFqYhR+fiL/3NWCXoLysAC9D4kULH5lVk22MXujvSV4gLtdaiS9e+KY
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6114.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(396003)(136003)(366004)(8676002)(6506007)(7696005)(53546011)(186003)(2906002)(4326008)(8936002)(52536014)(5660300002)(71200400001)(66446008)(64756008)(86362001)(66556008)(66476007)(66946007)(76116006)(33656002)(83380400001)(54906003)(316002)(478600001)(110136005)(9686003)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: e9hfeVlv255X4qwxaRG73VRVCxTZtaJv3hrAQHmbHCoyVGSXBf433Yf/Rrz6g2NaChRG5AiYY8PZODGNf4+TDU3UD1duxSN2JYNN61uCCeLYvpBtj3jZIwAHtm5V/SFET1Im6Mv+E3Y0gxA9bYrTn0hO1GS4hssgOPcEcv3l48ukBsCLaiCpBliVEgVUhToFzY+PtFzkDQI4237xZl4iEY2Fv/9Xs4W8Pt28oJRiVsFKSr0zQHm8ToXuc1dBdW3TTMZljiMqaW0FdI6nUs7b5+xjJTXbGKvpcRh6EwKwII+jcueubXSr/5MGU+leCpyey1vKljqR4LHr9FYia1jFWKhjg5CQJWnz8DmsENn7uBdMOAhgd3B2vIH/41U2rNX4mCJkne1kTIMrMrbII/a7gn3JAJSHrzV8F5WFNScpvONvsl8JKvPqLEV3FHjvj+6Xuy3jEN4n9botd57D7Ko/LToqsVTnpgQ3aUpnyhsMl20HbDKklNtexNId6ratIe4/g4a7LdfiU+eqrrbrsJ1m0TGgjdleS8q3e3W1SfhNUcv/h+BW76pdXJ8vNDAQAxJI1U12VHgWRcOjDvkN8BPPNNBgYjx6c5WTYVGeuQHk966ARBnENXCnAeCaEKt4JXtaTownDb0M5gQMZfBKvoQlE5WCrFxywF1NlsLWQtZj0jjzmkzZZMGprVmB7p3jDOxDX0ETDGvqlvUpsveMtaM9Nw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB6114.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c17f3a0-4a92-4d23-ba01-08d87f2cc973
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 12:42:40.6509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ftImQVxoadVPsmjOK4hdDSvdbvn4y/uDTYAHbX6YAAN70vy9uZ/o25M7ybA/y5vIAZA1orBHEnqqLL/QwVRNlCCwWl7uBrr+qryx+lgvhU4U1Iwouc4qGuC3mKtR2ekY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3556
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/U0Ai6tLB39Er9xMNZpg38vWbXw0>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 12:42:45 -0000

Hi Jonathan,

Indeed, FQ is ensuring (actually enforcing) per 5 tuple equal BW. Do you suggest we need to have FQ per 5 tuple in every bottleneck? This would indeed be a simple solution for CC developers. But not sure if every NW box would like to implement this functionality. From the moment flows are treated as an aggregate, the rates that CC's will get is exactly based on their respective behavior (say their formula), and if they are vastly different, so will their rates be...

As long as there is no consensus about universal FQ, I think we need to discuss what the formula should be.

Regards,
Koen.

-----Original Message-----
From: Jonathan Morton <chromatix99@gmail.com> 
Sent: Monday, November 2, 2020 1:52 AM
To: Christian Huitema <huitema@huitema.net>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>om>; iccrg IRTF list <iccrg@irtf.org>rg>; Bob Briscoe <ietf@bobbriscoe.net>et>; tsvwg IETF list <tsvwg@ietf.org>rg>; TCP Prague List <tcpPrague@ietf.org>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

> On 2 Nov, 2020, at 2:10 am, Christian Huitema <huitema@huitema.net> wrote:
> 
>> In any case, you have a scaling issue. Let's consider a 1.5Gbps link, with 15 ms delay and 1500 bytes packets. The nominal sending rate is 125,000 packets per second. The marking rate with your formula shall be p = 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the connection will on average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of the time. This falls well short of the requirement to provide frequent feedback!
> 
> Sorry, bug in my spreadsheet. The marking rate is actually 0.1%, about 2 packets per RTT. Still not frequent enough for my taste, but much better than 0.0008%. Nevertheless, the inverse relation between marking rate and data rate is not great.

A property of both Reno and DCTCP is that a particular CE marking probability results in a particular average cwnd, over some reasonably long period.  The relationship formula is of course very different for each one, but that qualitative rule happens to be the same.  It is a property that DualQ's coupled AQM design relies on.  CUBIC is a little different in its high-BDP regime, but acts like Reno otherwise.

What this means is that competing flows experiencing the same marking probability will converge to the same cwnd, and their relative throughputs will be inversely proportional to their effective RTTs.  This convergence is not necessarily very fast, but given a single queue and a single AQM, it's about as good as you can expect.

When you have an AQM per flow, you can do a bit better by applying a different marking probability to each flow.  This makes convergence faster, and you can make them converge to the same throughput, not merely the same cwnd.  When you have a separate queue per flow, you can additionally prevent one "fat" flow from affecting the latency of sparser flows, and *enforce* the throughput equality on short timescales, even with flows that are unresponsive to congestion signals.  This is all established practice.

And that is the key to achieving RTT independence with the minimum of added complexity.

 - Jonathan Morton