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 70DA33CB37 for ; Fri, 26 Jul 2019 17:35:40 -0400 (EDT) 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 In-Reply-To: Date: Fri, 26 Jul 2019 23:34:49 +0200 Cc: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" , Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" 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> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> <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> <1485F800-CFA5-40D6-8A49-CED09971911C@gmx.de> To: "Black, David" X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:7c/1jjhWW2JPmy4GFYGUKL85yPU+IhQX+1UNtmQYXb156KHYCuf BCyQU1WlL50psl8fqz7q0GlZfvwyFBycBTB2Lx6OlTgOR1bEHWyIuFSs0AP8QrOfYDugKZN 0edWwHo+1yg30U5GrQDG1FNV8T+l1nr3rCjtW2ccteD14CYHRnJYfP2m8JZ0tBu9debdpkz wUaFMXmp5EnJZtYZeKkiQ== X-Spam-Flag: NO 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= Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs 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: Fri, 26 Jul 2019 21:35:40 -0000 Hi David, > On Jul 26, 2019, at 21:58, Black, David wrote: >=20 > Sebastian, >=20 > Continuing with the official (officious?) response, in part as the = author of RFC 8311 ... >=20 >> 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? >=20 > 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. =20 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 >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Sebastian Moeller >> 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 >>=20 >>=20 >> [EXTERNAL EMAIL] >>=20 >> Dear David, >>=20 >> thanks for your clearing things up. I see, I should have read deeper = into the >> relevant "web" of RFCs before asking. >>=20 >> 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) >>=20 >> 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)): >>=20 >> "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." >>=20 >> 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. >>=20 >>=20 >> Now if I look at = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#page- >> 25, I see the following: >>=20 >> "A.1.4. Fall back to Reno-friendly congestion control on classic ECN = bottlenecks >>=20 >> 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]. >>=20 >> 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. >>=20 >> 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." >>=20 >> Here, the special casing of FQ-AQMs does not seem to be present, = which L4S >> RFC will have precedence here? >>=20 >>=20 >> 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? >>=20 >>=20 >> Best Regards >> Sebastian >>=20 >>> On Jul 26, 2019, at 16:10, Black, David = wrote: >>>=20 >>> Inline comment on "IETF's official stance": >>>=20 >>>> 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?), >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks, --David >>>=20 >>>> -----Original Message----- >>>> From: Sebastian Moeller >>>> 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 >>>>=20 >>>>=20 >>>> [EXTERNAL EMAIL] >>>>=20 >>>> Dear Bob, >>>>=20 >>>> 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. >>>>=20 >>>> Best Regards & many thanks in advance >>>> Sebastian Moeller >=20