[Cake] bbr vs all the aqms, cake winning...

[David P. Reed]

Interesting. Worth diving into.

Here's my reaction, though:

1. "Winning" (in this post title): there's no clear win here at all. Why?
   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 VERY SPECIFIC test setup (a ping vs. one full-on TCP stream, no competing network activity from other OS's and stacks). If I built a car that won the world speed record on the Bonneville Flats test, is my winning car even relevant to driving in LA freeways or Manhattan streets or even Montana back roads? Not bloody likely. The traffic from modern web browsers in a lecture hall on a typical college campus, including smartphones, has a serious congestion problem to solve. Nobody even knows how to study any of the algorithms suitability here. This is terrible to assert a "win" for.

2. Google is actively pushing QUIC to replace all of TCP, and its congestion management is not even implemented much less tested - and BBR isn't relevant to QUIC 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 interconnect point. Why no consideration of that at all? These guys are living in 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?

3. The problem of interoperability and compatibility of technologies in the real Internet still has not been addressed. My buddy Dave Clark said, about when RED was being discussed, that the interaction between different flows should at least start with "TCP compatibility" - by which he meant whatever a flow or (whatever QUIC 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 personally still think the idea is totally broken for a dozen technical reasons), there isn't one "diffserv", but the meaning of diffserv marks operationally (queue handling, routing paths, ...) is NOT interoperable at all - and the last time Dave tried to get a number of major Internet Access Providers to try to define interoperability for any subset of diffserv codepoints, they made 0 progress for a number of reasons, and they tried. Yet, this community of congestion control researchers continue to act like "diffserv" is an answer to some question.

The Internet is evolving rapidly, at the edges using "running code and rarely testing before deployment". That can only work if all the implementers cooperate, share research and address interoperability and compatibility.

I know there are no research funds available, unless you can use GPT or some other "Generative AI" name in the title. Hell, I bet Comcast will even take its own research budget and give it over to some projects with AI in the name and GPUs in the hardware. (Jason Livingood, I feel sorry for you, but I'd recommend turning your attention to optimizing audio chat services research rather than congestion, if you want to save your job).

[I'm actively working on using Machine Learning in real-time systems right now, advising a startup, but I don't think compatibility, interoperability, evolution of the Internet protocols will benefit from any of that - if anything, it will just make the congestion, interoperability, compatibility problems harder to solve and more important than ever.]

So I really care about the research directions here. And while this 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 this post says has been "won".
(we aren't gonna be racing in Bonneville Salt Flats).




On Thursday, September 26, 2024 18:21, "Dave Taht via Cake" <cake at lists.bufferbloat.net> said:

> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> Lots of flent, too:
> 
> https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0304609&type=printable
> 
> --
> Dave Täht CSO, LibreQos
>