From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A7D293B29E for ; Sun, 21 Jul 2019 08:30:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u/0aAndFgP5BIG3FrjjKJ0nSakusCiYlgkIAW1GBamk=; b=CIn0d0x5D9semS2GxlqZRo4ayv lNtpYbkdDfMPZ3e8TyUdonr5prKLXlTwgU8K+0QUyp9TLK3ifamR/kF5+6FUVjf7q3fZMuf1WgEVf AUKuVCJ6yFgnX2i/jtq5DC+QpiMkuf3LXAh+7r5xtCSMRSyTVnlMkj3kQVJAj1n3pUWfQaOZ3HHYJ p9j5tNiz5ZXgxJP2Jx2FdeZIOW108/8D3LuEE1i2O1+dJLF8abVomFCPF4PEhX6Dn1dwzjbmw9G7N h2tikhOWixXYjOcxQ8NeFKfpLLW4JW6SjLh3cBshlsUnbs+XVzQQ942Ng9dSZOW7InLd1Ob5yn9vF SZwmMOKw==; Received: from modemcable186.232-83-70.mc.videotron.ca ([70.83.232.186]:60410 helo=[192.168.0.161]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpAyw-0006pF-0z; Sun, 21 Jul 2019 13:30:26 +0100 To: "Black, David" , Wesley Eddy , Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" Cc: "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" 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> From: Bob Briscoe Message-ID: Date: Sun, 21 Jul 2019 13:30:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net 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 12:30:27 -0000 David, On 19/07/2019 21:06, Black, David wrote: > Two comments as an individual, not as a WG chair: > >> 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). > > 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. 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. 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). >>> 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). > > 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. I am trying to focus the issues list, which I would hope you would support, even without your chair hat on. Bob > > Reminder: This entire message is posted as an individual, not as a WG chair. > > Thanks, --David > >> -----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 >> >> >> [EXTERNAL EMAIL] >> >> 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? >> >> >>> 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. >> >> >>> 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? >> >> 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. >> >> >>> 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 >> >> >>> 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. >>> >> 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. >> > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/