In today’s Internet, information services such as WWW, Gopher, WAIS, etc. are oriented towards a reactive model: the Internet and its servers transport and respond to individual requests. Currently, those requests are serviced by conventional client/server systems. With the evolution of these systems, the expectations of the user interface are changing from an Internet model of “point, click, and wait” to an interactive “point, click, and action” behavior.

Even with existing client/server implementations, the Web can use tens of megabits of bandwidth to provide an interactive response time. Reaction speeds near 100 milliseconds (0.1 sec.) are required for transparent real-time interactive use. Given simple files in the 10 Kbyte range, this requires 0.8 Mbps, exclusive of transaction processing, file retrieval, and intermediate buffering. Current measurements of Web logs indicate that simple hypertext files are near this size; graphic files are typically 60-100 Kbytes or larger, and it is not uncommon for a single page to incorporate tens of such images. Bandwidths near 5-10 Mbps would be required.

We expect available end-user bandwidth to be in the 14 – 28 Kbps range for conventional modem access, and 128 Kbps for ISDN in the near future: all insufficient to support interactive access. We are developing techniques to adapt client/server hypermedia systems to the available bandwidth, and to use idle bandwidth between user requests to reduce the bandwidth required for real-time interactive access. Such techniques also adapt to other overall system parameters to optimize performance proactively, rather than waiting to react to user requests. Such proactive mechanisms are also suited to supporting emerging information services such as satellite, radio, and cable, as well as supporting mechanisms for replication in support of reliability (as above).

Discussion

Response time and bandwidth are key resources in this project. Current Internet user interfaces, such as Web browsers, Gopher and WAIS tools, are based on a “point, click, and wait” design, with seconds or minutes of response time. Public internet access requires a more “point, click, and act” design. Intelligent bandwidth examines the tradeoffs between bandwidth, storage, processing, and network topology itself in proactively reducing server response time.

Response time is critical in making Web browsers acceptable interfaces for general daily use. These browsers were originally conceived as graphical user interfaces (GUIs) to Internet file transfer mechanisms, based on a slow transaction model. The Web is now being considered a true interactive distributed application, requiring response times nearer to 100 ms. The bandwidth required to support interactive response time is enormous, even excluding other latencies, including transmission, disk access, and computation costs. Transmission of even a moderate hypertext page of 40 Kbytes in 100 ms requires a bandwidth of 3 Mbps.Note that the Internet backbone is only 45 Mbps currently, and that most of the Internet is limited to much lower speeds.

Bandwidth to the end user is likely to be in the 20-100 Kbps range for the foreseeable future. Even at these speeds, with the conventional client / server architecture, only 15 people could use the system simultaneously. Fortunately, memory costs, both in RAM and disk storage, have decreased to a point where we can consider methods that trade space for time or bandwidth, or consider amortizing replies in a single multicast response.

One solution to real-time response latency is source preloading of a receiver cache.When viewing a Web page, a user stays on that page for a several seconds before requesting another. The workstation and network connection are otherwise idle during that time, and even inexpensive mass-market workstation disks are can store many 10-20 100 Kbyte files in temporary space. The server is in the best position to anticipate the needs of the user, and also is in the best position to determine its own load, preloading receivers when it is idle, and avoiding this additional load when otherwise occupied. At 10 links per page estimated, and 40 Kbytes per link as before, we can send all 10 links from the server to the receiver with the same 4 Mbps bandwidth required before, if the user spends only 1 second browsing each page. As the time the user spends per page increases, the file sizes decrease, or the number of links per document decrease, the bandwidth requirements decrease as well.

In this way, memory (disk storage) can be used to reduce response time. This method also works when the “memory” is the bandwidth-delay product, i.e., the bits in transit between the source and receiver. It is thus useful when there is idle bandwidth-delay product, either as a result of a high-speed long-distance transmission line, or an otherwise idle low-speed or short-distance link. If the user spends 10 seconds reading each page, on 400 Kbps of bandwidth is required for the previous example. If we further constrain the hypertext file size to 10 Kbytes, we can accommodate 100 ms access times with current ISDN telephone links.

Memory can also be used to reduce bandwidth in a multiaccess medium, such as cable, radio, or Ethernet. Consider a video-on-demand system (or the Web home-page server), in which two users request the same video. If the requests are simultaneous, we can transmit the video once, halving the bandwidth requirements. If the requests are not simultaneous, we have to transmit the same information twice, with a time offset between the copies. Instead, we can insert some buffering into the network to reduce the probability of having to retransmit. The buffer acts as a cache, amortizing the load on the server but transmitting the video at different times, with only the cost of the storage of the offset. This is a very effective use of buffering near the “local loop”. Such techniques are useful in maintaining replicates, for reliability purposes as well.

We do expect that short video clips, made available via a Web interface, will be a predominant high-performance application potentially available during this proposal. Servers that automatically segment broadcast television into short video clips are available from MIT, providing sports highlights by team and textually-indexed jokes from the monologues of late-night shows. Video clip servers are beginning to appear, providing interactive help, such as CD-ROM video training disks and the MTA (Metro Transit) information kiosks (such as in the Municipal Court building, in downtown LA). These servers could be integrated into the WWW to provide distributed access and amortize the cost of production, without requiring the (small) cost of disk replication or the (large) cost of multi-disk players or multiple kiosks.

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

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.

Requirements

The protocol makes of use idle bandwidth to pre-load caches with objects that might be of interest in the future. Therefore, our reliability requirements are not as stringent as in traditional reliable multicast protocols.

Design requirements – lazy multicast transport protocol

Reliable
On top of mIP
Reliability Mechanism:
Servers are stateless. Therefore, receivers are required to provide state when asking for data.
Support for both files and streams for flexibility i.e to say a priori EOF may be known or not.
ACTION ACK:
Support multiple pending transfers.
Either side should be able to initiate a transfer.