From nobody Sat Aug 8 10:39:29 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 A7B053A0B1A for ; Sat, 8 Aug 2020 10:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HrZ4LkUgwdjb for ; Sat, 8 Aug 2020 10:39:25 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47ED43A0B0D for ; Sat, 8 Aug 2020 10:39:25 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id e11so4128744otk.4 for ; Sat, 08 Aug 2020 10:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/TefviNRgnkZeqN9xSqZIRvmCiqLv0PrGc6WTSQVKx0=; b=PSlIInobImcQO7Q/VY7kbXS5irhjNzc3Dgo/JF+7CJPGFfuFed9LoPS08YaMQIpUnf nWvjbd2pSwZHoscy4+mu951L6TVEZZt53a7NWGkNklcvIa1SFh/7cvTqVeqdPnFuWgfL kH/zV2x7rGlGz+kCcR8EW2q6JMwhD/e0F9Zi4k2azReo9KWcCuzg7YtEdoWgvvWkg5EX g2GSHZg8vJJTYP2PH8wV1yU8AOja5s7f3QZsZbMKFiY86k9CjstW1b53yXI5aaElXX3q e0GNTsVUGlEyIy6aRbsMvNA+l679KUL7KI0cdDFnqeTEI4AhpElgJ8uHzcY5ko+8BX+8 5Akg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/TefviNRgnkZeqN9xSqZIRvmCiqLv0PrGc6WTSQVKx0=; b=j02YyaND+Ic22iFfeGeaDjM5H6MZFgXQR70nTATz//nlP4uYb8SKD2k7ljEaObISLw 4MUVM41pEtikQzHjJy6pA5LoTKEKJKylLCd8kQp09UI19w+dVfDABR4djmDOumR5Rxdp 1iEqlWMLqCchDMpaVGIBhkFhQtGPfpys6uD9fFVpM3EYWl0OaYBQrJRg8j9oet3lYuvt /u0PT+gv4TNQLgVOyORwE11ke16DwFD524TNcibJUraDOs+FfNjfiYJroYFU64TCglOY PgR6MzyfXJMuN+CHV6uFwNYMdZvkPvYCK15b4zgpDH5Y+tZSxbf8Q3XkO6u1OriYeEiW 0s7Q== X-Gm-Message-State: AOAM533BuUR7G2CckquoW2basG5/bl1Ll1o/HP1dyufXXQGLxlR4NXmb qGm75gfrkB4n5SAa7Wrknozn2QhOyPJkNq318IlZUlU6B6E= X-Google-Smtp-Source: ABdhPJwmtyGjimLvBepl9WfY3I2S0SwCfPT9bBXTuJd+v/gg7XJ1GDxxyjjBccRXHPzGWY2nOycaLOeUPQXK3nhhxU4= X-Received: by 2002:a05:6830:1e71:: with SMTP id m17mr17759648otr.188.1596908364360; Sat, 08 Aug 2020 10:39:24 -0700 (PDT) MIME-Version: 1.0 From: Deepak K Date: Sat, 8 Aug 2020 23:08:41 +0530 Message-ID: To: tcpprague@ietf.org Cc: Tom Henderson Content-Type: multipart/alternative; boundary="000000000000cbf0a505ac6133ea" Archived-At: Subject: [tcpPrague] Queries about prague linux code 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: Sat, 08 Aug 2020 17:39:28 -0000 --000000000000cbf0a505ac6133ea Content-Type: text/plain; charset="UTF-8" Hello everyone, Hope you're doing well. I had a couple of quick questions about the current TCP Prague code at https://github.com/L4STeam/linux 1) There was a mention in Page 6 here ( https://www.bobbriscoe.net/projects/latency/tcp-prague-netdev0x13.pdf) that if Prague encounters a packet loss while in CWR state, ssthresh would be reduced by (2+alpha)/4 instead of the usual 50% reduction. However as far as I understand, the current code reduces it by half irrespective of whether it's in CWR. Is that right? 2) I have some questions with the flow of code when RTT scaling heuristic is particularly set to RTT_CONTROL_ADDITIVE. In prague_ai_ack_increase (), the function rtt_scaling_ops->ai_ack_increase() is called, with the parameter srtt_us. This in-turn calls prague_rate_scaled_ai_ack_increase() with the same parameter value. Now, srtt_us is compared with the result of prague_target_rtt(). This function maps to prague_dynamic_rtt_target(), which returns ca->rtt_target + srtt_us. So, doesn't this lead to a comparison between srtt_us and ca->rtt_target + srtt_us, which is redundant? Thanks! --000000000000cbf0a505ac6133ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
Hope you're doing well. I had a cou= ple of quick questions about the current TCP Prague code at https://github.com/L4STeam/linux

1= ) There was a mention in Page 6 here (https://www.bobbriscoe.net/pro= jects/latency/tcp-prague-netdev0x13.pdf) that if Prague encounters a pa= cket loss while in CWR state, ssthresh would be reduced by (2+alpha)/4 inst= ead of the usual 50% reduction. However as far as I understand, the current= code reduces it by half irrespective of whether it's in CWR. Is that r= ight?

2) I have some questions with the flow of code when RTT scalin= g heuristic is particularly set to RTT_CONTROL_ADDITIVE.
In prague_ai_ac= k_increase (), the function rtt_scaling_ops->ai_ack_increase() is called= , with the parameter srtt_us. This in-turn calls prague_rate_scaled_ai_ack_= increase() with the same parameter value. Now, srtt_us is compared with the= result of prague_target_rtt(). This function maps to prague_dynamic_rtt_ta= rget(), which returns ca->rtt_target + srtt_us.

So, doesn't t= his lead to a comparison between srtt_us and ca->rtt_target + srtt_us, w= hich is redundant?

Thanks!
--000000000000cbf0a505ac6133ea-- From nobody Mon Aug 10 07:08:33 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 B3CDC3A15AA for ; Mon, 10 Aug 2020 07:08:24 -0700 (PDT) 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=ham 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 tHRAbzsDzrxf for ; Mon, 10 Aug 2020 07:08:23 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150112.outbound.protection.outlook.com [40.107.15.112]) (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 044AD3A15C2 for ; Mon, 10 Aug 2020 07:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IPeDFy/3aSPAcrh2ajL/MKrH5O2K5e8NUDCHPVc+m6C6L8bHCYrxAx3bMhjd1/QvCtjJ54lLwYMTXql04CCYEYFhYY9E7ovmt14dUaQg3z7BdQx40ClF61FSEDR7qFht7lrPBqVfJ+2anvhzkox74TVPoH0QGVbEvGTGSLwLMZwX904xcHOXDoTZeVpPTlaqo2tshDkPvhMnAKLd0/CkJ5bk/e058XTvMlaUTBAYcCon7jcaAnpGxim3wsFcPMbm/CtnzNi28dE/dm6HrfBczLAJa0K8Y4TmNxxQebSCVHO+XI6JtRMOEmPuFbzG7PCMLf10SLnQeDTn4v2lLIdk+g== 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=kc46nSzO0i/FvRs/k7KYYj/o/HD3JjPFUSK8j21zoYA=; b=ntPvsXMjwmeLeaYA7HDUP1NZMM7HM5e/W1gV+/QSk9xvcywyjKqYRSS8z6axwTa2eXv+XYFuoaOmbThEnonhpkR58RM5yOImw4rzBg0xcXzI0WfycOk60QL1ym+fNCKDGXH+eEQLVX1UHCsUOJQO/H5gq3N49BfDyKt0F4Yz5q7G4V99N8/TNpwJDOkBtuiqs9GpuRbTzsarHHSIsncAtQqmLmqO3He44h3biy+BW1mKaSSVl8U97BZZbfPGzkoSY3ZTKcybUr7UbNX/MLqe0zvOOkbUbZkdyYnyvpRgZWjAPoFhnkMViVCs2j+lZ5tyQ9h3mSS3mXmBu7ApHlZzBQ== 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=kc46nSzO0i/FvRs/k7KYYj/o/HD3JjPFUSK8j21zoYA=; b=FXxsePaltpnz90VAItL602N2tXn4czVS+HoGnlHUDZ5q6PxgnmT1ep1SiM4kqI882t5S1mYxRozKqJl7vbsZi7SKFeJRGkMmNGp6on/Dbv3u/ZuiAuv1GROrmsgkeRO6MLR5lfnO6bGQvnx5ENB/fIPASTLzTtIM5r2dHsQb6MI= Received: from AM0PR07MB3937.eurprd07.prod.outlook.com (2603:10a6:208:4c::20) by AM4PR07MB3441.eurprd07.prod.outlook.com (2603:10a6:205:c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.10; Mon, 10 Aug 2020 14:08:18 +0000 Received: from AM0PR07MB3937.eurprd07.prod.outlook.com ([fe80::45a9:c1c4:f1ff:19d2]) by AM0PR07MB3937.eurprd07.prod.outlook.com ([fe80::45a9:c1c4:f1ff:19d2%7]) with mapi id 15.20.3283.014; Mon, 10 Aug 2020 14:08:18 +0000 From: "Tilmans, Olivier (Nokia - BE/Antwerp)" To: Deepak K , "tcpprague@ietf.org" CC: Tom Henderson Thread-Topic: [tcpPrague] Queries about prague linux code Thread-Index: AQHWbarj8kI3S3n4g0WV+5tfSwxglKkxX6gg Date: Mon, 10 Aug 2020 14:08:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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: [91.176.180.31] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f09f9022-e249-46f1-e0f5-08d83d36d4e5 x-ms-traffictypediagnostic: AM4PR07MB3441: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ts6O+GEVrclRkjzvPgWOOLro4foDLbOaXFvv6dtD5nX/uoqdPALIoSV5DJ3d7UJzxy/3qiruBqMO2lKTz7LKvuTRcXfmzIzXGI06iWxkPAbDe4nwCNwOTf9qfLX9Yd+jtc1j554p2bskkcSEBLXPJrp2For9y+vlzOqS/9cY0oH3hQ/kqTO8MEqeetiwujzVG1qufEackHAmYrkBCWxiUKOISxOIFl8oy2TR998d7iWk1Qhcw2CQrTKP/OeVIOBe4WKOP7JuvU2WIUCg0pxvh8h2gLK3X1Jta4R7FG73ZRc9bEaI9yiQd3Rc1YounVGvKlH4DBlyy7TA3CBUDi7OD9UOtltZJ/Wvqh9FYyLm9UT51YHQOeqA+uDJmDCxeJYpLJtQGgVVUxQUB1Y/HOL0Gg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3937.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(39860400002)(136003)(346002)(478600001)(66476007)(316002)(66556008)(52536014)(66446008)(64756008)(110136005)(4326008)(8936002)(8676002)(2906002)(26005)(71200400001)(186003)(66946007)(33656002)(76116006)(5660300002)(86362001)(9686003)(6506007)(7696005)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 1/K907kV3vjPzFXtbvOsqxD9rN1xR2WSvIghhLAMw8Kxe8D3NrGr3o1obabn6Lsh70E9nsS2ehPjjMLqm5ZIvK9/vRN9iEMS9I+JE8ar8boHQk0TUmKws2YGuf3QNv/5+hTmb4oUkwjJhV7Sw0Y4ltDYNptPzn/HrNl01UVdWnYeLh1BWk+VKQk54adarz1h1gk38ngBhCttBMsau734F72aRe8YUfaoyiU3O8oHaRMVHk0/QF6iJdG9knZSMSdtnNSKbLy8tMGcUhx9OYsko9uA5WEM4Syfb5ZtHZ7Zmc0Qxw61WE27rZzFcH/y+DNKFUJEAT+SwPEvzKDbIZEvaN1zCtDeGHo1VN1RROWE1+D+GNFbMR6cIFo/CixVEt9YSUCDUyOMmffWxlmyZUbYKWAJhwxi0UCLr8aPVhrlPhhWnXL6kU/XhF1vY+rAzp6qwkh43NwUUYuNHGLTa1zix/QrvT0F0UG2aHayc2rDzsTcn6lYOPeZCYmld6hYfElINnq/PpcORkAUbBZYLtyjOoUKpyrQLd9RnIr2Av+Q1YzswLZikC21hfxA7aWK/Nme4rMoHUiY8GlknNOHSilglAqTQ2DucLHsp8tgjSe52NIalI6gUCl1KdZ9f4jU/lJHljFmhJcQXYg2gDYoipc8qg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3937.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f09f9022-e249-46f1-e0f5-08d83d36d4e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 14:08:18.1928 (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: DFkuWJcA4jNgeXx8mdfHynOBLJSSBarToW52KFkfKzYP72/aS5NVOtL40psCPxHNBKvHnkbaFv9/K6JfGB1EYo8iUTZMwSoe4llfqJV4y7mbWPBbKIVqloyiRyCkmNvN X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3441 Archived-At: Subject: Re: [tcpPrague] Queries about prague linux code 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, 10 Aug 2020 14:08:32 -0000 SGkgRGVlcGFrLA0KIA0KID4gMSkgVGhlcmUgd2FzIGEgbWVudGlvbiBpbiBQYWdlIDYgaGVyZQ0K ID4gKGh0dHBzOi8vd3d3LmJvYmJyaXNjb2UubmV0L3Byb2plY3RzL2xhdGVuY3kvdGNwLXByYWd1 ZS1uZXRkZXYweDEzLnBkZikNCiA+IHRoYXQgaWYgUHJhZ3VlIGVuY291bnRlcnMgYSBwYWNrZXQg bG9zcyB3aGlsZSBpbiBDV1Igc3RhdGUsIHNzdGhyZXNoIHdvdWxkDQogPiBiZSByZWR1Y2VkIGJ5 ICgyK2FscGhhKS80IGluc3RlYWQgb2YgdGhlIHVzdWFsIDUwJSByZWR1Y3Rpb24uIEhvd2V2ZXIg YXMNCiA+IGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBjdXJyZW50IGNvZGUgcmVkdWNlcyBpdCBi eSBoYWxmIGlycmVzcGVjdGl2ZSBvZg0KID4gd2hldGhlciBpdCdzIGluIENXUi4gSXMgdGhhdCBy aWdodD8NCg0KWWVzLiBUaGUgcGFwZXIgaW5kZWVkIGFkdm9jYXRlcyB0byBub3QgYmxpbmRseSBy ZWR1Y2UgYnkgNTAlIGJ1dCBhbHNvIGZhY3Rvcg0KaW4gaG93IG11Y2ggdGhlIGNvbm5lY3Rpb24g bWlnaHQgaGF2ZSBhbHJlYWR5IHJlZHVjZWQgKGkuZS4sIHRvIGF2b2lkIHRoZQ0KYXZhbGFuY2hl IGVmZmVjdCBhIGZ1bGwgUlRUIG9mIG1hcmtzIHdpdGggb25lIGRyb3AgYXQgdGhlIGVuZCB3b3Vs ZCBoYXZlKSwNCmJ1dCBzdGF5ZWQgYXMgYSAodmVyeSkgbG93IHByaW9yaXR5IGl0ZW0uIFdlIHdv dWxkIHdlbGNvbWUgb2YgY291cnNlIGFueQ0KcGF0Y2gvdGVzdC8uLi4gYXJvdW5kIHRoaXMgcG9p bnQuDQoNCiA+IDIpIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyB3aXRoIHRoZSBmbG93IG9mIGNvZGUg d2hlbiBSVFQgc2NhbGluZyBoZXVyaXN0aWMNCiA+IGlzIHBhcnRpY3VsYXJseSBzZXQgdG8gUlRU X0NPTlRST0xfQURESVRJVkUuDQogPiBJbiBwcmFndWVfYWlfYWNrX2luY3JlYXNlICgpLCB0aGUg ZnVuY3Rpb24gcnR0X3NjYWxpbmdfb3BzLQ0KID4gPmFpX2Fja19pbmNyZWFzZSgpIGlzIGNhbGxl ZCwgd2l0aCB0aGUgcGFyYW1ldGVyIHNydHRfdXMuIFRoaXMgaW4tdHVybg0KID4gY2FsbHMgcHJh Z3VlX3JhdGVfc2NhbGVkX2FpX2Fja19pbmNyZWFzZSgpIHdpdGggdGhlIHNhbWUgcGFyYW1ldGVy IHZhbHVlLg0KID4gTm93LCBzcnR0X3VzIGlzIGNvbXBhcmVkIHdpdGggdGhlIHJlc3VsdCBvZiBw cmFndWVfdGFyZ2V0X3J0dCgpLiBUaGlzDQogPiBmdW5jdGlvbiBtYXBzIHRvIHByYWd1ZV9keW5h bWljX3J0dF90YXJnZXQoKSwgd2hpY2ggcmV0dXJucyBjYS0+cnR0X3RhcmdldA0KID4gKyBzcnR0 X3VzLg0KID4gDQogPiBTbywgZG9lc24ndCB0aGlzIGxlYWQgdG8gYSBjb21wYXJpc29uIGJldHdl ZW4gc3J0dF91cyBhbmQgY2EtPnJ0dF90YXJnZXQgKw0KID4gc3J0dF91cywgd2hpY2ggaXMgcmVk dW5kYW50Pw0KDQpZZXMsIHRoaXMgaXMgYSBjb2RlLXJldXNlIGFydGlmYWN0LiBUaGUgY29tcGFy aXNvbiB5b3UgcG9pbnQgZW5hYmxlcyB0bw0Kc2NvcGUgdGhlIGN3bmQtc2NhbGluZyBjb2RlIHRv IG9ubHkgb3BlcmF0ZSBpbiBhIGNlcnRhaW4gUlRUIHJlZ2lvbiAoZS5nLiwgb25seQ0KYmUgYWN0 aXZlIGZvciB0aGUgc3ViLTEwbXMgUlRUIGZsb3dzIGFzIHRoYXQncyB3aGVyZSBtb3N0IGNvLWV4 aXN0ZW5jZQ0KcHJvYmxlbXMgYXJlIGxvY2F0ZWQpLiBTaW5jZSB0aGUgX0FERElUSVZFIGhldXJp c3RpYyBzY2FsZXMgdGhlIGN3bmQNCmlycmVzcGVjdGl2ZWx5IGlmIHRoZSBiYXNlIFJUVCwgdGhh dCBjaGVjayBpcyBpbmRlZWQgYWx3YXlzIGJ5cGFzc2VkLg0KDQoNCkJlc3QsDQpPbGl2aWVyDQoN Cg== From nobody Fri Aug 14 12:07:01 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 5A9963A11E0 for ; Fri, 14 Aug 2020 12:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cXsYEl08eTE3 for ; Fri, 14 Aug 2020 12:06:57 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF943A11E3 for ; Fri, 14 Aug 2020 12:06:56 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id t7so8416388otp.0 for ; Fri, 14 Aug 2020 12:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LRlEeGt6vdxaoNqa05QycXFUM7kh1wSqCR6jqRRjpNA=; b=h3ZeuqaQ11fDwsHobj8Yl2iX9KUCWCfLT6vbxLmjPEBCoRSPo63cwPGNZ3fTiKpWwI pqcWswJ+kcxE4Fw5umfwaCnShSEMvbaS4C2frCwKzVoMR6WeIYWfQoOJ+qIeFQ6rtD1b SIyWIJSX0UNiau5BKRoQDrbOxwJOitGofM9UTZS4fMT8tcNm73egG+ldrCBEA2DKxV7b tqaJNPPFBty5pLkKmbW6soUSQGCuNBVpVKpbCJhCRawa5o9Po4N2m1FfB9zYQO1zrYpw pxsdNI7qJFSituGaimwws8GHmhKTWi/3MUzc2F/7AZKOiOiMNU34BZYTd4R3Ca2DSbvh lPHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LRlEeGt6vdxaoNqa05QycXFUM7kh1wSqCR6jqRRjpNA=; b=RSpGIgq0NlXXVI5XFgeNWPEkZyFzQ0x0ep65NzlgGbrmePBLUGWyGvH7Cc3Xi0PBds TCWpPA+YzBfXaNTt9GDDh1rHE4L1gilQNyu1suNzyGGVoAuO6HjtyKEQf4TkWwuaUuxr 8Jpqlyi09sJYS+Qh3tQ+gDtmh4lwQdRgYToB3uPJi5Pf5zOs4BjJXG8Arwh1pNCMBxJw owVJV7UHXByfQdEjCs/gHZ8g85pxtEMJQuyA/VG6A5VlNYwvW+TrQbjLPXGTYpwlbSjA xH6Bxlm+i/J81UIyc3zg1r+diWZl7IvUAfW5A5Sl1yTjf5FJLP22mjsAJMpKd8AZBdYX zpXg== X-Gm-Message-State: AOAM5314bO1b9qKt0A2v4IrjToU3IHkFNJnA8Mc+oX6reFjuUhTpOkhr j72Th3QdJcRdgMEgCQSEuxmfuPSZtU0WpiCz+beimDELB/vi8A== X-Google-Smtp-Source: ABdhPJwHdwb20UzdJx7oBbQFzKOutqR/NnfaJnZ0Vu+2dKEPD96ETElfgsGa0DGPwJEYNhS+vhLwP/aiEpScEMxQbhk= X-Received: by 2002:a9d:4704:: with SMTP id a4mr2748374otf.349.1597432015856; Fri, 14 Aug 2020 12:06:55 -0700 (PDT) MIME-Version: 1.0 From: Deepak K Date: Sat, 15 Aug 2020 00:36:09 +0530 Message-ID: To: tcpprague@ietf.org Content-Type: multipart/alternative; boundary="000000000000dbae8005acdb1fbc" Archived-At: Subject: [tcpPrague] Prague Cwnd reduction in CWR state 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: Fri, 14 Aug 2020 19:06:59 -0000 --000000000000dbae8005acdb1fbc Content-Type: text/plain; charset="UTF-8" Hi everyone, I am currently trying to align TCP Prague in the ns-3 network simulator with that of Linux. In the process, I came across an interesting behaviour: if the sender is in a CWR state, the cWnd update would look something like cWnd = cWnd - cWnd * alpha / 2 --- (1) I noted that this is how DCTCP updates its cWnd in Linux. But in the case of current Linux Prague code, the value reduction = cWnd * alpha / 2 --- (2) is subtracted from the cwnd_cnt variable, which sort of acts as a cushion and reduces the cWnd over many RTTs (in prague_update_cwnd( ) ), instead of reducing it instantaneously. I would like to mention a noticeable difference resulting from the approach taken in (2). All the following simulations were carried out in ns-3. While reproducing the single-flow topology from Pete Heist's scenario ( https://github.com/heistp/sce-l4s-ect1#scenario-1-one-flow : a Prague sender, DualQ bottleneck and a Prague receiver), I decided to implement both approaches in ns-3 to see how they differ from each other. For lower bottleneck bandwidths (5mbps and 50mbps in the scenarios), I didn't observe much difference between (1) and (2), and the approach in (1) aligned with the cWnd graphs from Linux (which I obtained separately via namespaces). However, for the scenario with a higher bottleneck speed - 250mbps in particular, the difference between (1) and the Linux approach (2) was significant. With (1), the cWnd was reduced by a smaller value when compared to (2), in ns-3.This meant that (2) took more time to reach a stable value in Additive Increase compared to (1). I also observed that cWnd reduced to a much lower value in Linux (again, graphs obtained via namespaces) when compared with the ns-3 plots from (1). My guess would be that in (2), since cWnd is decreased gradually, the sender would not immediately relieve the queue of congestion, and hence would receive few more ECE marks leading to further reduction later on when compared to (1). I noted this behaviour for both higher (80ms) and lower (20ms) values of RTT, with a 250mbps bottleneck. Could you comment on the reason for choosing approach (2) in Linux instead of (1)? Thanks. --000000000000dbae8005acdb1fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

I am currently trying to a= lign TCP Prague in the ns-3 network simulator with that of Linux.
In the process, I came across an interesting behaviour: if the sender is i= n a CWR state, the cWnd update would look something like
cWnd =3D= cWnd - cWnd * alpha / 2=C2=A0 =C2=A0 =C2=A0--- (1)
I noted that = this is how DCTCP updates its cWnd in Linux.=C2=A0

But in the case of current Linux Prague code, the value
reductio= n =3D cWnd * alpha / 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--- (2)
is subtracted from the cwnd_cnt variable, which sort of acts as a cus= hion and reduces the cWnd over many RTTs (in prague_update_cwnd( ) ), inste= ad of reducing it instantaneously.

I would like to= mention a noticeable difference resulting from the approach taken in (2). = All the following simulations were carried out in ns-3.=C2=A0
While reproducing the single-flow topology from Pete Heist'= s scenario (https://github.com/heistp/sce-l4s-ect1#scenario-1-one-flow=C2= =A0:=C2=A0a Prague sender, DualQ bottleneck and a Prague receiver), I decid= ed to implement both approaches in ns-3 to see how they differ from each ot= her.

For lower bottleneck bandwidths (5mbps and 50= mbps in the scenarios), I didn't observe much difference between (1) an= d (2), and the approach in (1) aligned with the cWnd graphs from Linux (whi= ch I obtained separately via namespaces).

However,= for the scenario with a higher bottleneck speed - 250mbps in particular, t= he difference between (1) and the Linux approach (2) was significant.=C2=A0=
With (1), the cWnd was reduced by a smaller value when compared = to (2), in ns-3.This meant that (2) took more time to reach a stable value = in Additive Increase compared to (1). I also observed that cWnd reduced to = a much lower value in Linux (again, graphs obtained via namespaces) when co= mpared with the ns-3 plots from (1).

My guess woul= d be that in (2), since cWnd is decreased gradually, the sender would not i= mmediately relieve the queue of congestion, and hence would receive few mor= e ECE marks leading to further reduction later on when compared to (1).

I noted this behaviour for both higher (80ms) and low= er (20ms) values of RTT, with a 250mbps=C2=A0bottleneck.
Coul= d you comment on the reason for choosing approach (2) in Linux instead of (= 1)?

Thanks.
--000000000000dbae8005acdb1fbc-- From nobody Mon Aug 17 05:57:33 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 0723C3A1520 for ; Mon, 17 Aug 2020 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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] autolearn=ham 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 MmBETf8yzpot for ; Mon, 17 Aug 2020 05:57:30 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10136.outbound.protection.outlook.com [40.107.1.136]) (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 320893A151A for ; Mon, 17 Aug 2020 05:57:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ltzPnKJTFxsPfXKmdepMM7k9Ky80qu5cE4l/j3VkHFANg8XWGjm6jyGf0lFPVpnZXBM20eFr0aimD1oRsJQymftowqd2zwY7Qscr8dEWYSzgH7kx4jBc3kocsic3RxhOPVsg3qhRkqEDoUdihsta8riEFZ2cTIn5OixZgujaC8bjzZIoQ612QBfy/T7+vylGEziXZQYoaA9MVJpYgJ8usPq33rpp3vZu5jY5IcRkxXAEQ6OwQi3IloTCAfHHXKbZ4KrzFQ9tKb5XwNzP9KT4BrM2dXyAVLuIocboYNEeA59Tc7F/NDjIb4h6UpUzhf+zD3tnOhQznNCuHCkO5bK/TA== 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=Vpm/AeoJd/j9o2PjTpOO8S+q/qptKS/InYKayba2bY0=; b=Op7Rz/I3rJft+ZIEyMvEFrSv87sb2q0e2KQBptJfn1hw8xviOxpfLnjj3jHMUBKmSwN6TvGznpzlgFUECDJhweCZYEfXAVghyF6/ze6PvkSRtHyP1Qx0vlXWqlqCscLvdsBVUZuUAzxKd4UCewbCnTu6btSJvw7mR67OWY3K1Tp1PGw0NlTuSRsSCEN49+aGMOwIA5MANH00oK8+8czpMKDug3lOYQfkRRxWv9aBcOOcWdyvJSObXOa83/6vyTkqd8Qpw8dmTdik/70RTVaETrfZUFUWXzyUAgiFXowmm6MaUqBgrNyjYOOFFK8NUtGbBv2XR/hHkmShpZgK38nSug== 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=Vpm/AeoJd/j9o2PjTpOO8S+q/qptKS/InYKayba2bY0=; b=aFcQ/GKqJqSqlL++JjOMkwPyNbj6NS5DUjh5V/ALi6wb+InWeopD1v2JwklIeARMlc8gqj0p8wDP6+1L5+CMKJiRkDLOwboY32dRpklYHDq/nMZbOIFZkVjGCygVsCIfekCdupq4B2NcfOn8nWYCCBiqdVp5/z1VvH9eVymCB0o= Received: from AM0PR07MB3937.eurprd07.prod.outlook.com (2603:10a6:208:4c::20) by AM0PR07MB5491.eurprd07.prod.outlook.com (2603:10a6:208:10b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.15; Mon, 17 Aug 2020 12:57:26 +0000 Received: from AM0PR07MB3937.eurprd07.prod.outlook.com ([fe80::45a9:c1c4:f1ff:19d2]) by AM0PR07MB3937.eurprd07.prod.outlook.com ([fe80::45a9:c1c4:f1ff:19d2%7]) with mapi id 15.20.3305.021; Mon, 17 Aug 2020 12:57:26 +0000 From: "Tilmans, Olivier (Nokia - BE/Antwerp)" To: Deepak K , "tcpprague@ietf.org" Thread-Topic: [tcpPrague] Prague Cwnd reduction in CWR state Thread-Index: AQHWcm4bMCcW7NbDy0mfwP7zmL+e26k8ONyg Date: Mon, 17 Aug 2020 12:57:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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:a03f:636b:f600:586c:8730:5819:4b6c] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 63786096-e79d-487f-237e-08d842ad17a2 x-ms-traffictypediagnostic: AM0PR07MB5491: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Twpq650UwozLKi7Ixy0w88WRzqJos+ZWk0/PPhFt8mSogSR6ZYekMnG0jlXbM4NTOTA9GxYsUZrQSiE83KJWxxU6U6oluTq2iMaiB43WDWg7YbxrltBTkfPxXIELnAEpWCdCsRXCHzyBRWOww98zsbViRZHX5HO+F8D1GH6nDpzP2zINdccUo/EOmUfjyGeJjnIDw1pU5y7hgQWnk4PVOT7475Oq9M2t/cotx2rqceGKia2K4ArhSahTwO44ryBfKhUNUaoDUQHBHH9h36/e60TPRgY8Ny5lCFTOgc4gEhjlhmhLxLGRQstQM9H50zDnvi4j72xdCrtZOOEkem+31yBRyr8JE88fu3nywqpkBPfLz3uQxdjCmfno9pIlKhBhYc9IohdvoGJBqQa0yP8ylg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3937.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(66446008)(5660300002)(64756008)(66556008)(86362001)(66476007)(110136005)(66946007)(2906002)(8936002)(8676002)(76116006)(83380400001)(55016002)(52536014)(33656002)(71200400001)(7696005)(478600001)(9686003)(6506007)(316002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xLWixHYoOIurVytI3zU/P6ZDi+rJ/pbOlIYgFY+P5R5mFfr8v2O2DGsGgZ81BF9QxQBS9MU2GHvPbzB5417Kid2aw7KacF+BvQImNk2/UFTFkZlQPa/KA3l1i6QHqlgXzxDzt6U4hbJKcxstqw8dOEJvb8kJrfixwPe02FnQIIbPqB4EoCtuttk04lYhv10atQlq5j/Z2A073YHMYeIbRS7vZ/KfNp8T//fCEMszmPBxWL+YMisfzHgVOhikc8nl6HhpoeJvyMzOHEbDJeMDSwnElolAGN65C9I/ETaCRr1doJ5pNJ/yCA6EXdb6hJnK0XNyp8D2JjEfuDCjBJAB63XOgsU+8CgHQtlm7Af1gkL+b385GBj03W2XLmDvi90FXLnnD/fQEZj1I4O8yCEOC0QAjDGm8nUu12VYMs87MRQku7D8PaVWCAvGrMeOjK0rrwwmhT8jDPjctwaWWZP5cij+M8I70CrYZMyIUhxQGxk/zhZNEWs6kixoDFFUgO06tXblvtzUSxkPArynfR2A5bfV9+9EAFKl0eKyGvc95tqbPzv1srCoCMn4RkZXkEnzhpKEtm+hfOADfj3aNj5p4Y6q9H23EpYx/GpRpfThyyg+MYcmOCDRi6rrHCyDXtm/IIBQgVGRhTutKlSIosjXn7+QHTMa6FFF/4G4xs106Cs201O1EgtLOhUR5j8oQE0qE7zJwhLp3cwScxuMr9vq1g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3937.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63786096-e79d-487f-237e-08d842ad17a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 12:57:26.5352 (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: YLVKOs+tNXNTi+ItE4GS05V2f8lrF+Qp9uttqiP13W6S6cdBX2NTUTXt7lAy9U54KLjlypXQ25VVGBmGEzSTB4k6b+CEe26hxvCA/w3at2gGxJIx/zms5S98hddPtGqS X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5491 Archived-At: Subject: Re: [tcpPrague] Prague Cwnd reduction in CWR state 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, 17 Aug 2020 12:57:32 -0000 SGkgRGVlcGFrLA0KDQogPiBJbiB0aGUgcHJvY2VzcywgSSBjYW1lIGFjcm9zcyBhbiBpbnRlcmVz dGluZyBiZWhhdmlvdXI6IGlmIHRoZSBzZW5kZXIgaXMgaW4NCiA+IGEgQ1dSIHN0YXRlLCB0aGUg Y1duZCB1cGRhdGUgd291bGQgbG9vayBzb21ldGhpbmcgbGlrZQ0KID4gY1duZCA9IGNXbmQgLSBj V25kICogYWxwaGEgLyAyICAgICAtLS0gKDEpDQogPiBJIG5vdGVkIHRoYXQgdGhpcyBpcyBob3cg RENUQ1AgdXBkYXRlcyBpdHMgY1duZCBpbiBMaW51eC4NCg0KTm90IGV4YWN0bHkuIERDVENQIGRv ZXMgaW5kZWVkIHVwZGF0ZSBzc3RocmVzaCB0byB0aGF0IHZhbHVlLCBidXQgZG9lcw0Kbm90IHVw ZGF0ZSBjd25kIGltbWVkaWF0ZWx5LiBJbnN0ZWFkLCB0aGUgY3duZCByZWR1Y3Rpb24gaXMgYXBw bGllZA0KZ3JhZHVhbGx5IG92ZXIgdGhlIG5leHQgUlRUIHRocm91Z2ggUFJSLg0KDQogPiBCdXQg aW4gdGhlIGNhc2Ugb2YgY3VycmVudCBMaW51eCBQcmFndWUgY29kZSwgdGhlIHZhbHVlDQogPiBy ZWR1Y3Rpb24gPSBjV25kICogYWxwaGEgLyAyICAgICAgICAgICAtLS0gKDIpDQogPiBpcyBzdWJ0 cmFjdGVkIGZyb20gdGhlIGN3bmRfY250IHZhcmlhYmxlLCB3aGljaCBzb3J0IG9mIGFjdHMgYXMg YSBjdXNoaW9uDQogPiBhbmQgcmVkdWNlcyB0aGUgY1duZCBvdmVyIG1hbnkgUlRUcyAoaW4gcHJh Z3VlX3VwZGF0ZV9jd25kKCApICksIGluc3RlYWQgb2YNCiA+IHJlZHVjaW5nIGl0IGluc3RhbnRh bmVvdXNseS4NCg0KQXMgd2UgdHJhbnNpdGlvbmVkIFByYWd1ZSBhd2F5IGZyb20gdXNpbmcgdGhl IGNvbmdfYXZvaWQvc3N0aHJlc2ggaG9va3MgYW5kDQppbnN0ZWFkIHVzZSB0aGUgdW5pZmllZCBj b25nX2NvbnRyb2wgaG9vaywgd2UgbG9zdCB0aGUgaW1wbGVtZW50YXRpb24gb2YgUFJSDQphbmQg dGhlIGJlbmVmaXRzIGl0IGJyaW5ncyAobmFtZWx5OiBubyB0cmFuc21pc3Npb24gInNpbGVuY2Ui IGFmdGVyIGEgY3duZA0KcmVkdWN0aW9uIGR1ZSB0byBhIGRyb3AvbWFyayB0aGF0IGVmZmVjdGl2 ZWx5IGRpc2FibGVzIGZhc3QtcmVjb3ZlcnkvLi4uLA0Kc2VlIFJGQzY5MzcpLiBUaGlzIGN3bmRf Y250IGN1c2hpb24gaXMgdGhlcmUgYXMgYSBzdG9wLWdhcCBpbXBsZW1lbnRhdGlvbjsNCklkZWFs bHkgYSAnZnVsbCcgUFJSIHNob3VsZCByZXBsYWNlIGl0Lg0KDQogPiBJIHdvdWxkIGxpa2UgdG8g bWVudGlvbiBhIG5vdGljZWFibGUgZGlmZmVyZW5jZSByZXN1bHRpbmcgZnJvbSB0aGUgYXBwcm9h Y2gNCiA+IHRha2VuIGluICgyKS4gQWxsIHRoZSBmb2xsb3dpbmcgc2ltdWxhdGlvbnMgd2VyZSBj YXJyaWVkIG91dCBpbiBucy0zLg0KID4gDQogPiBXaGlsZSByZXByb2R1Y2luZyB0aGUgc2luZ2xl LWZsb3cgdG9wb2xvZ3kgZnJvbSBQZXRlIEhlaXN0J3Mgc2NlbmFyaW8NCiA+IChodHRwczovL2dp dGh1Yi5jb20vaGVpc3RwL3NjZS1sNHMtZWN0MSNzY2VuYXJpby0xLW9uZS1mbG93IDogYSBQcmFn dWUNCiA+IHNlbmRlciwgRHVhbFEgYm90dGxlbmVjayBhbmQgYSBQcmFndWUgcmVjZWl2ZXIpLCBJ IGRlY2lkZWQgdG8gaW1wbGVtZW50DQogPiBib3RoIGFwcHJvYWNoZXMgaW4gbnMtMyB0byBzZWUg aG93IHRoZXkgZGlmZmVyIGZyb20gZWFjaCBvdGhlci4NCiA+IA0KID4gRm9yIGxvd2VyIGJvdHRs ZW5lY2sgYmFuZHdpZHRocyAoNW1icHMgYW5kIDUwbWJwcyBpbiB0aGUgc2NlbmFyaW9zKSwgSQ0K ID4gZGlkbid0IG9ic2VydmUgbXVjaCBkaWZmZXJlbmNlIGJldHdlZW4gKDEpIGFuZCAoMiksIGFu ZCB0aGUgYXBwcm9hY2ggaW4gKDEpDQogPiBhbGlnbmVkIHdpdGggdGhlIGNXbmQgZ3JhcGhzIGZy b20gTGludXggKHdoaWNoIEkgb2J0YWluZWQgc2VwYXJhdGVseSB2aWENCiA+IG5hbWVzcGFjZXMp Lg0KID4gDQogPiBIb3dldmVyLCBmb3IgdGhlIHNjZW5hcmlvIHdpdGggYSBoaWdoZXIgYm90dGxl bmVjayBzcGVlZCAtIDI1MG1icHMgaW4NCiA+IHBhcnRpY3VsYXIsIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gKDEpIGFuZCB0aGUgTGludXggYXBwcm9hY2ggKDIpIHdhcw0KID4gc2lnbmlmaWNhbnQu DQoNCldoZW4geW91IGNvbXBhcmUgIigxKSBhbmQgdGhlIExpbnV4IGFwcHJvYWNoICgyKSIsIHlv dSBhcmUgcmVmZXJyaW5nIHRvDQpuczMncy1EQ1RDUCBtb2RlbCBhcyAoMSkgYW5kIHRoZSBMaW51 eCBwcmFndWUgY29kZSBhcyAoMikgcmlnaHQ/DQpEb2VzIG5zMyBpbXBsZW1lbnQgUFJSPyBZb3Ug Y291bGQgZWFzaWx5IHNwb3QgdGhpcyBvbiBhIGN3bmQgZ3JhcGggYnkgY2hlY2tpbmcNCndoZXRo ZXIgdGhlIHJlZHVjdGlvbnMgYXJlIHNtb290aCBvciBub3QuDQoNCiA+IFdpdGggKDEpLCB0aGUg Y1duZCB3YXMgcmVkdWNlZCBieSBhIHNtYWxsZXIgdmFsdWUgd2hlbiBjb21wYXJlZCB0byAoMiks IGluDQogPiBucy0zLlRoaXMgbWVhbnQgdGhhdCAoMikgdG9vayBtb3JlIHRpbWUgdG8gcmVhY2gg YSBzdGFibGUgdmFsdWUgaW4gQWRkaXRpdmUNCiA+IEluY3JlYXNlIGNvbXBhcmVkIHRvICgxKS4g SSBhbHNvIG9ic2VydmVkIHRoYXQgY1duZCByZWR1Y2VkIHRvIGEgbXVjaCBsb3dlcg0KID4gdmFs dWUgaW4gTGludXggKGFnYWluLCBncmFwaHMgb2J0YWluZWQgdmlhIG5hbWVzcGFjZXMpIHdoZW4g Y29tcGFyZWQgd2l0aA0KID4gdGhlIG5zLTMgcGxvdHMgZnJvbSAoMSkuDQoNCkkgYW0gbm90IHN1 cmUgSSB1bmRlcnN0YW5kIGZ1bGx5IHRoYXQgcGFyYWdyYXBoLiBBcmUgYWxsIHRoZSByZWR1Y3Rp b25zIGluDQooMSkgc21hbGxlciB0aGFuIGluICgyKT8gWW91IG1lbnRpb24gcmVhY2hpbmcgYSBz dGFibGUgdmFsdWUsIHNvIEkgYXNzdW1lDQp5b3UncmUgYWxzbyBzcGVha2luZyBvZiB0aGUgU1Mt PkFJIHRyYW5zaXRpb24/DQoNCiA+IE15IGd1ZXNzIHdvdWxkIGJlIHRoYXQgaW4gKDIpLCBzaW5j ZSBjV25kIGlzIGRlY3JlYXNlZCBncmFkdWFsbHksIHRoZQ0KID4gc2VuZGVyIHdvdWxkIG5vdCBp bW1lZGlhdGVseSByZWxpZXZlIHRoZSBxdWV1ZSBvZiBjb25nZXN0aW9uLCBhbmQgaGVuY2UNCiA+ IHdvdWxkIHJlY2VpdmUgZmV3IG1vcmUgRUNFIG1hcmtzIGxlYWRpbmcgdG8gZnVydGhlciByZWR1 Y3Rpb24gbGF0ZXIgb24gd2hlbg0KID4gY29tcGFyZWQgdG8gKDEpLg0KDQpBc3N1bWluZyB5b3Vy IG5zMyBtb2RlbCBpbiAoMSkgZG9lcyBub3QgaGF2ZSBQUlIsIGl0IHdvdWxkIGJlIGludGVyZXN0 aW5nIHRvDQpjb21wYXJlIHRoZXJlIHRoZSBiZWhhdmlvciBvZiBEQ1RDUCB3aXRoIFBSUiAoZWl0 aGVyIGRpcmVjdGx5IGluIExpbnV4IG9yDQpleHRlbmRpbmcgbnMzKSB0byAoMikuDQogDQpJdCBp cyB0cnVlIHRoYXQgc21vb3RoaW5nIHRoZSBjd25kIGRlY3JlYXNlIG92ZXIgKHBhcnQgb2YpIGEg UlRUIHdpbGwNCmtlZXAgc29tZSBwcmVzc3VyZSBpbiB0aGUgcXVldWUgKGFzIG9wcG9zZWQgdG8g YSBmdWxsIHF1aWV0IHBlcmlvZCB3aGVyZSB0aGUNCnF1ZXVlIGZ1bGx5IGRyYWlucyBpbiB0aGUg Y2FzZSBvZiBhIDUwJSBoYWx2aW5nKS4gDQoNCiA+IA0KID4gSSBub3RlZCB0aGlzIGJlaGF2aW91 ciBmb3IgYm90aCBoaWdoZXIgKDgwbXMpIGFuZCBsb3dlciAoMjBtcykgdmFsdWVzIG9mDQogPiBS VFQsIHdpdGggYSAyNTBtYnBzIGJvdHRsZW5lY2suDQogPiANCiA+IENvdWxkIHlvdSBjb21tZW50 IG9uIHRoZSByZWFzb24gZm9yIGNob29zaW5nIGFwcHJvYWNoICgyKSBpbiBMaW51eCBpbnN0ZWFk DQogPiBvZiAoMSk/DQoNCk9yaWdpbmFsbHksIHdlIGhhZCB0byBhZGQgdGhpcyBpbiB0byByZS1l bmFibGUgZmFzdC1yZWNvdmVyeSB3aGVuIGZhY2luZyBkcm9wcy4NCkl0IGlzIGluZGVlZCB0cnVl IHRoYXQgdGhpcyBoYXMgYW4gZWZmZWN0IGluIHRoZSBFQ04tdHJpZ2dlcmVkIHJlZHVjdGlvbnMu DQoNClRoaXMgd291bGQgcHJvYmFibHkgd2FycmFudCBhbiBoeWJyaWQgYXBwcm9hY2gsIHVzaW5n IGEgUFJSLWluc3BpcmVkIHNtb290aA0KcmVkdWN0aW9uIGluIGNhc2Ugb2YgbG9zc2VzLCBhbmQg YW4gaW5zdGFudCByZWR1Y3Rpb24gZm9yIGN3bmQtdHJpZ2dlcmVkDQpyZWR1Y3Rpb24uDQoNClRo ZSBjb2RlIGlzIG9wZW4tc291cmNlLCBmZWVsIGZyZWUgdG8gZXhwZXJpbWVudCB3aXRoIHN1Y2gg YSBjaGFuZ2UuIFdlJ2QgYmUNCmhhcHB5IHRvIG1lcmdlIHBhdGNoZXMgaWYgeW91IHNob3cgZXhw ZXJpbWVudHMgc3VwcG9ydGluZyB0aGUgYmVuZWZpdHMgb2Ygc3VjaA0KY2hhbmdlcy4NCg0KDQpC ZXN0LA0KT2xpdmllcg0KDQogPiANCiA+IA0KID4gVGhhbmtzLg0K From nobody Tue Aug 18 00:57:04 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 092963A043E for ; Tue, 18 Aug 2020 00:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TzGFnpwxHlPA for ; Tue, 18 Aug 2020 00:57:00 -0700 (PDT) Received: from mx2.mail.elte.hu (mx2.mail.elte.hu [157.181.151.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9EB3A043A for ; Tue, 18 Aug 2020 00:56:59 -0700 (PDT) Received: from mailbox1.caesar.elte.hu ([157.181.151.157]) by mx2.mail.elte.hu with esmtp (Exim) id 1k7wUJ-0001ug-Ml from for ; Tue, 18 Aug 2020 09:56:57 +0200 Received: (Authenticated sender: lakis) by mailbox1.caesar.elte.hu with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1k7wTz-000853-4y for tcpprague@ietf.org; Tue, 18 Aug 2020 09:56:35 +0200 To: tcpprague@ietf.org From: =?UTF-8?Q?S=c3=a1ndor_Laki?= Message-ID: <24010457-65f3-edf0-4949-3df19962ee45@elte.hu> Date: Tue, 18 Aug 2020 09:56:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Antivirus: Avast (VPS 200817-8, 2020.08.17), Outbound message X-Antivirus-Status: Clean X-ELTE-SpamScore: -4.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 3.0 X-ELTE-SpamCheck-Details: score=-4.1 required=5.0 tests=ALL_TRUSTED, BAYES_00, L_AUTH autolearn=no autolearn_force=no SpamAssassin version=3.4.2 -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -3.0 L_AUTH Caesar auth -0.1 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Archived-At: Subject: [tcpPrague] An L4S AQM proposal at IRTF/ACM ANRW 2020 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: Tue, 18 Aug 2020 07:57:03 -0000 Dear All, we presented an alternative L4S AQM proposal at ANRW 2020 few weeks ago. In this study, we assume that different CCs (even scalable ones) require different congestion signal intensities, and thus applying the same ECN-marking  probability leads to significant unfairness in these cases. E.g., BBRv2 also implements a DCTCP-like scalable mechanism, but it is more "aggressive" than DCTCP (using default settings). Another problem we realized is that BBR's model-based CC could be misled by the AQM - also leading to flow unfairness. As a conclusion, this heterogeneity can only be handled by additional mechanisms like FQ or additional packet marking. Our proposal marks each packet of a flow with a value expressing the contribution of the packet in the total throughput of the flow. The AQM maintains simple value thresholds, leading to different ECN-marking ratios of the different flows without flow-states or per-flow queues. The paper and the talk is available at http://ppv.elte.hu/cc-independent-l4s/ Cheers, Sandor -- Sándor Laki, PhD Assistant professor Department of Information Systems Eötvös Loránd University Pázmány Péter stny. 1/C H-1117, Budapest, Hungary Room 2.506 Web: http://lakis.web.elte.hu Phone: +36 1 372 2869 / 8477 Cell: +36 70 374 2646 -- Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta. https://www.avast.com/antivirus