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

[David Lang <david@lang.hm>]

On Sat, 28 Sep 2024, David P. Reed wrote:

> On Friday, September 27, 2024 17:43, "David Lang" <david@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.

That's why I was saying 'traffic simulator' rather than 'traffic replay'. A good 
simulator is a much harder problem

The simulator needs both ends to send and receive traffid, dealing with delays, 
failures, and whatever the control system does.

This means that the simulator isn't 'play these packets' (for all the reasons 
you gave) but rather is managing the simulation at layer 7, not at layer 2. It 
would be things like: 'open these connections and send data' The data can be 
junk, but it's timing and size match real traffic. There are a lot of different 
types of traffic, and only ISPs can provide information about the mix of the 
traffic

for types, off the top of my head I know of: one-way streaming such as youtube, 
two way streaming such as zoom, bulk downloads, dependencies (DNS, http library 
calls, cache checks), gaming, bulk uploads, etc

the control software would have knobs to adjust the mix of traffic types, the 
number of endpoints (on each end), the volume of data, and report on failures 
(hard failures where the data doesn't get through, soft failures where there is 
'too much' latency for streaming/gaming', user perceived quality (page load 
times for simulated complex pages), etc

and then throw this sort of traffic between the endpoints and see how it changes 
with different control systems.

> 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.

simulating failures is useful once you have a good case to start with. Based on 
this discussion, I don't believe that they are starting from a good point, so 
injecting failures won't get them to where they can tell if they can handle 
"real world" traffic well.

A problem injector is also easier than the type of simulation master I'm talking 
about.

David Lang