4.9 Service and management issues

4.9.1 Quality of Service (QoS)

Quality of Service (QoS) is an area of increasing prominence in network design, and there are several reasons why QoS is of particular importance in multicasting. These include the following:

Guaranteed delivery—Service guarantees are highly desirable for applications that send audio and video or other real-time, high-bandwidth, or mission-critical data; consistent delivery is a concern. QoS considerations for multicast applications include tolerance to jitter, delay, and lost packets. In order to satisfy these requirements, the application must be able to reserve and exercise some control over network resources on an end-to-end basis, adding considerably to the complexity of the routing task.
Well-defined service characteristics—Multicast routing protocols use a number of techniques to construct multicast trees in order to deliver multicast traffic to group members. The physical paths involved in reaching these users will often vary in bandwidth and quality, as do the traffic conditions across different parts of the network. Multicast delivery trees do not guarantee any specific QoS, leading to potential unfairness in application service (particularly important in applications such as market data feeds). In order to satisfy QoS requirements when setting up a path, routers must include parameters such as delay, bandwidth, loss probability, cost, and jitter in their routing metrics. As we saw earlier, several of these constraints are contradictory, and it might be appropriate to let the user or application define the order in which these parameters are evaluated.
Traffic engineering—Some multicast routing protocols rely on flooding techniques. With sufficient bandwidth (e.g., a local enterprise), QoS is unlikely to be a problem. However, in relatively low bandwidth environments (such as a wide area network), it is highly desirable that traffic engineering be employed to constrain these application flows within known bounds to preserve bandwidth and keep costs down.

The issue of incorporating QoS routing with the various multicast routing protocols is being actively researched. The Resource Reservation Protocol (RSVP) has been specified by the IETF for use with both IPv4 and IPv6, and support for IP multicast QoS has been a consideration from the outset. For various reasons RSVP is unlikely to provide an end-to-end solution across large internetworks, and a longer-term solution to the problems of reliable IP multicasting is discussed in the next section.

4.9.2 Reliable IP multicast

All of the protocols we have discussed so far assist in the timely and efficient delivery of multicast traffic to multiple users, but they do not guarantee delivery. Traditional non—real-time applications (such as file transfer or terminal emulation) already have guaranteed delivery through protocols such as TCP, which offers full error detection and correction. The new generation of real-time applications requires similar support but without the overhead of a full connection-oriented transport protocol. As specified in [35], no single reliable multicast protocol is likely to meet the needs of all applications. Therefore, the IETF expects to standardize a number of protocols that are tailored to meet specific application and network requirements. This section briefly overviews some of the work in progress and discusses some of the issues involved.

Requirements

Reference [35] outlines the requirements for reliable multicast protocols that are to be considered for standardization by the IETF. They include the following:

Congestion control—The protocol must be safe to deploy in the widespread Internet. Specifically, it must adhere to three mandates: it must achieve good throughput (i.e., it must not consistently overload links with excess data or repair traffic), it must achieve good link utilization, and it must not starve competing flows.
Scalability—The protocol should be able to work under a variety of conditions, including multiple network topologies, link speeds, and the receiver set size. It is more important to have a good understanding of how and when a protocol breaks than how and when it works.
Security—The protocol must be analyzed to show what is necessary to allow it to cope with security and privacy issues. This includes understanding the role of the protocol in data confidentiality and sender authentication, as well as how the protocol will provide defences against Denial of Service (DOS) attacks.

These requirements are designed to ensure that protocols will be safe for widespread Internet deployment.

Design issues

As already intimated, many of the popular real-time applications, such as interactive multimedia, can tolerate some packet loss, and the sequencing and timing services provided by protocols such as RTP ensure that playback is still meaningful. For example, loss of a few frames in a video stream generally makes no difference to the perceived quality of the participants, since the human brain is smart enough to fill in the gaps. However, in a financial application, such as stock trading, loss of even a single packet can be disastrous. Participants in such an application generally demand guaranteed fairness and no loss of data. In the past such applications were implemented by providing each subscriber with a dedicated TCP session, but that approach does not scale, for reasons discussed in section 4.1.3. In a multicast environment it may be important that all updates reach all subscribers so that no group of users has an unfair advantage.

Reliable multicast protocols have the difficult task of providing timely error detection and correction without overburdening the network or compromising scalability. To date this functionality has often been built into the application itself by those wishing to pioneer this technology, with varying degrees of sophistication. For example, the client side of a multicast application could check received sequence numbers (either provided via RTP or through its own application protocol). If sequence numbers are out of order, or missing, then it could simply request resynchronization from the server at the last good event. The problem this raises in a multicast environment, especially in a stock-trading application, is how to update that subscriber in real time, for example:

Should we send updates via a dynamic reliable unicast session (e.g., a TCP session)?
Should we use a separate multicast or port address to redistribute lost data?
Should we send positive acknowledgments for every packet or only negative acknowledgments for missed packets?
Should we use sender-based Forward Error Correction (FEC) to ensure good throughput (since feedback is not required from receivers)?
Should we restart the whole multicast advertisement process back at that event to ensure that all parties are in sync and no unfair advantage is given?
Where should packets be buffered for possible replay? Should this be the responsibility of the server or some intermediate device?

Current status

This is a highly active area of research; several Internet drafts have been submitted related to reliable multicasting, and an Internet Research Task Force (IRTF) has recently been formed to expedite the development of standards-based reliable multicast. There are also a few vendors that offer proprietary reliable IP Multicast solutions designed for different applications and network environments, including support for applications such as multicast file transfer. Surveys of reliable IP Multicast protocols have been conducted as part of the DARPA Multicast Implementation Study (MIST). The interested reader should refer to [36, 37].

Reference [38] describes a reliable multicast transport protocol framework (RMF), which is designed to support reliable end-to-end delivery of multicast data. RMF does not define a specific protocol but provides a supporting framework. RMF guarantees delivery of data to all participants and provides some ordering mechanisms but does not reserve bandwidth (again, the domain of RSVP). RMF is designed to be independent of the underlying Transport and Network Layers.

An implementation called Reliable Multicast Protocol (RMP) is available to academic and research institutions under a no-cost license agreement, and is licensed commercially by GlobalCast Communications; see [39, 40] for further information. Another implementation called the Reliable Adaptive Multicast Protocol (RAMP), developed by TASC, Inc., and the University of Massachusetts at Amherst, is available (with C++ and Java source) from [37].

The Active Error Recovery/Nominee-based Congestion Algorithm (AER/NCA) protocol, developed by the DARPA-sponsored PANAMA project, utilizes active networks to enhance reliable multicast performance in a heterogeneous network. The services offered include repair services, as well as aggregation services for Round-Trip Time (RTT) estimates and congestion control. Version 1.1 of the software and use cases has been released and is available from [41].

Work on congestion control is maturing rapidly via the Reliable Multicast Congestion Control (RMCC) [42] in the IRTF Reliable Multicast Research Group (RMRG) and has enabled the IETF to charter the RMT working group. Work on reliable bulk transfer is outlined in [43]. For general material and research data on reliable IP multicast, the reader should refer to [1, 44].

4.9.3 Multicast service management

We have discussed the protocols for obtaining multicast group membership (IGMP) and multicast routing (DVMRP, PIM, OSPF, CBT, etc.), as well as protocols for supporting real-time applications (RTP, RTCP, RTSP). However, these protocols merely provide a delivery path; they have no knowledge of the applications they support and therefore cannot disseminate knowledge about applications. We have also seen that there are different models for multicast applications. For example, a conference setup application uses a many-to-many model, whereas permanent guides (analogous to TV Guides) uses a one-to-many model, where a listener joins the guide group to find out which IP Multicast sessions are of interest. Given the dynamic nature of multicast services, users and administrators require standard mechanisms for handling multicast application management issues such as the following:

Service announcements and conference invitations (including the name and subject of the session, time of event, duration)
Reachability information (i.e., which multicast address and port to use)
Media types and encodings (audio, video, etc.)
Security parameters

Currently the configuration of network nodes for multicast services is the responsibility of the network administration staff. Users must be made aware of new services or service changes through mechanisms such as e-mail or the Web, and there is no standard capability to automate service. The IETF Multiparty Multimedia Session Control (music) Working Group is actively developing protocols for the management and coordination of multimedia sessions. To date their primary focus has been to enable conferencing over the MBone and protocols to emerge so far include the Session Description Protocol (SIP), Session Directory Announcement Protocol (SDAP), and the Simple Conference Control Protocol (SCCP). For further details, refer to [45–47].