Simulation Results

In the tables shown later, the Alg. column describes which algorithm we are using: Sender Based (SB), Receiver Based (RB), and Receiver Only (RO). The Filter column describes the filtering algorithm used. The BW column lists the actual bottleneck bandwidth of the route between sender and receiver. The Fail column lists whether links fail in the simulation. The w column gives the size of the packet window. The Traffic column gives the amount of extra traffic simulation. The Mean, $\sigma$ , Med., and Max. columns describe the mean, standard deviation, median, and maximum, respectively, of the ratio of the estimate error to actual bandwidth.

For the graph, we plot the bandwidth measured against elapsed time in the flow. We collect measurements at every packet arrival. Packet arrivals are not evenly distributed in time, so the points are not evenly distributed along the x-axis. In each graph we also plot the actual bandwidth so we can gauge the accuracy of each algorithm. Note that all graphs in this section plot bandwidth on a log scale starting at 10,000 b/s rather than 1 b/s.

Receiver Only Measurements

**Table IV:** This table compares the accuracy of various Packet Pair algorithms depending on whether they are Sender Based, Receiver Based, or Receiver Only.
Alg.	w	Traffic	Mean	$\sigma$	Med.	Max.
SB	$\infty$	0Kb/s	0.001	0.026	0.000	0.998
RB	$\infty$	0Kb/s	0.001	0.028	0.000	0.998
RO	$\infty$	0Kb/s	0.001	0.035	0.000	0.998
SB	$\infty$	400Kb/s	12.204	12.264	1.000	25.667
RO	$\infty$	400Kb/s	0.009	0.051	0.006	0.998
RB	$\infty$	400Kb/s	0.008	0.034	0.005	0.998

In this section we compare the accuracy of Sender Based Packet Pair, Receiver Based Packet Pair, and the new Receiver Only Packet Pair. We configure the simulator to use Ethernet as the client technology and use either no congestion or 400Kb/s of congestion.

The results are summarized in Table IV. With no congestion, all of the Packet Pair algorithms have less than 1% error. With 400Kb/s of congestion, the 1200% error of SBPP is probably too much for most applications, while the error of RBPP and ROPP are still less than 1%.

These results confirm our assertion in Section IV-D that ROPP can achieve an accuracy close to that of RBPP, while maintaining the ease of deployment of SBPP.

Congestion Tolerance and Detecting Bandwidth Change

**Table V:** This table compares the accuracy of various Packet Pair algorithms with varying window size and varying congestion.
Alg.	Fail	w	Traffic	Mean	$\sigma$	Med.	Max.
RB	N	$\infty$	400Kb/s	0.009	0.051	0.006	0.998
RB	N	128	400Kb/s	0.005	0.037	0.000	0.998
RB	N	32	400Kb/s	0.110	0.252	0.000	0.998
RB	Y	$\infty$	0Kb/s	1.705	2.598	0.000	5.667
RB	Y	128	0Kb/s	0.602	1.463	0.000	5.667
RB	Y	32	0Kb/s	0.263	0.794	0.000	5.667

**Figure 3:** This graph shows the effect of varying window size (w) in an Ethernet client simulation with varying bandwidth and no congestion. Notice the change in actual bandwidth at 10, 15, 20 and 26 seconds.
$\includegraphics[angle=270,width=12cm]{epsi/window_size_Ethernet_0k_1.epsi}$

In this section, we explore how well RBPP tolerates congestion and detects bandwidth changes. We use RBPP because it is more accurate than SBPP and ROPP and we wanted to isolate the effects of our new algorithms. We enable RBPP to detect bandwidth changes by setting a packet window size (w) of less than $\infty$ . The question is whether our assertions in Section IV-E are accurate that a larger window size will be more resistant to congestion and a smaller window size will adapt more quickly to bandwidth changes. The results indicate that this assertion is correct.

Table V summarizes the statistics. The first three lines show the accuracy of three different window sizes when experiencing moderate congestion. As expected, smaller window values give less accurate results. However, even the 11% average error of the w = 32 estimate is probably tolerable for many applications.

The next three lines show how different window sizes affect agility. To test the agility of smaller window sizes in adapting to changing bandwidth, we configure the simulator to shut down the primary links periodically and route traffic through lower bandwidth secondary links (see Section VI). When we use all the packets from the beginning of the connection (i.e. w = $\infty$ ), RBPP has a significant error. As we would expect, the error decreases as we decrease the window size. The estimate with w = 32 is 144% more accurate than the w = $\infty$ estimate.

To visualize the effect of the different window sizes, we plotted the estimated and actual bandwidth in Figure 3. Notice the changes in actual bandwidth (the thin solid line) at 10, 15, 20 and 26 seconds. The actual bandwidth begins at 10Mb/s (the bottleneck bandwidth of the primary route), dips to 1.5Mb/s (the bottleneck bandwidth of the secondary route) at 10 seconds, rises again to 10Mb/s at 15 seconds and switches again between these values at 20 and 26 seconds. We removed the w = $\infty$ plot from this graph because it always remains at 10Mb/s and obscures the other plots. Notice that all the estimates jump to the correct estimate within three packets of the start of the connection. The plot with w = 32 adapts to the change at t = 10 almost instantly, while the w = 128 plot is slower to adapt. At the t = 26 change, the w = 32 plot is again more agile than the w = 128 plot.

Strangely, neither plot adapts to the t = 15 change. Examination of the trace revealed that the TCP code in ns was not increasing its window as it should have. Therefore, it was sending packets with a potential bandwidth of only 1.5Mb/s. As we discussed in Section V-A, Packet Pair algorithms cannot report a measured bandwidth higher than the potential bandwidth.

We conclude from these results that we must decrease the window size to detect changes in bandwidth quickly. This supports the conclusion in Section IV-E that we must make a tradeoff between timeliness and accuracy in choosing a window size.

Potential Bandwidth Filtering

**Table VI:** This table compares the accuracy of different filtering algorithms.
Alg.	Filter	BW	Mean	$\sigma$	Med.	Max.
SB	MBF	10Mb/s	0.001	0.000	0.020	0.998
SB	PBF	10Mb/s	0.001	0.000	0.020	0.998
RB	MBF	10Mb/s	0.001	0.000	0.020	0.998
RB	PBF	10Mb/s	0.001	0.000	0.020	0.998
SB	MBF	500Kb/s	0.442	2.368	0.250	25.667
SB	PBF	500Kb/s	0.078	0.268	0.000	0.998
RB	MBF	500Kb/s	4.355	3.394	7.000	7.000
RB	PBF	500Kb/s	0.000	0.021	0.000	0.998

In this section, we investigate the effectiveness of our new filtering algorithm, PBF. As discussed in Section V-B, PBF is designed to overcome the problems that the standard Measured Bandwidth Filtering (MBF) algorithm has on traffic with mostly low potential bandwidth packets. It would also be desirable if PBF performed no worse than MBF on traffic where most of the packets have high potential bandwidth. In order to test PBF, we used our simulated Ethernet network for the mostly high potential bandwidth traffic and the uplink of a simulated asymmetric cable modem network for the mostly low potential bandwidth traffic. In addition to a varying amount of overall congestion, we also set up a second TCP connection between the same two hosts as the first connection, but in the reverse direction. This ensures that there are at least a few high potential bandwidth packets in the outbound direction.

The results are summarized in Table VI. The first four lines show that PBF is equivalent to MBF on the Ethernet network. The next four lines show that PBF is anywhere from 37% to 435% more accurate on average than MBF on the cable modem network. MBF also has a significantly lower median than PBF, so MBF's poor average accuracy cannot be blamed on a few outliers. Examination of the trace verifies the analysis of Section V that the outbound link is filled with acks which overwhelm the few data packets. This causes MBF to incorrectly report the bandwidth of the acks as the true bandwidth. PBF is able to filter out those samples and discern the true bandwidth.