From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E27943B29E for ; Fri, 2 Aug 2019 09:15:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564751726; bh=ugUBSujZuKIGXPHRqQ4v/2lEkJOKLnlRX2iF5ZGTGbQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=O894eUXy95vo7VUQ2yHP/ML5KIiVO7p6WrlZ0ypxLTHfMcqBZT0SJXHobJG6ZTMeC z4t12PXp6TxBTshD7mMDP4bnUNI1nTw2as3oeDtAmM1mmx9t4frek/7qMK+HmtWEQ+ N3xWww4WsOIBnX3Re+ZSaO5Avf97rqTmrENcErg4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LjZn2-1iV58w0lqq-00bXpz; Fri, 02 Aug 2019 15:15:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 2 Aug 2019 15:15:23 +0200 Cc: Jonathan Morton , tcpm@ietf.org, ECN-Sane , tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:6XHtP07waXiolpH/2jXVlCbpP1vT9X1zFgvFyqTpj7OtlxGi626 37sAbLEu3/s/iftInsG0fKwoKx3og88lAUSI1LdF3Jixg/k+f5T2eeyR1lXDPOtSUpQGBUX tIqn33x4DjcMw8Od3kcD2//WM4oeX5Vs3Wt4aG11xxMU+Han7EKSDZF6bx75atervwIz8E/ cGxpiTQw98xJM4dWxTnZQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:YqH0/9ThHVQ=:3pUbOKbFr67gK0m/1tdivo +TVOwRbgLzp3Zmv+bUX8TbZ0QzsY4XvkLf64AtUVTNOeUAL8U1gOO87ofozwx2CAg0eVYlgIL JmDY5+4ekArsLOe9c3CAGjCUjrXiA7WXRuxenOQlkDIDxvlDcRq1FVbdarprw1g/wIuCERuDK V1UfAYKXVbWKpRxc3upF0HoCRF9l91tqZD7gmi7v4kRME8dvrWMb04GmKajN9J6UG13Nwj/bK o7v4yAogCCfqgl8kKKxew4FwA3xw4zAIrboZMsAhe3PDEJnTxaL8I4CUT5qftQzwiz9g0lkmz 2fBESRa4VFGu/JxRHS+8GlobDpPfKUiYY2oYvomC0PB2yz/0fZ8YnZnHJt8DKUrdTG/cWomhT JWgdaEY+VXsV1YiSDjorqjFD+4c9rNeK7zFtWvvVmjiz2Bp/aeVozKBSrXfwSsmvcDpbppjU7 XMepC/PSkg1fjqOK/5xvrGCm/Vrmj9vhYXPPbMl0L69gTTPBkf/QFhRgCtKfBhblNsdL3xY58 jkxpjg6hL/6rCchz8VArzMV/tIk2KhU9fzvtjptoWab957HGnZ/ojvXrWFhgXMLhKCUUa5geH 8ogzrOvQafNJO1WKcjJ8380JhBEaG7LFPXEOSH6C+CV1sWooeBIiAulOvJbPew76egc4CGrK9 mJ/v6IZYz5fKeebkOhWRtaZsJkngcdGr6dv1YeYi2Jm6oy1F3F4eLx9FRcBFWErz+8/2RHmbt laD928QXC+wPUrcFOLjg7c4JIc5KIwKAR3M4IIw1P4IrpOt+plxH0WdEfnVeVMeQbFEufVSBK 1cMnszF2JU1TFj14VfHcknhFMZLZP7e++5Q7HaGLaZTh+dvm3KoViymbyOKpgqtLtlmi1SOFU BRHPygV7hznJ7y4p43cH0/FNccpsVu3mbZyUswQFSJWgurP50aqxP12JXJjZivbhwUb5ct4qQ mW7xxq0glwkHfyKh6CTUBrbMijZaPANcP0449c2BcL8JdBmVOS+yhB8AmtFSbwT4glbCOVZ1R K6V54Yp9Iwv55Zp3SdR7ViLzQlEeutkYnQAtWimLiG9YPh6ORT12e3iqaJTNN6vrBInejRtqX piz/wy22VdYpbJg33L5VSo7g2PsatQdk9rpLV0R0Sja83SIgbgW6jsY0GfjEMB8iIk+hYWE5/ P3DjU= 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: Fri, 02 Aug 2019 13:15:31 -0000 Hi Ruediger, > On Aug 2, 2019, at 10:29, = wrote: >=20 > Hi Jonathan, >=20 > 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 >=3D 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).=20 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).=20 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 >=20 > 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). >=20 > There may be a tradeoff between simplicity and general applicability. = Awareness of that tradeoff is important. To me, simplicity is the design = aim.=20 >=20 > Regards, >=20 > Ruediger=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: tsvwg Im Auftrag von Jonathan Morton > Gesendet: Dienstag, 9. Juli 2019 17:41 > An: Bob Briscoe > Cc: tcpm IETF list ; ecn-sane@lists.bufferbloat.net; = tsvwg IETF list > Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly = classified as L4S >=20 >> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe wrote: >>=20 >> 1. It is quite unusual to experience queuing at more than one >> bottleneck on the same path (the available capacities have = to >> be identical). >=20 > 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. >=20 > 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. >=20 > 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. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane