RTCP-based Feedback: Concepts

1
RTCP-based FeedbackConcepts Message Timing
Rulesdraft-wenger-avt-rtcp-feedback-01.txt

• Stephan Wenger
• TU Berlin
• stewe_at_cs.tu-berlin.de

• Jörg Ott
• Universität Bremen TZI
• jo_at_tzi.org

2
We have agreed that...

• providing feedback is a good idea
• groups should be supported but point-to-point
  scenarios should be given special consideration
• the approach should work with all media
• a base spec should define timing and generic
  message formats
• profiles/extensions should deal with specific
  media requirements

3
This is the base spec!

• An extension to the RTP AVP
• Refines rules for transmitting RTCP
• eliminates five second minimum interval
• but sticks to overall bandwidth limits
• Probabilistic operation
• will provide timely feedback in many cases
• no substitute for TCP-style ACKs though
• Complements message specification
• draft-fukunaga-low-delay-rtcp-01.txt

4
Changes

• Generalized document from specific video feedback
  to general purpose
• Added immediate feedback option
• for point-to-point scenarios
• Clarification on RTCP messages to be used
• aligned with draft-fukunaga-low-delay-feedback
• Calculation of T_dither_max
• Editorial changes, terminology

5
Modes of Operation
Regular RTCP mode
Early RTCP mode
Immediate FB mode
Group size
2
Report every relevant event immediately
Report many of the events but not all
Just regular RTCP packets
Send feedback regular RTCP packets
6
Modes of Operation (2)

• Current mode depends on
• available RTCP bandwidth f (session b/w, group
  size, sender/receiver)
• events expected to report per time interval
• application and media stream sensivitity
• Example
• 20 packets per second, 5 average loss
• on average one event report per second
• requires 1 kbit/s RTCP b/w per peer
• No strict boundaries!

7
Rules

• What to send?
• ACK-style feedback only for point-to-point
• NACK-style always
• Status in regular RTCP
• Minimal or full compound RTCP packets
• Allowed to send?
• group size 2
• last FB sent by me was no Immediate/Early FB
  nobody else has sent one for this event (damping)
• Check RTCP bit rate budget!

8
Timing Rules (1)
T_dither_max f (group size, RTT)
t_e
t0
Last RR (T_rr_last)
Next RR scheduled (T_rr_next)
Event detected
Immediate/Early RTCP
9
Timing Rules (2)

• Calculate T_dither_max f (grp size, RTT)
• group size 2? ? T_dither_max 0
• RTT available? ? T_dither_max RTT/2
• else ? T_dither_max 100ms
• If t0 T_dither_max gt T_rr_next
• send as regular compound RTCP
• Get random t_e from t0 t0T_dither_max
• Check for other FB messages
• if not send Immediate/Early RTCP at t_e
• extra delay for next Regular RTCP

10
Open Issues

• Make it an AVP extension (wording)
• SDP attributes for feedback?
• agroup-size min-max
• artcp-fb acknacktoken params
• Limit damping?
• to get a better picture at sender
• complexity vs. added value?
• Implications on RTP congestion control?
• Implement...

11
When to send Feedback

• General design criteria
• Avoid that a single receiver monopolizes the
  mechanism
• Do not increase overall RTCP b/w
• Avoid feedback implosions
• Allow timely feedback (whenever possible)
• Support multicast
• with group sizes as large as feasible