ITU Telecommunication Standardization Sector	Document APC-1308
Study Group 16	
Q.12-14/16 Rapporteur Meeting	12 August 1997
Sunriver, 8-11 September 1997

SOURCE:  Yong-Min Choi, Sang-Gil Kim / Korea Telecom
Tel : +82 2 526-5106, 5124
Fax: +82 2 526-6498
e-mail: himrchoi@rcunix.kotel.co.kr, sgk@ktweb.kotel.co.kr

TITLE: 	The Necessity of Standardization on Reliable Multicast Protocol

PURPOSE:
This document presents a brief technical overview of several higher level protocols used with IP Multicast and suggests the necessity of standardization on reliable multicast protocol. First, Protocols that have been developed to support real-time multimedia delivery are epitomized. These include the Real-time Transport Protocol (RTP), the control protocol (RTCP) that works in conjunction with RTP, the resource reservation protocol (RSVP), and the real-time streaming protocol (RTSP). Next, reliable IP Multicast protocols, an emerging standards area, are discussed. Some of the transport-layer reliable multicast protocols that have been announced are described briefly.

1.	Need for additional protocols
The Internet has been used primarily for the reliable transmission of data with minimal or no delay constraints. The TCP/IP protocols were designed for this type of traffic and work very well in this context. However, multimedia traffic possesses different characteristics and hence requires the use of different protocols to provide the necessary services. Since there is no fixed path for datagrams to flow across the Internet, there is no mechanism for ensuring that the bandwidth needed for multimedia is available between the sender and receiver, so quality of service cannot be guaranteed. In addition, TCP doesn't provide timing information, a critical requirement for multimedia support.
Multimedia applications can generally forego the complexity of TCP and use instead a simpler transport framework. Most playback algorithms can tolerate missing data much better than lengthy delays caused by retransmissions, and they do not require guaranteed in-sequence delivery. A number of protocols have been developed to enhance the Internet architecture and improve support of applications like audio, video and interactive multimedia conferencing. The RTP, RTCP, RSVP and RTSP protocols are introduced below in Table 1. These real-time oriented protocols are designed to be used over both multicast or unicast network services. 
Since many real-time applications can conserve network and server resources by using IP Multicast, the special requirements and characteristics of IP Multicast have been considered in the design of protocols, such as scalability, multicast routing, and accommodation of large numbers of receivers and heterogeneous receivers. However, IP Multicast cannot  provide reliable services, which assure receiving of all packets by all of the recipients. Reliable delivery is, therefore, guaranteed by error correction schemes which are designed to overcome the limitations of unreliable multicast datagram delivery without burdening the network. Some of the transport-layer reliable multicast protocols that have been announced are described briefly. 
Table 1. Comparison of Higher Level Protocols
	RTP	RTCP	RTSP	RSVP	
Purpose	- To transmitting real time data	- To support RTP	- To provide robust protocol for streaming multimedia	- To provide timely delivery and guarantee a QoSs	
Standard	IETF RFC 1889	Draft	Draft	Draft	
Layer	RTP/UDP/IP	RTCP/UDP/IP	RTSP/RTP/UDP/IP	RSVP/IP	
Function	- To provide time information (to synchronize and display audio and video data and to determine lost packets and packet arrival disorder)
- To provide end-to-end delivery services	- To provide information to application
- To identify RTP source
- To control RTCP transmission interval
- To convey minimal session control information	- Framework rather than protocol	- To make a resource reservation
- Forward the request upstream
- To provide session layer services	
* RTP : Real-Time Transport Protocol
* RTCP : Real-Time Control Protocol
* RTSP : Real-Time Streaming Protocol
* RSVP : Resource Reservation Protocol

2.	Reliable Multicast Protocol
IP Multicast enables applications to significantly reduce the load on network resources and to scale to higher levels. Reliable services ensure the sender that all packets are received by all of the recipients. Reliable delivery is required by many real time and non-real time applications. In the real time area, data conferencing, web services and data broadcast applications use reliable services. Non real-time applications such as information and software distribution, and file transfer also need reliable services.
For unicast IP services, error correction and detection in the TCP layer provides reliability. Such traditional techniques for error detection and correction in a large scale multicast environment might result in an overload of acknowledgments to the sender, which would increase network congestion. Reliable multicast protocols provide error correction schemes which are designed to overcome the limitations of unreliable multicast datagram delivery without burdening the network. There are many approaches to reducing the number of acknowledgments in a reliable multicast service. The error correction mechanisms can vary, depending on application requirements and the multicast environment.
A list and comparison of the reliable Multicast Protocols are described briefly in the following.
2.1 Reliable Multicast Transport Protocol (RMTP) by Lucent Technologies
The RMTP protocol, developed by Lucent Technologies, was designed to provide bulk distribution of files and is interesting in its use of a hierarchical tree to ensure scalability. RMTP has been implemented on the MBone and a version of RMTP/UDP/IP is currently deployed in AT&T's switched network, which uses only IP-Multicast routers.
-	Reliability: 
Multi-level Hierarchical approach in which leaf receivers periodically send status messages to their Designated Receivers (DRs).
Status messages consist of the lower end of the flow control window and a bit vector indicating which packets were received and lost relative to the window's lower end. DRs, in turn, send their status periodically to the higher layer DRs and so on until the DRs at the highest level send their status to the Sender. Lost packets are recovered by local retransmissions by their DR. Retransmissions are either unicast or multicast based on a threshold. 
-	Heterogeneous: 
Supports completely reliable and quasi-reliable modes. 
-	Scalability: 
Demonstrated over 18 sites in different U.S. states and Taiwan on the Internet.. 
-	Flow Control: 
A combination of rate control and window-based control. The sender can set its maximum rate before a session begins and then it can adjust its rate based on the status of receivers. Uses a TCP-like slow start mechanism when congestion is sensed. (e.g. multiplicative back off and linear increase of window size) 
-	Late-join/Leave: 
Supports late join/leave by using a two-level cacheing mechanism at each DR and at the sender. The size of the cache may be changed depending on how late you want to allow a receiver to join an ongoing session. 
-	Fragmentation/Reassembly: 
        Supported. 
-	Ordering: 
Information from each receiver is delivered in order. However, RMTP does not guarantee causal delivery or various application level semantics like RMP does.
2.2 Reliable Multicast Transport Protocol (RMTP) by NTT and IBM
Separate retransmission and polling are also effective to avoid unnecessary multicast retransmission. Packet scramble has been applied to RMTP to safeguard from illegal use of multicast data. This offset the defect of IP multicast; everybody can pick up multicasted IP packets. RMTP by NTT and IBM is based on only end-to-end communication, and does not use window-based retransmission, but uses rate-based flow control, while the other RMTP uses intermediate nodes to gather ACKs and based on window-based retransmission and flow controls. The two approaches are in completely opposite directions. Two RMTP codes exists. One was developed by NTT and the other by IBM independently only by sharing the protocol specification. Interconnectivity tests for the two implementation was executed successfully in September 1995 and the interoperability of RMTP version 1 specification has been proved.
-	Reliability: 
RMTP is oriented for reliable massive data distribution to large number of users. Publication and software delivery which require completely error free replication are typical applications. Reliability is achieved by end-to-end communications instead of using gateways. RMTP is realized on UDP and IP stack. IP multicast is used for the data flow from a server to receivers. Reliability(error recovery) is based on error detection by receivers and NACK is used for reporting the packets loss. For one round of data re/transmission consisting of whole data packets which are not received by all receivers, only one NACK or ACK is used. ACK is used for complete data receiption notification by receivers instead of implicit receipt notification by timeout. polling packet is also send by the server to unresponding receivers. Backoff time algorithm is applied to offset ACK implosion problem. RMTP is a connection oriented protocol including receiver confirmation and logging. This is for subscriber confirmation and for billing, and also applicable for user authentication.
-	Heterogeneous: 
RMTP has a separate retransmission function by which BUSY declared receivers are retransmitted after the main multicast re/transmission phase. BUSY declare receivers are retransmitted by unicast at present implementation. The server detected separation of performance impared receivers are under test and to be included in the version 2 specification.
-	Scalability: 
RMTP has been tested for 5000 receivers with including error and delay emulation in LAN environment. In the experiments, RMTP has been able to deliver 2Mbyte of data to 5000 receivers in 3 minutes, while four parallel FTP usage consumed 3 hours in the same environment.
-	Flow Control: 
Monitoring-based rate flow control has been applied to RMTP and has shown a drastic throuphput improvement while reducing redundant retransmission.
-	Late-join/Leave: 
Membership is static during the established connection.
-	Fragmentation/Reassembly: 
Multiple use of RMTP provides very massive data transfer.
-	Ordering: 
Packet reordering is supported at receivers. Message ordering is out of scope at present.

Reference
Web Sites
1. 	http://www.cs.columbia.edu/~hgs/rtp/			RTP information
2. 	http://www.isi.edu/div7/rsvp/rsvp-home.html		RSVP information
3. 	http://www6.real.com/prognet/rt/		RTSP Resource Center
4. 	http://www.ipmulticast.com/		IP Multicast Initiative
IETF RFCs
RFC 1889 RTP: A Transport Protocol for Real-Time Applications
RFC 1890 RTP Profile for Audio and Video Conferences with Minimal Control
RFC 1458 Requirement s for Multicast Protocols
RFC 2090 TFTP Multicast Option