From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 1ED983CB36 for ; Thu, 21 Mar 2019 04:46:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553157920; bh=iUdV0eZz6SpGxAIyBFMOzt63SF790yCZudZBOYdgBeQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=N7eL7w9OGCPiuxRN4t7pNF1UgRGUkJid2R29oXQMmIpgnGDseCxAlgZEp6OuO+Aqv 4bX0Za+vZG62Fjzdyynr3iWAPi8PUOqtD+z20ToMGtDVwGSfIKt2NY81AnH4NU5BQu XWUzTtSFws2LbDXSwgkrtiPU5CRbV+eJAt1RhNd8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4GRv-1goXA32DyN-00rq8p; Thu, 21 Mar 2019 09:45:20 +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: Thu, 21 Mar 2019 09:45:18 +0100 Cc: Jonathan Morton , tsvwg IETF list , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <5427B3D9-BA3E-45A3-A678-73378B64FC22@gmx.de> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:9P3z+kVYIMGs5OYDlpW9BucNrz8xJ79EqEfzfq38uqXxXh/zNNY OTAsceVdM2ieFM9ct9JA3TRBGYOhXcTdXTeG3Eo/NU7i+M2JDlP2xaEj7Qs9HDraXvA3q9q xeHJY5uWRaAi1i/ye8mC4lolSD8WMoVmQ1JDhmjHcqVYjCmxAgO/GyTvGb5pUHw4oyBLS+x JBDBhjw9pjI9v4C4TfYyw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2Oxee0xuNGE=:WEcCqEvoChcQLPBYX4TcHo dgioR370yNAsfesP52NBySonFYbH0lzxNKAzI7r02mUF9ZAG3sNr2tAlkVq981Lk/LAJpNy2Q vlyLxx9wYFVIT6tNxA34Tabve0MnfPFSP9Jg9shKKAsjt8Ci59nEQfx02cd6ZeyHUGSsHdvLi YDXA/6IraK+N/vYK+4LRBIwaQO2rcqv6N3QRPUN1kC7QuaLX+FzG1Hw158eudTVHSUoXN7EOJ aMjqbbjS0g/j7pimvCTHWT9JD1kzBvYBJXDfU5tX3D5F/Oh8C/pU2UeKB/9JqIzGV4RtGfx/G RNiEoFK/KBhGDXvKRzCBqrMkqJAjDoQfJ3lHCAhx8uAV9gDW0BR+gFrSy6BhMzq7QYCgAwHqF GSQchry547eEHk41u+7yEFiTpxh62NSGcGsDUOEywhen4tACzLpasBWdgN/ljMKrO4M9ZaY5P lG8gEMvOg5Q6+db+zZh4JXlXAgN+NDB9X8OQDz1E1l4Slk+4GubYX187urqH9X7Ru5/38hhge pbmECozze8Ljmk+P4vckX/fh4JkH0VW8KgEIu/cFVvcQCMobelj7L0z+IJC17RVJ99VWPAmst M+EEiazMhJK5CNKNHUaRlDWabMNoqhSzhcC7NdJYFeahsQOs6Mp3Js5pmUTiQSuH6hizmJl8l ML77KIycsQ5fy0dbXmx33YM7F0dWO3yk26t6ribkjbe1i4v9qtQOVfpRbP5pSH3VPYhaoxY2Y jGJFYs+efABe/ZHVtVdyiWaJ94ReN9uM45QTT81I/SoU2NMFVBSwZ/03VD9WYIFsiS+EKHf3T QKImajAwrSinxgKFuW8hoZVsMb5cnBDd5lr1pEyVsNsQKZDL+vOOi5rSp76X+EieuhGPx8Pto D/Ta72nczeajmJQzmwxAn0eUfpbQ1P01AJDUph1fpKL2gWaDvQCauY34iavINqiu/2mkGT2ni TKQHnwF9nfA== Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 08:46:04 -0000 > On Mar 21, 2019, at 07:04, Bob Briscoe wrote: >=20 > [...] > As regards the desire to use SCE instead of the L4S approach of using = a classifier, please answer all the reasons I gave for why that won't = work, which I sent in response to your draft some days ago. Is there any work planned showing why the heuristic based on CE = is not going to cause problems? Because as it stands ECT(1) might be a = useful piece of information for a traffic classifier, but it certainly = is not a reliable traffic category identifier (unless you are interested = in the category: packets that promise to respond in the L4S-way if they = should encounter congestion). > The main one is incremental deployment: the source does not identify = its packets as distinct from others, so the source needs the network to = use some other identifier if it wants the network to put it in a queue = with latency that is isolated from packets not using the scheme. The = only way I can see to so this would be to use per-flow-queuing. I think = that is an unstated assumption of SCE. You write a whole section on alternative labeling schemes in = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-B = that you rule out, but that is based on hand-waving over the fact that = CE-marking destroys the neat L4S labeling by ECT(1) scheme in two ways = (mis-classifiaction of by AQM and mis-interpretation by end-point).=20 You write: "Given shortage of codepoints, both L4S and classic ECN sides = of an AQM would have to use the same CE codepoint to indicate that a = packet had experienced congestion. If a packet that had already been = marked CE in an upstream buffer arrived at a subsequent AQM, this AQM = would then have to guess whether to classify CE packets as L4S or = classic ECN. Choosing the L4S treatment would be a safer choice, = because then a few classic packets might arrive early, rather than a few = L4S packets arriving late;" but in all honestly this simply assumes the = rate of CE-marked packets of non-L4S flows will be low, otherwise your = four Ls will suffer. Regarding the second ambiguity you write: "A.1.4. Fall back to Reno-friendly congestion control on classic ECN = bottlenecks [side note on = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-23 = bottleneck appears in normal font instead of bold] It would take time for endpoints to distinguish classic and L4S ECN = marking. An increase in queuing delay or in delay variation would be a = tell-tale sign, but it is not yet clear where a line would be drawn = between the two behaviours. It might be possible to cache what was = learned about the path to help subsequent attempts to detect the type of = marking." This has issues that IMHO need empirical data instead of hand-waving. = Competent AQM solutions will control traffic rates without introducing = massively increasing delays which will make it harder to do a heuristic = based on RTT or RTT variation, this is the same mis-design LEDBAT = suffers from, making inportant decisions based on un-reliable = information... And trying to cache the L4S-ness of the active AQM = assumes a steady-state behaviour of the network, which will not work for = all cases. >=20 > In contrast, L4S works with either per-flow queuing or dualQ, so it is = more appropriate for a wider spread of scenarios. Again, in that same = unanswered email, I described a way L4S can use per-flow queuing, and = Greg has since given pseudocode. There are other problems with doing the = codepoints the SCE way round - pls see that email. >=20 > There has been a general statement that the SCE way round is purer. = However, that concept is in the eye of the beholder. The SCE way round = does not allow the ECN field to be used as a classifier, Nor does the proposed L4S interpretation, as elaborated above. > so you don't get the benefit above about support for per-flow-queueing = and dual queue. You also don't get the benefit of being able to relax = resequencing in the network, I am still failing to grasp how this is supposed to work, and I = had a look at the RACK RFC already. IMHO the link technology people = should think about how much slack they require and ask the RACK = developers to add that as a minimum to the specification, assuming it is = reasonable. Say, lower level ARQ is expected to take 5ms worst-case, = than ask RACK to specify a minimum reordering window of 10ms. The = current RACK draft with re-ordering window bound to be <=3D RTT will not = give reliable re-odering allowance to the lower levels unless they = measure the RTT for each flow independently, I am sure that that is not = going to fly... > because the network has no classifier to look at. Same here CE-marked packets have no reliable label, and I assume = that with L4S at steady-state and link capacity one can expect quite a = number of CE-marked packets. I begin to wonder whether there is a nomenclature mismatch here, and I = have a definition of classification that is alien to the field here. > For these, the SCE codepoint would need to be combined with a DSCP, = and I assume you don't want to do that. >=20 > The L4S way round signifies an alternative meaning of the ECN field, = which is exactly what it is. The problem of having to guess which type = of packet a CE used to be has been roundly discussed at the IETF in TCPM = and TSVWG WGs and it has been decided it is a non-problem This is not something to "decide" but something to = experimentally test, but I guess I am just getting disillusioned how = internet sausage is made... Best Regards Sebastian > if it is assumed to have been ECT(1) even if it was not - as written = up in draft-ietf-ecn-l4s-id. And that discussion assumed TCP with = 3DupACK reordering tolerance, not the more liberal use of RACK (or a = RACK-like approach in other transports). With a RACK-like approach, it = becomes even less of a problem. >=20 >=20 > Bob >=20 >> - Jonathan Morton >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat