From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DD15F3B2A4 for ; Thu, 29 Nov 2018 03:08:49 -0500 (EST) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gSHNP-0004Po-Q3; Thu, 29 Nov 2018 09:08:47 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gSHNM-000EW2-4A; Thu, 29 Nov 2018 09:08:47 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Thu, 29 Nov 2018 09:08:42 +0100 Cc: Jonathan Morton , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 360B00F47009F2910592838DE16FC2C7C3F32EC5 Subject: Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 08:08:50 -0000 > On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote: >=20 > On Thu, 29 Nov 2018, Jonathan Morton wrote: >=20 >> You are essentially proposing using ECT(1) to take over an intended = function of Diffserv. >=20 > Well, I am not proposing anything. I am giving people a heads-up that = the L4S authors are proposing this. >=20 > But yes, you're right. Diffserv has shown itself to be really hard to = incrementally deploy across the Internet, so it's generally bleached = mid-path. Rumours, rumours. Just like "SCTP can never work", all the Internet must = run over HTTP, etc etc. For the "DiffServ is generally bleached" stuff, there is pretty clear = counter evidence. One: = https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523e= bb9482c6869e98b/Barik18ITC30.pdf And another: = http://tma.ifip.org/wp-content/uploads/sites/7/2017/06/mnm2017_paper13.pdf= >> In my view, that is the wrong approach. Better to improve Diffserv = to the point where it becomes useful in practice. >=20 > I agree, but unfortunately nobody has made me king of the Internet yet = so I can't just decree it into existance. Well, for what you want (re-ordering tolerance), I would think that the = LE codepoint is suitable. From: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 "there ought to be an expectation that packets of the LE PHB could be = excessively delayed or dropped when any other traffic is present" ... I think it would be strange for an application to expect this, yet = not expect it to happen for only a few individual packets from a stream. >> Cake has taken steps in that direction, by implementing some = reasonable interpretation of some Diffserv codepoints. >=20 > Great. +1 > I don't know if I've asked this but is CAKE easily implementable in = hardware? =46rom what I can tell it's still only Marvell that is trying = to put high performance enough CPUs into HGWs to do forwarding in CPU = (which can do CAKE), all others still rely on packet accelerators to = achieve the desired speeds. >=20 >> My alternative use of ECT(1) is more in keeping with the other = codepoints represented by those two bits, to allow ECN to provide more = fine-grained information about congestion than it presently does. The = main challenge is communicating the relevant information back to the = sender upon receipt, ideally without increasing overhead in the TCP/IP = headers. >=20 > You need to go into the IETF process and voice this opinion then, = because if nobody opposes in the near time then ECT(1) might go to L4S = interpretation of what is going on. They do have ECN feedback mechanisms = in their proposal, have you read it? It's a whole suite of documents, = architecture, AQM proposal, transport proposal, the entire thing. >=20 > On the other hand, what you want to do and what L4S tries to do might = be closely related. It doesn't sound too far off. Indeed I think that the proposal of finer-grain feedback using 2 bits = instead of one is not adding anything to, but in fact strictly weaker = than L4S, where the granularity is in the order of the number of packets = that you sent per RTT, i.e. much higher. > Also, Bob Briscoe works for Cable Labs now, so he will now have = silicon behind him. This silicon might go into other things, not just = DOCSIS equipment, so if you have use-cases that L4S doesn't do but might = do with minor modification, it might be better to join him than to fight = him. Yes... Cheers, Michael