From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 720923CB38 for ; Fri, 19 Jul 2019 17:50:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563573002; bh=uC+NJXiRhORv8398tPR7eHdM6i7DqBrXmOeTnasZ/pU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=K7UcihGEM0kHD4npl9JPm6p/s63WmUY+UXLpuZihNNKn7XdPzXNYNYxvq2WqzxaB9 kwF6Evu9yDSTJO3dvo+J1QvBLKcpo95KrRddJI40IaYeuJRoVXzzfGXM1DSLY1bFab tb/u/llwQ5IdYfF2bZrLc0frch328Q6sHrKV8PuY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.86.147]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mqs0X-1iAx231ewD-00mpAg; Fri, 19 Jul 2019 23:50:02 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 19 Jul 2019 23:49:58 +0200 Cc: Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2C41EE02-0304-4955-A9CD-FA71B7CC8D70@gmx.de> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> To: Wesley Eddy X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:Vzgb6J8RLdEs5+Ratm33p+Ef0uHXpeZuAYqkvGtEBwsbv9CxmLa K5D/z1qNEL9TzDRkOd+EDQSaykdN2FXb0OHMOKhrsBmHY3nFl2F1J2r23m0V8ZwWpohBDxh Woeq1MZJPY9/9eoLSCm41VVNx1GVZwFrJtDO6zHUeOYObgX+AFboLozuClY8flJTY78Bbwf YvYnj72ftysN6+HmH1Akw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:yHP1zxIfK0M=:01njOZ0mf/4G+1d//drjKe Q+NhT9kfOlDKX3m6YtMWigd9FU/vHqL+vc6cJUU+hwxqI8FxVQXQvKHv7ZcupAOBfW5wNPICw DcFRPPRlTF4gXwFJ0a1sdIZugwMOXRwhTYZ1qf0y/uWg/5ouYsVAWsAr/qeyqlZbPTlvRopCy f7VTzLOs4N3WO4iGn5ehuteIXuU+rhDcLQ4kwlS0ZbcQ+Ck/k/qTHLr6GucL5wwOCVtnxAvg4 I0gY15jvRgQbd4TH7YWz/MD+gj3nzu3sPZhdkvf67o5I0Q2aOVL1+h1top3UmgA8dz1V0d4yf pQFRKBBt+K0sQJHaVvz2nmPp6FHOCCGfx0kLI5pBeo1dfE4YcKjDvWVzd84hx91+/jm2WVbr5 hlujqC2ythAQgz6dPku2pHqcbgjh/KASn4JvvwtPRzDRgpOZAwQQ3FC0BtOJFIqgDf05OYTEk OL4nSEMpBZD68ONpMFTvNtBlPp8kUh68i5AkJDkT7oMVmXGB6auk/eR5hODNic7QBd61WqI29 udfHxSWnWnG24uAgVqv6Jnmetf2LT0EazAZ39F5AkXSYPTvdX5FoHn+HtRmxtU1MF2s3rnhwV hvUg6VBarD4g97yYx7Oe6vcJEUUWf8XucPYws5bVUN+nqhr9oOUgFPRYdzKHav0YrK0clbVUO UFTPzlkwtVQWl8zUuUmpfE0ueA94ArU5CLkd328ebXulf/ZNb8G0JbnfUHL8KoQ7rfwdpaCaa +07ZGKw3hxh25N+nQyAnfVs0oJsvYF85R+BhLlQWxhSBTXJ9xO2sTrh32ctzFr+BA88pzDyL7 k1aNsDzUZ3swWUy5e3wsZ9gD6G4KURqB3t47ImjEX2BKObqOAVia4ADBWNy7E79yd6jzzhGxX JPN3pXGPheLATiov5zMXYBHpbca9YAjf7ljJRe3udpY1QJtLMJLIF/jPWcDKqAP8jlHVofhxB dAtQVjQC/cknv2pRy1Z3tSysmyJ1kX4bpiXTu1hwRjKfd3uvakSU3nQAxV5RU8bRJvVhDSHEw tlt1pwuLWeEtdCHVsmpXBrtRo44y4EoC55RmV3tPjNb1DCWe+1g3tKI7mGBnSzUtYqW0rNiKk eHUdSCYllc9OZc= Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts 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, 19 Jul 2019 21:50:06 -0000 > On Jul 19, 2019, at 20:33, Wesley Eddy wrote: >=20 > On 7/19/2019 11:37 AM, Dave Taht wrote: > [...] >> In particular conflating "low latency" really confounds the subject >> matter, and has for years. FQ gives "low latency" for the vast >> majority of flows running below their fair share. L4S promises "low >> latency" for a rigidly defined set of congestion controls in a >> specialized queue, and otherwise tosses all flows into a higher = latency >> queue when one flow is greedy. >=20 > I don't think this is a correct statement. Packets have to be from a = "scalable congestion control" to get access to the L4S queue. =20 With the current proposal, a packet needs to set the ECT(1) = codepoint, there is _no_ checking whether there is a "scalable = congestion control" operational on this flow. Even worse every CE-marked = packet will be put into the L4S queue; the latter is a consequence of = the currently preferred choice of using ECT(1) as L4S classifying bit. = Sure the queue protection feature might help to demote flows not playing = along the L4S rules back into the RFC3168 queue, but queue protection is = advertized as optional.... > There are some draft requirements for using the L4S ID, but they seem = pretty flexible to me. Mostly, they're things that an end-host = algorithm needs to do in order to behave nicely, Except there is no real enforcement/measurement whether flows = "behave nicely", at least as far as I can see. > [...] >=20 >> So to me, it goes back to slamming the door shut, or not, on L4S's = usage >> of ect(1) as a too easily gamed e2e identifier. As I don't think it = and >> all the dependent code and algorithms can possibly scale past a = single >> physical layer tech, I'd like to see it move to a DSCP codepoint, = worst >> case... and certainly remain "experimental" in scope until anyone >> independent can attempt to evaluate it. >=20 > That seems good to discuss in regard to the L4S ID draft. There is a = section (5.2) there already discussing DSCP, and why it alone isn't = feasible. There's also more detailed description of the relation and = interworking in = https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02 IMHO a new protocol ID is the solution: See = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#appendix-B.4" 'B.4. Protocol ID It has been suggested that a new ID in the IPv4 Protocol field or the IPv6 Next Header field could identify L4S packets. However this approach is ruled out by numerous problems: o A new protocol ID would need to be paired with the old one for each transport (TCP, SCTP, UDP, etc.); o In IPv6, there can be a sequence of Next Header fields, and it would not be obvious which one would be expected to identify a network service like L4S; o A new protocol ID would rarely provide an end-to-end service, because It is well-known that new protocol IDs are often blocked by numerous types of middlebox; o The approach is not a solution for AQMs below the IP layer;" None of these points are show stoppers, IMHO: 1) Especially since in all likelihood only two new protocol IDs will be = needed, "AIAD TCP" and "AIAD UDP".=20 2) The IPv6 issue is a bit of a red herring as the next header field = typically seems to contain the exact same number as IPv4's protocol = field and chained headers are probably rare. Also if the primary next = header is not of an L4S type, simply treating the flow as RFC3168 = compliant seems like a safe option. 3) Okay that is a challenge, but ig L4S is worth its salt, it will offer = enough incentives to overcome this hurdle, otherwise why waste ECT(1) on = something that the market/the network community does not seem to want? 4) Me: "Doctor it hurts if I put an AQM below the IP layer." Physician: " Do not do that then!" Honestly, how is an AQM below the IP layer (so L1/L2) going to act on = IP's ECN code points as required for L4S, but going to fail to look at = the protocol/next header field? This is a really clean solution for L4S issues with the currently = proposed badly fitting classifier, that solves all issues with = interoperability with the rest of the current internet.=20 [...] Best Regards Sebastian=