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

> I addressed how this affects p-HTTP in the implications section.
> The main problem is that muxing at the application layer has some
> side-effects, and will be incompatible with kernel-based integrated
> services scheduling mechanisms.

This reminds me a point I'd like make about the "slow-start restart"

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.


Received on Friday, 14 June 1996 02:44:12 UTC