Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs

Sebastian Moeller <moeller0@gmx.de> Fri, 26 July 2019 21:35 UTC

Return-Path: <moeller0@gmx.de>
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 39F581201E7 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 14:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 b6zeZWxmGRUK for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 14:35:44 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id E6D95120241 for <tsvwg@ietf.org>; Fri, 26 Jul 2019 14:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564176892; bh=JZLX3cYU2GcfFqUkGQkxQhElUiKRx3S45Yk8a1OTdtI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ipdqS91LyBlB39BGlTw7U4GXt3ztOc3ngLyTMJAJnWubmReuN0qVyyItjHCQNhKpv QJOSftcOCxYwSdIr+OKTw2zySxvb2fI3k0nnSKkDbULklgOa+djVzk/pj6zMc0IyZz SSrFNgbnXaVwDFeuWNMUjQdQqjwDyhq9uH7SwodI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.181.30.162]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWBpJ-1hswBJ0Nbd-00XHV7; Fri, 26 Jul 2019 23:34:52 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363064000A@MX307CL04.corp.emc.com>
Date: Fri, 26 Jul 2019 23:34:49 +0200
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Dave Taht <dave@taht.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <79BFBD62-9962-4946-BBAD-7A58C1FB9D74@gmx.de>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.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> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> <E031B993-DAAF-4BE4-A542-33C44310D6E9@gmx.de> <77522c07-6f2e-2491-ba0e-cbef62aad194@bobbriscoe.net> <619092c0-640f-56c2-19c9-1cc486180c8b@bobbriscoe.net> <3A454B00-AEBC-48B6-9A8A-922C66E884A7@gmx.de> <21E40F44-2151-4565-970E-E1CEBE975036@gmx.de> <CE03DB3D7B45C245BCA0D243277949363063EA1C@MX307CL04.corp.emc.com> <1485F800-CFA5-40D6-8A49-CED09971911C@gmx.de> <CE03DB3D7B45C245BCA0D243277949363064000A@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:7c/1jjhWW2JPmy4GFYGUKL85yPU+IhQX+1UNtmQYXb156KHYCuf BCyQU1WlL50psl8fqz7q0GlZfvwyFBycBTB2Lx6OlTgOR1bEHWyIuFSs0AP8QrOfYDugKZN 0edWwHo+1yg30U5GrQDG1FNV8T+l1nr3rCjtW2ccteD14CYHRnJYfP2m8JZ0tBu9debdpkz wUaFMXmp5EnJZtYZeKkiQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:U4pjMbFs6L8=:/MfkaAMw2ob0qG23UXF4bt D48rKg/o7K3ORFZIShBmKUpXJF9ZNJw2xtKHB9jwJjjeJErTBJ97Ip0+wQmqMl7jrh1XLSter ZGW57YV3jyFkFTRr59mp2Cd730eyF/DJ54cq/cPYxNuLRawsY2mUFgKQbePfBlCuklORVeFXK wE4fTe4CBlIAzGh7ArXFfCrY6AAf9uLFwardkCQ8iNbpRgpsz6BnTaZsyTyZ4wnVH0HEcebBc VjGznZNcJE+Aj0S0B73wPXbsKwm/5jtE9qDR1Q25uP3cfZmUnRoGp4e5It8RHymjQfwnrNCID Z6sw9vE7rqtRSgN+vS5dfpN8SThHJ3KVhEWkwC0RRhhcClUHql3/p0WC0YIApjAKh0LIQp4e7 UJrn6HZppXesfD1Lg66orB4RmV8TTA9vRbWVzLNYyqOPJHShWeVJ/UcQIMJmUW4eY/A4l7QPx luwi/uvVX7soTfsCHnfq1DfsZbKxXUYVfk4ywnmFWxf8lCHUwD6rbFBDMn+KE/e1UafFteDXt 7q26PKtV/TSogzw3Gnqo5SCCgwTy07/alij1c/OOteNGZ21XIRXaRxDJVv5QHYTeir0En06yl TDLUKLWyrAEwR6B5ftE6cH9WkzEi/apusjym0VdyPuNz7wSHB0mkjQOzPWvVMR0EiztFiEkSa TPD+bhD82BsL+XxplhnueZmoxVt+OS0OegVSWAamDslv/OFn4Gend+Ay1lCf4eMRTEBJWPMTa INDWx8sxduSognIKC/tjnMu4WCVnrS0WvnNdgkRX7LlIGCZzsrWPfY9N5ntP50fG4CpUHrqvd B1ctFiYpnYySgXp2NaJmPySeEfrDYjXyhPC2+MUg5MIV4FtlkwPWR3s+HC8qPtyJ/TIEewPqH YiVbXGR35kCfZK0BpYqqep7w2JDQw1Qs44HRfphoX0aUjLh4dDUvW0AbzMyd4iCrFz1ESEjzf /oDHJIg1LRrfHC9O8T8M+co+1h8dvygzepYC1YirKZ4x6p63OwL3cGOPq+Sw9Z1qClm3hFZc2 rWnmpRYevbhy7F74Nxq6QJsATRfV/5RF8ZNjjBZTgg3WxB3PU4GWU0GXvdCcl/8xcI8DP6QEE TWo3yvTyBWgZh8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LkJlIzjHs9Uf4bKXhKrdncZr9zc>
Subject: Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs
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: Fri, 26 Jul 2019 21:35:58 -0000

Hi David,


> On Jul 26, 2019, at 21:58, Black, David <David.Black@dell.com> wrote:
> 
> Sebastian,
> 
> Continuing with the official (officious?) response, in part as the author of RFC 8311 ...
> 
>> Am I correct in interpreting the following  sentence from RFC 8311:
>> "ECN experiments are expected to coexist with deployed ECN
>>   functionality, with the responsibility for that coexistence falling
>>   primarily upon designers of experimental changes to ECN."
>> as meaning, that L4S will need to implement the long discussed fall-back to
>> RFC3168 compliant responses to CE marks, if a RFC3168 AQM is detected as
>> being active on a path, and that L4S endpoint need to closely monitor for signs
>> of RFC3168 behavior?
> 
> As RFC 8311 is a Proposed Standard RFC, the text quoted from that RFC "represents the consensus of the IETF community" (from "Status of This Memo" boilerplate in RFC 8311), and hence needs to be respected in the design of the L4S experiment.  

	Ah okay, thanks for clearing that up.

> I think the specific implications of that RFC 8311 text on the L4S experiment design are ultimately a technical matter for the WG to determine

	Is there really any wiggle room? "the responsibility for that coexistence falling primarily upon designers of experimental changes to ECN" seems pretty explicit to me...

> , but ignoring the quoted text would not be acceptable (and does not appear to be occurring).

	Ah okay, I was under the impression, that there very much was an open question whether peaceful co-existence with RFC3168 compliant AQMs was actually a requirement or whether that could be negotiated away at the green table. Great that we agree that this issue on interoperability with the existing RFC-compliant internet is not optional ;)


Best Regards
	Sebastian

> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: Friday, July 26, 2019 12:07 PM
>> To: Black, David
>> Cc: Bob Briscoe; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave Taht; De
>> Schepper, Koen (Nokia - BE/Antwerp)
>> Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> Dear David,
>> 
>> thanks for your clearing things up. I see, I should have read deeper into the
>> relevant "web" of RFCs before asking.
>> 
>> Am I correct in interpreting the following  sentence from RFC 8311:
>> "ECN experiments are expected to coexist with deployed ECN
>>   functionality, with the responsibility for that coexistence falling
>>   primarily upon designers of experimental changes to ECN."
>> as meaning, that L4S will need to implement the long discussed fall-back to
>> RFC3168 compliant responses to CE marks, if a RFC3168 AQM is detected as
>> being active on a path, and that L4S endpoint need to closely monitor for signs
>> of RFC3168 behavior? I ask because section 4.1 fails to put in those safe-guard
>> clauses explicitly (in my reading this effectively says anything goes, as long as it
>> is defined in its own RFC)
>> 
>> Now looking at the L4S RFC I see (https://tools.ietf.org/html/draft-ietf-tsvwg-
>> l4s-arch-04#page-21 (assuming that this is one of the RFCs required to allow the
>> exemption according to RFC8311)):
>> 
>> "Classic ECN support is starting to materialize on the Internet as an
>>   increased level of CE marking.  Given some of this Classic ECN might
>>   be due to single-queue ECN deployment, an L4S sender will have to
>>   fall back to a classic ('TCP-Friendly') behaviour if it detects that
>>   ECN marking is accompanied by greater queuing delay or greater delay
>>   variation than would be expected with L4S (see Appendix A.1.4 of [I-D.ietf-
>> tsvwg-ecn-l4s-id]).
>>   It is hard to detect whether this is
>>   all due to the addition of support for ECN in the Linux
>>   implementation of FQ-CoDel, which would not require fall-back to
>>   Classic behaviour, because FQ inherently forces the throughput of
>>   each flow to be equal irrespective of its aggressiveness."
>> 
>> Which I believe to be problematic, as it conflates issues. The problem with L4S-
>> CE response on non L4S-AQMs is that it will give L4S flows an unfair and
>> unexpected advantage, so L4S endpoints should aim at detecting non-L4S AQMs
>> on the path and not (just) "that ECN marking is accompanied by greater queuing
>> delay or greater delay variation than would be expected with L4S". Sure delay
>> variations can be a eans of trying to detect such an AQM, but this text basically
>> gives L4S the license to just look at RTT variations and declare victory if these
>> stay below an arbitrary threshold.
>> 	Also I voiced concerns about the rationale for excluding RFC3168 FQ-
>> AQMs from this fall-back treatment, and gave an explicit example of a system in
>> use (post-true bottleneck ingress shaping) that I would like to see to be tested
>> first. This should be easy to test (and as far as I know these tests are planned if
>> not already done) so that the RFC can either be amended with a link to the data
>> showing that this is harmless, or changed ot indicate that the fall-back might
>> also be required for FQ-AQMs under certain conditions.
>> 
>> 
>> Now if I look at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#page-
>> 25, I see the following:
>> 
>> "A.1.4.  Fall back to Reno-friendly congestion control on classic ECN bottlenecks
>> 
>>   Description: A scalable congestion control needs to react to ECN
>>   marking from a non-L4S but ECN-capable bottleneck in a way that will
>>   coexist with a TCP Reno congestion control [RFC5681].
>> 
>>   Motivation: Similarly to the requirement in Appendix A.1.3, this
>>   requirement is a safety condition to ensure a scalable congestion
>>   control behaves properly when it builds a queue at a network
>>   bottleneck that has not been upgraded to support L4S.  On detecting
>>   classic ECN marking (see below), a scalable congestion control will
>>   need to fall back to classic congestion control behaviour.  If it
>>   does not comply with this requirement it could starve classic
>>   traffic.
>> 
>>   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."
>> 
>> Here, the special casing of FQ-AQMs does not seem to be present, which L4S
>> RFC will have precedence here?
>> 
>> 
>> Anyway, am I correct in interpreting all of the above as a clear an unambiguous
>> requirement for L4S components like TCP-Prague to implement RFC3168-AQM
>> detection and fall-back to appropriate behavior before being given the
>> permission for usage on the wider internet?
>> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>>> On Jul 26, 2019, at 16:10, Black, David <David.Black@dell.com> wrote:
>>> 
>>> Inline comment on "IETF's official stance":
>>> 
>>>> The first option seems highly undesirable to me, as a) (TCP-friendly) single
>> queue
>>>> RFC3168 AQM are standards compliant and will be for the foreseeable future,
>> so
>>>> ms making them ineffective seems like a no-go to me (could someone clarify
>>>> what the IETF's official stance is on this matter, please?),
>>> 
>>> The IETF expects that all relevant technical concerns such as this one will be
>> raised by participants and will be carefully considered by the WG in determining
>> what to do.
>>> 
>>> That was the technical answer, now for the official [officious? :-) ] answer ...
>> the current L4S drafts do not modify RFC 3168 beyond the modifications already
>> made by RFC 8311.  If anyone believes that to be incorrect, i.e., believes at least
>> one of the L4S drafts has to further modify RFC 3168, please bring that up with a
>> specific reference to the text in "RFC 3168 as modified by RFC 8311" that needs
>> further modification.
>>> 
>>> Thanks, --David
>>> 
>>>> -----Original Message-----
>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>> Sent: Friday, July 26, 2019 6:20 AM
>>>> To: Bob Briscoe
>>>> Cc: Black, David; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave Taht;
>> De
>>>> Schepper, Koen (Nokia - BE/Antwerp)
>>>> Subject: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
>>>> 
>>>> 
>>>> [EXTERNAL EMAIL]
>>>> 
>>>> Dear Bob,
>>>> 
>>>> we have been going through the consequences and side effects of re-defining
>>>> the meaning of a CE-mark for L4S-flows and using ECT(1) as a flllow-
>> classifying
>>>> heuristic.
>>>> One of the side-effects is that  a single queue ecn-enabled AQM will CE-marl
>> L4S
>>>> packets, expecting a strong reduction in sending rate, while the L4S endpoints
>>>> will only respond to that signal with a mild rate-reduction. One of the
>>>> consequences of this behaviour is that L4S flows will crowd out RFC3168 and
>>>> non-ECN flows, because these flows half their rates on drop or CE-mark
>>>> (approximately) making congestion go away with the end result that the L4S
>>>> flows gain an undesired advantage, at least that is my interpretation of the
>>>> discussion so far.
>>>> Now there are two options to deal with this issue, one is to declare it
>>>> insignificant and just ignore it, or to make L4S endpoints detect that condition
>>>> and revert back to RFC3168 behaviour.
>>>> The first option seems highly undesirable to me, as a) (TCP-friendly) single
>> queue
>>>> RFC3168 AQM are standards compliant and will be for the foreseeable future,
>> so
>>>> ms making them ineffective seems like a no-go to me (could someone clarify
>>>> what the IETF's official stance is on this matter, please?), b) I would expect
>> most
>>>> of such AQMs to be instantiated close to/at the consu,er's edge of the
>> internet,
>>>> making it really hard to ameasure their prevalence.
>>>> In short, I believe the only sane way forward is to teach L4S endpoints to to
>> the
>>>> right thing under such conditions, I believe this would not be too onerous an
>> ask,
>>>> given that the configuration is easy to set up for testing and development and
>> a
>>>> number of ideas have already been theoretically discussed here. As far as I
>> can
>>>> see these ideas mostly riff on the idea that such anAQM will, under
>> congesation
>>>> conditions, increase each ftraversing flow's RTT and that should be quickly
>> and
>>>> robustly detectable. I would love to learn more about these ideas and the
>> state
>>>> of development and testing.
>>>> 
>>>> Best Regards & many thanks in advance
>>>> 	Sebastian Moeller
>