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 063723CB38 for ; Fri, 26 Jul 2019 06:21:06 -0400 (EDT) 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 In-Reply-To: <3A454B00-AEBC-48B6-9A8A-922C66E884A7@gmx.de> Date: Fri, 26 Jul 2019 12:20:16 +0200 Cc: "Black, David" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" , Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" 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> <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> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:OQIz22h3Wp31PPGTlUmOJuBCXLj6PaA89OOwEt+uFLX4AUP1Cpz 7kkxh0DmdqobdwNTwPDPAUdtm3spg5rpElo9tUq6ljoSueoCkOj4C5LS2IsNwswDd0D4HF3 sSGIw5LWMaiqp56kcysUSfmglM4aEjXqkzNw+xFTSDc+VUwmDVb9bbuhtPtoL6OnptIY7za V2oN8gS7dhfGg17D+Gz+Q== X-Spam-Flag: NO 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= Subject: [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 10:21:07 -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=