Webcanal: a Multicast Web Application

Summary. The paper presents the architecture and protocol for a webcasting application. The protocol, called LRMP, extends RTP/RTCP to offer reliable service.

More Detail

• broadcast of frequently updated Web documents such as news or press release (characterized by one to many, batched transmission)
• broadcast of slides (characterized by one to many, interactive transmission)
• Web conference (characterized by many to many, interactive transmission)

The authors mention mWeb, but don't differentiate themselves from it.

Differences between SRM and LRMP:

• Sender-only repair. Four points:
  1. The author believes that "all-involved recovery" is appropriate only if local recovery is implemented. The problem with this is that both libsrm and LRMP now implement local recovery.
  2. The author also note that the control traffic necessary to maintain sender round-trip times necessary for all-involved recovery could grow prohibitively large. There is a flaw in their argument. They state that late joiners will seek timestamp information in the form of a protocol. However, in SRM timestamp information is piggy-backed in session announcements which are multicast at low-rates and limited to a certain percentage (such as <5%) of session traffic so as to avoid control traffic implosion.
  3. The argue, also, that all-involved recovery could lead to duplicates multicast to the whole group. Although SRM implements slotting/dampening, it is true that this is possible.
  4. The author notes that sender-only repair saves the recipient from having to cache. WebCanal recipients cache, anyway. Furthermore, SRM recipients can choose not to cache old data.

• Application-level control. LRMP allows the application some control of recovery. In the event that a receiver finds too great a difference between the currently receiveda sequence number and that of the first lost packet, the receiver will send a SYNC_ERR. At the sender side, LRMP will report the reception of the SYNC_ERR packet and the application bears the responsibility for addressing (or not) the situation. (In SRM, all-involved recovery addresses this situation.) In SRM, the application is given control over many things: ordering, reliability, framing, protocol (in that it can add additional messages).

• RTP. LRMP is implemented as an extension to RTP/RTCP which, alone, provides unreliable, unordered service meant for real-time protocols for which end-to-end delay is important. This seems a mismatch for webcasting which has loose end-to-end delay requirements but strict reliability requirements. SRM is implemented directly on top of UDP.

• Flow control. LRMP implements flow-control using using rate-based mechanism. Their algorithm uses information reported by RTCP Receiver Report packets; xmission rate decreased when there are many receivers with a significant loss rate and increased when there are few. Their algorithm may cause reception failure at the worst senders. libsrm implements rate control of data transmission, but I'm unsure of the algorithm.

Differences between WebCanal and MASHCast:

• LRMP vs. SRM (see above).

• Both SRM and WebCanal users can request past events, but WebCanal users must always explicitly request past events while MASHCast can be configured to impose an always-recover or lazy-recovery policy. WebCanal does provide a list of past-seen pages that can be retrieved from the sender -- that's a nice touch.

• WebCanal doesn't make an effort to eliminate duplicate server hits that could result from the synchronization inherent in collaborative situations. For example, in a lecture setting, a reference to a URL by the lecturer may prompt many listeners to request that URL nearly simultaneously. In MASHCast, these requests are dampened by reply-pending message timers. In WebCanal, this situation could result in server implosion.

• Because WebCanal doesn't use all-involved recovery, if the sender is partitioned (which could be common in a collaborative session amongt geographically disparate participants) a late-joiner cannot retrieve the data. The probability of this happening is lessened in MASHCast where only if the late-joiner is partitioned can they not retrieve the data. Also, if the late-joiner is partitioned, the late-joiner will be selected to fetch it (this is assuming that they have the URL to fetch).

• HTTP Proxy. In Webcanal, can use a pipe-lined URL to avoid setting the proxy (http://Webcanal.host:port/|http://www.w3.org/). In MASHCast, the URL is mangled by the CastingDirector to form a pipe-lined URL.

• Persistent disk cache. Both use persistent caches on disk.