[Bloat] Remy: Computer-Generated Congestion Control

[Dave Taht]

On Thu, Aug 21, 2014 at 5:21 AM, Michael Welzl <michawe at ifi.uio.no> wrote:
> 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.

Heh. It is my wish, certainly, to see the remy concept extended to
solving the problems I consider important. The prospect of merely
warming my feet on a nice 80 core box for a week, and evaluating the
results, is quite appealing.

I'll gladly trade someone else's code, and someone else's compute
time, for a vacation (or unemployment, if it works out!). Can arrange
for a very hefty cluster to tackle this stuff also, if the code were
public.

I have encouraged keith to look into the netfpga.org project as a
possible target for the rules being created by remy's algorithms.

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

Which varies based on the real physical RTT to the server. One of the
biggest problems in
nets today is that larger flow sources (CDNS, HAS(netflix)) keep
moving closer and closer to the
end node, with all the problems with tcp fairness that short RTTs
induce on longer ones, like your radio
flow blow.

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

I too use a low rate radio stream to measure the impact of other flows
on my listening experience.

I'd written this before the bufferbloat project got rolling, before
I'd even met jim.

http://nex-6.taht.net/posts/Did_Bufferbloat_Kill_My_Net_Radio/

... haven't had a problem for 2 years now. :)

Still do use the stream ripping thing for taking stuff on the road.

>
> 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  :-)

Huh? The original bufferbloat experiments were against a comcast cable
modem, and various other devices, lacking FQ entirely. there was a
youtube video, a paper, (things like "daddy, why is the internet slow
today" and various other resources. So the earliest stuff was "upload
+ ping + complaints about the network from the kids", and the later
simultaneous up+down+ping abstraction was to get the kids out of the
equation.

I agree that up+down+ping is not as useful as we'd like now that FQ is
on the table.

I have been attempting to formalize where we are now, adding rigor
based on those early benchmarks,  with both netperf-wrapper's
tcp_bidirectional test, the more advanced rrul and rtt_fairness tests,
and a model in ns3. Given how much bloat we've killed elsewhere I
would like to continue to improve these tests to properly show
interactions with truly isochronous streams (there are several tests
in netperf-wrapper now that leverage d-itg for that now (thx toke!),
and more bursty yet rate limited flows like videoconferencing which
we've been discussing the structure of with various members of the
rmcat group.

My complaint comes from seeing very low bandwidths and long rtts and
short queue lengths used in materials used to explain bufferbloat,
like this:

https://www.udacity.com/wiki/cn/assignment5-buffer-bloat

when the reality:

1) There is a double bump you see in tcp for example at truly
excessive queue lengths). You also see truly
terrible ramp up performance when competing data and ack flows.

2) the example assumes byte to packet length equivalence (100 packets
= 150kb) which is completely untrue -
100 packets is in the range of 6.4kb-150kb - and a reason why we have
much larger packet based queue lengths in the real world IS because of
optimizing for acks, not data in commonly deployed equipment.

If you want to test a byte based queue length, by all means (I have
gradually come to the opinion that byte based packet queues are best),
but test either packet or byte based queues under conditions that are
ack dominated or data dominated, with both, preferably all scenarios.

3) it is at 1.5mbit, not the 5,10,100mbit speeds. Below 10mbits you
see IW10 or IW4 effects, you see ssthresh not hit, and a variety of
other tcp specific issues, rather than the generic bufferbloat
problem.

4) the 20ms in that course is actually reasonable.  :)

I don't understand what the harm would have been to the student to use
1000 packets, and test up, down, and up + down, at 10 or 100Mbit.

5) I'd have liked it if the final experiment in the above course
material switched to huge queue lengths (say for example, cisco's 2800
default for their 4500 line), or explained the real world situation
better, so the takeaway was closer to the real size and scope of the
problem.

Anyway...

Nearly every paper I've read make one or more of the above
modifications to what I'd viewed as the original experiment, and I'd
like to add rigor to the definitions of phrases floating around like
"bufferbloat episode", and so on.


> Michael
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article