1. 13 Dec 2000AVT WG - 49th IETF1 RTCP-based Feedback: Concepts & Message Timing Rules draft-wenger-avt-rtcp-feedback-01.txt Stephan Wenger TU Berlin stewe@cs.tu-berlin.de Jörg Ott Universität Bremen TZI jo@tzi.org

2. 13 Dec 2000AVT WG - 49th IETF2 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. 13 Dec 2000AVT WG - 49th IETF3 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. 13 Dec 2000AVT WG - 49th IETF4 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. 13 Dec 2000AVT WG - 49th IETF5 Modes of Operation Group size2 Regular RTCP mode Early RTCP mode Immediate FB mode Report every relevant event immediately Report many of the events but not all Just regular RTCP packets Send feedback + regular RTCP packets

6. 13 Dec 2000AVT WG - 49th IETF6 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. 13 Dec 2000AVT WG - 49th IETF7 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. 13 Dec 2000AVT WG - 49th IETF8 Timing Rules (1) t0 Event detected Last RR (T_rr_last) Next RR scheduled (T_rr_next) T_dither_max = f (group size, RTT) t_e Immediate/Early RTCP

9. 13 Dec 2000AVT WG - 49th IETF9 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 > T_rr_next send as regular compound RTCP Get random t_e from [ t0 ; t0+T_dither_max ] Check for other FB messages if not: send Immediate/Early RTCP at t_e extra delay for next Regular RTCP

10. 13 Dec 2000AVT WG - 49th IETF10 Open Issues Make it an AVP extension (wording) SDP attributes for feedback? –a=group-size: [min]-[max] –a=rtcp-fb: {ack|nack|token} [params] Limit damping? –to get a better picture at sender –complexity vs. added value? Implications on RTP congestion control? Implement...

11. 13 Dec 2000AVT WG - 49th IETF11 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