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.