IB 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.