Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

"Bless, Roland (TM)" <roland.bless@kit.edu> Mon, 22 July 2019 16:28 UTC

Return-Path: <roland.bless@kit.edu>
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 32ACA120168 for <tsvwg@ietfa.amsl.com>; Mon, 22 Jul 2019 09:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tgKkMyJolDe8 for <tsvwg@ietfa.amsl.com>; Mon, 22 Jul 2019 09:28:31 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E675B120052 for <tsvwg@ietf.org>; Mon, 22 Jul 2019 09:28:30 -0700 (PDT)
Received: from [2a00:1398:2:4006:60b2:65d2:1d6d:5e4c] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1hpbAo-0007RW-Ll; Mon, 22 Jul 2019 18:28:26 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 83C6F420B6A; Mon, 22 Jul 2019 18:28:26 +0200 (CEST)
To: Dave Taht <dave@taht.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
Cc: "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, Sebastian Moeller <moeller0@gmx.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <D13294C4-105C-4F58-A762-6911A21A18C6@akamai.com> <CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com> <ce4b1e2d-3bc8-265c-6bcd-5a26b4dd89e9@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <AM4PR07MB3459B1173917DAFBCEB25511B9FA0@AM4PR07MB3459.eurprd07.prod.outlook.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>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <b7e01724-e7f5-cff2-9b3e-b722f981dccb@kit.edu>
Date: Mon, 22 Jul 2019 18:28:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <87ef2myqzv.fsf@taht.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1563812906.749433595
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Hc0daf9DdRrk9tabztig2UngYKM>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Mon, 22 Jul 2019 16:28:34 -0000

Hi Dave and all,

[sorry, I'm a bit behind all the recent discussion, however...]
I agree in several points here:
1) burning ECT(1) for L4S is less beneficial than using ECT(1)
   as different kind of congestion signal as proposed in SCE
2) L4S could also use the very same signal, probably in
   addition to an L4S DSCP.
3) I don't think that we need to couple a particular SCE
   implementation to the ECT(1) usage.

Regards,
 Roland

Am 19.07.19 um 17:37 schrieb Dave Taht:
> "De Schepper, Koen (Nokia - BE/Antwerp)"
> <koen.de_schepper@nokia-bell-labs.com> writes:
> 
>> Hi Sebastian,
>>
>> To avoid people to read through the long mail, I think the main point I want to make is:
>>  "Indeed, having common-Qs supported is one of my requirements. That's
> 
> It's the common-q with AQM **+ ECN** that's the sticking point. I'm
> perfectly satisfied with the behavior of every ietf approved single
> queued AQM without ecn enabled. Let's deploy more of those!
> 
>> why I want to keep the discussion on that level: is there consensus
>> that low latency is only needed for a per flow FQ system with an AQM
>> per flow?"
> 
> Your problem statement elides the ECN bit.
> 
> If there is any one point that I'd like to see resolved about L4S
> vs SCE, it's having a vote on its the use of ECT(1) as an e2e
> identifier.
> 
> The poll I took in my communities (after trying really hard for years to
> get folk to take a look at the architecture without bias), ran about
> 98% against the L4S usage of ect(1), in the lwn article and in every
> private conversation since.
> 
> The SCE proposal for this half a bit as an additional congestion
> signal supplied by the aqm, is vastly superior.
> 
> If we could somehow create a neutral poll in the general networking
> community outside the ietf (nanog, bsd, linux, dcs, bigcos, routercos,
> ISPs small and large) , and do it much like your classic "vote for a
> political measure" thing, with a single point/counterpoint section,
> maybe we'd get somewhere.
> 
>>
>> If there is this consensus, this means that we can use SCE and that
>> from now on, all network nodes have to implement per flow queuing with
>> an AQM per flow.
> 
> There is no "we" here, and this is not a binary set of choices.
> 
> In particular conflating "low latency" really confounds the subject
> matter, and has for years. FQ gives "low latency" for the vast
> majority of flows running below their fair share. L4S promises "low
> latency" for a rigidly defined set of congestion controls in a
> specialized queue, and otherwise tosses all flows into a higher latency
> queue when one flow is greedy.
> 
> The "ultra low queuing latency *for all*" marketing claptrap that l4S
> had at one point really stuck in my craw.
> 
> 0) There is a "we" that likes L4S in all its complexity and missing
> integrated running code that demands total ECN deployment on one
> physical medium (so far), a change to the definition of ECN itself, and
> uses up ect(1) e2e instead of a dscp.
> 
> 1) There is a "we" that has a highly deployed fq+aqm that happens to
> have an ECN response, that is providing some of the lowest latencies
> ever seen, live on the internet, across multiple physical mediums.
> 
> With a backward compatible proposal to do better, that uses up ect(1) as
> an additional congestion notifier by the AQM.
> 
> 2) There is a VERY large (silent) majority that wants nothing to do with
> ECN at all and long ago fled the ietf, and works on things like RTT and
> other metrics that don't need anything extra at the IP layer.
> 
> 3) There is a vastly larger majority that has never even heard of AQM,
> much less ECN, and doesn't care.
> 
>> If there is no consensus, we cannot use SCE and need to use L4S.
> 
> No.
> 
> If there is no consensus, we just keep motoring on with the existing
> pie (with drop) deployments, and fq_codel/fq_pie/sch_cake more or less
> as is... and continued refinement of transports and more research.
> 
> We've got a few billion devices that could use just what we got to get
> orders of magnitude improvements in network delay.
> 
> And:
> 
> If there is consensus on fq+aqm+sce - ECN remains *optional*
> which is an outcome I massively support, also.
> 
> So repeating this:
> 
>> If there is this consensus, this means that we can use SCE and that
>> from now on, all network nodes have to implement per flow queuing with
>> an AQM per flow.
> 
> It's not a binary choice as you lay it out.
> 
> 1) Just getting FIFO queue sizes down to something reasonable - would be
> GREAT. It still blows my mind that CMTSes still have 700ms of buffering at
> 100Mbit, 8 years into this debate.
> 
> 2) only the network nodes most regularly experiencing human visible
> congestive events truly need any form of AQM or FQ. In terms of what I
> observe, thats:
> 
> ISP uplinks
> Wifi (at ISP downlink speeds > 40Mbit)
> 345G 
> ISP downlinks
> Other in-home devices like ethernet over powerline
> 
> I'm sure others in the DC and interconnects see things differently.
> 
> I know I'm weird, but I'd like to eliminate congestion *humans* see,
> rather than what skynet sees. Am I the only one that thinks this way?
> 
> 3) we currently have a choice between multiple single queue, *non ECN*
> enabled aqms that DO indeed work - pretty well - without any ECN support
> enabled - pie, red, dualpi without using the ect identifier, cake
> (cobalt). We never got around to making codel work better on a single
> queue because we didn't see the point, but what's in cobalt could go
> there if anyone cares.
> 
> We have a couple very successful fq+aqm combinations, *also*, that
> happen to have an RFC3168 ECN response.
> 
> 4) as for ECN enabled AQMs - single queued, dual q'd, or FQ'd, there's
> plenty of problems remaining with all of them and their transports, that
> make me very dubious about internet-wide deployment. Period. No matter
> what happens here, I am going to keep discouraging the linux distros as
> a whole to turn it on without first addressing the long list of items in
> the ecn-sane design group's work list.
> 
> ....
> 
> So to me, it goes back to slamming the door shut, or not, on L4S's usage
> of ect(1) as a too easily gamed e2e identifier. As I don't think it and
> all the dependent code and algorithms can possibly scale past a single
> physical layer tech, I'd like to see it move to a DSCP codepoint, worst
> case... and certainly remain "experimental" in scope until anyone
> independent can attempt to evaluate it. 
> 
> second door I'd like to slam shut is redefining CE to be a weaker signal
> of congestion as L4S does. I'm willing to write a whole bunch of
> standards track RFCs obsoleting the experimental RFCs allowing this, if
> that's what it takes. Bufferbloat is still a huge problem! Can we keep
> working on fixing that?
> 
> third door I'd like to see open is the possibilities behind SCE.
> 
> Lastly:
> 
> I'd really all the tcp-go-fast-at-any-cost people to take a year off to
> dogfood their designs, and go live somewhere with a congested network to
> deal with daily, like a railway or airport, or on 3G network on a
> sailboat or beach somewhere. It's not a bad life... REALLY.
> 
> In fact, it's WAY cheaper than attending 3 ietf conferences a year.
> 
> Enjoy Montreal!
> 
> Sincerely,
> 
> Dave Taht
>>From my sailboat in Alameda
>