These figures show timing diagrams from HTTP transfers, the number of bytes recieved plotted versus elapsed time. They are described in an upcoming paper. Each image shows 30 transfers. My comments describe the characteristics of the network path that can be inferred from the image.
Click on the images to download the Postscript version, which shows individual lines more clearly.
(above) Long rtt with moderate variability. High bottleneck bandwidth. Large buffer at server. Large bw-delay product. Most transfers never leave slow start, but a few enter congestion avoidance.
(above) Short rtt with moderate variability. Low bottleneck bandwidth. Bw-delay product is small, but buffer at server is even smaller. Transfers never reach path capacity.
(above) Medium rtt with very low variability, except during the initial reply-request rtt, which is highly variable, probably due to delays at the server. High bottleneck bandwidth. Again, throughput is limited by buffer space at the server. One unusual feature here is the horizontal line near 60,000 bytes. This seems to be a server-level delay imposed on every transfer after the first 60,000 bytes.
(above) Medium rtt with very low variability. High bottleneck bandwidth. Transfers never leave slow start.
(above) Low rtt with low variability except during the initial request-reply rtt. Medium bottleneck bandwidth. Evidence of dropped packets (long horizontal lines). Most transfers never leave slow start.
(above) Clearly trimodal performance, probably because the same DNS name maps to different servers at different times. Bottleneck bandwidth is consistently high, but the rtts of the different paths are very different. For the short rtt path, buffer space at the server is sufficient for most transfers to reach the capacity of the path, but for the longer rtt paths it is not.
(above) Medium rtt, with considerable variability. Low bottleneck bandwidth. After 4 rounds of slow start, most transfers enter self-clocking steady state. Some evidence of dropped packets.
(above) Medium rtt with very low variability except during the initial request-reply rtt. High bottleneck bandwidth. Large buffer at server. Most transfers never leave slow start.
(above) Probably at least two paths here, one with high bottleneck bandwidth, one with low. On the "slow" path, most transfers enter self-clocking steady state and achieve good throughput near the capacity of the path. On the "fast" path, rtt times are highly variable, and transfers only send a few packets per rtt, possibly due to a very small buffer at the server. The effective throughput of these transfers is much less than the capacity of the path.
(above) This server ignored the HTTP/1.0 Range command and sent the whole file, not just the first 100,000 bytes. After 5 rounds of slow start, most transfers enter self-clocking steady state, although there is some variation in the effective throughput they achieve (and the distribution may be multimodal?).
(above) High and variable rtt, high bottleneck bw. One transfer seems to enter congestion avoidance; the rest are limited by buffer space at the server.
(above) High and variable rtt, high bottleneck bw. Large buffer at server. Most transfers never leave slow start, but there are some dropped packets and a few transfers that drop out of slow start early and muddle along in congestion avoidance for a long time.
(above) Moderate rtt, with low variability except for a few outliers during the initial request-reply round trip, possibly due to delays at the server. High bottleneck bandwidth and buffer space, so most transfers never leave slow start.