Locating Bottleneck/Congested Links

1. Locating Bottleneck/Congested Links Jeng Lung WebTP Meeting 11/8/99

2. Locating Bottleneck/Congested Link for a Group of Hosts • Tree topology is needed if you wish to know which hosts share a bottleneck or congested link, either from a receiver’s (one receiver connected to multiple servers) or server’s point of view (one server connected to multiple receivers). • For the receiver, you could use this information to make tradeoffs between pipes in order to optimize user satisfaction. This information can also be used to initialize starting rate to a particular server. • For the server, you could use this information for rate allocation/congestion management.

3. Bandwidth Estimation • Estimate both bottleneck/available bandwidth between two hosts at the same time using existing traffic. • Use the distribution of packet interarrival times to estimate bottleneck bandwidth. • Use either throughput or goodput for estimating available bandwidth.

4. Tree Inference • Traceroute • More useful for receivers than servers due to scalability problems. • Can cache the information on the receiver since most receivers visit the same sites. • An “one” time cost since most Internet routes are fairly stable. • Partition according to packet loss statistics • Can’t use shared packet loss information to partition the hosts since different servers are sending different packets at different rates. • Takes time to obtain accurate loss statistics hence takes time to converge to the correct tree. • Group hosts that experience packet loss in the same time period.

5. Creating the Bottleneck/Available Bandwidth Tree • Calculated immediately once you have the tree topology and end-to-end bandwidth estimates for all connected hosts. • Leafs of the tree contains the bottleneck/available bandwidth to that host. • Start at the leaf nodes and propagate the maximum bottleneck/available bandwidth values up the links of the tree. • Utilization of a link is: • (available bw of the link) / (bottleneck bw of the link)

6. Measurements on the Receiver • Measurements done on receiver or sender? • On the receiver • Needs sender’s transmission timings to be more accurate (V.P.’s RBPP, L&B’s ROPP, PBF). • Since the number of sites that the receiver connects to is limited, the bandwidth tree can be constructed without overburdening the system’s resources (i.e. depths of 2-3 on the receiver versus depths of 11-12 on the sender/server). • Can cache bottleneck bandwidth tree since it is fairly static. • Possibly cache available bandwidth info according to time of day/day of week since Internet congestion follows a temporal pattern.

7. Measurements on the Sender • On the sender • Only measures the RTT therefore open to ACK compression problems. • Problem of scalability with thousands of flows. The tree would be changing at a high rate with multiple connections initiating and endings. • However, you need these measurement information on the server for rate allocation/scheduling and congestion management.

8. Goals • Passive measurements – use existing traffic instead of probing. • Need reliable filtering to filter out packets that have been time compressed or time extended. • Need to know what time scale is appropriate for rate allocation/congestion management and adjust the measurement window size accordingly.