1995

HTTP Problem Statement

General Web Transport Problem Statement

In order for the Web to continue to grow and prosper, we need to broaden the usability and scalability of the Web in some areas. Here are some example areas where current HTTP performs poorly or not at all:

• You are attending a lecture in an auditorium full of 300 others with laptops sharing a single radio or I/R link. You want to be able both to see the lecturer's slides (which contain both animations and video), while browsing elsewhere on the Web.
• You use your PDA or portable over your cellular telephone or wireless connection. Research prototypes exist today for such systems.
• An advertiser buys a 30 second commercial during the World Cup or Super Bowl, and at the next commercial break, you, along with 2 million other people attempt to access the same URLs. We already see problems of "flash crowds" on the Web, and these will become more and more common.
• You want pages that contains both dynamically updating text and and embedded video window. Such prototypes exists today in commercial laboratories.
• You are using a disconnected (from the Internet) laptop on the beach in the Carribean. When you reconnect, your system it should be able to re validate its cache, pick up notification of changes in the Web you are interested in, and potentially post forms you've filled out.

Many more examples are easy to generate. Each of these examples can be characterized by one or more of the following issues:

• Scaling
• Latency
• Bandwidth
• Disconnected operation

One can argue that bandwidth and latency of the Internet will improve to wired locations. However, wireless PDA's and portable machines, where power consumption imposes serious limits, and satellite links to remote locations where speed of light limits latency, makes it clear bandwidths in the 9600-19200 baud range and latency in the >1/2 second range will be with us for a long time. Latency and bandwidth are independent variables; for example satellite IP systems exist today which provide good bandwidth to remote locations, but poor latency. Both round trips and bandwidth usage must be minimized.

Scaling issues are obviously already a major issue. The Web now is the heaviest user of bandwidth on the Internet. Solutions to some of the above examples will likely require use of multi-cast. Any Web protocol deployed must deal with issues that affect the network; e.g. congestion control, use of name services, etc. The Web needs to scale up to handle the high load cases.

Family of Protocols

We envision HTTP-NG as one member of a family of protocols. These include protocols for:

• Caching and replication of Web servers and proxies
  The caching/replication protocol will likely be primarily used between replicas and caching proxy servers.
• Notification of changes
  Users need to be notified of changes in the Web. This theme came up many times at the Collaboration workshop as an essential enabler for collaborative systems. Exact requirements were not yet understand. Note the potential interactions between caching proxies and end users for disconnected operation for notification.
• Client/server transport, primarily browsers to (proxy) servers. This is the protocol we currently call HTTP-NG. A browser on a relatively high speed network might also participate in notification and caching protocols under some circumstances, but that the client/server protocol is intended as the human-driven transport protocol between browsers and servers.

Most current users of the WWW are now at home, optimistically a minimum of 160 milliseconds from the closest part of the internet. (measured to a local ISP, using 28.8K-baud modem). Slower modems, cellular modems and many wireless systems have even higher latency and lower bandwidth. HTTP 1.X is a simple request/response protocol, not designed for the environment where it is now most heavily used. Persistent connections in HTTP 1.X will solve some, but not all of these problems; HTTP itself requires many unneeded round trips. The current protocol is also a limitation on browsers pre-fetching or post-fetching information as links are followed.

To solve the problems presented by these realities of the global internet, we need a client/server protocol enabling out of order operation, priority control over operations, streaming ("batching"), and good bit efficiency, to enable better browser performance and better use of the web over low bandwidth and high latency connections.

Simon Spero's work is a good starting point for discussion; he has worked hard to minimize round trips in his design, to overcome latency problems. He has a complete analysis of a HTTP session worth reading.

HTTP-NG needs to be defined to allow its use with other transport protocols as they become available (e.g. T/TCP), that may allow for lower latency operation, and potentially to take advantage of other services the Internet may provide in the future (e.g. RSVP).

The WWW is only one of a number of important Internet protocols; our challenge is also to allow for smooth integration of other services (e.g. audio and video protocols) into the WWW, rather than believing that HTTP-NG is the universal transport for all applications (though it will be a very important one...). Security, authentication and authorization must work well in this context of a family of protocols; such information must be able to be shared with other companion protocols as are already in use with the Web.