An Extensible RTCP Control Framework for Large Multimedia Distributions Paper by:

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

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

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

4. BackgroundRTP / RTCP • Real-time Transport Protocol (RTP): An Internet standard for sending real-time 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)

5. RTP Packet Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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

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

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

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

9. 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 R1 R3 RN R2

10. 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 R1 R3 RN R2

11. 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 R1 R3 RN R2

12. 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 R1 R3 RN R2

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

14. Reflection vs. Summarisation (Bandwidth vs. Group Size) 1e9 Reflection 1e8 1e7 Summarisation 1e6 1e5 Compression ratio 1e5 Bandwidth (bytes) 1e4 1000 100 10 1 .1 1 10 1e5 1e5 1e6 1e7 100 1e4 1000 Group Size

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

16. 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)(.0375B), B(u)=(1- (w*nb/nw))(.037B) • 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.)

17. Standard RTCP vs. Hierarchical Aggregation(update interval vs. Group Size) 1e7 Standard RTCP 1e6 1e5 1e5 n = 1000 1e4 Reporting Interval (secs/pkt) n = 100 1000 n = 10 100 n = 1 10 1 .1 1 10 1e5 1e5 1e6 1e7 100 1e4 1000 Group Size

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

19. Questions.