W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: two ideas...

From: <touch@ISI.EDU>
Date: Fri, 1 Dec 1995 17:46:03 -0800
Message-Id: <199512020146.AA25516@ash.isi.edu>
To: touch@ISI.EDU, ses@tipper.oit.unc.edu
Cc: mogul@pa.dec.com, marc@ckm.ucsf.edu, www-talk@www0.cern.ch, www-speed@tipper.oit.unc.edu
> From: Simon Spero <ses@tipper.oit.unc.edu>
> To: touch@ISI.EDU
> Cc: mogul@pa.dec.com, touch@ISI.EDU, marc@ckm.ucsf.edu, www-talk@www0.cern.ch,
>         www-speed@tipper.oit.unc.edu
> Subject: Re: two ideas...
> The concept of speculative transmission has been in HTTP-NG from back
> before it was HTTP-NG; the technique can be used with HTTP/1.X with
> persisent connections, but for several reasons, I believe that this is not
> ideal. The main reason is the potentially negative effects of
> speculative-mistakes; if complete documents are sent in monolithic chunks,
> you need to wait for the whole of one document to arrive before you can
> see what's next. With NG's interleaving you can send small chunks of each
> object. Since the first bytes are the most important in terms of user
> response, this improves percieved TTR. 

This presumes that the speculative transmission doesn't have 
preemption, which is a prerequisite.

There is a list of prerequisites for source anticipation, which
are completely different from those conventionally used for
(receiver-side prefetching). These were worked out as part of
my dissertation research, and precede the web itself.

They are:

	direct requests preempt speculative responses
		both at the server and at the client

	direct requests and responses preempt speculative packets
		in the network - i.e., this is why you need
		red-flagged ABR ATM packets, or some sort of
		similar flag in integrated-services IP. It doesn't
		work at all with current IP.

	cache hits are forwarded to the server presender
		so that the server presender can update 
		its speculation set

	speculative responses are dropped if
		no bandwidth in the net
		server busy with other direct requests or responses
		client cache is full (drop at the cache)
Note - the server rules imply that cache updates
arrive on a different IP port than direct requests,
and that the cache loads come on different IP ports
than direct responses.

Using these rules avoids the mistake you observe with the proposal
in HTTP-NG - using the same port requires a RTT to preempt a connection
and enable a direct response.

That can be easily avoided.

Received on Saturday, 2 December 1995 04:42:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC