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

<Ruediger.Geib@telekom.de> Mon, 05 August 2019 07:27 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD854120157; Mon, 5 Aug 2019 00:27:26 -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 03xdyYORROR5; Mon, 5 Aug 2019 00:27:24 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id 7134A12002F; Mon, 5 Aug 2019 00:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564990039; x=1596526039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v1XHRfeW+AgkDaZXaMyS4nOGDkJEkR3IIXX1nOOMosg=; b=jOGKnojCiKNSON1wE2gW5GUAvQTUO03BXqjtTXvCRLeeANyHLMe7MCTo 5TrDRNJ6uDwLq/7GXdJ0KkLM7Sno923rdaPOPAJK87q7rP4tfoHhZQTRb mr4AqvWXjXOsWd6B4AoelyPogcbklL9Yo0xf2T+l5KOv/ATzMfxOIZwTS SBE0NQPRWGj01e6LprDufIteOAHGlk4k3dRgaBNo2SpVTJf2DzBsmUiCL OFioGkdtfnYfVjxXRvW6eMIjnDfp8g74h7RzYj5fVutAF4/ncdvkyC5GE GBJtH+LTb3AEdJOUK27wq0ByU8geKzlMArcJ9pbGKnUVqM7/ow2GBkxnh A==;
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 09:27:17 +0200
X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473098187"
X-MGA-submission: =?us-ascii?q?MDEcXczYCT1lJf1F0nyQb/oHt4/Y5SKgzWumaW?= =?us-ascii?q?hcnM2luH/81TQJI0JYC4ToMziCQdMwNpoXfK6JzIkO6/7V6sKr8Jr+fN?= =?us-ascii?q?KXn7OtL8zKxLKxjAeC7JKSFNgfNNC4ZohAlfSiKDaNTyLOuf1bjrpH5U?= =?us-ascii?q?dAH4uDo35o+btvihzY37LqFw=3D=3D?=
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 09:27:14 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 09:26:52 +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 09:26:52 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 09:26:53 +0200
Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0735.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.144) 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 07:26:51 +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 07:26:51 +0000
From: <Ruediger.Geib@telekom.de>
To: <moeller0@gmx.de>
CC: <tcpm@ietf.org>, <ecn-sane@lists.bufferbloat.net>, <tsvwg@ietf.org>
Thread-Topic: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
Thread-Index: AQHVSTRkPkpydBILe0SaPVsimE5Fu6bsIA6Q
Date: Mon, 5 Aug 2019 07:26:51 +0000
Message-ID: <LEXPR01MB0463C090812BEA6DAB566A1E9CDA0@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> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de>
In-Reply-To: <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de>
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: 8b100635-6932-490d-09ed-08d71976490c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LEXPR01MB0735;
x-ms-traffictypediagnostic: LEXPR01MB0735:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <LEXPR01MB0735D06080BFC8E8189A9A479CDA0@LEXPR01MB0735.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(396003)(39860400002)(189003)(199004)(102836004)(966005)(66066001)(85202003)(71190400001)(76176011)(81156014)(68736007)(81166006)(86362001)(66574012)(71200400001)(53546011)(3846002)(11346002)(446003)(6116002)(508600001)(305945005)(7736002)(64756008)(66556008)(66476007)(66446008)(5660300002)(2906002)(26005)(186003)(486006)(8676002)(8936002)(52396003)(53936002)(85182001)(6916009)(66946007)(33656002)(4326008)(14454004)(476003)(256004)(14444005)(6306002)(9686003)(55016002)(54906003)(7696005)(76116006)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0735; 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: EZtEwq/gRehR+pw1oMAGCRMGaAHmhgUb02+1X2q9ywj/vI40YUy37pL+rq++B3FW1wwQ+HlYKBZQqPMptGVoRfV2qGugNnFsa5Dr0CZRI36s2Be5hQdKKN20OE1VEMV+a5RecffgIJvBmjaxTI5LcwwKGGfAuyP3uCecm5wY9Vv4SjmyudXVxAHVJWrK/kGznTXDK18kuivZmkb6S0hJ2TdyKMzWXaQoGCrkOaTayZ55UINw/IT1eo6WQbfaI9NOycWxV3dG+l+AYAtmwpVBQaUwhc6HbypW+Z2nRFnznIP6nc/S5C7m/xbLILXjBaTrzi1N/lOZqmBK4bmOn7dOWZoFJib4QA+kf7tbMEILvciUMGb2x0s9RVNeP+px8LVszo7A9EjOPJ+1bQJiwvwWA+slJ1zhc7Za1rgcKmNulc4=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b100635-6932-490d-09ed-08d71976490c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 07:26:51.8125 (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: LEXPR01MB0735
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/nZvKd8ncI5A7WrTlqvI1idDNXbs>
Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 07:27:27 -0000

Hi Sebastian,

the access link is the bottleneck, that's what's to be expected. As far as I know, in the operator world shapers here by and large removed policers.

A consecutive chain of narrower links results, if the Home Gateway runs with an additional ingress or egress shaper operating below the access bandwidth, if I get you right. 

I understand that you aren't interested in having 300ms buffer delay and may be some jitter for a phone conversation using best effort transport. A main driver for changes in consumer IP access features in Germany are publications of journals and regulators comparing IP access performance of different providers. Should one provider have an advantage over the others by deploying a solution as you (and Bob's team) work on, it likely will be generally deployed.

As far as I can see, latency aware consumers still are a minority and gamers seem to be a big group belonging here. Interest in well performing gaming seems to be growing, I guess (for me at least it's an impression rather than a clear trend).

I'd personally prefer an easy to deploy and operate standard solution offering Best Effort based transport being TCP friendly and at the same time congestion free for other flows at a BNG for traffic in access direction (and for similar devices in other architectures of course). 

Fighting bufferbloat in the upstream direction the way you describe it doesn't construct a chain of links which are consecutively narrower than the bottleneck link, I think.

Regards,

Ruediger

 



-----Ursprüngliche Nachricht-----
Von: Sebastian Moeller <moeller0@gmx.de>; 
Gesendet: Freitag, 2. August 2019 15:15
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>;
Cc: Jonathan Morton <chromatix99@gmail.com>;; tcpm@ietf.org; ECN-Sane <ecn-sane@lists.bufferbloat.net>;; tsvwg@ietf.org
Betreff: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S

Hi Ruediger,



> On Aug 2, 2019, at 10:29, <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?

	Just an example from a network you might be comfortable with, in DTAGs internet access network there typically are traffic limiting elements at the BNGs (or at the BRAS for the legacy network), I am not 100% sure whether these are implemented as policers or shapers, but they tended to come with >= 300ms buffering. Since recently, the BNG/BRAS traffic shaper's use the message field of the PPPoE Auth ACK to transfer information about the TCP/IPv4 Goodput endusers can expect on their link as a consequence of the BNG/BRAS"s traffic limiter. In DOCSIS and GPON networks the traffic shaper seems mandated by the standards, in DSL networks it seems optional (but there even without a shaper the limited bandwidth of the access link would be a natural traffic choke point).
 Fritzbox home router's now use this information to automatically set egress (and I believe also) ingress traffic shaping on the CPE to reduce the bufferbloat users experience. I have no insight in what Telekom's own Speedport routers do, but I would not be surprised if they would do the same (at least for egress). 
	As Jonathan and Dave mentioned, quite a number of end-users, especially the latency sensitive ones, employ their own ingress and egress traffic shapers at their home routers as the 300ms buffers of the BNG's are just not acceptable for any real-timish uses (VoIP, on-line twitch gaming, even for interactive sessions like ssh 300ms delay are undesirable). E.g. personally, I use an OpenWrt router with an FQ AQM for both ingress and egress (based on Jonathan's excellent cake qdisc) that allows a family of 5 to happily share a 50/10 connection between video streaming and interactive use with very little interference between the users, the same link with out the FQ-AQM active makes interactive applications feel like submerged in molasses once the link gets saturated...
	As far as I can tell there is a number of different solutions that offer home-router based bi-directional traffic shaping to solve bufferbloat" from home (well, not fully solve it, but remedy its consequences), including commercial options like evenroute's iqrouter, and open-source options like OpenWrt (with sqm-scripts as shaper packet). 
	It is exactly this use case and the fact that latency-sensitive users often opt for this solution, that causes me to ask the L4S crowd to actually measure the effect of L4S on RFC3168-FQ-AQMs in the exact configuration it is actually used today, to remedy the same issue L4S wants to tackle.

Best Regards
	Sebastian


> 
> 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. 
> 
> Regards,
> 
> Ruediger 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <tsvwg-bounces@ietf.org>; Im Auftrag von Jonathan Morton
> Gesendet: Dienstag, 9. Juli 2019 17:41
> An: Bob Briscoe <ietf@bobbriscoe.net>;
> Cc: tcpm IETF list <tcpm@ietf.org>;; ecn-sane@lists.bufferbloat.net; tsvwg IETF list <tsvwg@ietf.org>;
> Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S
> 
>> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe <ietf@bobbriscoe.net>; wrote:
>> 
>>      1.  It is quite unusual to experience queuing at more than one
>>          bottleneck on the same path (the available capacities have to
>>          be identical).
> 
> Following up on David Black's comments, I'd just like to note that the above is not the true criterion for multiple sequential queuing.
> 
> Many existing TCP senders are unpaced (aside from ack-clocking), including FreeBSD, resulting in potentially large line-rate bursts at the origin - especially during slow-start.  Even in congestion avoidance, each ack will trigger a closely spaced packet pair (or sometimes a triplet).  It is then easy to imagine, or to build a testbed containing, an arbitrarily long sequence of consecutively narrower links; upon entering each, the burst of packets will briefly collect in a queue and then be paced out at the new rate.
> 
> TCP pacing does largely eliminate these bursts when implemented correctly.  However, Linux' pacing and IW is specifically (and apparently deliberately) set up to issue a 10-packet line-rate burst on startup.  This effect has shown up in SCE tests to the point where we had to patch this behaviour out of the sending kernel to prevent an instant exit from slow-start.
> 
> - Jonathan Morton
> 
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane