From nobody Mon Nov 2 04:42:53 2020 Return-Path: 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)" To: Jonathan Morton , Christian Huitema CC: iccrg IRTF list , Bob Briscoe , tsvwg IETF list , TCP Prague List 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: 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> <5ba51c98-9600-a55f-5d9f-bff012eb39e4@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: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 su= ggest 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 respe= ctive behavior (say their formula), and if they are vastly different, so wi= ll their rates be... As long as there is no consensus about universal FQ, I think we need to dis= cuss what the formula should be. Regards, Koen. -----Original Message----- From: Jonathan Morton =20 Sent: Monday, November 2, 2020 1:52 AM To: Christian Huitema Cc: De Schepper, Koen (Nokia - BE/Antwerp) ; iccrg IRTF list ; Bob Briscoe = ; tsvwg IETF list ; TCP Prague List 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 wrote= : >=20 >> In any case, you have a scaling issue. Let's consider a 1.5Gbps link, wi= th 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 =3D 2/(r*= 0.015), which is about 0.0008%. Over the last 10 RTT, the connection will o= n average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of th= e time. This falls well short of the requirement to provide frequent feedba= ck! >=20 > 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 th= an 0.0008%. Nevertheless, the inverse relation between marking rate and dat= a rate is not great. A property of both Reno and DCTCP is that a particular CE marking probabili= ty results in a particular average cwnd, over some reasonably long period. = The relationship formula is of course very different for each one, but tha= t qualitative rule happens to be the same. It is a property that DualQ's c= oupled AQM design relies on. CUBIC is a little different in its high-BDP r= egime, but acts like Reno otherwise. What this means is that competing flows experiencing the same marking proba= bility 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 abo= ut as good as you can expect. When you have an AQM per flow, you can do a bit better by applying a differ= ent marking probability to each flow. This makes convergence faster, and y= ou 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 unrespons= ive 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