IB Research Plan

For the experiments in this research, we will make use of traffic generators that emulate WWW browser request streams, to evaluate the performance of our system as individual users would perceive it (available from C. Williamson, Canada). In addition, we will use traces of WWW servers available on the Internet, and in cooperation with NCSA and CERN (among others), to measure the expected aggregate load on the servers and the ability of Intelligent Bandwidth methods to adjust to the variable aspects of that load.

There are tradeoffs between anticipative communication, caching, and channel access protocols that affect memory, computation, and disk storage requirements. For example, anticipative communication sacrifices down-link data bandwidth and base server computation to reduce remote client-perceived latency and up-link feedback bandwidth, but helps only for access to highly structured data. Caching sacrifices remote client disk space for transaction bandwidth and latency, but helps only for data reuse. Each existing method supports a characteristic asymmetry and protocol type. Recent FTP results show that latency can be reduced by 67%, to 0.7 round-trip-time, for 7-fold increase in bandwidth.

Intelligent Bandwidth is the integrated use of these tradeoffs to optimize overall system performance. We have learned that strict layering in protocols is ineffective, because it isolates the protocol from its environment too much. IB is a way to make the protocol mechanisms, and thus the applications on which they rely, sensitive to the characteristics of the network environment in which they operate.

Consider the WWW server. Designers of a typical home page are often caught in the dilemma of whether to make the home page "spiffy" with lots of graphics and visual interest, or simple text-only menus. The former has better impact, but at the cost of additional bandwidth. The latter reduces bandwidth and response time, but at the expense of effective use of the graphical medium. Proposals are already under way in the WWW community to modify the HTTP protocol to provide an indication of the capabilities of the client system, to indicate the best effort-to-result tradeoff to the server. Here we are proposing to augment that interface to additionally consider the abilities of the network to support the client / server interaction.

IB can also be used to reduce the cost of repeated broadcasts. Small caches distributed throughout the network can trade buffer space for the phase-difference between requests of the repeated information, so that more efficient multicast protocols can be used for general distribution. This trades multicast efficiency and cache storage for excessive use of bandwidth, and is especially useful in on-demand access to public service announcements, such as would occur immediately following an emergency.

Example use of Intelligent Bandwidth - a pump and filter for the Web

We use Intelligent Bandwidth to augment the existing WWW client/server with a presending pump and browser filter (figure below). The IB methods outlined here are designed to use surplus bandwidth-delay product, such as on a substantially idle phone or ISDN line, to minimize server response time. The pump and filter are supported by either the existing transport protocols or their more recent extensions, or by an augmented transport protocol.

(FIG) Using Intelligent Bandwidth in the Web via the pump and filter.

The pump acts as a proxy for the browser at the server. It keeps soft state indicating the last request received from the browser, and peeks into the data stream to find URLs from embedded in replies from the server. The pump then makes requests for URLs on the same server to be forwarded to the filter.

The pump permits two kinds of HTML replies to be sent to the browser - direct replies, and present replies. The present replies are tagged to be saved on the disk by the filter. In a high bandwidth-delay product network, these tags may not be necessary, because the present documents arrive just as they are needed at the browser. The most disk space required is the larger of the bandwidth-delay product and the bandwidth-(idle-time) product. If there is some upper-bound on reasonable disk usage for the filter to cache present data, that can be indicated to the pump, to avoid wasted effort.

The filter stores forwarded server replies to the disk. It also intercepts URL requests from the browser. If the URL is on the disk, the filter responds with the request and forwards the URL to the pump (not to be forwarded to the server). If the URL isn't on the disk, the request is sent to the pump to be forwarded to the server.

The pump manages the sending of all possible next requests, and manages the possible states of the client.The pump uses the server-side TCP signal of excess bandwidth to initiate presending, and the branching window allows the pump to send alternate streams of messages to the client. As the pump emits these messages, the branching in the server-side TCP increases.

The filter allows the browser to receive only those messages that correspond to a particular state. This client-side TCP also indicates branch selections to the server-side TCP, to perform state resolution.