1. Objectives
2. Requirements
3. Architecture and Protocols
4. Light-weight Reliable Multicast Protocol
5. Related Issues
6. Current Status
7. References

This is a compressed version. More detailed version is in progress.

1. Objectives

This tool should avoid the problems of the existing Web multicast tools, i.e., with better loss control, portability and user interface.

It is intended to be used for:

• broadcast of press and news release, like a Web news radio, characterized by one to many and batched transmission.
• broadcast of slides, e.g., for education or conferences, characterized by one to many but interactive transmission.
• Web conference, characterized by many to many and interactive transmission.
• further extension to multicast proxy cache.

2. Requirements

Different from other continuous-media applications on the MBONE, the multicast of HTML documents has very different requirements:

• almost real-time. Different from real-time audio and video applications, users can tolerate some delay for receiving HTML documents. The tolerable delay ranges typically from 0 - 10 seconds.
• reasonable rate. The size of HTML documents is relatively small (except including embedded objects). It is reasonable to base the design on use of a limited part of the bandwidth available.
• burst transmission.
• loss is generally not tolerated. Still different from real-time audio and video applications, loss of packets can not be tolerated.
• while 100% reliability is attractive, it is difficult to achieve it in practice. The level of quality of service is to be controlled by the sender to prevent the disturb caused by a receiver with a very bad network connection.
• every user in the group can send documents.
• sender control as an option. There should be a control on the number of senders at the same time to be scalable to large group size.
• interface with existing Web browsers.

3. Architecture and Protocols

To avoid to reinvent the wheel, we intend to make use of the already available protocols and take the maximum benefits from the experience from various projects on reliable multicast protocol.

Since 1980's, a number of reliable multicast protocols have been emerged. Each of them has its own emphasis and application scope.

The complexity of this type protocol grows with the level of requirements on reliability, such as throughput, delay, ordering and loss repair, etc. It is rather difficult, if not impossible, to design one universal protocol which meets the needs of all applications. Reliable protocols should be tailored to the particular requirements of a particular application.

The protocols to be used are shown in the following table. At the top level, Web data are encoded in the MIME format. Then they are delivered to the layer of light-weight reliable multicast protocol which is built on top of RTP (Real Time Protocol).

The light-weight reliable multicast protocol is much like the SRM (Scalable Reliable Multicast) protocol, but with some simplifications. In addition, LRMP provides some functions for session control.

4. Light-weight Reliable Multicast Protocol

4.1 Session control

4.2 Synchronization

4.3 Loss and Flow Control

5. Related Issues

5.1 Interface with Web Browsers

• documents to be sent are specified in a file. This is the batched mode. Weboard reads this list file, and sequentially sends out the documents. For conveniency, no need to include embedded objects in the list. A HTML parser in Weboard allows to fetch them automatically.
• set the Weboard as the proxy of the Web browser. In this way the user's open operations are directed to Weboard. Weboard is charged of fetching the requested document and multicast on the MBONE.
• whereas the proxy scheme allows to catch user's open operations, it is somewhat dangerous since all user's open operations will be multicast, even not intended. Yet other possibilities should be provided. We use a special form of URL, the pipelined URL to allow a user to multicast a document. It is of the following form:

  http://weboard.host:port/|http://www.w3.org/

  which means the first HTTP server in that line to fetch the URL that follows. Thus URLs in the standard form will not be directed to Weboard if it is configured as the proxy server.

5.2 Embedded Objects

While multicast, Weboard sends first the HTML file and sequentially sends embedded objects in the list. At reception, each time an embedded object is received, the displayed HTML document will be refreshed.

There are problems when embedded objects reference other objects, which is the case for java objects.

5.3 Caching

While the currently received document is displayed automatically, users are allowed to view the list of received documents together with related information and have the possibility to display or delete them.

6. Current Status

Work is in progress to implement the LRMP protocol and a multicast simulator that allows test on local networks.

At the time we consider that the code is stable, we will put the Weboard tool available on our ftp site.

References

1. Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, January 1996.
2. H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, Audio-Video Transport WG, RFC 1890, January 1996.
3. T. Turletti and C. Huitema, RTP payload format for H.261 video streams, Audio Video Transport WG, INTERNET-DRAFT, July 7, 1996.
4. Sally Floyd, Van Jacobson, Steven McCanne, Ching-Guang Liu, Lixia Zhang, A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing, ee.lbl.edu, Nov, 1995.
5. Reliable Multicast Protocol, research.ivv.nasa.gov.