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

Sebastian Moeller <moeller0@gmx.de> Fri, 26 July 2019 10:21 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 389EF1202E2 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 03:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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] 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 Rs5Q7bxNDLi6 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 03:21:10 -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 92F541202DF for <tsvwg@ietf.org>; Fri, 26 Jul 2019 03:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564136419; bh=sfJtmXhPk59j0mx4QWMXkgtF3VVWcxGWKQjRz/aJjfo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=CijX3KkHw6YfhEZqx3ifkH8wr25+WJms3LIZNgbSyTaxlbJrGz05Tlt+Y/3WAdJtp xU3qMC036mwhmpey3R5Zi46ueplvD9HutRJjrcYNDtoREvmy15ABN+DZyzRsA28zik XWZ4gUGV+zVsuJqXM3qi+0MGGkOMFYyg/ubgxKMk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.180.85.154]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MGBB1-1hebGG36kJ-00F9r2; Fri, 26 Jul 2019 12:20:19 +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: <3A454B00-AEBC-48B6-9A8A-922C66E884A7@gmx.de>
Date: Fri, 26 Jul 2019 12:20:16 +0200
Cc: "Black, David" <David.Black@dell.com>, "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: <21E40F44-2151-4565-970E-E1CEBE975036@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>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:OQIz22h3Wp31PPGTlUmOJuBCXLj6PaA89OOwEt+uFLX4AUP1Cpz 7kkxh0DmdqobdwNTwPDPAUdtm3spg5rpElo9tUq6ljoSueoCkOj4C5LS2IsNwswDd0D4HF3 sSGIw5LWMaiqp56kcysUSfmglM4aEjXqkzNw+xFTSDc+VUwmDVb9bbuhtPtoL6OnptIY7za V2oN8gS7dhfGg17D+Gz+Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:PwY0J6q8LNQ=:nn+2YFczNd+oCXPwUm4J2i EMXuwcfB3XFg/D/lwWAQR/x3s+xIpboY5mG05FGOMYjeX7cKL5WEAAyrreusZhaypjRu/ETx/ GBPegp0zEXwHiwVbSxFUCv6Rpr+XQ5KqRTZeQ1uVs5Yko9auTsa6rnaP1T6TIJJVCwHlWTXRD gjTc/FTGXDhlWaAx6f2K9OuLJHjFYXQs8GqryN0+uJRAT+gCNppnP7NNA/yUgpv1OOPp7xJ05 4Gi9hlvZgZrtz08rwZEKQMrXa1vIzrP2WVQsTtaWu5BuSbLRWry6hCz+sGJuwrzy4Pz45Nmhw 7DYW9NRcd4LWKUMN0/zoEZz+VinKbFgPBkN1ycZsPOtq6QaQxGY06KjgA9DnJQ5MXb6hRBsJI fmMJwgdKHbvCCkpYKU1I7rtg2s8ETMIk3RUoAwPR6p2wBaUKhKpqAiaJiGBHX/BecNiA9K0Aq sghgo4AFN8knbtaD/zoDBjZlCm/YUo+/rsEujm2OA5+3VQ5+H2whwk0Y0e71bUsd8RH154j/m PHQAqavFbR0i+TmXGvKUQ3wM2ZLhlhUezhyudyKkNcneiWkaurahsbZ1e3gl8M548JlWuDLsr FunXthfUVFMGyC1O8noYgAKUsNw4GOqJoWQI4xjBWhjR6Dkp6MX/9IwMHHtZvRoRziqOPNCmS xTrWB0ynuFdgYLPXgw1cynI8aSRpPmN6h60iLEZaLKADP6gA+AwtH1isuZFxmtMRR+9sgMyZU OBoVbIiDRaEBaMHbn0DPY3kr/b9Od0V8H/uC2t8kJgwFzyphyymjj2ACOP1EOL6aF1wYldmwR pxN+LTE73nEjL4R+l71c4swaUjadhxzoDU1fIdOipVQtonqbWyhcBLGK7zfOSH/5IrmZ93UgM 0DellNBeFurwJ4Dt9KxG7wMu21azl/RbFUHTvrG9D8TbK2suRL0Xxhi/174Z6k3z3NDWk8ZQH 4JnTrNuIVONcvpaotjxMDqKv2A5EXZR/shZMOiw3HhjvnvLvcgAuFHp54nvMr91ty4qtqEaep y3E7VWUD/z/MtdK6mQvkk1GLAQPeCd+9d5KK8QvRGs3hCqdyZ5b7XqTe2KY1tegW5yZGw4CK/ mmkWTkDEoWKIA4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/C8g1ROGWsx5XBRs3U92Gm9mNmQw>
Subject: [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 10:21:11 -0000

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