From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 09:45:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79EFDCF0 for ; Thu, 23 Apr 2015 09:45:47 +0000 (UTC) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14BE61480 for ; Thu, 23 Apr 2015 09:45:46 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t3N9jhhn013761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 19:45:44 +1000 Message-ID: <5538BF47.4000803@swin.edu.au> Date: Thu, 23 Apr 2015 19:45:43 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:45:47 -0000 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