Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sun, 21 July 2019 15:10 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF19A12004D for <tsvwg@ietfa.amsl.com>; Sun, 21 Jul 2019 08:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw3xgqeaD9Uz for <tsvwg@ietfa.amsl.com>; Sun, 21 Jul 2019 08:10:03 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 192CD120020 for <tsvwg@ietf.org>; Sun, 21 Jul 2019 08:10:02 -0700 (PDT)
Received: from dhcp-8115.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:d848:d03a:c071:ad3d]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 47B0C1B00111; Sun, 21 Jul 2019 16:09:53 +0100 (BST)
Message-ID: <5D34803D.50501@erg.abdn.ac.uk>
Date: Sun, 21 Jul 2019 11:09:49 -0400
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bob Briscoe <ietf@bobbriscoe.net>
CC: "Black, David" <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>, Dave Taht <dave@taht.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <ce4b1e2d-3bc8-265c-6bcd-5a26b4dd89e9@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <AM4PR07MB3459B1173917DAFBCEB25511B9FA0@AM4PR07MB3459.eurprd07.prod.outlook.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <AM4PR07MB345956F52D92759F24FFAA13B9F50@AM4PR07MB3459.eurprd07.prod.outlook.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <AM4PR07MB3459B471C4D7ADAE4CF713F3B9F60@AM4PR07MB3459.eurprd07.prod.outlook.com> <D231681B-1E57-44E1-992A-E8CC423926B6@akamai.com> <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com> <A6F05DD3-D276-4893-9B15-F48E3018A129@gmx.de> <AM4PR07MB3459487C8A79B1152E132CE1B9CB0@AM4PR07MB3459.eurprd07.prod.outlook.com> <87ef2myqzv.fsf@taht.net> <a85d38ba-98ac-e43e-7610-658f4d03e0f4@mti-systems.com> <CE03DB3D7B45C245BCA0D243277949363062879C@MX307CL04.corp.emc.com> <e1660988-3651-0c3b-cdc1-5518f067e42e@bobbriscoe.net>
In-Reply-To: <e1660988-3651-0c3b-cdc1-5518f067e42e@bobbriscoe.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3dM727ouyz3zxvX0uqzDq6MnVCQ>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 15:10:07 -0000

I'd like to add to this what I understand as an individual ... see inline.

On 21/07/2019, 08:30, Bob Briscoe wrote:
> 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).
>
>
It would always be possible to have taken an approach that required a 
DSCP to use the "alternantive ECN semantic" . This option was debated 
when L4S was first discussed. The WG draft decided against that 
approach, and instead chose to use an ECT(1) codepoint. That I recall 
was analysed in depth.

This does not preclude someone from classifying on a DSCP (such as the 
suggested NQB) to also choose which ECN treatment to use (should that be 
useful for some reason, e.g. because the traffic is low rate). To me, at 
least, it important to allow traffic with DSCP markings to utilise the 
AQM ECN treatments.

>>>> 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 cn 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.
That is what has been described in the WG drafts since they entered 
TSVWG. I don't recall any suggested change to that decision until just now.
>>     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.
That was always possible under the "alternative ECN markings", but I 
understood the purpose was to facilitate an Internet experiment.
> Please confirm:
> a) that your RACK concern only applies in controlled environments, and 
> ECT1+DSCP resolves it
That seems more than obviously needed to me. There is a lot of traffic 
that uses some notion of timeliness for retransmission. Designing such a 
transport to be robust is tricky, but we're alreday exploring that for 
TCP and QUIC.

On the other hand, I have many times urged caution in creating 
assumptions that wit would be OK for Internet paths to somehow now allow 
more reordering. I'd like to see that happen - but I don't this 
recommendation is appropriuate.
> 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
>
Gorry
>>
>> Reminder: This entire message is posted as an individual, not as a WG 
>> chair.
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: tsvwg <tsvwg-bounces@ietf.org> 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
>