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 376413B29E for ; Mon, 25 Mar 2019 05:52:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553507531; bh=IHKK6lBzppN5un8BpAs8bHjOKSy8i7omnodVmL4ANMs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P8nmWAfz/Fh829I0NJ+5h/f0+Gogri5OaPvW7IcUNocK1S5qmVIyI7YTSqIyhIW5s MiwoT6Hs2mobIbkhGESezh7nEnPHJw54/L8OWXvxTIahZQ5IxQDAwkUAMyNkmTp4Cx xvHoLlFSHdH2rtsEC+sxzsfltWwK2Bw/JN8uOwjU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LkOeR-1gXewS2wqR-00cO15; Mon, 25 Mar 2019 10:52:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 25 Mar 2019 10:52:10 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <71EB61FA-C296-49FA-A191-0998FA66B097@gmx.de> References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> To: Luca Muscariello X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:ackYrMnPaZooCm2t84MYAos5ddqaddUhsM8pa5LZmGQ1ablEa6V 8ZEklKpYvfmu+euhBnJj/ghzuNGTNpL+jyhZDIWfvvbyzRSBF2XaA8wNK49E2ufu79O2pQT 3/n/wGJK6Jqp8Qh2uOgfJHdC8T5gQ2iM8kTRPGu4zif39AhrAFE2E5d8vLPYhd2VycYmped +8l2KUX3Wk2lRjitCmoYg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CX7YiQp/K84=:KyTVXBCD9xx7qQLuay4X+6 oeoAm1p+SJXwWPC5JKtZIwMK1Ubxxej30MJQOKyeBhF8rq7pjApLhrI9RcMIksf6QpztGUeEs 8DtuHkkFyeqHuA/uiFJV+eNdgQBHqBZ8rCSvFDDofXJb5+NHTo4/McKpiSBwt0D4N//0q5ltw o8ZZhnmU2s19MfNA27GLRyiTaAdcOcfpCsLN+LO3IAbFSFQJ688BOeU2m3sVsdwp8Ud33xrH5 DcV2Q1+xGJIt5qGBApm1CFWAGY0X6p7JMXmCoGEw7cdBwwHjsfQtH6TaYOpnVC72kCNQG5RLO kw3lxN3GM3GsX6FnM7cg00Sh7nsLyQlyQtns8AbrJCFbxX2f8ycdoXGEQtrA03NiyM67+oj65 e0GGVoSkQQ2dvaMDme2Zq0y82GiuRO5/N7uf2u5/lk6gQZ9dZ4SSCH2hXmRoFgMOy/ukqCU64 DVZv3BBSxFk/2xTgECVab/y9jQ91K3InXbomJ4GQv4+qttLW5OvFGDgKbq9x692jBtThtj6+n bhJBIdzbYT2JbhSaZP/Tccl8TcfmCS6qD1zMZbYZU8OITEErlDQw3ynIwHi+yFnFWPBOkLPU4 VpFx912OIjTbesole60UEj7UDdUaiOCw/BAHgH6PrL82JX30zJhJqzs0dngCp+wP+lpAkFF9A lrrv3wO7tfobHrxfAj+Cpt7WprzrQ+pwq4eWLu1xQ4laUk4jdngGvSespkg/KAzvnDxIxj/vi FIdtSz9R5w5cjJZFySZGZFul54ZJbxaA9d4OtLgaLsXxSpqZzcP0OOqV2V0/4bZIZWTWbwSnO dKKeXLLQ5m2oMXaRNZ2XwbQTgalBxgdGQqBX7pMg88aopvBX5yJKFHiBqxJ4Oipv/PRk68kMR rXA9agPE52FHQcpKDJ5NA9qDvGuAWReH+mqT4ccVzbf83rGM1rNINWkX9ptvhLA6IGBsmB2nd FeeJtnt6/fw== Subject: Re: [Ecn-sane] FQ in the core 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: Mon, 25 Mar 2019 09:52:13 -0000 Hi Luca. > On Mar 25, 2019, at 10:17, Luca Muscariello = wrote: >=20 > We've had this discussion multiple times. >=20 > - You do not need FQ everywhere and depending on=20 > the case you can do approximations of that. >=20 > - What I believe you always need is flow-awareness. >=20 > - There are already implementations of dual-queue systems in DC = switches such as the Cisco nexus 9k. >=20 > - The dualQ system in docsis is the wrong way to implement a = flow-aware system with two queues.=20 > For many reasons including, but not limited to the fact that dualQ to = work makes assumptions about the behaviour of the end-points. > A flow aware queuing system should not be sensitive to some sort of = compliancy of the end-points. +1 > You cannot trust the end-points and the protection system should not = discriminate good vs bad based on a badge carried by the packets. Exactly my sentiment, "speak softly, and carry a big stick" or = "Doveryai, no proveryai" in any way do not give special treatment just = because someone asks nicely, in other words "Pedo mellon a minno" = considered harmful. >=20 > - I also believe dualQ fails to achieve its goal under current and = future traffic patters. I would very much like to test that, maybe the VMs intended as = one of the hackathon's goals will make playing with that easier. >=20 > - The approach described in this paper also works for 2 queues only = and makes no assumption about the end-points. > It does not require marking at all. >=20 > James Roberts et al. > Minimizing the overhead in implementing flow-aware networking.=20 > In Proceedings of the 2005 ACM symposium on Architecture for = networking and communications systems (ANCS '05).=20 > DOI: https://doi.org/10.1145/1095890.1095912 > https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf >=20 > - There is not one TCP, there is no one single transport in the wild. = There are many and there will be many more. > The docsis specs makes the assumption that to be a good guy you must = be part of one Church. The one specified. > This is a very religious assumption about end-points' behaviour. > All the others are bad guys. I'm the only one who sees this as deeply = wrong? I tried to make this point in the past, LLLLS seems to = accidentally position itself as the be-all end-all of internet transport = and if we know one thing about the future it is its crappy = predictability in the long run... >=20 > - Almost 10 years ago I built a FQ prototype on an NPU based on Cavium = with Alcatel-Lucent (the team was based in Paris).=20 > That was supposed to be an ALU7750 target. The problem was that not a = single ISP was even aware of the topic. Nobody was asking for it. > It's a chicken and egg problem Mikael. If you do not ask loudly nobody = builds it. How could something like this be priced? On a port by port = basis, like vectoring for VDSL2, then ISPs could still offer something = like that as an extra they could sell for latency sensitive customers? >=20 > - I also built with Ikanos in 2010, a FQ prototype in their MIPS based = SoC. 32 queues for the France Telecom livebox > and it worked. Ikanos was later acquired by Qualcomm and that SoC is = not used anymore in favour of Broadcom. Ah, this is why ikanos disappeared... >=20 > Hope this helps to make progress in the discussion All, quite interesting, gracie! Best Regards Sebastian >=20 > Luca >=20 >=20 >=20 >=20 >=20 > On Mon, Mar 25, 2019 at 8:55 AM Dave Taht wrote: > I don't really have time to debate this today. >=20 > Since you forked this conversation back to FQ I need to state a few = things. >=20 > 1) SCE is (we think) compatible with existing single queue AQMs. CE > should not be exerted in this case, just drop. Note that this is also > what L4S wants to do with the "normal" queue (I refuse to call it > classic). >=20 > 2) SCE is optional. A transport that has a more agressive behavior, > like dctcp, should fall back to being tcp-friendly if it > sees no SCE marks and only CE or drop. >=20 > 3) At 100Gbit speeds some form of multi-queue oft seems needed. (and > this is in part why folk want to relax ordering requirements). So some > form of multiple queuing is generally the case. At the higher speeds, > DC's usually overprovision anyway. >=20 > 4) The biggest cpu overhead for any of this stuff is per-tenant (in > the dc) or per customer shaping. This benefits a lot from a hardware > assist. (see senic). I've done quite a bit of DC work in the past 2 > years (rather than home routers), and have had a hard look at the > underlying substrates for a few multi-tenant implementations.... >=20 > 4) "dualq" hasn't tried to address the fact that most 10Gbit and > higher cards have 8 or more hardware queues in the first place. >=20 > 5) Companies like preseem are shipping transparent bridges that do > fq_codel/cake on customer traffic. >=20 > I've long been in periodic negotions with makers of "big iron" like, > for example, the new 128 core huwei box and others I cannot talk about > at the moment, to get so far as an existence proof. >=20 > So I'd like to kill the meme that SCE requires FQ, at least, for now, > until after we do more tests. >=20 > As for FQ everywhere, well, I'd like that, but it's not needed in > devices that already have sufficient multiplexing. >=20 >=20 >=20 >=20 >=20 > On Mon, Mar 25, 2019 at 8:16 AM Mikael Abrahamsson = wrote: > > > > On Sun, 24 Mar 2019, Sebastian Moeller wrote: > > > > > =46rom my layman's perspective this is the the killer argument = against the > > > dualQ approach and for fair-queueing, IMHO only fq will be able to > > > > Do people on this email list think we're trying to trick you when = we're > > saying that FQ won't be available anytime soon on a lot of platforms = that > > need this kind of AQM? > > > > Since there is always demand for implementations, can we get an = ASIC/NPU > > implementation of FQ_CODEL done by someone who claims it's no = problem? > > > > Personally I believe we need both. FQ is obviously superior to = anything > > else most of the time, but FQ is not making itself into the kind of > > devices it needs to get into for the bufferbloat situation to = improve, so > > now what? > > > > Claiming to have a superior solution that is too expensive to go = into > > relevant devices, is that proposal still relevant as an alternative = to a > > different solution that actually is making itself into silicon? > > > > Again, FQ superior, but what what good is it if it's not being used? > > > > We need to have this discussion and come up with a joint = understanding of > > the world, otherwise we're never going to get anywhere. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > Ecn-sane mailing list > > Ecn-sane@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/ecn-sane >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane