W3C HTTP 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:

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

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:

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.

Jim Gettys,
@(#) $Id: 951005_Problem.html,v 1.5 1997/06/05 21:00:03 jigsaw Exp $