Netlab, Computer Science Department, Caltech
Aug 17, 2005
We conduct NS-2 simulation to test the performance of FAST with topologies that Dummynet testbed cannot reliably emulate. The scenarios setup include: FAST with noise traffic, interaction between FAST and Reno, FAST on multiple bottleneck links.
The FAST NS-2 code is implemented by CUBIN Lab.
Parameters:
We use large amonts of random exponential on/off traffic to simulate the noise generated by web traffic and study the behaviour of FAST. Different noise levels (from 2% to 80% of the bottleneck capacity) are simulated.
The topology is shown in the following figure. The delay labeled on each link is one-way propagation delay. The buffer size for all the links are unlimited unless specified.
We use three classes of parallel flows. The first class starts at time zero and stops at 900th second. The second class starts at 180-th second and stops at 720-th second. The third class starts at 360-th second and stops at 540-th second. Each class has two parallel FAST flows so that we can also examine the fairness among the same class of flows.
The noise traffic is multiple flows of exponential on-off traffic. The average burst time and a idle time are both 100ms. The bandwidth of each flow is 4Mbps. Hence, in average, the life of a flow transfers 50KB data on average, with a rate of 500KBps, similar to a web traffic.
We vary the number of noise flows to from 0, 10, 25, 50, 100, 200, 400. The
average aggregate throughput is 0%, 2%, 5%, 10%, 20%, 40%, 80% of the bottleneck
capacity.
The following table shows the individual throughput of each flow. Clicking on a figure leads to the details of other measured variables.
For noise=0% and 2%, the new FAST flows could not see the correct propagation delay. There are unfairness due to this measurement error.When the noise increases to 5% and beyond, the propagation delay error diminishes. The rate of the flows slighly oscillate to adapt to the noise traffic. When the noise is 80% of the capacity, the flows cannot keep stablility since most of the capacity is occupied by the noise traffic.
Most data from the measurement community show that the mice traffic ususally contributes about 10% to 20% of the aggregate traffic (in terms of bytes) , we expect the figures for noise=10% and noise=20% will be more realistic.
|
|
|
|
|
|
|
|
|
|
|
We simulate the interaction between FAST and Reno with different mix levels.
We use similar topology as in Scenario 1, except that the delays in all the flows are 1/5 of the corresponding delays in scenario 1, since the NS 2 runs very slow in this case with the original delay settings. The topology is shown in the following figure.
We use the same three classes of flows as in Scenario 1. Each class has four FAST or Reno flows running parallelly. We vary the number of Reno flows from 0 to 4 (and hence the number of FAST flows from 4 to 0) in each class. When there are both Reno flows and FAST flows, we double the length of the simulation to make sure that Reno gets enough time to reach oscillation state.
The FAST flows have small oscillation when the third class join. This is because the that the bottleneck buffer, which is 50% of the BDP cannot hold all the packets introduced by FAST. So, FAST works as an aggressive AIMD algorithm in this period of time. Oscillation leads to slightly smaller throughput.
|
|
|
In single bottleneck link with droptail queueing management, the equilibrium rates of FAST and Reno in competition are predictable, based on the synchronization assumption of Reno loss and instantaneous convergence of FAST. See model and matlab script for details. From this model, we can prove that there is a unique equilibrium for FAST and Reno flows when they are sharing a single bottleneck link. The share depends on several factors: bottleneck capacity, bottleneck buffer size, propagation delays of Reno flows and alpha values of FAST flows.
In the following figures, the purple curve shows the prediction of Reno's throughput by the model. The real Reno throughput is slightly higher than the prediction since both of the assumptions, synchronization loss in Reno and instantaneous convergence of FAST, underestimate the throughput of Reno.
These results show that FAST flows are not completely starved or completely overwhelming in the interaction with Reno flows. (Note: If the buffer size is infinitely large and there is no random loss, FAST flows ARE completely starved. But this situation is not realistic.)
|
|
|
|
We use a topology that similar to two LANs connected by a WAN connection, as in the following figure.
We vary the link capacity between A and B among 10Mbps, 100Mbps, 155Mbps, 622Mbps and 1Gbps to see if the FAST flows can achieve proportional fairness as expected.
We start two flows on each of the following paths:
1->A->B->4
1->A->2
3->B->4
All the flows last for 300 seconds. The bottlenecks are link 1->A, B->4 and A->B. (when A->B is large enough, it is not the bottleneck. Calculation shows that the threshold is 1/3 Gbps)
In the following table, we show the queue length of each bottleneck link. Clicking on a figure leads to the details of other measured variables.
queue0 is for the bottleneck A->B. queue1 is for 1->A and queue 2 is for B->4.
When the capacity of A->B is small (in the cases of 10Mbps, 100Mbps and 155Mbps), A->B is a bottleneck. When its capacity is high (the case of 622Mbps and 1Gbps), A->B is no longer the bottlneck.
There is very small oscillation in the queue. But when we look at the congestion window trajectories, they are very smooth. The queue oscillation is +/-1 packet around the equilibrium in all the cases. Hence, our understanding is that the oscillation is an integer effect.
|
|
|
|
|
|
|
|
We also look at one of the flows running on the path of 1->A->B->4. The following figure compares its throughput, under different bottleneck capacity, to the theoretical prediction.
Each data point corresponding to one simulation in the table above, for 10Mbps to 1Gbps (0.83pkt/sec to 83pkt/sec). We see that the throughput matches the prediction of proportion fairness very well. See matlab script for the calculation.
