13 Dec 2000 AVT WG - 49th IETF 1

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

13 Dec 2000 AVT WG - 49th IETF 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

13 Dec 2000 AVT WG - 49th IETF 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

13 Dec 2000 AVT WG - 49th IETF 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

13 Dec 2000 AVT WG - 49th IETF 5

Modes of Operation

Group size2

RegularRTCP mode

Early RTCPmode

ImmediateFB mode

Report everyrelevant eventimmediately

Report manyof the events

but not all

Just regularRTCP packets

Send feedback + regular RTCP packets

13 Dec 2000 AVT WG - 49th IETF 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!

13 Dec 2000 AVT WG - 49th IETF 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!

13 Dec 2000 AVT WG - 49th IETF 8

Timing Rules (1)

t0

Eventdetected

Last RR(T_rr_last)

Next RRscheduled(T_rr_next)

T_dither_max = f (group size, RTT)

t_e

Immediate/EarlyRTCP

13 Dec 2000 AVT WG - 49th IETF 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 > 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

13 Dec 2000 AVT WG - 49th IETF 10

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

13 Dec 2000 AVT WG - 49th IETF 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