______________________________ Reply Separator _________________________________
Subject: Re: two ideas...
Author: www-talk@w3.org at Internet
Date: 08/12/95 10:53
From: Simon Spero <ses@tipper.oit.unc.edu>
> 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.
This presumes that the speculative transmission doesn't have
preemption, which is a prerequisite.
It's also a prerequisite (or, to be more precise, an important
optimization) for pipelining + persistent connections in HTTP 1.1.
As John Wraclawksi pointed out to me after my SIGCOMM presentation,
if you are doing pipelining and the user hits the "Stop" button, you
either need preemption, or you have to close the connection
and reopen a new one (which wastes several RTTs, but is no worse
than HTTP 1.0).
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.
Of course, it's an interesting tradeoff if the "preemption"
mechanism adopted is "close and reopen the TCP connection": how often
does this increase latency to the user vs. how often does a successful
prefetch reduce latency? But I think one can do a reasonably fast
preemption using the TCP Urgent Pointer (cf. the Telnet protocol).
direct requests preempt speculative responses
both at the server and at the client
Yup. Preempt may mean "abort" or it may mean "suspend".
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.
Since our aim is to make HTTP + current TCP + current IP +
current link layers (i.e., not ATM) work better within the next
year or so, this is moot. As you observe, it can't be done.
Also, it's a micro-optimization; one or two packets of latency
(if the MTUs are set according to Van Jacobson's advice in RFC1144)
should not materially affect interactivity.
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!
speculative responses are dropped if
no bandwidth in the net
server busy with other direct requests or responses
In our model, servers can stop sending prefetch predictions if they
are overloaded (or use a feedback control system to adjust their
prediction threshold to maintain slightly under 100% loading).
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).
-Jeff