1. Objectives

This tool is designed for exchange of Web documents, basically of the text/html
MIME type, on the Internet, in multicast mode among a group of people, or in
unicast between two users. It is also aimed as a testbed to experiment
reliable multicast protocol on the "text" media.

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

Protocols

MIME Encoded Data

Light-weight Reliable Multicast Protocol (LRMP)

RTP/RTCP

UDP/IP

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

Not yet available.

4.1 Session control

4.2 Synchronization

4.3 Loss and Flow Control

5. Related Issues

5.1 Interface with Web Browsers

Weboard is intended to be interoperable with multiple Web browsers.
It functions like a multicast proxy server to browsers.
There are three ways to multicast documents:

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.

We have tested the last method, it works well when the HREF links in
the document are relative path names.

5.2 Embedded Objects

Embedded objects and inline images are parts of an integral Web document.
They should be sent together with the document where they are embedded.
Weboard parses the HTML document to be sent to collect embedded objects.
Embedded objects are maintained in a list related to the HTML document.

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

Weboard caches all received documents.

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

The prototype is being implemented in java. Current version does not
include the LRMP protocol. It runs well on a local network where almost
no loss is encountered.

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.