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

Greg White <g.white@CableLabs.com> Mon, 02 November 2020 05:58 UTC

Return-Path: <g.white@CableLabs.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 997E43A0DBF; Sun, 1 Nov 2020 21:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=cablelabs.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 LU3CXyETOtAo; Sun, 1 Nov 2020 21:58:16 -0800 (PST)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690119.outbound.protection.outlook.com [40.107.69.119]) (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 982393A0EA1; Sun, 1 Nov 2020 21:58:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T6odPAaz7IKg6u78tDOSxFYTs1mto8hGX0M/uHh1cYkKS5BInmyp0U9v+zGcJ+R/KVkVRGlyN9hg3jV7quYdD6aOhHsXBbDAwGKjIdzDL8G2aYVvjUGOEVW8huBaISqDmU4kK5OAwYLrwa5YmzCATnwNBNvQmeK66KIEOoECWT1fiUnaORk+NXJXkk0ghKx4UwFq2+3WugtxHEukmNqWGU9c7OKkmPLRJjfpwWLkZyNblmWg2dVrKdVUY16M2fLErbdxtoSFd3Nb7tDt5LglR+WV54vxYO2gA4FDLmXcXm2DvFgXzsCq8HJNehiSmdkLjZq7TxeaP87Z7bfHFYKLsA==
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=ybMrz8xsxQ8n6e+CflRofkVzD/6gzXtyKpyTrdEpJos=; b=SGjEIuRrgFPeN3SrGBhTdXaDIgOQc4e+A8s4Nxinl4uoQ10qA5Xg9l1yR76ZCAiMmtLlXxgLrKvNi7BzYCkdfegcfLbR3P3olEyN1UEzzf+Kzeq/M8himvwAB7Ia2d+pF//jsiqs8VDo0kqhpTxJt+/KmfjBOTwcjXgJMITrbTtuiHGk4Xiyp0BIegZ+61pU/SfhuraS8wFQaB0xr+FZZMVpngFDAziof8FG0MHz/T+IpZlmgNWkBaINcE9DHnxACfJTF9XjVeCEkRVP1tLrgCAQWEh4jSV+qg0LNWNjeoZB/hn/9/kaVHUHZ6K+Z4nM8LOWNp5xPDeeF9jSJ03G6Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ybMrz8xsxQ8n6e+CflRofkVzD/6gzXtyKpyTrdEpJos=; b=EIU8osQwjx03p9jXYtgisVERMZ7APJI01fU32hOoO6aXFuvgJ1Zan/xSBBy16ed44mgGVMYztRkZsWQOuftZYNR3kw9oaPJqkWawwBYD/4Xgl1lEQNMeY38ldiNlgEwqO5gjdZM83sFaw3/Ke7pnhhQS8m70mWV26gqIJEcdccsYQXAhQTWV7K4YEFQnWAjegBXHQ4gAQqp05nLVRQGVX0bK3L0/5huZyPDxqBcOojpJPBIo5z3cxQyZdQMv7M9k8M5EXCwGW1ALoSXgPun/0wtyi1bpc7UOaHjc2e9vx4gixC5j7OwTfe5d6YSRSdOGkn8PQFdjinKLjHURJqI0Og==
Received: from CY4PR0601MB3713.namprd06.prod.outlook.com (2603:10b6:910:92::10) by CY4PR06MB2375.namprd06.prod.outlook.com (2603:10b6:903:15::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.28; Mon, 2 Nov 2020 05:58:01 +0000
Received: from CY4PR0601MB3713.namprd06.prod.outlook.com ([fe80::e03a:dba6:a8d0:17e0]) by CY4PR0601MB3713.namprd06.prod.outlook.com ([fe80::e03a:dba6:a8d0:17e0%7]) with mapi id 15.20.3499.029; Mon, 2 Nov 2020 05:58:01 +0000
From: Greg White <g.white@CableLabs.com>
To: Christian Huitema <huitema@huitema.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Jonathan Morton <chromatix99@gmail.com>
CC: iccrg IRTF list <iccrg@irtf.org>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>
Thread-Topic: [tsvwg] [tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
Thread-Index: AQHWsKqTEvlUwocdKECuNOe/y5VAQqmz9+eA///rqAA=
Date: Mon, 2 Nov 2020 05:58:00 +0000
Message-ID: <35DF946B-06F0-44DD-A220-40D74777385D@cablelabs.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>
In-Reply-To: <fc6f56f1-add4-fdc0-4718-012ee10102bf@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20100402
authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=CableLabs.com;
x-originating-ip: [98.245.82.7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a083fd2f-bbcc-45df-674f-08d87ef44191
x-ms-traffictypediagnostic: CY4PR06MB2375:
x-microsoft-antispam-prvs: <CY4PR06MB23752529D50ABFC4D893C451EE100@CY4PR06MB2375.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Sl2ttzuqgceSrTnuq3zbYSiykOlf3uPEZj5EJOPhVAccNPI4onwgIexbBy/8867lNJ75f0XUt/Xu8k0s7R6MDpJziU/L5/kkksI7ZN78EBHfnpzFNBMrRYCsvqWHW98tAToedeBzZJZkASR8gq+TAbYR8W2+S2ZCu8Vfp4t6ZbUkTCGWgv5L1CabAYIlZhxs91R2pLZXHn2SrZ+ck62ZOaM8vARDm1pfIWIKmvrm0T4AX7PkF5blvZd+0oVI7uKufflDSbF+H0KI/bXalZU/S1Vv3gTgfbKQro4d3kGernbj19IzopnDO/9n4zNvCiDE3lAKqOSjhE71BOi2EN62iwrZyIVGkxxKO8VxKkDCxYF1lun8Et24/XPhK+uS6PDYBBlvexIy+AvLWWIYpNUWoOR31egh2W3ExInhyrVv565gtjGyS6jKw+C6cb6LWKygWvOfokE0oeOxMy4GaWEdxA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3713.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(136003)(366004)(39830400003)(26005)(6486002)(186003)(53546011)(478600001)(71200400001)(83380400001)(6512007)(2906002)(66446008)(64756008)(66556008)(66476007)(5660300002)(6506007)(66946007)(2616005)(166002)(76116006)(54906003)(966005)(8936002)(316002)(33656002)(110136005)(86362001)(36756003)(8676002)(4326008)(85282002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: UAgNwlVr1sJ9KLALO271/uPB39kklH4Wtz50s8O/zqki6rCbX4MNnE30Q/JZuthDvZJdLmSSr+Yj+iWYQUuKUr3TQFmisDiDaK8gMFO2odnH5iSL+Q2gkOwEX7iHT6rwxFpwEbEMmbKh5PkjQXebMYSH1nn3YLNW9CBMbC/dlUuTyvkuZruhpri5OPx5Fom41rzn7dhAtWfF/lHJ3bBB1wWDKrI3X4XFCJGr35XXJXZAm6tTgN/QpmiQacokZCinNSiWNKVUI3GE6P9UAe325TYBV02MyLCc0XsKHDnl2cGtDBF5yuzqbnLdPuVuQXwc1FQQlAVIzRJf5tqhFePGjLxefzp630nKXswssWe5IqGua1ldBIRHOneVeBUmBpZHAnMoKTkHm4M6QKy/YPK5Ppjq/BmMwuJCUOsJvsOiRZLNiV4fPwTeyQh2TGT+IS/SrNXCz7RO1Wj8NODmV51ZHInrl22jK9O/WnXGCVBRAvKpLGaf4diTzk8I0QH0Y7PLw+PFi60RTgCe+HDyL3hT4DntflxH7d2nmzuruSanDPAySSG4XeMFE5eY1COeaN0KqjYIF2GgZ435KklC7Pk0/TiY0DDoFx4EXkvqphuhtRz1FPOCg5vARJaCqPVq6MX+BhOZuhUd0Yo/1rGmIr9v9g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_35DF946B06F044DDA22040D74777385Dcablelabscom_"
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3713.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a083fd2f-bbcc-45df-674f-08d87ef44191
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 05:58:00.8784 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: o0DRITjiQJhYsVaWZ+iZU+Upos0GdbmCGT6zNnMzyMZM2koLeSUHkOOnzbKmTkuSFa2FZrv25LhM22prQsHEzA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2375
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/2Rq3C71ovTRCWFRWB26YhQp61fQ>
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 05:58:19 -0000

On 11/1/2020 3:55 PM, Christian Huitema wrote:
On 11/1/2020 1:53 PM, De Schepper, Koen (Nokia - BE/Antwerp) wrote:

>>By the way, I do think that L4S makes too many hypotheses about the CC. I wish the AQM was based on intrinsic properties, such as "this flow is using more than its fair share of bandwidth"

This last quote is exactly what the L4S marking is intended to do: the smoothed marking probability over a longer time interval (about 10 RTTs) indicates the fair target rate. Assuming we agree on 15ms being the reference RTT, then the average rate can be r=2/(p*0.015)=133/p packets per second. So you can evaluate yourself if you use more or less than the fair share. How you respond to this knowledge is up to your CC.

I think that part of the complexity in L4S AQM comes from trying to achieve fair sharing of resource without actually implementing fair queuing. You end up expecting that implementations apply a formula and derive their packet sending rate from a smoothed average of the packet marking rate. It may work well in controlled environments, but I am afraid that very few implementations are ever going to do that in practice.

Congestion Control algorithms are much more likely to treat packet losses, markings, or delay increases as signals that they are sending too fast, while considering their absence or lower frequency as signal that they might be able to send faster. Implementations also are likely to take into account the recent history, for example monitoring the min RTT (LEDBAT, BBR), or monitoring the recent available bandwidth (BBR). They also typically filter signals, e.g., consider only one packet loss or ECN mark per RTT (New Reno, Cubic, etc.). This is expected, because we do see packet losses arriving in batches, and can reasonably expect ECN marks to have the same behavior. But implementations are inherently selfish, do not really trust the signals from the network, and are very unlikely to end up applying the formula that you suggest.

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.

[GW] But, this always works out to 2 marks per RTT or 2 marks per 15ms (whichever is slower), so in that sense it doesn’t depend on data rate at all.  The sender slows down if it sees more frequent marks than this, accelerates if it sees fewer marks than this, and stays put if it sees marking at this rate.

If you give up the formula, you could end up with a significantly simpler event based congestion control, in which applications slow down if they see too many CE marks, accelerate if they only see a very low marking rate, and stay put if they see an infrequent marking rate. I can see applications doing that, resulting in a fairly stable network and low delays. Of course, you will have to do some form of fair share enforcement to catch violators, but I am sure you can come up with something.

-- Christian Huitema







_______________________________________________

tcpPrague mailing list

tcpPrague@ietf.org<mailto:tcpPrague@ietf.org>

https://www.ietf.org/mailman/listinfo/tcpprague