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

[David P. Reed]

On Friday, September 27, 2024 17:43, "David Lang" <david at lang.hm> said:

> 
> could the community try and produce 'traffic simulators' that implement these
> various protocols with a more realistic traffic pattern? something that can be
> turned up or down with a few presets of the mix that we can make available for
> the academics to use for their testing?

It's a pretty good idea.

However, some things I think about...it's important to remember that just recording traffic streams and playing them back filters out almost all of the "control" dynamics.
In the real Internet. It's the control feedback that causes instability and bufferbloat - everything is feedback system among a large set of endpoints - typically hundreds of them at minimum. It's hard for those who think from a perspective of one "server", or from one "client", or between a "pair" to realize that networks aren't like that. Every "independent" but concurrent activity feeds back significant "noise" into the other activities, changing latency in every protocol, etc.

Even the dynamic behavior of a single router out-queue affects everything, especially, as you know, the queues upstream and downstream.

THat's one reason that I find any work that tries to find ways to store packets in router queues ("background service") to be dubious, because that's one of the things that always increases dynamic instability. Always is my belief based on much experience and experimentation - there may even be a theorem there, but it's tricky to find the premises of such theorem.

However, this suggests a "stress simulator" that might help create realistic experiments - instead of simulating traffic, simulate instabilities in routers by injecting packets into queues for mix of flows based on some probabilistic model that acts like "real Internet". These injected packets might, for example, have invalid checksums on purpose to avoid harming any endpoint stacks. So such a tool would be a lot easier to deploy.

RRUL isn't typical, but it at least is a simple setup that pushes certain AQM challenges into a real bottleneck queue, if there is one bottleneck. Simulating, say, a highly optimized "single page web site" programmed in JavaScript with some rich UI packages, even in the single bottleneck case with multiple edge smartphones running other apps (like Zoom and streaming audio) - one can't really tell if that covers any other cases of interest.

> 
> David Lang
>