From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CFDDE3CB39 for ; Mon, 5 Aug 2019 05:36:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564997770; x=1596533770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l/4mNRY0uV54zDSWa3jtWjkQX8wWqLKLHRjKKRp2+Zo=; b=fWwe0w2iqi5eVwvPWCgJp/GYwC0sC4XVEqsFy86RMrZrlgw0qNqsK3LF 2mn2T0HJAbHOLWNPDlfUALfpDoJrU1w6VKzrQ9KAtd0wC+ohynnXR9Gzv nj8wBj1L4q5jqMkp0Qy0oMBRfATjR+PmfvTE6JP0LBY9mAu4N0vWh0TjM AY/awd04rQGSELg14NEjFMjpxLCCNOn2OrlSJBhB7tkLGfnzUeOJjXVdE ump4sZUAa3s/v9WGF4S91Pke2RwFYQYhrgXKnf8bAGz0q7IA+LDM8kz3T LuXyo88F0pLpQlsfkjd6Lg1S0jRcVrUVd675yTk/s73ES62Bs4CfbtynS Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 11:36:09 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473241958" X-MGA-submission: =?us-ascii?q?MDHu/OrjxSTIOQ7vYWxJVNNCuGIam3y9Pe11F1?= =?us-ascii?q?xzpBSI0KTTWdl8eUVQYkaKHlfxSS9PYj1n8/MqhndJHm+/gdEjBoDBpF?= =?us-ascii?q?5q8j/upl8WFAe8IWg2LIHc2ekIeUhQh1zBFTQYSscQlWsDFJm8oWwbIz?= =?us-ascii?q?iLQLxziF7pFGwLxzZhPAeGSw=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 11:35:59 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 11:35:49 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 11:35:49 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.19) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 11:35:49 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0205.DEUPRD01.PROD.OUTLOOK.DE (10.158.164.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 09:35:48 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 09:35:48 +0000 From: To: CC: , , Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTwgAAbvwCABKfngA== Date: Mon, 5 Aug 2019 09:35:48 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> In-Reply-To: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 177602fa-43b6-4d01-0e07-08d719884c5b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB0205; x-ms-traffictypediagnostic: LEXPR01MB0205: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(136003)(39850400004)(189003)(199004)(6116002)(3846002)(6306002)(256004)(2906002)(71200400001)(45776006)(81166006)(81156014)(14444005)(64756008)(76116006)(66446008)(66476007)(66946007)(66556008)(71190400001)(8676002)(8936002)(14454004)(966005)(76176011)(53936002)(66574012)(52396003)(7696005)(53546011)(102836004)(508600001)(476003)(66066001)(305945005)(7736002)(11346002)(446003)(9686003)(486006)(86362001)(5660300002)(6916009)(68736007)(186003)(4326008)(1411001)(26005)(54906003)(55016002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0205; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /dQaiOKs/xhlzbl2AlncrX01e+7FOFm+W4rbrBjAG6PlRbgdYcyuPTWoWIOjUr2i2C4vqorHFaSeMq3z3hgqq0/TmvhWu7+kPpaxMXJYO3DGVXZp4HylxoKrgyqO119v4fA5lCnmx9rzRYynZ+maNM5S66HU3V1z2m/3uGCBE0EWrH3TRQdD/fFqJaPwnvtLQLHxK73CvClcNseFjYtj1PnSozUuc545TITe47XR17mR7C0Zx5mvBRE58NyvKmGQBdSB6jrEZhnsdplT1fM9nci739Be11P+RZFVz+gxOLWfQ+58IIq3a53ofNJ5efJoC+I9X8VkbornAzANTKkGvBy8My2w+T2Edbad4htdl4Ux1138gVFX1h+laDzzXxO1GTo3wLOA/dAzXjbqaV5X0q5CDB4oKilqUWHTZx4xISk= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 177602fa-43b6-4d01-0e07-08d719884c5b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 09:35:48.3067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0205 X-OriginatorOrg: telekom.de Subject: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 09:36:14 -0000 Jonathan Morton marked [JM] below, Ruediger Geib [RG]. > On 2 Aug, 2019, at 9:29 am, wrote: >=20 > Hi Jonathan, >=20 > could you provide a real world example of links which are consecutively n= arrower than sender access links? >=20 > I could figure out a small campus network which has a bottleneck at the I= nternet access and a second one connecting the terminal equipment. But in a= small campus network, the individual terminal could very well have a highe= r LAN access bandwidth, than the campus - Internet connection (and then the= re's only one bottleneck again). >=20 > There may be a tradeoff between simplicity and general applicability. Awa= reness of that tradeoff is important. To me, simplicity is the design aim.= =20 [JM] A progressive narrowing of effective link capacity is very common in c= onsumer Internet access. Theoretically you can set up a chain of almost un= limited length of consecutively narrowing bottlenecks, such that a line-rat= e burst injected at the wide end will experience queuing at every intermedi= ate node. In practice you can expect typically three or more potentially n= arrowing points: [RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , firs= t two sentences. That's a sound starting point, and I don't think much has = changed since 2005.=20 [RG] About the bursts to expect, it's probably worth noting that today's mo= st popular application generating traffic bursts is watching video clips st= reamed over the Internet. Viewers dislike the movies to stall. My impressio= n is, all major CDNs are aware of that and try their best to avoid this sit= uation. In particular, I don't expect streaming bursts to overwhelm access = link shaper buffers by design. And that, I think, limits burst sizes of the= majority of traffic. [RG] Other people use their equipment to communicate and play games (that's= what I see when I use commuters). Unless gaming pictures are rendered on a= server or live pictures of communicating persons are streamed, there shoul= d be no bursts. Still I miss the consecutively narrowing bottlenecks with q= ueues being built at each instance with a likelihood justifying major engin= eering and deployment efforts. Any solution for Best Effort service which i= s TCP friendly and support scommunication expecting no congestion at the sa= me time should be easy to deploy and come with obvious benefits.=20 [RG] I found Sebastian's response sound. I think, there are people interest= ed in avoiding congestion at their access. [RG] I'd like to repeat again what's important to me: no corner case engine= ering. Is there something to be added to Sebastian's scenario? =20