Testing Congestion Control Algorithms

[grenville armitage]

On 04/23/2015 17:17, Karlis Laivins wrote:
> Hi,
>
> I am currently working on a modification of TCP NewReno congestion control
> algorithm. It seems that I have been able to write a working module.
>
> Now, I am looking for a way to test the performance of the built-in
> congestion control algorithms and the new algorithm. I have heard about the
> NS-2 simulator, and I am trying to compile and configure it now, but that's
> just a statistical tool (from what I hear) and the results are far from
> reality (please correct me, if I am wrong).
>
> Please recommend a tool or way I can test the performance of the congestion
> control algorithm in a "real" environment (sender side - 2 Computers, one
> connected to the wireless network, other to a wire, receiver - one PC,
> running FTP server, both senders each sending a big file at the same time).
> I would like to get comparable performance results from each of the
> existing congestion control algorithm as well as the new one I have created
> by modifying the NewReno algorithm.
>
> Thank you in advance for your assistance.

Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@

Indeed, I would suggest you don't bother with ns-2 -- it wont help you do meaningful comparisons to a kernel-resident cc module you develop under FreeBSD.

If you have the time and inclination to build a small testbed using a couple of physical hosts, you might find this tool useful -- http://caia.swin.edu.au/tools/teacup

My colleague and I built TEACUP (TCP Experiment Automation Controlled Using Python) to automate many aspects of running TCP performance experiments in our small, specially-constructed physical testbed. TEACUP enables repeatable testing of different TCP algorithms over a range of emulated network path conditions, bottleneck rate limits and bottleneck queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD CC modules vs conventional FreeBSD and Linux CC algorithms.)

A key caveat: TEACUP assumes your physical testbed is a multi-host/single-bottleneck dumbbell-like topology with suitably configured end hosts and Linux-based bottleneck router (see http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an example). TEACUP does not try to run experiments over arbitrary network paths or the wider Internet. This has satisfied our use-cases, other people's mileage may vary :-)

We've released TEACUP in case it may be useful to other researchers who already have (or are interested in setting up) similar network testbeds.

(Small note -- we recently found a small bug in some of the v0.9 data analysis code, which will be fixed when v0.9.2 comes out RSN.)

cheers,
gja