As described so far, PCP seems merely to have
replicated the delays caused by TCP slow start - 
steps to
determine the bandwidth. However, we note that
the impact of a PCP probe is independent of its test rate,
in contrast to TCP's approach of sending at its target rate for a
full round trip time. Thus, it is easy to test
aggressively in PCP, without fear of disrupting existing
connections. We use this flexibility to reduce the startup transient
to a constant number of round trips in the common case.
We achieve this by keeping history information about the base
rates previously used to each Internet address. When this history
information is available, we set the initial probe rate to be 
of
the previous base rate, and then use binary search from that point
forward. This allows the end host to usually identify the optimal
rate within two round trip times after the initial connection
establishment. We also keep track of the variance in base rates and
the accuracy of predictions made based on the history information; if
the history provides inaccurate estimate, we halve/double the initial probe
rate after each inaccurate/accurate prediction, up to 1/3 of the
base rate. Note that we do not set the
initial rate to be the entire previous base rate, to avoid the chance
that multiple hosts will simultaneously probe for, and seemingly
acquire, the full link bandwidth. Our use of history is similar to
that of the MIT Congestion Manager (CM) [6] but more general;
because CM uses TCP, it can only reuse the congestion window if
multiple transfers to the same location happen almost simultaneously.
A mistakenly large congestion window in TCP could cause massive packet
loss. Because the cost of making a mistake with history in PCP is
only a wasted probe, we can make more aggressive use of potentially
stale data of the likely available bandwidth of a path.