From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 37B0C3B29E; Mon, 11 Mar 2019 03:54:31 -0400 (EDT) Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LvV1X-1guQJK2fDf-010d6f; Mon, 11 Mar 2019 08:54:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 11 Mar 2019 08:54:01 +0100 Cc: Mikael Abrahamsson , Cake List , "codel@lists.bufferbloat.net" , "ecn-sane@lists.bufferbloat.net" , Jonathan Morton , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <0051F4BA-76D8-4E45-9DFB-975A36B90821@gmx.de> References: <550C0248-1704-49DA-ABDC-49A91E0AC6F3@akamai.com> <1EE25778-8571-4506-A334-38C544470ACE@gmail.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:LghJM0ngjH3u6C3I8BBCouyJwsiyiIeN5/QIVGiH2DGzpAomJul e7aLR6lBw1DB+Ftomb+TUN3XS9jO/9P8xhY0XR5Rjvu1wAglUfg+EHPUDXPlQ++yR8q9VKO Y7WL7Sg87EcOqdJrKE6AuRIofiIkv28DW5wPvUb5dkA1llsBEPwMfohRGYCIYr5T0QcOy7L a5bM0S3ygP40s1cW0ysmQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:M0xsr6N+k8A=:5aS9O26px62o3WQajSBv+0 QODHGrTpm2zVb4LFn3VZ+w+MSn1PFPS53YA7oYWdFe4Lg0zGL5I7/U67Kc6P5lj8xrZY13GRT TFzuVf4+qVa3C5YpPjrtQ7GdCyOjwzsfnAT3BQkq/W3rLh1r4lscrtYOKj3tPY0chWqKn2d6S +TnlC54RU1jjM0/mkCrTTl/RMDDRnp7GF/SHTTysOQlW5DWO8/fd4U3sxmwUE5IaG96HTXeJk CTYiOt25SKT5q51zyK7dnZ2cvCo7wUSFYIUYZv1do1hj6YCng5/6eCAXOV1ejUXVokeHsRqxI YnDm8qfw7dY5yj22RmGYxZ3Yl/N85vukaIhSYJklrr9AF08xtfWxZ45ssRn85XKzbsJOggJVW SkadE1bZl9F72t94EXp8Ksxm0Pxmd3SGoZlW4HsaCmFe99SIdZjvTlCL4Mr3o3sKrVR0lorKk WvOzmflyrD3svG5g4wXmH+SJuwx0OOGfAd4FI+ZLYfZ+NiXlAf9AMn0o6Jrs999gp47yYmJfY Vvp994mdxrGNXGtzrwAhv8LvfD9xCi5Mo3BJhXwSdskZmmoZPSZUadGDAS/f+s5/Si0I2Nno+ W0ff2R8q+sNzBWFxh8e5paCg9c72BspqWexrgNma0s8io391zVHhM3ASMQ/iEBDDoP2wFMYZ/ W+4onuaCLiZxZU3ZUHJhe3Tm4B8XWcb/qYfieTxtqDktFPl/SS1ob4gNof5nQJLV5k02HUrcS Dxc24DBNZdCmU6Rr3shKrPA8aqG/Uz4yjOfYhi0dAn9/2CiKWHnij3snscLaZ5JFLeIJJsdPi unQmG7CtABRNM5wjd6ENanH2nVimulKBaYzS1BQnHJe3PkN9iIDyVqGS+qDoqJ9oz4D5vO0Oi xes442t/AS0dPblmmdINLEgpAmpfprY1i1xZy0Fc39mkfCSGExx+hljkyudhEDT1/6eBLqd38 EfeCfQ/kIZQ== Subject: Re: [Cake] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft - X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 07:54:31 -0000 Dear Richard, I am an interested layman here, so do not take my questions too = seriously... > On Mar 11, 2019, at 08:35, Richard Scheffenegger = wrote: >=20 > I can remember reading quite a few papers where a similar scheme for = ect(1) was adopted - often with additional changes on both ends to make = use of this signal. Including schemes that encoded complex information = in the stream of ect0/ect1... >=20 > Where can one find simulations of the interaction between legacy and = l4s flows when using this? Given that l4s is not deployed, I would argue that until it is = anything new will only need to play nice with what you call legacy flows = (I would call them normal flows). >=20 > I think the l4s use of dctcp, to allow coupled queue selection based = on the transports expectations, is a more useful case for ect(1) But L4s, at least from a glance at = draft-briscoe-tsvwg-l4s-arch-01 seems ti merit the unicorn-qualifier = that Mikael used: since it seems to imply that the l4s path will not = encounter drops just marks to achieve its goal of "keep[ing] congestion = loss to zero". This probably is true for a rather strict definition of = "congestion loss", but it flies into the face of the naive insight that = once under sufficient load a router is going to drop packets to keep its = queues under control, and if each flow uses up less of the queue (a = worthy goal) it will just take more concurrent flow to push the router = into the dropping regime, but that is a quantitative difference not a = qualitative one. I guess this shows the lack of understanding from my = side more than short-comings of l4s... Best Regards Sebastian >=20 > Richard >=20 > Gesendet mit der GMX iPhone App >=20 > Am 11.03.19 um 08:08 schrieb Mikael Abrahamsson >=20 >> On Sun, 10 Mar 2019, Jonathan Morton wrote: >>=20 >>> An interesting idea, but SCE marks will appear even when there's a = lot=20 >>> of congestion (at high rates, ie. probably every packet that doesn't=20= >>> carry CE), as well as showing up at low frequency when the level of=20= >>> congestion only warrants reducing the growth rate. I think the word=20= >>> "Some" is sufficiently descriptive, while "Slight" might cause = people to=20 >>> ignore it completely. >>=20 >> One way to handle this would be "buffering experienced" or something = like=20 >> that. Ie if this packet is being enqueued into a buffer with = non-trivial=20 >> number of packets in it, mark it. >>=20 >> The L4S proposal also has the property that their use of this last = code=20 >> point combination in the entire packet header (and this is a big = thing,=20 >> this is the last unicorn) also meant the packet was allowed to be=20 >> re-ordered. I thought this was a big and nice thing, for other areas. = This=20 >> new proposal removes that property. >>=20 >> =46rom what I can see, L4S actually is quite novel and has the chance = to=20 >> seriously change the way queueing is done. This proposal seems more = like=20 >> "a little more of what we had before" which I do not think warrants=20= >> claiming this last unicorn codepoint. I'd like its use to be truly = novel=20 >> and be more than a tweak. >>=20 >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat