HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:25:47 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:34:00 GMT ETag: "2e7ca9-3da5-350ea5f8" Accept-Ranges: bytes Content-Length: 15781 Connection: close Content-Type: text/plain INTERNET-DRAFT Bernard Aboba Microsoft Corporation Requirements for Unreliable Multicasting of Web Resources 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires October 1, 1997. Please send com- ments to the authors. 2. Abstract This document discusses applications for unreliable multicasting of Web resources as well as requirements for an unreliable multicast pro- tocol suitable for this use. 3. Introduction 3.1. Purpose Many Web sites that distribute popular, frequently updated content experience problems with "flash crowds": thousands of access per minute to the same Web page overload the Web server or the network link leading to the server. Moreover, with the increasing growth of "push" technology, it is likely that these problems will get worse, not better. It is possible that IP multicasting of Web resources may be used both to solve serious existing operational problems like "flash crowds", and to avoid creating new problems due to "server push" applications. Several applications appear to be naturally amenable to use of unreli- able multicast. Aboba [Page 1] INTERNET-DRAFT 26 March 1997 In this context, unreliable refers to applications where a repair mechanism is not required. These are typically applications where the material is of time value (stock tickers), so that it makes more sense to wait for the resource to be re-multicast than to attempt to repair it; applications in which an alternative means is available for retrieving the resource (cache filling); applications in which error correction is performed at the datalink layer; or applications in which a separate error correction stream is transmitted along with the data, typically on a separate group. In a cache filling application, there is a relatively small probabil- ity that a particular missing resource will be hit, and so it is often more costly to request a repair than to leave an incompletely received resource in the cache, where it may never be requested. Cache hits when they do occur, will typically be spread out over time, and there- fore not synchronized to the original transmission. As a result, such applications present no danger of a NAK implosion. 4. Requirements The requirements for unreliable multicast transmission of Web resources are as follows: Transport issues Robustness Prioritization Low overhead Encapsulation issues Source differentiation Resource demultiplexing Receiver reporting Sender reporting Layered encoding Need for an encoded clock 4.1. Transport issues 4.1.1. Robustness It is desirable that an unreliable Web multicast scheme be efficient in transmission of small as well as large resources. Where transmission of large resources is required, unreliable multi- casting techniques may be quite effective. For example, in a cache filling application where 80 percent of the file has been received prior to a cache miss, 80 percent of the bandwidth required to retrieve the resource would have been saved, which would greatly out- weigh the cost of the connection setup for the subsequent cache miss. However, most Web resources are in the 1 Kbyte to 10 Kbyte range, and so if the profile of resources transmitted via unreliable Web Aboba [Page 2] INTERNET-DRAFT 26 March 1997 multicasting were to more resemble the average, then an optimized encapsulation is likely to require from 2 to 20 packets. In this case unsophisticated unreliable multicast schemes are likely to be highly vulnerable to packet loss. The effect of packet loss may be mitigated by a number of techniques, including utilization of an error correc- tion channel, as well as use of a data carousel, possibly operating with offset layering. The use of an error correction channel is only likely to be effective for non-burst errors. Where errors are relatively uncorrelated, the effect of packet loss may be mitigated at the expense of additional overhead proportional to the loss rate. To allow receivers to sub- scribe to an error correction channel up to their estimated loss rate, it is necessary for the transmission rate to be sufficiently below the channel capacity so as to allow for the receiver to subscribe to the transmission as well as to the required error correction group. Where burst errors are present, error correction channels will not be very effective and the resulting reception time will increase. If packet loss rates are substantial, then many revolutions of the data carousel will be required since on each revolution of the carousel the chance of completing the transmission will be small. Thus, after a certain number of carousel revolutions, it probably makes sense to stop listening. Thus in an unreliable multicast transmission there is a distinct possibility that the transmission will not complete, and the application must be able to deal with this effectively. 4.1.2. Prioritization In situations where "flash crowds" are anticipated, it is desirable to encourage use of unreliable Web multicasting, possibly at the expense of unicast retrievals of the same resource. As a result, it will be desirable for unreliable Web multicasts to reside on a high priority multicast port; in addition, it may be desirable for this traffic to be prioritized above unicast HTTP. 4.1.3. Low Overhead Since resource multicasting will typically use a small MTU size (i.e. 536 octets), it is important that a low overhead encapsulation be cho- sen. In order to achieve this, the URL must not be sent in every packet. In addition, it may be desirable to support header compres- sion. 4.2. Encapsulation issues Aboba [Page 3] INTERNET-DRAFT 26 March 1997 4.2.1. Source differentiation Since mixing is not useful for transmission of Web resources, and allowing multiple sources would make it difficult to maintain rate control, it is likely that only one source will be sending to a group at one time. Nevertheless, in the case where there is a handoff, it is necessary to be able to differentiate sources, since packets from the two sources may be intermingled. However, it appears that this source differentiation can be accomplished using the source IP address and port, without requiring a source ID in addition. 4.2.2. Resource demultiplexing For multicast resource transmission, it desirable to be able to reuse a group and port for the sending of multiple resources. Resources are typically of small size, and therefore the overhead of obtaining a group address and setting up the transmission would be excessive. Since it is possible for packets from one resource to become intermin- gled with another due to out of order delivery, it is necessary to be able to demultiplex resources sent from a single source. However, it is typically undesirable to have to include the resource URL in every packet, since packets will typically be small, and URLs may be large. Therefore a resource ID is likely to be required. 4.2.3. Receiver reporting Even though we are discussing unreliable transmission, some kind of receiver feedback is likely to be desirable. Such feedback can be used to estimate listenership, packet loss rates, and receiver band- width availability. Jitter is not likely to be a useful metric for reception quality in this case. Typically, receiver reporting information will be used both for engi- neering purposes (diagnosis of transmission problems) as well as for business purposes (listenership information). While receiver reports could be useful in allowing senders to adjust transmission parameters, typically it is more desirable to allow receiver-driven rate adapta- tion via layered encoding. By transmitting a resource on several groups, each starting transmis- sion with a different offset, the receiver may adjust their reception rate based on the available bandwidth. Typically, the group transmis- sion rates will be tailored to commonly available bandwidths, i.e. 10 Kbps for 14.4 Kbps modems, 20 Kbps for 28.8 Kbps, 30 Kbps for single channel ISDN, etc. Sender-driven transmission rate adjustment appears to be useful in only a limited number of circumstances. In cases where a small frac- tion of listeners are experiencing problems, it is undesirable to adjust the transmission rate; instead, the affected receivers should adjust their rate by leaving the higher bandwidth groups. If this does not work, they should stop listening to the transmission Aboba [Page 4] INTERNET-DRAFT 26 March 1997 altogether. A circumstance in which sender-driven transmission rate adjustment appears useful is in the case where the majority of listeners are only subscribed to the lowest transmission rate group, yet appear to lack the bandwidth to also join an error correction group appropriate to their packet loss rate. In this case the sender should back off the transmission rate on the lowest group to allow for successful recep- tion of the error correction information. As there are applications in which receiver feedback may not be feasi- ble or desirable (satellite transmission), it must be possible to turn off the receiver reporting mechanism if desired. 4.2.4. Sender reporting Just as receivers may wish to provide feedback to senders, so may senders wish to provide instructions to receivers. This may include information about the particular resource being transmitted (such as the resource length, related keywords, or URL), or information on the status of the transmission itself, such as the highest offset trans- mitted. 4.2.5. Layered encoding Layered multicasting appears to be essential for multicast transmis- sion of resources, since it provides for receiver-driven rate adapta- tion, as well as for transmission of error-correction information. While layered encoding was originally proposed for use in audio/video transmission, it can also be applied to data carousel style transmis- sions. In this application, each of the layers transmits the same resource, beginning at a different offset. Receivers with sufficient bandwidth may then subscribe to multiple groups, and receive the resource more quickly. Layered encoding may also provide for error correction, by allowing error correction information to be transmitted on separate groups. Receivers may then subscribe to these groups according to their aver- age packet loss rate; receivers experiencing high loss rates will typ- ically join a higher bandwidth error correction group. In order to allow for the additional bandwidth of an error correction group, the sender transmission rate should be set appropriately. 4.2.6. Need for an encoded clock Most uses of unreliable resource multicasting do not have realtime requirements, and as a result, it is not envisaged that unreliable multicasting of Web resources requires an encoded clock. Aboba [Page 5] INTERNET-DRAFT 26 March 1997 5. Acknowledgements Thanks to Harald.T.Alvestrand, Jim Gemmell, Paul Leach and Thomas Pfenning for useful discussions of this problem space. 6. References [1] R. Braden. "Requirements for Internet hosts - application and support." STD 3, RFC 1123, IETF, October 1989. [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, January 1996. [3] H. Schulzrinne. "RTP Profile for Audio and Video Conferences with Minimal Control." RFC 1890, GMD Fokus, January 1996. [4] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, LBNL, June 1996. [5] J. Palme, A. Hopmann. "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)." draft-ietf-mhtml-spec-03.txt, Stockholm University/KTH, ResNova Software, August, 1996. [6] E. Levinson. "The MIME Multipart/Related Content-type." draft- ietf-mhtml-related-00.txt, Xison, May, 1996. [7] J. Palme. "Sending HTML in E-mail, an informational supplement." draft-ietf-mhtml-info-03.txt, Stockholm University/KTH, August, 1996. [8] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. [9] J. Crowcroft, Z. Wang, A. Ghosh, C. Diot. "RMFP: A Reliable Mul- ticast Framing Protocol." draft-crowcroft-rmfp-00.txt, UCL, November, 1996. [10] P. Parnes. "RTP Extension for Scalable Reliable Multicast." draft-parnes-rtp-ext-srm-01.txt, LuTH/CDT, November, 1996. 7. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 6]