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 6A35A3CB3D for ; Sun, 21 Jul 2019 12:09:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563725297; bh=IPPZoB9o3ewkmI7AIRVJwUqi/we6BydoQWx8N5Uek7o=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=EqxhrFot+LDPt6etuJ4VDd5JQ7jij9dqy5q1ZeSY+reIAXybXLNRwIlQL88X9idIB ThSQH1F06A+JqSaRzxP7OspVKrkNJgrZ7O7Y2wB++deG9KtKJ4SMiqCdwN0MCmLu+P oJHCXlMpCzl0aZOdp0pbhip9+ZBCfDF2YRTwfjLM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.149.150]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MryXH-1iAJRU1Ror-00nytG; Sun, 21 Jul 2019 18:08:17 +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: Sun, 21 Jul 2019 18:08:13 +0200 Cc: "Black, David" , Wesley Eddy , Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <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: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:3F3erCkkwu2lwE8txIB5DQdT4tKDFoahfjHokjqhTGdXmtoTHsf BoyymSAe8MhHwLTspSMeGZbjXIAEyhXSxo1pjdrlfCDvQdzIuAwILnvN01dkNAu5yrUufw3 MxtHnmmhWPuwqWzXnd/mcpvyhHBEQVgYWSxkuGwlAno+NP3bbJoh0cHVdh2lFuIY927vXiO 2ttUOHciXhIVgudyhHBWw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xp8VPHS9uY8=:9hjvq27nk/Onohf7s20dlq vFPFxW0gvBfugUO4ApWowFKXjv/uwokLJEnTp6TqNkjtj9p9cXunR7977V/83kjWE/FY3HAJZ RFZaQyZoBljq/Px22NTcX8IDBfpwl3A2kxmU6nn82fTSHVScKoQ7CF30de+o7phYWtXcH5V9/ Qh7PW17HnN2g///PZ1077DTx/ZypYfRkEf21DR9uhvp2cdk7Hd6riCJmn3Hc+jyM9n156NTTP ciwuFxgZPsgLFzBdR9HCjcKm8oNSZSbiw2yBl7S1VbY+YroLKQN5mvxItN8LHFXS6YJDlQP0C 6cwWMvtdLg0Su6l1hLzEYfoo8okmDLtZm8KLcQ1ihn1xtMAFig9glScasRNnnvpO9o7RldoVY 0RpdT/JwWLNI54fwT0lDDuQmPoxsesYCX7z0ACrfkrvvqFYKRqnJSLJtHwL34+UNxxeblcSH2 SMDUU5UxpiGRhV+PZaeU+/5sDFVxlD+R9rEC8JsmoPlyyDo9o0RDfR3O0I9Jct+pFahVEbyyg Onr7LnUUglSlX/pkEWUp+81kZNwXsAbuS5HFRC0MRJQLVOSq8H4eiduMxif6TdQ6n9M6gAyEt a+zzfUr+xuYqw9MRdTFuRfdcTQzSM7U6Q2PJ5EmdtQprJ49owSYa+bO7zCrtil4ot6qK0O4v4 kFaDXRIw8ScjrHZDAqKxYPwMs8xDJJ3kz/kjCEx6FuUAHunJuAJagXIPgYTz1mUF6Ox7eUwoz /553vJdlj8scwITePGwuGm2mWeRyRY9Gn3fvxcmWLLSsVPuD8uJn0bta4QHmmLXCTWvwTr91U BpuPQk4ZiC0ISRtQHUPrO3FrhSyAM5FWTlwQB/wRaT9BGE+0VgFTwqVfq8aAgDqmtENIDhWVy z2iisT8M0hmewhYNCUdOY9e3DInew6ddd+uoWqypvsHoxFV9r6TyR7J7X+qcD32ZNgnobfFFB YKu8EssqZA0Jh2zgSRsVJ6bClSFlvXbangilgU/qQ0eODNfsFZ5/mhLpeYXYSXiCvkMYw8uwh ztFsEqk84F3GaP/UBh9clahGJsC39F26l4viIE8aRJbVOtaC0nAQs2pl81xSk7sPzWv+gpKBP mjcKQ2KXeKIDbA= 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: Sun, 21 Jul 2019 16:09:05 -0000 Hi Bob, > On Jul 21, 2019, at 14:30, Bob Briscoe wrote: >=20 > David, >=20 > On 19/07/2019 21:06, Black, David wrote: >> Two comments as an individual, not as a WG chair: >>=20 >>> Mostly, they're things that an end-host algorithm needs >>> to do in order to behave nicely, that might be good things anyways >>> without regard to L4S in the network (coexist w/ Reno, avoid RTT = bias, >>> work well w/ small RTT, be robust to reordering). I am curious = which >>> ones you think are too rigid ... maybe they can be loosened? >> [1] I have profoundly objected to L4S's RACK-like requirement (use = time to detect loss, and in particular do not use 3DupACK) in public on = multiple occasions, because in reliable transport space, that forces use = of TCP Prague, a protocol with which we have little to no deployment or = operational experience. Moreover, that requirement raises the bar for = other protocols in a fashion that impacts endpoint firmware, and = possibly hardware in some important (IMHO) environments where investing = in those changes delivers little to no benefit. The environments that I = have in mind include a lot of data centers. Process wise, I'm ok with = addressing this objection via some sort of "controlled environment" = escape clause text that makes this RACK-like requirement inapplicable in = a "controlled environment" that does not need that behavior (e.g., where = 3DupACK does not cause problems and is not expected to cause problems). >>=20 >> For clarity, I understand the multi-lane link design rationale behind = the RACK-like requirement and would agree with that requirement in a = perfect world ... BUT ... this world is not perfect ... e.g., 3DupACK = will not vanish from "running code" anytime soon. > As you know, we have been at pains to address every concern about L4S = that has come up over the years, and I thought we had addressed this one = to your satisfaction. >=20 > The reliable transports you are are concerned about require ordered = delivery by the underlying fabric, so they can only ever exist in a = controlled environment. In such a controlled environment, your ECT1+DSCP = idea (below) could be used to isolate the L4S experiment from these = transports and their firmware/hardware constraints. >=20 > On the public Internet, the DSCP commonly gets wiped at the first hop. = So requiring a DSCP as well as ECT1 to separate off L4S would serve no = useful purpose: it would still lead to ECT1 packets without the DSCP = sent from a scalable congestion controls (which is behind Jonathan's = concern in response to you). And this is why IPv4's protocol fiel/ IPv6's next header field = are the classifier you actually need... You are changing a significant = portion of TCP's observable behavior, so it can be argued that = TCP-Prague is TCP by name only; this "classifier" still lives in the IP = header, so no deeper layer's need to be accessed, this is non-leaky in = that the classifier is unambiguously present independent of the value of = the ECN bits; and it is also compatible with an SCE style ECN signaling. = Since I believe the most/only likely roll-out of L4S is going to be at = the ISPs access nodes (BRAS/BNG/CMTS/whatever) middleboxes shpould not = be an unsurmountable problem, as ISPs controll their own middleboxes and = often even the CPEs, so protocoll ossification is not going to be a = showstopper for this part of the roll-out. Best Regards Sebastian >=20 >=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. >>> 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 >> [2] We probably should pay more attention to that draft. One of the = things that I think is important in that draft is a requirement that = operators can enable/disable L4S behavior of ECT(1) on a per-DSCP basis = - the rationale for that functionality starts with incremental = deployment. This technique may also have the potential to provide a = means for L4S and SCE to coexist via use of different DSCPs for L4S vs. = SCE traffic (there are some subtleties here, e.g., interaction with = operator bleaching of DSCPs to zero at network boundaries). >>=20 >> To be clear on what I have in mind: >> o Unacceptable: All traffic marked with ECT(1) goes into the L4S = queue, independent of what DSCP it is marked with. >> o Acceptable: There's an operator-configurable list of DSCPs = that support an L4S service - traffic marked with ECT(1) goes into the = L4S queue if and only if that traffic is also marked with a DSCP that is = on the operator's DSCPs-for-L4S list. > Please confirm: > a) that your RACK concern only applies in controlled environments, and = ECT1+DSCP resolves it > b) on the public Internet, we currently have one issue to address: = single-queue RFC3168 AQMs, > and if we can resolve that, ECT1 alone would be acceptable as an L4S = identifier. >=20 > I am trying to focus the issues list, which I would hope you would = support, even without your chair hat on. >=20 >=20 >=20 > Bob >=20 >>=20 >> Reminder: This entire message is posted as an individual, not as a WG = chair. >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: tsvwg On Behalf Of Wesley Eddy >>> Sent: Friday, July 19, 2019 2:34 PM >>> To: Dave Taht; De Schepper, Koen (Nokia - BE/Antwerp) >>> Cc: ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org >>> Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts >>>=20 >>>=20 >>> [EXTERNAL EMAIL] >>>=20 >>> On 7/19/2019 11:37 AM, Dave Taht wrote: >>>> It's the common-q with AQM **+ ECN** that's the sticking point. I'm >>>> perfectly satisfied with the behavior of every ietf approved single >>>> queued AQM without ecn enabled. Let's deploy more of those! >>> Hi Dave, I'm just trying to make sure I'm reading into your message >>> correctly ... if I'm understanding it, then you're not in favor of >>> either SCE or L4S at all? With small queues and without ECN, loss >>> becomes the only congestion signal, which is not desirable, IMHO, or = am >>> I totally misunderstanding something? >>>=20 >>>=20 >>>> If we could somehow create a neutral poll in the general networking >>>> community outside the ietf (nanog, bsd, linux, dcs, bigcos, = routercos, >>>> ISPs small and large) , and do it much like your classic "vote for = a >>>> political measure" thing, with a single point/counterpoint section, >>>> maybe we'd get somewhere. >>> While I agree that would be really useful, it's kind of an "I want a >>> pony" statement. As a TSVWG chair where we're doing this work, = we've >>> been getting inputs from people that have a foot in many of the >>> communities you mention, but always looking for more. >>>=20 >>>=20 >>>> 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. >>> 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. 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, that might be good things anyways >>> without regard to L4S in the network (coexist w/ Reno, avoid RTT = bias, >>> work well w/ small RTT, be robust to reordering). I am curious = which >>> ones you think are too rigid ... maybe they can be loosened? >>>=20 >>> Also, I don't think the "tosses all flows into a higher latency = queue >>> when one flow is greedy" characterization is correct. The other = queue >>> is for classic/non-scalable traffic, and not necessarily higher = latency >>> for a given flow, nor is winding up there related to whether another >>> flow is greedy. >>>=20 >>>=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. >>> 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 >>>=20 >>>=20 >>>> I'd really all the tcp-go-fast-at-any-cost people to take a year = off to >>>> dogfood their designs, and go live somewhere with a congested = network >>> to >>>> deal with daily, like a railway or airport, or on 3G network on a >>>> sailboat or beach somewhere. It's not a bad life... REALLY. >>>>=20 >>> Fortunately, at least in the IETF, I don't think there have been >>> initiatives in the direction of going fast at any cost in recent >>> history, and they would be unlikely to be well accepted if there = were! >>> That is at least one place that there seems to be strong consensus. >>>=20 >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane