FAST TCP simulator module for ns-2
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
Overview
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
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 netlab.caltech.edu/FAST. 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
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 <http://www.cubinlab.ee.unimelb.edu.au/ns2fasttcp>
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.
1. Download and install NS2 version 2.29 from www.isi.edu/nsnam/ns/ following the instructions shown there.
2. Download the FAST-TCP NS archive:
Version 1.1 FAST-TCP for NS2.29 (fast-tcp-ns2-v1_1c.zip) (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.
- 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.
- 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, which defaults to 1.5ms. (From version 1.1b, this is replaced by the TCL variable mi_threshold_ which defaults to 0.75ms.) As a heuristic, on a path with capacity C, alpha/C must be 5 times greater than TCP_FAST_CC_MIQ (or mi_theshold_). 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.
- Memory consumption in the test files is large. Receiver window, queue sizes etc need to be optimized better to reduce memory allocation.
- Version 1.1: SACK introduced
- Version 1.0: Basic FAST functionality for loss-free networks.
A number of test script are included in the archive. These test show the operation of FAST under various conditions, such as different number of flows and capacities. 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. Alpha in this experiment is set to 200.
The unfairness between 20 and 60 seconds occurs because sources 2 and 3
estimate the base RTT incorrectly; they attribute some of the queueing delay
to propagation. When source 3 terminates at 60 seconds, the queue temporarily
empties (Figure 1.4), allowing source 2 to correct its base RTT estimate
(Figure 1.6),
and the link is shared fairly from 60 to 80 seconds. This emptying of the
queue happens much more frequently in "real" networks than in the highly
idealised NS2 simulations.
Figure 1.1: Scenario
Figure 1.2: Source Rates
Figure 1.3: Source Window
Figure 1.4: Router Queue Size
Figure 1.5: Src 1 RTT measurement
Figure 1.6: Src 2 RTT measurement
Test 2: Multiple sources sharing multiple links
This experiment illustrates the behaviour of FAST with multiple links. The bottleneck link for flow 1 changes during the experiment from Link 1 to Link 3. Alpha in this experiment is set to 1000.
Figure 2.1: Scenario
Figure 2.2: Source Rates
Figure 2.3: Source Window
Figure 2.4: Router Queue Size
Figure 2.5: Src 1 RTT measurement
In this experiment loss is introduced by making the buffer size too small to support all of the active flows. The buffer size of the link is set to 1000, and alpha is 800, which means that when more than one flow is active, the flows attempt to queue more than 1000 pkts. This experiment validates that FAST reacts to loss as well as queuing delay. The loss recovery mechanism is at the moment not very efficient, as no SACK information is used, which results in the goodput being below capacity. In particular, the base-RTT estimate is broken.
Figure 3.1: Scenario
Figure 3.2: Source Rates
Figure 3.3: Source Window
Figure 3.4: Router Queue Size
Figure 3.5: Src 1 RTT measurement
Test 4: High Bandwidth Delay Product
This experiment validates the stability of FAST in a high speed medium delay network.
Figure 4.1: Scenario
Figure 4.2: Source Rates
Figure 4.3: Source Window
Figure 4.4: Router Queue Size
Figure 4.5: Src 1 RTT measurement
This experiment investigates the performance of FAST in which packets are dropped according to a Bernoulli process, with probabilty 0.0001.
Figure 5.1: Scenario
Figure 5.2: Source Rates
Figure 5.3: Source Window
Figure 5.4: Router Queue Size
Figure 5.5: Src 1 RTT measurement
