From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 371733CB37 for ; Mon, 5 Aug 2019 08:16:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1565007413; x=1596543413; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1p6NBs9VlTWdj9etn3VEV2k3YHMRtK/2N+TK3g6b3gY=; b=6sqS2ZiIGn8HvwYvHdjEzf/B1gp1iLv9/nvlJuTYGtqzVL+iEPi767je SOsB5LIPFaze+ptYuWHydpkgBOAzmUNSETD+rnctuaZZgyqSjC8XAOEMy j4s6PcUfMWt5tja3OkuLXlkAEtY0efz9CI5gcfRnzbZCZt1qXumAx4+3U 3UQmXa0s6ig4Ratd1CAzUJFiWU+tjT8wrphq6UYiLzLHhioAwpoeoR7wN el91sxdqvw9sUuY0VZWNxdnVQV9NyMCaA5EoaYpddt+i5jHtKSE5+5a/D W/gTFpJS8NFX9wUUafu+ZllufZngGQ8I2Z6WW02uTaQjeg8SNrZyDkVbs Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 14:16:51 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473401192" X-MGA-submission: =?us-ascii?q?MDHMV5cBsQt9ixhT7iyFOImqe0l1nwqEyAPAC7?= =?us-ascii?q?tRa7eTZ0zbCQ12mZJ5uJK6j1fDkNdZ5X94IyUzSO9HFXFtS++NCRqcuQ?= =?us-ascii?q?SISZy5tee3WBDJl4TGES0259sVpHjb+hOoCLi+xkNMYCYhnT7Z06db85?= =?us-ascii?q?WS0whcOUMhmNqU7QtDqPVf4w=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 14:16:49 +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 14:16:38 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) 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 14:16:38 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.16) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 14:16:37 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB1247.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.26) 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 12:16:37 +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 12:16:37 +0000 From: To: CC: , , Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTwgAAbvwCABKfngIAAI2aAgAABO+A= Date: Mon, 5 Aug 2019 12:16:37 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> In-Reply-To: <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@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: 810bba89-af6e-4f1c-87fb-08d7199ec3cb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB1247; x-ms-traffictypediagnostic: LEXPR01MB1247: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(366004)(136003)(189003)(199004)(5660300002)(186003)(26005)(8936002)(8676002)(486006)(6916009)(53936002)(52396003)(305945005)(508600001)(7736002)(3846002)(66946007)(6116002)(446003)(11346002)(66446008)(66476007)(66556008)(64756008)(9686003)(476003)(54906003)(76116006)(6306002)(55016002)(33656002)(2906002)(4326008)(7696005)(256004)(14454004)(14444005)(71190400001)(45776006)(76176011)(102836004)(966005)(66066001)(86362001)(66574012)(81166006)(71200400001)(81156014)(1411001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1247; 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: H5HJeX2IabJzpN5DMxaAo3k8DHXi51HvSGgKbUVgcK25yK3eEOFs/xGaNmORlTGG5UHqjor8jaDfjbjqtUE5Ab+eD0YQ6M1FkLIOBPF/j68t8Xr+HBDpQdBtFbJ6PzjI7qGYnYo6VdoRbERzzGl7HcSIh7yhfjSuMiboQNefT4oWwYEU4PuMvwingoXTtmWkFDhtNbs9viNUD8bPQsERX6vJKAvXFGruMsSw+pDi7w/egJWAybmDL0TtkENHUxyQgB3A7ZCs7TlV3zP5tVPqdpqBwXIVvYff+gEyI8vSPPxfRJ5s7zjTW8Js5NU47kr067ENAC3WOeyPX/L263Fm928Fgbtu7VKNr7pEnu3rlOlVTel3fHuiGyAy7rWPDMvB24t3owPizzpanQSxwkqu4tFFbLyth1jXACSQLBgx2CQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 810bba89-af6e-4f1c-87fb-08d7199ec3cb X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 12:16:37.5847 (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: LEXPR01MB1247 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 12:16:57 -0000 As I said, no corner-case engineering. On my vacation site abroad, Netflix = worked as well as it does at home. Germany is often criticised as a laggard= in developing a competitive broadband access market. My interest in IETF w= ork being set up to work around commercial problems between ISPs and ISPs o= r CDNs in a rich country like the UK or US is low.=20 If your technical standardization activities help to make using the Interne= t more convenient in African countries without raising extra cost or requir= ing extra skills, I'm sure that's a fair market. I know that these countrie= s are struggling to improve the services operated in their networks. Condit= ions there (and some Asian countries) differ strongly from those in many ot= her parts of the world. It might be a good thing to clarify under which scenarios the problem solut= ions you work on create the most significant benefit. In the market that I am aware of, there's a single regular bottleneck, whic= h is the consumer access or terminal. -----Urspr=FCngliche Nachricht----- Von: Jonathan Morton =20 Gesendet: Montag, 5. August 2019 13:00 An: Geib, R=FCdiger Cc: tcpm@ietf.org; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classifi= ed as L4S > [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-r= ate burst injected at the wide end will experience queuing at every interme= diate node. In practice you can expect typically three or more potentially= narrowing points: >=20 > [RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , fi= rst two sentences. That's a sound starting point, and I don't think much ha= s changed since 2005.=20 As I said, that reference is *usually* true for *responsible* ISPs. Not al= l ISPs, however, are responsible vis a vis their subscribers, as opposed to= their shareholders. There have been some high-profile incidents of *delib= erately* inadequate peering arrangements in the USA (often involving Netfli= x vs major cable networks, for example), and consumer ISPs in the UK *typic= ally* have diurnal cycles of general congestion due to under-investment in = the high-speed segments of their network. To say nothing of what goes on in Asia Minor and Africa, where demand routi= nely far outstrips supply. In those areas, solutions to make the best use = of limited capacity would doubtless be welcomed. > [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 impress= ion is, all major CDNs are aware of that and try their best to avoid this s= ituation. In particular, I don't expect streaming bursts to overwhelm acces= s link shaper buffers by design. And that, I think, limits burst sizes of t= he majority of traffic. In my personal experience with YouTube, to pick a major video streaming ser= vice not-at-all at random, the bursts last several seconds and are essentia= lly ack-clocked. It's just a high/low watermark system in the receiving cl= ient's buffer; when it's full, it tells the server to stop sending, and aft= er it drains a bit it tells the server to start again. When traffic is flo= wing, it's no different from any other bulk flow (aside from the use of BBR= instead of CUBIC or Reno) and can be managed in the same way. The timescale I'm talking about, on the other hand, is sub-RTT. Packet int= ervals may be counted in microseconds at origin, then gradually spaced out = into the millisecond range as they traverse the successive bottlenecks en r= oute. As I mentioned, there are several circumstances when today's servers= emit line-rate bursts of traffic; these can also result from aggregation i= n certain link types (particularly wifi), and hardware offload engines whic= h try to treat multiple physical packets from the same flow as one. This t= hen results in transient queuing delays as the next bottleneck spaces them = out again. When several such bursts coincide at a single bottleneck, moreover, the que= uing required to accommodate them may be as much as their sum. This "incas= t effect" is particularly relevant in datacentres, which routinely produce = synchronised bursts of traffic as responses to distributed queries, but can= also occur in ordinary web traffic when multiple servers are involved in a= single page load. IW10 does not mean you only need 10 packets of buffer s= pace, and many CDNs are in fact using even larger IWs as well. These effects really do exist; we have measured them in the real world, rep= roduced them in lab conditions, and designed qdiscs to accommodate them as = cleanly as possible. The question is to what extent they are relevant to t= he design of a particular technology or deployment; some will be much more = sensitive than others. The only way to be sure of the answer is to be awar= e, and do the appropriate maths. > [RG] Other people use their equipment to communicate and play games These are examples of traffic that would be sensitive to the delay from tra= nsient queuing caused by other traffic. The most robust answer here is to = implement FQ at each such queue. Other solutions may also exist. > Any solution for Best Effort service which is TCP friendly and support sc= ommunication expecting no congestion at the same time should be easy to dep= loy and come with obvious benefits.=20 Well, obviously. Although not everyone remembers this at design time. > [RG] I found Sebastian's response sound. I think, there are people intere= sted in avoiding congestion at their access. > the access link is the bottleneck, that's what's to be expected. It is typically *a* bottleneck, but there can be more than one from the vie= wpoint of a line-rate burst. > [RG] I'd like to repeat again what's important to me: no corner case engi= neering. Is there something to be added to Sebastian's scenario? He makes an essentially similar point to mine, from a different perspective= . Hopefully the additional context provided above is enlightening. - Jonathan Morton