Re: [Bloat] Remy: Computer-Generated Congestion Control

[Michael Welzl <michawe@ifi.uio.no>]

Dave,

About this point that I've seen you make repeatedly:

> My biggest problem with all the work so far is that it starts with a
> constant baseline 150ms or 100ms RTT, and then try various algorithms
> over a wide range of bandwidths, and then elides that base RTT in all
> future plots. Unless you read carefully, you don't see that...
> 
> The original bufferbloat experiment was at a physical RTT of 10ms,
> with bidirectional traffic flooding the queues in both directions, on
> an asymmetric network. I keep waiting for more experimenters to try
> that as a baseline experiment.


This sounds like a call for reality, when the point is to measure things that matter to the system you're investigating. E.g., if I'm investigating TCP, and I don't specifically work on ACK behavior (ACK congestion control or something like that), I usually don't care much about the backwards traffic or the asymmetry. Yes it does influence the measured RTT a bit, but then you argue for using a smaller base RTT where the impact of this gets smaller too.

What matters to the function of congestion controllers is the BDP, and the buffer size. As for real RTTs, I like pinging wwoz.org because it's a radio station in New Orleans. I do sometimes listen to it, then I get traffic via a TCP connection that has this RTT. Very real. My ping delay is consistently above 110ms.

On a side note, I can't help but mention that the "original bufferbloat experiment" features ping over FQ... measuring ping all by itself, pretty much  :-)

Michael