Re: two ideas...

[email protected]
Fri, 1 Dec 1995 17:46:03 -0800


> From: Simon Spero <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected], [email protected], [email protected],
> [email protected]
> 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.

Joe