An Extensible RTCP Control Framework for Large Multimedia

An Extensible RTCP Control Framework for Large Multimedia Distributions Paper by: Julian Chesterfield Eve M. Schooler Presented by: Phillip H. Jones

Motivation • Multimedia sessions typically relay on Real-time Transport Protocol (RTP) for transmitting data, and on Real-time Transport Control Protocol (RTCP) for transmitting control information. • As the number of entities involved in a Multimedia session increases, and in asymmetric heterogeneous broadcast environments the RTCP protocol becomes ineffective (e. g. Source Specific Multicast (SSM), satellite networks)

Objectives • Provide extensions to RTCP to address – Scalability, to allow RTCP to support large Multimedia heterogeneous sessions. – RTCP inability to operate effectively in unidirectional/asymmetric broadcast environments

Background RTP / RTCP • Real-time Transport Protocol (RTP): An Internet standard for sending realtime data (e. g. , Internet telephony, interactive audio/video). It consists of a data and control (RTCP) component that work together. – Data: provides support for streaming data (e. g. timing reconstruction, loss detection, data content type) • Real-time Transport Control Protocol (RTCP): The control part of RTP. Provides 3 (4) main functions: – Data delivery monitoring • Provides function to application for sending and receiving status reports • Entity outside a session can monitor reports to verify correct functionality of a session or debug issues occurring during a session – Src Identification – Allow session member to calculate the rate to send status messages – Minimal session management? ? (Optional)

RTP Packet Header 0 1 2 3 0123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V: version, P: padding, X: extension, CC: CSRC count, M: maker, PT: payload type

Examples of information sent in RTCP status messages • Time Stamps: Network Time Protocol (NTP), RTP – Used to correlate time stamp of a given session to absolute wall clock time – Can be used to make rough estimate of round-trip time between receivers • Fraction of packets lost, Total packets sent • Sender ID of the Status message • Messages can be extended to provide addition information depending on Packet Type

Why RTP instead of TCP? ? • In many cases real-time Multimedia applications (e. g. streaming audio, video) are more concerned with constant data rate instead of having a guarantee of receiving all packets and in order. – TCP is good for applications that need grantees on delivery and delivery order. However the resend protocol of TCP can cause unacceptable delays in real-time data streaming applications – RTP is designed to focus on: • Supplying applications with constant data rate • Giving applications feed back on the quality of a link that can in turn be used to allow the application to adapt to changing link conditions.

Underlying Assumptions of RTP • #1 All entities are fully connected to each other allowing for a feedback path for control/status information between all entities – Protocol implements status/control information distribution by simply letting a entities broadcast its control/status information to all other entities – To mitigate the amount of control traffic verse data traffic a non-scalable (as far a status interval delay) requirement for the amount of network bandwidth allocated for control information is implemented • #2 All entities are equal – Constant rate for all entities to receive control information

Issues with Assumption #1 in asymmetric/unicast environments • In an asymmetric environments such as Satellite networks a single source broadcast to many points. However these receiver points are usually not connected to each other. Therefore there is no back channel for control/status information to be sent to all entities at once. Satellite R 1 R 3 R 2 RN

Solution use a unicast back channel • Instead of having one entity broadcast to all other receivers: – Individual receiver sends control/status information to the source – Source Broadcast report to all receivers (Reflection) Satellite R 1 R 3 R 2 RN

Summarisation (more intelligent use of the unicast back channel) • • Some of the information sent in control status messages are only important to the Source. Also in many cases other receivers are only interest in the aggregate state of the network. Summarisation is the process of the Source gathering report packets from many receivers then processing this data in order to broadcast a summary report which is of a much smaller size the pure Reflection

Reflection vs. Summarisation (Bandwidth vs. Group Size) Bandwidth (bytes) 1 e 9 1 e 8 1 e 7 Reflection Summarisation 1 e 6 1 e 5 Compression ratio 1 e 5 1 e 4 1000 10 1. 1 1 e 7 1 e 6 1 e 5 1 e 4 1000 10 1 Group Size

Issues with Assumption #2 in asymmetric/unicast heterogeneous environments • The assumption that all entities in the network should receive and send report messages at equal rates breaks down in certain systems. • Example: In a sensor network if a monitor of a critical safety device needs timely data, then RTPs policy of decreasing the rate at which all entities send messages could cause problems in such a system

Solution: Devise a priority scheme to “Bias” the rate at which an entity sends report messages • Biasing: Collect feedback from a biased set of receives at a higher rate then others – B(b)= (w * nb/nw)(. 0375 B), B(u)=(1 - (w*nb/nw))(. 037 B) • Where nw is the weighted group size, nw = (n-nb)+(w*nb) • w is is the ration of biased BW to unbiased • Hierarchical aggregation: Create a hierarchy of summarisation nodes to control the report frequency of subgroups of receivers (e. g. perform higher frequency feedback collection from time critical receivers. )

Reporting Interval (secs/pkt) Standard RTCP vs. Hierarchical Aggregation (update interval vs. Group Size) 1 e 7 Standard RTCP 1 e 6 1 e 5 1 e 4 1000 n = 100 n = 10 n=1 100 10 1. 1 1 e 7 1 e 6 1 e 5 1 e 4 1000 10 1 Group Size

Conclusion • Two concepts were presented to help RTP become effective in asymmetric heterogeneous real-time networks – Unicast feed back channel – Summarisation

Questions.