From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp95.iad3a.emailsrvr.com (smtp95.iad3a.emailsrvr.com [173.203.187.95]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0FF653B29E for ; Fri, 27 Sep 2024 17:10:40 -0400 (EDT) Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7EB8722FB8; Fri, 27 Sep 2024 17:10:39 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app17.wa-webapps.iad3a (Postfix) with ESMTP id 5C051E1D58; Fri, 27 Sep 2024 17:10:39 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 27 Sep 2024 17:10:39 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 27 Sep 2024 17:10:39 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "bloat" , "Cake List" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1727471439.369527853@apps.rackspace.com> X-Mailer: webmail/19.0.25-RC X-Classification-ID: fa86a3c4-ed4b-43be-932b-1adb026e25fc-1-1 Subject: Re: [Cake] bbr vs all the aqms, cake winning... X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2024 21:10:40 -0000 Interesting. Worth diving into.=0A=0AHere's my reaction, though:=0A=0A1. "W= inning" (in this post title): there's no clear win here at all. Why?=0A A= . Very narrow tests, not applicable to real world situations. That's not a = bad approach to a research project - but you can't generalize outside the V= ERY SPECIFIC test setup (a ping vs. one full-on TCP stream, no competing ne= twork activity from other OS's and stacks). If I built a car that won the w= orld speed record on the Bonneville Flats test, is my winning car even rele= vant to driving in LA freeways or Manhattan streets or even Montana back ro= ads? Not bloody likely. The traffic from modern web browsers in a lecture h= all on a typical college campus, including smartphones, has a serious conge= stion problem to solve. Nobody even knows how to study any of the algorithm= s suitability here. This is terrible to assert a "win" for.=0A=0A2. Google = is actively pushing QUIC to replace all of TCP, and its congestion manageme= nt is not even implemented much less tested - and BBR isn't relevant to QUI= C at all. Similarly, there's more and more WebRTC traffic and RTP traffic -= many SMB's are seeing very high percentages of such traffic at their inter= connect point. Why no consideration of that at all? These guys are living i= n an ancient past - networking as it was 2 decades ago. Again, to do simple= , controlled research, that's OK. But dammit, why is the research community= focusing in their 20 year rearview mirror?=0A=0A3. The problem of interope= rability and compatibility of technologies in the real Internet still has n= ot been addressed. My buddy Dave Clark said, about when RED was being discu= ssed, that the interaction between different flows should at least start wi= th "TCP compatibility" - by which he meant whatever a flow or (whatever QUI= C does, which is lots of UDP pairs at once) does to adapt under congestion,= it should NOT damage "ordinary TCP". That was in an IRTF meeting, I don't = think Dave ever recorded that observation. But it is a MINIMUM requirement.= Now there are others. As "diffserv" keeps being bruited about (and I perso= nally still think the idea is totally broken for a dozen technical reasons)= , there isn't one "diffserv", but the meaning of diffserv marks operational= ly (queue handling, routing paths, ...) is NOT interoperable at all - and t= he last time Dave tried to get a number of major Internet Access Providers = to try to define interoperability for any subset of diffserv codepoints, th= ey made 0 progress for a number of reasons, and they tried. Yet, this commu= nity of congestion control researchers continue to act like "diffserv" is a= n answer to some question.=0A=0AThe Internet is evolving rapidly, at the ed= ges using "running code and rarely testing before deployment". That can onl= y work if all the implementers cooperate, share research and address intero= perability and compatibility.=0A=0AI know there are no research funds avail= able, unless you can use GPT or some other "Generative AI" name in the titl= e. Hell, I bet Comcast will even take its own research budget and give it o= ver to some projects with AI in the name and GPUs in the hardware. (Jason L= ivingood, I feel sorry for you, but I'd recommend turning your attention to= optimizing audio chat services research rather than congestion, if you wan= t to save your job).=0A=0A[I'm actively working on using Machine Learning i= n real-time systems right now, advising a startup, but I don't think compat= ibility, interoperability, evolution of the Internet protocols will benefit= from any of that - if anything, it will just make the congestion, interope= rability, compatibility problems harder to solve and more important than ev= er.]=0A=0ASo I really care about the research directions here. And while th= is paper isn't bad, the concerns I have above really need to be recognized,= because 5 years from now, the game won't be the game that the title of thi= s post says has been "won".=0A(we aren't gonna be racing in Bonneville Salt= Flats).=0A=0A=0A=0A=0AOn Thursday, September 26, 2024 18:21, "Dave Taht vi= a Cake" said:=0A=0A> _________________________= ______________________=0A> Cake mailing list=0A> Cake@lists.bufferbloat.net= =0A> https://lists.bufferbloat.net/listinfo/cake=0A> Lots of flent, too:=0A= > =0A> https://journals.plos.org/plosone/article/file?id=3D10.1371/journal.= pone.0304609&type=3Dprintable=0A> =0A> --=0A> Dave T=C3=A4ht CSO, LibreQos= =0A> =0A