Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S

<Ruediger.Geib@telekom.de> Mon, 05 August 2019 09:36 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E51200A1; Mon, 5 Aug 2019 02:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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=telekom.de
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 b-6DHvHFnFqJ; Mon, 5 Aug 2019 02:36:15 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 16984120077; Mon, 5 Aug 2019 02:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564997773; x=1596533773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l/4mNRY0uV54zDSWa3jtWjkQX8wWqLKLHRjKKRp2+Zo=; b=ANwdeR/5+U62zd1zeEfHy4ycHWjKLyQvOywoyo1G1IrYyuboOUzx0qny GQFgYGfl5wiCpUEpIGb2A0BJ9TXxDvqyrS4U3eXQcOaXKQcRZXa8pgRjK BlmSSKNsNiuteizRE3OxdImgMEqxYYkyOJ+fDsIH9yF9MM4K1jnfVqfK1 rFFtKUx4EnJSqdVh6pV1bj8wtR5NTnthTZnpD/oKyRlqCoTjBD+U3ay2s UJTb/DzJpN/pUm2nHlGHS3kozGzHhmGNo9qF4/bwnuPd6IQqjpMkfmd6z WRieN2UavzRgGA1IXfGkZcx5iT4o29pKzhXN0z7AnQmEssQvFzEnB44X6 A==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 11:36:10 +0200
X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473241958"
X-MGA-submission: MDHu/OrjxSTIOQ7vYWxJVNNCuGIam3y9Pe11F1xzpBSI0KTTWdl8eUVQYkaKHlfxSS9PYj1n8/MqhndJHm+/gdEjBoDBpF5q8j/upl8WFAe8IWg2LIHc2ekIeUhQh1zBFTQYSscQlWsDFJm8oWwbIziLQLxziF7pFGwLxzZhPAeGSw==
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: Ruediger.Geib@telekom.de
To: chromatix99@gmail.com
CC: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org
Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S
Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTwgAAbvwCABKfngA==
Date: Mon, 05 Aug 2019 09:35:48 +0000
Message-ID: <LEXPR01MB046306842E5AB407A7BFC6619CDA0@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE>
References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <E54BA49C-0790-48B4-82BB-4C0F3FE3FB20@gmail.com> <FRXPR01MB0710085AE4AEFA896819AFA69CD90@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE> <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: <LEXPR01MB020525BBC715C6457D2B81549CDA0@LEXPR01MB0205.DEUPRD01.PROD.OUTLOOK.DE>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XwBoPg_SZ12PHAgA-nfikmyH_Ac>
Subject: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 09:36:18 -0000

Jonathan Morton marked [JM] below, Ruediger Geib [RG].

> On 2 Aug, 2019, at 9:29 am, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:
> 
> Hi Jonathan,
> 
> could you provide a real world example of links which are consecutively narrower than sender access links?
> 
> I could figure out a small campus network which has a bottleneck at the Internet access and a second one connecting the terminal equipment. But in a small campus network, the individual terminal could very well have a higher LAN access bandwidth, than the campus - Internet connection (and then there's only one bottleneck again).
> 
> There may be a tradeoff between simplicity and general applicability. Awareness of that tradeoff is important. To me, simplicity is the design aim. 

[JM] A progressive narrowing of effective link capacity is very common in consumer Internet access.  Theoretically you can set up a chain of almost unlimited length of consecutively narrowing bottlenecks, such that a line-rate burst injected at the wide end will experience queuing at every intermediate node.  In practice you can expect typically three or more potentially narrowing points:

[RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , first two sentences. That's a sound starting point, and I don't think much has changed since 2005. 

[RG] About the bursts to expect, it's probably worth noting that today's most popular application generating traffic bursts is watching video clips streamed over the Internet. Viewers dislike the movies to stall. My impression is, all major CDNs are aware of that and try their best to avoid this situation. 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 should be no bursts. Still I miss the consecutively narrowing bottlenecks with queues being built at each instance with a likelihood justifying major engineering and deployment efforts. Any solution for Best Effort service which is TCP friendly and support scommunication expecting no congestion at the same time should be easy to deploy and come with obvious benefits. 

[RG] I found Sebastian's response sound. I think, there are people interested in avoiding congestion at their access.

[RG] I'd like to repeat again what's important to me: no corner case engineering. Is there something to be added to Sebastian's scenario?