draft-ietf-avt-rtcp-feedback-06.txt   draft-ietf-avt-rtcp-feedback-07.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-06.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-07.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
2 May 2003 6 June 2003
Expires November 2003 Expires December 2003
Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
specific mechanisms). This document defines an extension to the specific mechanisms). This document defines an extension to the
Audio-visual Profile (AVP) that enables receivers to provide, Audio-visual Profile (AVP) that enables receivers to provide,
statistically, more immediate feedback to the senders and thus statistically, more immediate feedback to the senders and thus
allow for short-term adaptation and efficient feedback-based repair allow for short-term adaptation and efficient feedback-based repair
mechanisms to be implemented. This early feedback profile (AVPF) mechanisms to be implemented. This early feedback profile (AVPF)
maintains the AVP bandwidth constraints for RTCP and preserves maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups. scalability to large groups.
Table of Contents Table of Contents
1 Introduction..................................................3 1 Introduction...................................................3
1.1 Definitions.............................................4 1.1 Definitions................................................4
1.2 Terminology.............................................5 1.2 Terminology................................................5
2 RTP and RTCP Packet Formats and Protocol Behavior.............6 2 RTP and RTCP Packet Formats and Protocol Behavior..............6
3 Rules for RTCP Feedback.......................................6 3 Rules for RTCP Feedback........................................6
3.1 Compound RTCP Feedback Packets..........................6 3.1 Compound RTCP Feedback Packets.............................6
3.2 Algorithm Outline.......................................8 3.2 Algorithm Outline..........................................8
3.3 Modes of Operation......................................9 3.3 Modes of Operation.........................................9
3.4 Definitions and Algorithm Overview.....................11 3.4 Definitions and Algorithm Overview........................11
3.5 AVPF RTCP Scheduling Algorithm.........................14 3.5 AVPF RTCP Scheduling Algorithm............................13
3.5.1 Initialization........................................14 3.5.1 Initialization......................................14
3.5.2 Early Feedback Transmission...........................14 3.5.2 Early Feedback Transmission.........................14
3.5.3 Regular RTCP Transmission.............................17 3.5.3 Regular RTCP Transmission...........................17
3.5.4 Other Considerations..................................18 3.5.4 Other Considerations................................18
3.6 Considerations on the Group Size.......................19 3.6 Considerations on the Group Size..........................19
3.6.1 ACK mode..............................................19 3.6.1 ACK mode............................................19
3.6.2 NACK mode.............................................19 3.6.2 NACK mode...........................................19
3.7 Summary of decision steps..............................21 3.7 Summary of decision steps.................................21
3.7.1 General Hints.........................................21 3.7.1 General Hints.......................................21
3.7.2 Media Session Attributes..............................21 3.7.2 Media Session Attributes............................21
4 SDP Definitions..............................................22 4 SDP Definitions...............................................22
4.1 Profile identification.................................22 4.1 Profile identification....................................22
4.2 RTCP Feedback Capability Attribute.....................22 4.2 RTCP Feedback Capability Attribute........................22
4.3 RTCP Bandwidth Modifiers...............................26 4.3 RTCP Bandwidth Modifiers..................................26
4.4 Examples...............................................26 4.4 Examples..................................................26
5 Interworking and Co-Existence of AVP and AVPF Entities.......28 5 Interworking and Co-Existence of AVP and AVPF Entities........27
6 Format of RTCP Feedback Messages.............................29 6 Format of RTCP Feedback Messages..............................29
6.1 Common Packet Format for Feedback Messages.............30 6.1 Common Packet Format for Feedback Messages................30
6.2 Transport Layer Feedback Messages......................32 6.2 Transport Layer Feedback Messages.........................32
6.2.1 Generic NACK..........................................32 6.2.1 Generic NACK........................................32
6.2.2 Generic ACK...........................................33 6.2.2 Generic ACK.........................................33
6.3 Payload Specific Feedback Messages.....................35 6.3 Payload Specific Feedback Messages........................35
6.3.1 Picture Loss Indication (PLI).........................35 6.3.1 Picture Loss Indication (PLI).......................35
6.3.1.1 Semantics..........................................35 6.3.1.1 Semantics...................................35
6.3.1.2 Message Format.....................................36 6.3.1.2 Message Format..............................36
6.3.1.3 Timing Rules.......................................36 6.3.1.3 Timing Rules................................36
6.3.1.4 Remarks............................................36 6.3.1.4 Remarks.....................................36
6.3.2 Slice Lost Indication (SLI)...........................37 6.3.2 Slice Lost Indication (SLI).........................37
6.3.2.1 Semantics..........................................37 6.3.2.1 Semantics...................................37
6.3.2.2 Format.............................................37 6.3.2.2 Format......................................37
6.3.2.3 Timing Rules.......................................38 6.3.2.3 Timing Rules................................38
6.3.2.4 Remarks............................................38 6.3.2.4 Remarks.....................................38
6.3.3 Reference Picture Selection Indication (RPSI).........39 6.3.3 Reference Picture Selection Indication (RPSI).......39
6.3.3.1 Semantics..........................................39 6.3.3.1 Semantics...................................39
6.3.3.2 Format.............................................40 6.3.3.2 Format......................................40
6.3.3.3 Timing Rules.......................................40 6.3.3.3 Timing Rules................................40
6.4 Application Layer Feedback Messages....................41 6.4 Application Layer Feedback Messages.......................41
7 Early Feedback and Congestion Control........................41 7 Early Feedback and Congestion Control.........................41
8 Security Considerations......................................42 8 Security Considerations.......................................42
9 IANA Considerations..........................................43 9 IANA Considerations...........................................44
10 Acknowledgements.............................................47 10 Acknowledgements..............................................47
11 Authors' Addresses...........................................48 11 Authors' Addresses............................................48
12 Bibliography.................................................48 12 Bibliography..................................................48
12.1 Normative references...................................48 12.1 Normative references.....................................48
12.2 Informative References.................................49 12.2 Informative References...................................49
13 IPR Notice...................................................50 13 IPR Notice....................................................50
14 Full Copyright Statement.....................................50 14 Full Copyright Statement......................................50
1 Introduction 1 Introduction
Real-time media streams that use RTP are, to some degree, resilient Real-time media streams that use RTP are, to some degree, resilient
against packet losses. RTP [1] provides all the necessary against packet losses. RTP [1] provides all the necessary
mechanisms to restore ordering and timing present at the sender to mechanisms to restore ordering and timing present at the sender to
properly reproduce a media stream at a recipient. RTP also properly reproduce a media stream at a recipient. RTP also
provides continuous feedback about the overall reception quality provides continuous feedback about the overall reception quality
from all receivers -- thereby allowing the sender(s) in the mid- from all receivers -- thereby allowing the sender(s) in the mid-
term (in the order of several seconds to minutes) to adapt their term (in the order of several seconds to minutes) to adapt their
skipping to change at page 7, line 20 skipping to change at page 7, line 20
RTCP FB messages are just another RTCP packet type (see section RTCP FB messages are just another RTCP packet type (see section
4). Therefore, multiple FB messages MAY be combined in a single 4). Therefore, multiple FB messages MAY be combined in a single
compound RTCP packet and they MAY also be sent combined with other compound RTCP packet and they MAY also be sent combined with other
RTCP packets. RTCP packets.
Compound RTCP packets containing FB messages as defined in this Compound RTCP packets containing FB messages as defined in this
document MUST contain RTCP packets in the order defined in [1]: document MUST contain RTCP packets in the order defined in [1]:
o OPTIONAL encryption prefix that MUST be present if the RTCP o OPTIONAL encryption prefix that MUST be present if the RTCP
packet(s) is to be encrypted. packet(s) is to be encrypted according to section 9.1 of [1].
o MANDATORY SR or RR. o MANDATORY SR or RR.
o MANDATORY SDES which MUST contain the CNAME item; all other SDES o MANDATORY SDES which MUST contain the CNAME item; all other SDES
items are OPTIONAL. items are OPTIONAL.
o One or more FB messages. o One or more FB messages.
The FB message(s) MUST be placed in the compound packet after RR The FB message(s) MUST be placed in the compound packet after RR
and SDES RTCP packets defined in [1]. The ordering with respect to and SDES RTCP packets defined in [1]. The ordering with respect to
other RTCP extensions is not defined. other RTCP extensions is not defined.
Two types of compound RTCP packets carrying feedback packets are Two types of compound RTCP packets carrying feedback packets are
skipping to change at page 11, line 9 skipping to change at page 11, line 9
As stated before, the respective FB thresholds depend on a number As stated before, the respective FB thresholds depend on a number
of technical parameters (of the codec, the transport, the type of of technical parameters (of the codec, the transport, the type of
feedback used, etc.) but also on the respective application feedback used, etc.) but also on the respective application
scenarios. Section 3.6 provides some useful hints (but no precise scenarios. Section 3.6 provides some useful hints (but no precise
calculations) on estimating these thresholds. calculations) on estimating these thresholds.
3.4 Definitions and Algorithm Overview 3.4 Definitions and Algorithm Overview
The following pieces of state information need to be maintained per The following pieces of state information need to be maintained per
receiver (largely taken from [1]). Note that all variables (except receiver (largely taken from [1]). Note that all variables (except
in item g) below) are calculated independently at each receiver. in item h) below) are calculated independently at each receiver.
Therefore, their local values may differ at any given point in Therefore, their local values may differ at any given point in
time. time.
a) Let "senders" be the number of active senders in the RTP a) Let "senders" be the number of active senders in the RTP
session. session.
b) Let "members" be the current estimate of the number of receivers b) Let "members" be the current estimate of the number of receivers
in the RTP session. in the RTP session.
c) Let tn and tp be the time for the next (last) scheduled c) Let tn and tp be the time for the next (last) scheduled
skipping to change at page 12, line 33 skipping to change at page 12, line 33
last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the
next Regular RTCP packet will be delayed until at least next Regular RTCP packet will be delayed until at least
T_rr_interval after the last Regular RTCP transmission, i.e. it T_rr_interval after the last Regular RTCP transmission, i.e. it
will be scheduled at or later than tp+T_rr_interval. Note that will be scheduled at or later than tp+T_rr_interval. Note that
T_rr_interval does not affect the calculation of T_rr and tp; T_rr_interval does not affect the calculation of T_rr and tp;
instead, Regular RTCP packets scheduled for transmission before instead, Regular RTCP packets scheduled for transmission before
tp+T_rr_interval will be suppressed if, for example, they do not tp+T_rr_interval will be suppressed if, for example, they do not
contain any FB messages. The T_rr_interval does not affect contain any FB messages. The T_rr_interval does not affect
transmission scheduling of Early RTCP packets. transmission scheduling of Early RTCP packets.
NOTE: Providing T_rr_interval as an independent variable is NOTE: Providing T_rr_interval as an independent variable is meant to
meant to minimize Regular RTCP feedback (and thus bandwidth minimize Regular RTCP feedback (and thus bandwidth consumption) as
consumption) as needed by the application while additionally needed by the application while additionally allowing the use of more
allowing the use of more frequent Early RTCP packets to provide frequent Early RTCP packets to provide timely feedback. This goal
timely feedback. This goal could not be achieved by reducing could not be achieved by reducing the overall RTCP bandwidth as RTCP
the overall RTCP bandwidth as RTCP bandwidth reduction would bandwidth reduction would also impact the frequency of Early feedback.
also impact the frequency of Early feedback.
n) Let t_rr_last be the point in time at which the last Regular n) Let t_rr_last be the point in time at which the last Regular
RTCP packet has been scheduled and sent, i.e. has not been RTCP packet has been scheduled and sent, i.e. has not been
suppressed due to T_rr_interval. suppressed due to T_rr_interval.
o) Let T_retention be the time window for which past FB messages o) Let T_retention be the time window for which past FB messages
are stored by an AVPF entity. This is to ensure that feedback are stored by an AVPF entity. This is to ensure that feedback
suppression also works for entities that have received FB suppression also works for entities that have received FB
messages from other entities prior to noticing the feedback messages from other entities prior to noticing the feedback
event itself. T_retention MUST be set to at least 2 seconds. event itself. T_retention MUST be set to at least 2 seconds.
skipping to change at page 14, line 4 skipping to change at page 13, line 50
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+---> |---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( | | | | | ( ( |
| t0 te | | t0 te |
tp tn tp tn
\_______ ________/ \_______ ________/
\/ \/
T_dither_max T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling Figure 2: Event report and parameters for Early RTCP scheduling
3.5 AVPF RTCP Scheduling Algorithm
3.5 AVPF RTCP Scheduling Algorithm
Let S0 be an active sender (out of S senders) and let N be the Let S0 be an active sender (out of S senders) and let N be the
number of receivers with R being one of these receivers. number of receivers with R being one of these receivers.
Assume that R has verified that using feedback mechanisms is Assume that R has verified that using feedback mechanisms is
reasonable at the current constellation (which is highly reasonable at the current constellation (which is highly
application specific and hence not specified in this document). application specific and hence not specified in this document).
Assume further that T_rr_interval is 0, if no minimal interval Assume further that T_rr_interval is 0, if no minimal interval
between Regular RTCP packets is to be enforced, or T_rr_interval is between Regular RTCP packets is to be enforced, or T_rr_interval is
set to some meaningful value, as given by the application. This set to some meaningful value, as given by the application. This
skipping to change at page 18, line 37 skipping to change at page 18, line 33
messages have been stored and are awaiting messages have been stored and are awaiting
transmission, an RTCP packet MUST be scheduled for transmission, an RTCP packet MUST be scheduled for
transmission at tn. This RTCP packet MAY be a minimal transmission at tn. This RTCP packet MAY be a minimal
or a Regular RTCP packet (at the discretion of the or a Regular RTCP packet (at the discretion of the
implementer) and the compound RTCP packet MUST include implementer) and the compound RTCP packet MUST include
the stored RTCP FB message(s). t_rr_last MUST remain the stored RTCP FB message(s). t_rr_last MUST remain
unchanged. unchanged.
2c) Otherwise (if t_rr_last + T_rr_current_interval > tn 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn
but no stored RTCP FB messages are awaiting but no stored RTCP FB messages are awaiting
transmission), the compound RTCP packet MUST NOT be transmission), the compound RTCP packet MUST be
scheduled. t_rr_last MUST remain unchanged. suppressed (i.e. it MUST NOT be scheduled). t_rr_last
MUST remain unchanged.
In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST
be set to TRUE (possibly after sending the Regular RTCP packet) and be set to TRUE (possibly after sending the Regular RTCP packet) and
tp and tn MUST be updated following the rules of [1] except for the tp and tn MUST be updated following the rules of [1] except for the
five second minimum. five second minimum.
3.5.4 Other Considerations 3.5.4 Other Considerations
If T_rr_interval != 0 then the timeout calculation for RTP/AVPF If T_rr_interval != 0 then the timeout calculation for RTP/AVPF
entities (section 6.3.5 of [1]) MUST be modified to use entities (section 6.3.5 of [1]) MUST be modified to use
skipping to change at page 41, line 10 skipping to change at page 41, line 10
RPS for certain bit rate/frame rate/loss rate scenarios. RPS for certain bit rate/frame rate/loss rate scenarios.
Therefore, RPS messages should typically be sent as soon as Therefore, RPS messages should typically be sent as soon as
possible, employing the algorithm of section 3. possible, employing the algorithm of section 3.
6.4 Application Layer Feedback Messages 6.4 Application Layer Feedback Messages
Application Layer FB messages are a special case of payload- Application Layer FB messages are a special case of payload-
specific messages and identified by PT=PSFB and FMT=15. specific messages and identified by PT=PSFB and FMT=15.
There MUST be exactly one Application Layer FB message contained in There MUST be exactly one Application Layer FB message contained in
the FCI field. the FCI field, unless the Application Layer FB message structure
itself allows for stacking (e.g. by means of a fixed size or
explicit length indicator).
These messages are used to transport application defined data These messages are used to transport application defined data
directly from the receiver's to the sender's application. The data directly from the receiver's to the sender's application. The data
that is transported is not identified by the FB message. that is transported is not identified by the FB message.
Therefore, the application MUST be able to identify the messages Therefore, the application MUST be able to identify the messages
payload. payload.
Usually, applications define their own set of messages, e.g. Usually, applications define their own set of messages, e.g.
NEWPRED messages in MPEG-4 [16] or FB messages in H.263/Annex N, U NEWPRED messages in MPEG-4 [16] or FB messages in H.263/Annex N, U
[17]. These messages do not need any additional information from [17]. These messages do not need any additional information from
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/