Re: P-HTTP and Slow-Start [ draft may be of interest]

> From: Zheng Wang <>
> This reminds me a point I'd like make about the "slow-start restart"
> problem.
> One of the problems with current HTTP is that a seperate connection
> has to be established to fetch each URL which has the extra delay of
> openning a connection and a "slow-start". 
> P-HTTP solves the problem of new connection for each URL fetch.
> Many people believe that P-HTTP can alos avoid "slow-start" which
> is *not* true in general. "Slow-start" is used to space out the
> packets when you have a bunch of packets to send but there are no acks
> in the pipe to clock them out. Therefore, "slow-start" is necessary whenever
> the pipe is empty (at the beginning of a connection, restart after a timeout
> and sender is idle for a while). If a user pauses between two URL fetches,
> which is very likely, TCP will do a "slow-start". To completely eliminate
> the "slow-start" problem, we probably have to move towards rate-based control.

Not just that - SS also restarts after "filling a hole", i.e., when the
window jumps forward because there was only one hole to fill in the
receiver's window.

Also, SS isn't an issue because it doesn't matter in the current net.
(highly-cited URLs and papers to the contrary).

For the 95% of files transferred by HTTP, which are around 6K or
smaller, over the 95% of end-to-end links used, which are dominated by
ISDN or slower links, there are only 1-2 packets in transit. Omitting
SS *and* 3-way connection re-establishment reduces the transfer times
by around 10-20%, which won't even be noticed.

Joe Touch -
ISI / Project Leader, ATOMIC-2, LSAM
USC / Research Assistant Prof.      

Received on Friday, 14 June 1996 11:01:26 UTC