An Extensible RTCP Control Framework

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
• -------------------------
  -------
• V2PX 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
1e7
1e6
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-
  (wnb/nw))(.037B)
• Where nw is the weighted group size, nw
  (n-nb)(wnb)
• 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
1e7
1e6
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.