You are on page 1of 17

Overview Download & Installation Known Issues & Bugs Change log Sample Test Results - Test 1: Multiple source sharing

one link - Test 2: Multiple sources sharing multiple links - Test 3: Low buffer size - Test 4: High Bandwidth Delay Product - Test 5: Random loss

This site is for the Network Simulator (NS2) implementation of FAST developed at the University of Melbourne's Centre for Ultra-Broadband Information Networks (CUBIN). This code was written by Tony Cui, with advice from Lachlan Andrew and others. FAST-TCP is a new TCP congestion control algorithm developed at Caltech's Netlab. The official FAST-TCP website is at For actual implementations, such as the FAST TCP Aria, contact FASTsoft. The NS2 implementation is an ongoing effort and any bugs should be reported to or The source code here may be freely used for research or teaching purposes. However, we request that any resulting publications cite this simulator. A suitable citation may be T.Cui and L. Andrew, "FAST TCP simulator module for ns-2, version 1.1", available from <>

Thanks to Krister Jacobsson for comments on version 1.1b. Thanks to Xioaliang Wei for fixing a bug in loss recovery in version 1.1a. Thanks to Nirav Jasapara for fixing a bug in ECN support in version 1.1.

Download & Installation
1. Download and install NS2 version 2.29 from following the instructions shown there. 2. Download the FAST-TCP NS archive: Version 1.1 FAST-TCP for NS2.29 ( (Release date: January 2007) 3. Unzip the file, and change to the directory fast-tcp-ns2-v1_1c 4. Run ./install, and answer the prompts 5. Run one of the test scripts, such as do_test1 to verify the installation process.

Known Issues & Bugs

Loss recovery is quite basic. Version 1.1 of this simulator includes SACK (as the real FAST TCP does). However, FAST TCP's advanced loss recovery is not implemented.

Sample Test Results A number of test script are included in the archive. The unfairness between 20 and 60 seconds occurs because sources 2 and 3 estimate the base RTT incorrectly. Receiver window. It is necessary to have alpha somewhat larger the threshold so that FAST does not re-enter MI during the initial turn on transient or subsequent transients. Figure 1. the queue temporarily empties (Figure 1.1: SACK introduced Version 1. alpha/C must be 5 times greater than TCP_FAST_CC_MIQ (or mi_theshold_). All tests use 1kByte packets Test 1: Multiple source sharing one link This experiment shows the normal operation of FAST on a properly dimensioned medium speed link.5ms. queue sizes etc need to be optimized better to reduce memory allocation.1: Scenario . Memory consumption in the test files is large. • Changelog • • Version 1.0: Basic FAST functionality for loss-free networks. This emptying of the queue happens much more frequently in "real" networks than in the highly idealised NS2 simulations. Alpha in this experiment is set to 200.75ms.) As a heuristic. on a path with capacity C. allowing source 2 to correct its base RTT estimate (Figure 1.1b. and the link is shared fairly from 60 to 80 seconds.4). which defaults to 1.6). this is replaced by the TCL variable mi_threshold_ which defaults to 0. such as different number of flows and capacities. they attribute some of the queueing delay to propagation. (From version 1.• It is important that alpha is set large enough so that the resulting delay is sufficiently above the multiplicative increase threshold TCP_FAST_CC_MIQ. These test show the operation of FAST under various conditions. When source 3 terminates at 60 seconds.

3: Source Window .2: Source Rates Figure 1.Figure 1.

Figure 1.5: Src 1 RTT measurement .4: Router Queue Size Figure 1.

Figure 2.Figure 1. The bottleneck link for flow 1 changes during the experiment from Link 1 to Link 3.1: Scenario . Alpha in this experiment is set to 1000.6: Src 2 RTT measurement Test 2: Multiple sources sharing multiple links This experiment illustrates the behaviour of FAST with multiple links.

2: Source Rates .Figure 2.

Figure 2.3: Source Window Figure 2.4: Router Queue Size .

5: Src 1 RTT measurement Test 3: Low buffer size In this experiment loss is introduced by making the buffer size too small to support all of the active flows. the flows attempt to queue more than 1000 pkts. The buffer size of the link is set to 1000. which means that when more than one flow is active. and alpha is 800. This experiment validates that FAST reacts to loss as well as queuing delay. as no SACK .Figure 2. The loss recovery mechanism is at the moment not very efficient.

Figure 3.information is used. In particular.2: Source Rates Figure 3.1: Scenario Figure 3.3: Source Window . the base-RTT estimate is broken. which results in the goodput being below capacity.

Figure 3.4: Router Queue Size Figure 3.5: Src 1 RTT measurement .

Figure 4.Test 4: High Bandwidth Delay Product This experiment validates the stability of FAST in a high speed medium delay network.1: Scenario .

2: Source Rates Figure 4.3: Source Window .Figure 4.

5: Src 1 RTT measurement .Figure 4.4: Router Queue Size Figure 4.

with probabilty 0.Test 5: Random loss This experiment investigates the performance of FAST in which packets are dropped according to a Bernoulli process.0001. Figure 5.1: Scenario .

Figure 5.3: Source Window .2: Source Rates Figure 5.

Figure 5.4: Router Queue Size Figure 5.5: Src 1 RTT measurement .