- From: Zheng Wang <Z.Wang@cs.ucl.ac.uk>
- Date: Fri, 14 Jun 1996 10:36:54 +0100
- To: touch@isi.edu
- Cc: http-wg <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, J.Crowcroft@cs.ucl.ac.uk
> 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" 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. Cheers Zheng
Received on Friday, 14 June 1996 02:44:12 UTC