W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: P-HTTP and Slow-Start [touch@isi.edu: draft may be of interest]

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
Message-Id: <5606.834745014@cs.ucl.ac.uk>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/914
> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC