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

Re: two ideas...

From: <touch@ISI.EDU>
Date: Thu, 7 Dec 1995 18:34:02 -0800
Message-Id: <199512080234.AA04064@ash.isi.edu>
To: touch@ISI.EDU, mogul@pa.dec.com
Cc: www-talk@www0.cern.ch, www-speed@tipper.oit.unc.edu
> From mogul@pa.dec.com Thu Dec  7 17:43:17 1995

> Although the HTTP working group hasn't really addressed this yet,
> it presumably will happen fairly soon, so I think one can assume
> that HTTP 1.1 will have preemption whether or not it has prefetching.

How "optimized" this is depends on the transport protocol.

> 	cache hits are forwarded to the server presender
> 		so that the server presender can update 
> 		its speculation set
> 
> This won't be popular with the HTTP community, since it adds
> server load.  And it's not clear to me that the server's "speculation
> set" (predictive model) should be updated to reflect cache-hit
> behavior ... since (in our approach, at least) its purpose is
> to predict cache-miss behavior!

Predicting the next cache-miss is helped by feeding the cache-hit
behavior back to the source. Granted, this adds load. 

The idea is as follows:
	Client asks for the root page
	Server sends the root page
		Server presends the pages the root page points to
		Server presends their children, recursively,
		breadth-first, until getting feedback or running
		out of capacity
	Client HITS a root child in the cache
		Client sends the name of the child hit to the server
		Server deletes subtrees not based at that child,
		refocusing its "presending" set

The idea is based on the information-theoretic implications of
sending and receiving packets. Receiving a packet decreases the
imprecision in the estimated state of the remote side. Sending a
packet (I have proposed) increases the imprecision in the estimated
state equivalently. The goal of presending is to create a
loosely-coupled feedback where the state imprecision is bounded.

(Aside - presending is a potentially EXPENSIVE techique that
is designed to get around *propagation* latency, primarily)

> 	
>     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.
>     
> This might be an optimization, but it's not necessary.  And if
> you don't insist on this optimization, the changes to HTTP are
> quite minimal (and hence easy to get into the standard).

I wasn't sure if it was required, but it sure makes backward
compatibility trivial. If you're not listening to the port, the
packets just get dropped. That way, I don't need it in the
"standard" - so long as I provide the client-side mux that 
aggregates the data, it'll work with existing clients.

Joe
Received on Thursday, 7 December 1995 21:37:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT