Before studying the design of the prediction mechanisms, one must answer the question: assuming perfect predictors, what's the maximum latency reduction possible using this technique? The upper bound will determine whether pre-pushing is worthwhile.
The upper bound is determined by a number of factors, including:
Figure 2 shows the idle time distribution observed in the UCB traces. Here we estimate idle time by looking at each user's requests, and calculate the difference between the estimated end-of-transmission of one request to the start of the next request. Differences of less than 1 second are presumed to be for concurrent transfers. The figure show that about 60% of the requests are preceded by 2 to over 120 seconds of idle time, indicating that there are plenty of opportunities to take advantage of the idle time to reduce client latency.
Our simulation assumes a perfect predictor at the proxy side; that is, at any time, it can predict the next k requests for a user for any k. Furthermore, the simulation assumes that at each user end a pre-push buffer exists to hold pre-pushed pages from the proxy. The pre-push buffer is separate from the user browser cache. User Web accesses that hit in the browser cache is hidden from the proxy However, we assume that for every accesses that hit in the pre-push buffer, the proxy receives a notification message.
Our simulation assumes that a document can only be pushed if it has been seen before in the trace. Obviously, unless Web servers provide prefetch-hints to proxies, this is the limitation in reality. We further assume that the proxy has infinite cache space, and proxy cache documents on disks, and for every document that is pushed, there is a 10ms latency to fetch the document from disk first.
Finally, the simulation assume that the buffer is flushed if the user's idle time exceed 30 minutes. This is because in reality, the idle time signifies a new session and we assume it to be impossible to predict across the sessions.
