Testing Congestion Control Algorithms

Thu Apr 23 22:22:17 UTC 2015

This is veering somewhat off tangent for the freebsd-net list, but...

On 04/23/2015 21:15, Karlis Laivins wrote:
> Hello once again,
>
> Before I dive in the TEACUP, I wanted to clarify this - should I build the
> testbed to consist of FreeBSD machines, will I be able to use congestion
> control module (.ko) that was created by modifying the cc_newreno (written
> in C) in TEACUP, or will I have to rewrite it in Python?

Short answer: TEACUP doesn't implement CC algorithms per se. It focuses on controlling all the data generation & capture tools, end hosts and bottleneck to start/log/stop TCP performance tests using whatever CC algorithm you select. You will need to copy-paste-edit about 5 lines of TEACUP's python code so TEACUP will recognise and kldload your new module on your FreeBSD end hosts.

For the long answer -- ping me offlist.

> Sorry, if this question seems silly, but I have limited time to do the
> tests and I want to be sure that I don't have to redo something in a
> language that I haven't used yet.

TEACUP takes a bit of time to set up the end hosts and bottleneck router with the right tools. But once you have it running you'll be able to iterate across a range of TCP and path parameters quite efficiently.

cheers,
gja

>
> Thank you in advance for your answer!
>
> With Best Regards,
> Karlis
>
> On Thu, Apr 23, 2015 at 12:45 PM, grenville armitage <garmitage at swin.edu.au>
> wrote:
>
>>
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>

-- 
Professor Grenville Armitage
Centre for Advanced Internet Architectures
School of Software and Electrical Engineering
Faculty of Science, Engineering and Technology
Swinburne University of Technology, Australia
http://caia.swin.edu.au/cv/garmitage