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

Sebastian Moeller <moeller0@gmx.de> Fri, 26 July 2019 16:07 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 EE2BE1201C8 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 09:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 63wIZH2vH4zV for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 09:07:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 51FF6120048 for <tsvwg@ietf.org>; Fri, 26 Jul 2019 09:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564157215; bh=qi0zwc14JrhuCqL3Y0PUllL4Y8jvSEgVOz/WgLNXvAk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=kVu/zk14AanpHOVxzI/KcGkOm4Brano7rc1xsWwQ/OoW1fds8MYyN2YiVMVjlwve4 f4nFV4wf3jky2OJEIbjqQGPAAj4Jhp97+EP7ohRWK+FUb2GZxhMW7ZC/4Vajo+S/Rf uR+e3MDcWkJdRFwmr2iR66ifPVj+zivrnI/fOXX4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.180.85.154]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MF3DM-1hbdTT0Wa0-00FPIM; Fri, 26 Jul 2019 18:06:55 +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: <CE03DB3D7B45C245BCA0D243277949363063EA1C@MX307CL04.corp.emc.com>
Date: Fri, 26 Jul 2019 18:06:52 +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: <1485F800-CFA5-40D6-8A49-CED09971911C@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>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:Yfu1HOADIxKe4a1njkPhWyoANoQ83Cnf9GjCdHYWB62nApTQJy9 dvZyufAKRiT+LWf0rYeAvOctSNe6HWTcY8FMmRC/J5E5jawlA7oS5tSKTPVRQqKorXcSBHN 3nDmziWMACh1t4PANPdUwSVIKOq2EHYl7RL1NZSBM58xLoW9M15fz8T5tf0iNiYsnHFFnxe CpX28wUlDoEB6AHc0mxNQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:QeaqRFys1Is=:bgF6DNIS61JboM5vZ2Fu55 Njltio3i342UHilzpVGW/zcgNB+ceYf/liYmIHXqVpAZUxohpAYQFXHRfMkCAZIxQRbgqTGMB 3CEuhW9bpIMX9qxshPzlqDoqqMnNVoMLsSGRWooJBeLftIuAXR9Uz+ssBeFFFjd7dauV9QWVv WG30N73Z4vm6g6izv9iyPFwU7J4W57/hT3hkeG0j5p3EobRxdVHQ8fY4Yafzv6X849pcffDSL NAwjqzjsC5kcYxQImgMWQZ8GxHqtPI4RsuB9ccvy2VhHkoV8fb9yk3YfXmrNVDFZUx2JG1BnI 4DaH8581lTH6C1N8CvUio5kmRmTRo2zObJysgG5iV1m+dQVPLcYuyN9kNtntwwORBKU7BgfKM e1x2vFft+ODiI50dK72LwHNqOYvT9F0zsbOXq4acpbywWKi8hY6sLM5suque0t9jh/FsGMnWe +VaRGWT9O/1GyFNZhc0TdAbtTvPbLSLG7SxA0OYIRLIs14Xd0YtCuB4ZUgxloAe4I6jbUeZxq Sxe4a6okFDrlt2EHYd/cqoEWao+hez5LJaVdMLsLzZJiM0AuYtgnwGE6Z7L4dux5huXQ6uF0H MN2HjQEP0qzBEfnfMSGYv0EuqJYwMfoyLJLhPduvpwUOQUlpArBRptfc3OuJsIzELLXFealvc 4nTRpc5bF5VOxL1AXNlYDZmff6Fg6l5tmi4jZQTuOfFnJLeVTTCufzXDO8SYsdiE0bJqczmnS MHmu5lnTYhKyKqVcvP/c5/5CYR1zo5MJi7RnoR3+JnAUiU7kocVUbuBogml18aj4WM1d32DUe H4KfKiNDJOpYz+MLy9nTnx4+17xZJoO4uUJIz3iWmR700OCOHqCD6GaoxWF2ZPBge6pu2sLIN 0Kt9tRKRSPst6GWOK63Z5tSoJzg48JmD/qCHRYBT+8wUunkolADlWnYyYvn2SV5gatOtb5MDW uD4xJn3FnPUpxTTqw+OrjiV0WAWkvk3obGzGBPfSz1R/lr95BFosELoXOj4Oe8M7nYdJbesPC VNatPF/7O2WOWY4kSwOkEC/T/SVimWg4SjgtZba+XDJLDH/Kpq16mWRtctABAhGqCPWIYBtzU kj7l6Pv7REUKGg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1AHP88IYOuN_9Y3kMzbHgvGM5qE>
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 16:08:02 -0000

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