draft-ietf-avt-rtp-retransmission-00.txt   draft-ietf-avt-rtp-retransmission-01.txt 
David Leon David Leon
Internet Draft Viktor Varsa Internet Draft Viktor Varsa
Document: draft-ietf-avt-rtp-retransmission- Nokia Document: Nokia
00.txt draft-ietf-avt-rtp-retransmission-01.txt
Expires: September 2002 March 2002 Expires: December 2002 June 2002
RTP retransmission framework RTP retransmission framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 34 skipping to change at line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
RTP retransmission is an effective packet loss recovery scheme for RTP retransmission is an effective packet loss recovery scheme for
real-time applications with relaxed delay bounds. real-time applications with relaxed delay bounds.
This document describes an RTP retransmission framework. It defines This document describes an RTP retransmission framework. It defines
a payload format for retransmitted packets and recommends rules for a payload format for retransmitted packets and recommends rules for
sending these packets. Retransmitted RTP packets are sent in a sending these packets. Retransmitted RTP packets are sent in a
separate stream from the original RTP stream. It is assumed that separate stream from the original RTP stream. It is assumed that
feedback from receivers to senders indicating the occurred packet feedback from receivers to senders indicating the occurred packet
losses is available by some means not defined here. losses is available by some means not defined here.
Main changes since draft-leon-rtp-retransmission-02.txt Main changes
*since draft-ietf-avt-rtp-retransmission-00.txt:
An applicability statement was added.
The security considerations section was expanded.
*since draft-leon-rtp-retransmission-02.txt:
The previous version of the draft described the use of the The previous version of the draft described the use of the
redundancy payload format (RFC 2198) in order to send retransmission redundancy payload format (RFC 2198) in order to send retransmission
Leon, Varsa IETF draft - Expires September 2002 1
RTP retransmission framework June 2002
data and original data in the same stream. At IETF #53, it was data and original data in the same stream. At IETF #53, it was
concluded that RFC 2198 was not intended to such a use. Piggybacking concluded that RFC 2198 was not intended to such a use. Piggybacking
retransmitted packets was thus removed from the draft. retransmitted packets was thus removed from the draft.
Leon, Varsa IETF draft - Expires September 2002 1
RTP retransmission framework March 2002
Table of Contents Table of Contents
Abstract...........................................................1 Abstract...........................................................1
Main changes since draft-leon-rtp-retransmission-02.txt............1 Main changes.......................................................1
1. Introduction....................................................2 1. Introduction....................................................2
2. Terminology.....................................................2 2. Terminology.....................................................3
3. Retransmission framework basic principles.......................3 3. Applicability statement.........................................3
4. Retransmission payload format...................................4 4. Retransmission framework basic principles.......................4
5. Use with the Extended RTP profile for RTCP-based feedback.......5 5. Retransmission payload format...................................5
6. Congestion control..............................................7 6. Use with the Extended RTP profile for RTCP-based feedback.......6
7. Example scenario of unicast streaming...........................8 7. Congestion control..............................................8
8. SDP usage.......................................................8 8. Example scenario of unicast streaming...........................8
9. FEC for retransmission..........................................9 9. SDP usage.......................................................9
10. Security consideration........................................10 10. Security consideration.........................................9
11. References....................................................10 Appendix: FEC for retransmission..................................10
References........................................................11
Author's Addresses................................................11 Author's Addresses................................................11
1. Introduction 1. Introduction
Packet losses between an RTP sender and receiver may significantly Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received signal. Several techniques, such degrade the quality of the received signal. Several techniques, such
as forward error correction (FEC), retransmissions or adaptation of as forward error correction (FEC), retransmissions or application
application layer (e.g. video) error resilience techniques based on layer (e.g. video) error resilience adaptation based on back-channel
back-channel messages may be considered to increase the robustness messages may be considered to increase the robustness to packet
to packet loss. RFC-2354 [1] discusses the different options. loss. RFC-2354 [1] discusses the different options.
When choosing a technique for a particular system, the tolerable When choosing a technique for a particular system, the tolerable
latency of the application has to be taken into account. In the case latency of the application has to be taken into account. In the case
of multimedia conferencing, the end-to-end delay has to be at most a of multimedia conferencing, the end-to-end delay has to be at most a
few hundred milliseconds in order to guarantee interactivity, which few hundred milliseconds in order to guarantee interactivity, which
usually excludes the use of retransmission. On the other hand, in usually excludes the use of retransmission. On the other hand, in
the case of multimedia streaming, the user can tolerate an initial the case of multimedia streaming, the user can tolerate an initial
latency as part of the session setup and thus an end-to-end delay of latency as part of the session setup and thus an end-to-end delay of
several seconds is possible. Retransmission may thus be considered several seconds is possible. Retransmission may thus be considered
for such applications. for such applications.
This document proposes a retransmission framework. It defines a This document proposes a retransmission framework. It defines a
payload format for retransmitted RTP packets and retransmission payload format for retransmitted RTP packets and retransmission
rules. This RTP retransmission scheme requires frequent packet loss rules. This RTP retransmission scheme requires frequent packet loss
indication feedback to the RTP entity performing retransmission. The indication feedback to the RTP entity performing retransmission. The
AV profile [2] does not provide this feature and could therefore not AV profile [2] does not provide this feature and could therefore not
be used. However, the retransmission scheme could be run under the be used. However, the retransmission scheme could be run under the
Leon, Varsa - Expires December 2002 2
RTP retransmission framework June 2002
extended RTP profile for RTCP-based feedback[3] which defines a NACK extended RTP profile for RTCP-based feedback[3] which defines a NACK
message that can be sent as part of a compound RTCP packet. message that can be sent as part of a compound RTCP packet.
2. Terminology 2. Terminology
Leon, Varsa - Expires September 2002 2
RTP retransmission framework March 2002
The following terms are used in this document: The following terms are used in this document:
Original packet: refers to an RTP packet sent by an RTP sender as Original packet: refers to an RTP packet which carries user data
part of an RTP stream. sent for the first time by an RTP sender.
Original stream: refers to the stream of original packets. Original stream: refers to the stream of original packets.
Retransmission packet: refers to an RTP packet whose payload Retransmission packet: refers to an RTP packet whose payload
includes the payload of an already sent original packet. Such a includes the payload of an already sent original packet. Such a
retransmission packet is said to be associated with the original RTP retransmission packet is said to be associated with the original RTP
packet whose payload is included in the retransmission packet. packet whose payload is included in the retransmission packet.
Retransmission request: a means by which an RTP receiver is able to Retransmission request: a means by which an RTP receiver is able to
request that the RTP sender send a retransmission packet associated request that the RTP sender send a retransmission packet associated
with a given original packet. In [3], a retransmission request is with a given original packet. In [3], a retransmission request is
sent as a packet loss indication in a NACK message. sent as a packet loss indication in a NACK message.
Retransmission stream: the stream of retransmission packets Retransmission stream: the stream of retransmission packets
associated to with an original stream. associated to with an original stream.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [4]. document are to be interpreted as described in RFC-2119 [4].
3. Retransmission framework basic principles 3. Applicability statement
There are two proposals for RTP retransmissions (this proposal
draft-ietf-avt-rtp-retransmission-01.txt and draft-ietf-avt-rtp-
selret-05.txt). Both proposals may be optimum under a different set
of constraints.
This draft enables the receiver to perform reliable loss detection
of user data, i.e. the receiver can differentiate between lost
packets sent for first time and lost retransmissions.
Reliable user data loss detection is required for example in RTP
conversational text (RFC 2793) in order to indicate missing text to
the user. For some applications, reliable loss detection of user
data may not be strictly required but may enhance a receiver
performance.
This retransmission algorithm allows receivers to trade-off the
playout delay versus the number of retransmissions for a given
packet. This delay does not need to be signalled to the sender and
can be changed dynamically during the session in order to adapt to
varying network conditions. Receivers should choose whether to
request a missing packet based on an estimation of its timestamp
Leon, Varsa - Expires December 2002 3
RTP retransmission framework June 2002
which is usually obtained from the observed correlation between the
RTP sequence number and timestamp. Implementers should carefully
design their decision retransmission request algorithm in order to
limit the risk of unnecessary retransmission.
This retransmission scheme requires a separate RTP session to send
retransmitted packets. As a consequence, two additional ports are
needed: one port for the RTP retransmission stream and one port for
the associated RTCP. While this is generally not a problem, the
implementers should assess the implications in the targeted
environment.
This scheme may be used in a multicast RTP session in order to
perform unicast retransmission to each participant.
If a separate session is used, mixers, translators and packet caches
may be able to separate retransmission packets from original packets
at an RTP session level based only on the port being used and
process them differently if necessary.
4. Retransmission framework basic principles
Retransmission packets MUST NOT share the RTP Sequence Number (SN) Retransmission packets MUST NOT share the RTP Sequence Number (SN)
space with the original stream. The retransmission stream SHOULD use space with the original stream. The retransmission stream SHOULD use
a different RTP session (as defined in RTP [5]) from that of the a different RTP session (as defined in RTP [5]) from that of the
original stream. Since a separate session is used, the original and original stream. Since a separate session is used, the original and
retransmission streams are sent to different multicast group/unicast retransmission streams are sent to different multicast group/unicast
addresses and/or port numbers. The retransmission stream has then addresses and/or port numbers.
its own SN space..
There are several reasons why the SN space must not be shared: There are several reasons why the SN space must not be shared:
Since retransmission packets do not share the SN space with the Since retransmission packets do not share the SN space with the
original packets, the receiver is able to distinguish between the original packets, the receiver is able to distinguish between the
loss of original packets and retransmission packets. Otherwise, loss of original packets and retransmission packets. Otherwise,
reliable data loss detection would not be possible. Reliable data reliable loss detection of user data would not be possible. Reliable
loss detection is mandated for example in RTP conversational text data loss detection of user data is mandated for example in RTP
[6]. conversational text [6].
RTP Timestamp (TS) estimation of missing original packets is RTP Timestamp (TS) estimation of missing original packets is
necessary at the receiver in order to decide whether a necessary at the receiver in order to decide whether a
retransmission is useful or not. A retransmission is useful if the retransmission is useful or not. A retransmission is useful if the
retransmission packet as a response to the retransmission request is retransmission packet sent as a response to the retransmission
estimated to arrive at the receiver before the time it is used for request may still be used when it arrives at the receiver. The
playback (playout time). The missing original packet TS can be missing original packet timestamp can be estimated from timestamp of
estimated from TS of packets preceding and following the SN gap packets preceding and/or following the sequence number gap caused by
caused by the missing packet in the original stream. the missing packet in the original stream.
Leon, Varsa - Expires September 2002 3
RTP retransmission framework March 2002
The fact that RTP streams for original and retransmission packets do The fact that RTP streams for original and retransmission packets do
not share the same SN space guarantees that the RTP timestamp not share the same SN space guarantees that the RTP timestamp
estimation method is reliable. Reliability would be sacrificed if estimation method is reliable. Reliability would be sacrificed if
original and retransmission packets were sent in the same RTP original and retransmission packets were sent in the same RTP stream
stream. The TS estimate for a lost retransmission packet ,when as the timestamp estimate for a lost retransmission packet would
calculated as above, would then be incorrect. This is because the
retransmission packet usually has a smaller "out-of-order" TS than
the TS of the consecutive original packets.
There are no modifications to the payload format of the original Leon, Varsa - Expires December 2002 4
packets. Retransmission can thus work with any existing payload RTP retransmission framework June 2002
format.
then be incorrect. This is because the retransmission packet usually
has a smaller "out-of-order" timestamp than the timestamp of the
consecutive original packets.
When the retransmission stream is sent to a multicast RTP session, When the retransmission stream is sent to a multicast RTP session,
receivers may choose to subscribe or not to subscribe to the RTP receivers may choose whether to subscribe or not to the RTP session
session carrying the retransmission stream. Thus, a multicast carrying the retransmission stream. Therefore, a multicast streaming
streaming application can use retransmission and still be backwards application can use retransmission and still be backwards compatible
compatible as receivers which do not implement the retransmission as receivers which do not implement the retransmission payload
payload format only join the RTP session carrying the original format only join the RTP session carrying the original stream. A
stream. A scenario where the original session is multicast and scenario where the original session is multicast and separate
separate unicast sessions carry the retransmission stream to each unicast sessions carry the retransmission stream to each
participant, is also possible. In this scenario, a receiver can participant, is also possible. In this scenario, a receiver receives
receive retransmission packets only for original packets that it has only the retransmission packets it has itself requested and not the
itself requested, and not the retransmission packets that are sent retransmission packets that are requested by other receivers.
as responses to retransmission requests from other receivers.
Mixers, translators and packet caches may be able to separate Mixers, translators and packet caches may be able to separate
retransmission packets from original packets at an RTP session level retransmission packets from original packets at an RTP session level
and process them differently if necessary. and process them differently if necessary.
As a consequence of having separate RTP sessions for original and As a consequence of having separate RTP sessions for original and
retransmission streams, there are also separate RTCP streams and retransmission streams, there are also separate RTCP streams and
statistics for these two sessions. There is thus no corruption of statistics for these two sessions. There is thus no corruption of
the original stream RTCP statistics. The RTP sender is able to know the original stream RTCP statistics. The RTP sender is able to know
the packet loss and jitter of the original stream. It can thus the packet loss and jitter of the original stream. It can thus
estimate what the quality of the received signal would be without estimate what the quality of the received signal would be without
the use of retransmission. the use of retransmission.
4. Retransmission payload format 5. Retransmission payload format
The payload format of a retransmission packet is shown below. The payload format of a retransmission packet is shown below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| OPT | OSN | | |E| OPT | OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload | | Original RTP Packet Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leon, Varsa - Expires September 2002 4
RTP retransmission framework March 2002
RTP header usage: RTP header usage:
The same SSRC value SHOULD be used for the original stream and the The same SSRC value SHOULD be used for the original stream and the
retransmission stream. In the RTP header, SN has the standard retransmission stream. In the RTP header, SN has the standard
definition, i.e. it MUST be one higher than the SN of the preceding definition, i.e. it MUST be one higher than the sequence number of
retransmission packet. The payload type is dynamic and indicates the the preceding retransmission packet. The payload type is dynamic and
use of the retransmission payload format. All other fields of the indicates the use of the retransmission payload format. All other
RTP header have the same value as in the original RTP packet. fields of the RTP header have the same value as in the original RTP
packet.
Leon, Varsa - Expires December 2002 5
RTP retransmission framework June 2002
The retransmission packet payload carries an E bit, an OPT field (7 The retransmission packet payload carries an E bit, an OPT field (7
bits) and an OSN field (2 bytes) followed by the original RTP packet bits) and an OSN field (2 bytes) followed by the original RTP packet
payload. The E bit is an extension bit for future-proofing. It MUST payload. The E bit is an extension bit for future-proofing. It MUST
be set to zero. The OPT field is the payload type of the original be set to zero. The OPT field is the payload type of the original
packet payload that is being retransmitted. The OSN field is the SN packet payload that is being retransmitted. The OSN field is the
of the original packet that originally carried the same payload. sequence number of the original packet that originally carried the
same payload.
5. Use with the Extended RTP profile for RTCP-based feedback 6. Use with the Extended RTP profile for RTCP-based feedback
6.1 Sending rules for RTCP-based feedback
When the Extended RTP profile for RTCP-based feedback [4] is used, When the Extended RTP profile for RTCP-based feedback [4] is used,
it is RECOMMENDED that receivers send retransmission requests it is RECOMMENDED that receivers send retransmission requests
according to the rules in this section. The rules described according to the rules in this section. The rules described
hereafter aim at limiting the maximum delay before a retransmission hereafter aim at limiting the maximum delay before a retransmission
request can be sent and are compliant to the more general rules request can be sent and are compliant to the more general rules
described in the profile itself. described in the profile itself.
5.1 Sending rules for RTCP-based feedback The NACK message format defined in the profile should be used. Early
RTCP packets should not be used and the NACK message should always
be appended to a regularly scheduled compound RTCP packet that is
sent at every RTCP report interval T_rr.
The minimum RTCP report interval is computed according to the Any other rules to send feedback may be used as long as they are
allowed RTCP bandwidth of a given session (obtained explicitly or compliant with the profile. In particular, a receiver may send NACK
calculated as a percentage of the RTP session bandwidth). The NACK messages in early RTCP packets. However, in that case the time when
message format defined in the profile is used. Early RTCP packets the next RTCP packet following this early RTCP packet can be sent
SHOULD NOT be used, and the NACK message SHOULD always be appended could be too late to report a loss occurring right after the early
to a regularly scheduled compound RTCP packet that is sent at every RTCP packet was sent. Sending RTCP packets at regular intervals
RTCP report interval T_rr. guarantees that the delay between detecting an original packet loss
and being able to send a NACK message for that packet is no longer
than the RTCP interval.
Any other rules to send feedback MAY be used as long as they are 6.2 Receiver algorithm for generating retransmission requests
compliant with the profile in use. In particular, a receiver MAY
send NACK messages in early RTCP packets. However, in that case the This section gives some general guidelines on how a receiver should
time when the next RTCP packet following this early RTCP packet can decide whether or not to request a packet retransmission. An actual
be sent could be too late to report a loss occurring right after the receiver implementation should take into account such factors as the
early RTCP packet was sent. Sending RTCP packets at regular network environment and the media type.
intervals guarantees that the delay between detecting an original
packet loss and being able to send a NACK message for that packet is
no longer than the regular RTCP interval.
A receiver should compute an estimate of the delay D to receive a A receiver should compute an estimate of the delay D to receive a
retransmission packet after a NACK message has been sent. This retransmission packet after a NACK message has been sent. This
estimate may be obtained from past observations, RTCP report round- estimate may be obtained from past observations, RTCP report round-
trip time if available or any other means. trip time if available or any other means.
Leon, Varsa - Expires September 2002 5
RTP retransmission framework March 2002
The minimum receiver buffering delay B (i.e. the time between a The minimum receiver buffering delay B (i.e. the time between a
packet is received and its payload is used at the receiver) is the packet is received and its payload is used at the receiver) is the
RTCP reporting interval added to the delay estimate, which RTCP reporting interval added to the delay estimate D, which
guarantees that a retransmission packet as a response to a sent guarantees that a retransmission packet sent as a response to a
Leon, Varsa - Expires December 2002 6
RTP retransmission framework June 2002
retransmission request can be received before its payload is used. retransmission request can be received before its payload is used.
i.e. i.e. B>T_rr+D
B>T_rr+D
It can be seen that the needed receiver buffering delay is dependent It can be seen that the needed receiver buffering delay is dependent
on the amount of RTCP traffic allowed in the session. It is on the amount of RTCP traffic allowed in the session. It is
illustrated in Section 7 that moderate RTCP feedback traffic is illustrated in Section 8 that moderate RTCP feedback traffic is
enough to perform retransmission with reasonable receiver buffering enough to perform retransmission with reasonable receiver buffering
delay. delay.
5.2 Receiver algorithm for generating retransmission requests A receiver should maintain a list of missing original packet
sequence numbers. A receiver needs also to store for each missing
A receiver needs to maintain a list of missing original packet original packet an estimated RTP timestamp as described in Section
sequence numbers (SN) since its last sent RTCP packet. A receiver 4. At the next scheduled RTCP packet sending time, the receiver
needs also to store for each missing original packet an estimated estimates which of the missing packets should be requested in the
RTP timestamp (TS) as described in Section 3. NACK message (see usage of the PID and BLP fields of the NACK
message format in [4]) of the RTCP compound packet. A missing packet
At the next scheduled RTCP packet time, the receiver estimates based should be requested if it is estimated the associated retransmission
on the estimated TS of the missing original packet if a packet could still be used at the time it arrives at the receiver.
retransmission packet as a response to a NACK message that would be The receiver should remove from its list of missing packets, the
sent in the current RTCP packet could arrive at the receiver before packets which were deemed too old to be requested.
its playout time or not. If not, it removes the packet SN from its
list of missing packets. The receiver then sends retransmission
requests for the missing original packets by adding the SNs of the
missing original packets to a NACK message in the scheduled RTCP
compound packet (see usage of the PID and BLP fields of the NACK
message format in [4]). If needed for signalling of multiple missing
SN, multiple NACK messages can be added to the RTCP compound
packet..
If the retransmission stream is sent to a multicast session, the If the retransmission stream is sent to a multicast session, the
receiver SHOULD listen to NACK messages from other receivers. If a receiver should listen to NACK messages from other receivers. If a
NACK message for the SN of a missing packet at the receiver has been NACK message for the sequence number of a missing packet has been
sent by another receiver, the receiver SHOULD ignore that SN in its sent by another receiver, the receiver should ignore that sequence
list of missing packets and refrain from sending a retransmission number in its list of missing packets and refrain from sending a
request for that SN. retransmission request for that sequence number.
The same retransmission request may be resent by the receiver if no
retransmission packet with OSN equal to the missing original packet
SN was received after an estimated retransmission reception time.
This increases robustness to the loss of a NACK message or of a
retransmission packet. The repeated retransmission request may be
sent at the earliest at the next RTCP report scheduled time.
Repeated retransmission requests MUST be sent in the original RTP
session and not in the retransmission RTP session. The number of
repeated retransmission requests that may be sent for a given
missing original packet SN depends on the ratio of the receiver
buffering delay and RTCP session bandwidth.
Leon, Varsa - Expires September 2002 6 The same retransmission request may be resent in the original RTP
RTP retransmission framework March 2002 session if the requested packet was not received after an estimated
retransmission reception time. This increases the robustness to the
loss of a NACK message or of a retransmission packet. The number of
retransmission requests that may be sent for a given missing
original packet sequence number depends on the receiver buffering
delay.
The receiver should upon reception of a retransmission packet remove The receiver should upon reception of a retransmission packet remove
the SN corresponding to the original packet (OSN in the the corresponding original packet sequence number(OSN in the
retransmission payload format) from the list of missing SNs. retransmission payload format) from the list of missing sequence
numbers.
5.3 RTCP sending rules in the retransmission RTP session 6.3 RTCP sending rules in the retransmission RTP session
Since the original stream and the retransmission stream are carried Since the original stream and the retransmission stream are carried
in separate RTP sessions, the retransmission stream has its own RTCP in separate RTP sessions, the retransmission stream has its own RTCP
stream as well. The amount of RTCP sent for the retransmission stream as well. The amount of RTCP sent for the retransmission
stream is computed as a fraction of the retransmission RTP session stream is computed as a fraction of the retransmission RTP session
bandwidth. Since the retransmission traffic is limited, the overhead bandwidth. Since the retransmission traffic is limited, the overhead
caused by the additional RTCP packets in the retransmission RTP caused by the additional RTCP packets in the retransmission RTP
session is moderate. For example, assuming a 64 kbps original RTP session is moderate. For example, assuming a 64 kbps original RTP
session and on average 3% packet loss and all lost original packets session and on average 3% packet loss and all lost original packets
retransmitted once, the bandwidth of the retransmission RTP session retransmitted once, the bandwidth of the retransmission RTP session
Leon, Varsa - Expires December 2002 7
RTP retransmission framework June 2002
would be about 2 kbps. In this case the recommended RTCP traffic for would be about 2 kbps. In this case the recommended RTCP traffic for
the retransmission RTP session would be 0.1 kbps. the retransmission RTP session would be 0.1 kbps.
Early RTCP packets and RTCP feedback messages SHOULD NOT be used in Early RTCP packets and RTCP feedback messages SHOULD NOT be used in
the retransmission RTP session. the retransmission RTP session.
6. Congestion control 7. Congestion control
RTP retransmission poses a risk of increased network congestion. In RTP retransmission poses a risk of increased network congestion. In
a best-effort environment, packet loss is caused by congestion. a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmitting older packets in addition to the Reacting to loss by retransmitting older packets in addition to the
current data would thus further increase congestion. Implementations current data would thus further increase congestion. Implementations
SHOULD follow the recommendations below in order to use SHOULD follow the recommendations below in order to use
retransmission. retransmission.
The RTP profile under which the retransmission scheme is used The RTP profile under which the retransmission scheme is used
defines an appropriate congestion control mechanism in different defines an appropriate congestion control mechanism in different
environments. Following the rules under this profile, an RTP environments. Following the rules under the profile, an RTP
application can determine its acceptable bitrate and packet rate in application can determine its acceptable bitrate and packet rate in
order to be fair to other applications such as TCP flows and other order to be fair to other applications such as TCP flows and other
RTP flows. RTP flows.
If an RTP application uses retransmission, the acceptable packet If an RTP application uses retransmission, the acceptable packet
rate and bitrate SHOULD include both the original and retransmitted rate and bitrate SHOULD include both the original and retransmitted
data. This will guarantee that an application using retransmission data. This guarantees that an application using retransmission
should be fair to any other RTP or TCP flows. Such a rule would should be fair to any other RTP or TCP flows. Such a rule would
translate in practice into the following actions: translate in practice into the following actions:
If enhanced service is used it should made sure that the total If enhanced service is used, it should be made sure that the total
bitrate and packet rate do not exceed that of the requested service. bitrate and packet rate do not exceed that of the requested service.
It should be further monitored that the requested services are It should be further monitored that the requested services are
actually delivered. In a best-effort environment, the sender SHOULD actually delivered. In a best-effort environment, the sender SHOULD
NOT send retransmission packets without reducing the packet rate and NOT send retransmission packets without reducing the packet rate and
Leon, Varsa - Expires September 2002 7
RTP retransmission framework March 2002
bitrate of the original stream (for example by encoding the data at bitrate of the original stream (for example by encoding the data at
a lower rate). a lower rate).
In addition, the sender MAY retransmit only the packets that it In addition, the sender MAY retransmit only the packets that it
deems important and ignore NACK messages for other packets in order deems important and ignore NACK messages for other packets in order
to limit the bitrate to limit the bitrate
These congestion control mechanisms should keep the congestion level These congestion control mechanisms should keep the congestion level
under an acceptable limit. This would in turn guarantee that the under an acceptable limit. This would in turn guarantee that the
packet loss should be moderate. Too high a packet loss would mean packet loss should be moderate. Too high a packet loss would mean
that congestion is not kept under control and retransmission should that congestion is not kept under control and retransmission should
then not be used. then not be used.
7. Example scenario of unicast streaming 8. Example scenario of unicast streaming
Let us assume that the RTP session bandwidth is 64 kbps and the Let us assume that the RTP session bandwidth is 64 kbps and the
receiver buffering delay is 3 seconds. The network round trip time receiver buffering delay is 3 seconds. The network round trip time
is 500 ms and Receiver RTCP packets are sent at 2-second intervals is 500 ms and Receiver RTCP packets (including NACK messages ) are
from the receiver including NACK messages for missing original
packet SNs. With these time limitations, when the receiver algorithm Leon, Varsa - Expires December 2002 8
for generating retransmission requests described in Section 5.2 is RTP retransmission framework June 2002
followed, only one NACK message but no repeated NACK messages can be
sent for the same original packet loss. Let us assume an original sent at 2-second intervals. With these time limitations, when the
packet rate of 50 packets per second (1 packet every 20 ms). At this receiver algorithm for generating retransmission requests described
packet rate in a packet loss distribution worst case scenario where in Section 6.2 is followed, only one request per packet loss can be
every 17th original packet is lost (i.e. 5.88% uniform packet loss), sent. Let us assume an original packet rate of 50 packets per second
a maximum of 6 NACK messages need to be appended to the RTCP (1 packet every 20 ms). At this packet rate, with the packet loss
compound packet that is sent every 2 seconds. The 6 NACK messages distribution worst case scenario where every 17th original packet is
can report any packet losses in an SN range of 6*17=102, thus the lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages
number of required NACK messages would not increase with higher need to be appended to the RTCP compound packet that is sent every 2
packet loss rates. The overhead required per RTCP compound packet seconds. The 6 NACK messages can report any packet losses in an SN
for the 6 NACK messages is 36 bytes which carries 6 PID and 6 BLP range of 6*17=102, thus the number of required NACK messages would
fields in addition to the feedback message headers. not increase with higher packet loss rates. The overhead required
per RTCP compound packet for the 6 NACK messages is 36 bytes which
carries 6 PID and 6 BLP fields in addition to the feedback message
headers.
The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+ The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+
RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The
needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP
bandwidth is well below the maximum allowed RTCP bandwidth that bandwidth is well below the recommended RTCP bandwidth. The receiver
would be allowed when using [4]. From the receiver to the sender the RTCP recommended bandwidth in an RTP session with 64 kbps is about
RTCP bandwidth limit in an RTP session with 64 kbps is about 0.25*64 0.25*64 = 1.6 kbps.
= 1.6 kbps.
8. SDP usage 9. SDP usage
The binding to the payload type number is indicated by an rtpmap The binding to the payload type number is indicated by an rtpmap
attribute. The name used in the binding is "RTX".. attribute. The name used in the binding is "RTX".
c=IN IP4 113.3.12.11 c=IN IP4 113.3.12.11
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
a=rtpmap:96 H263-1998/90000 a=rtpmap:96 H263-1998/90000
a=fmtp:96 rtcp-fb nack a=fmtp:96 rtcp-fb nack
Leon, Varsa - Expires September 2002 8
RTP retransmission framework March 2002
m=video 49172 RTP/AVPF 97 m=video 49172 RTP/AVPF 97
a=rtpmap:97 RTX/90000 a=rtpmap:97 RTX/90000
9. FEC for retransmission 10. Security consideration
Retransmission and FEC [7] have similar security conditions as far
as encryption and congestion control are concerned.
Applications utilizing encryption SHOULD encrypt both the original
and the retransmission stream. Old keys will likely need to be
cached so that when the keys change for the original stream, the old
key is used until it is determined that the key has changed on the
retransmission packets as well.
Congestion control considerations with the use of retransmission are
dealt with in Section 7 of this document.
Any other security considerations of the profile under which the
retransmission scheme is used should be applied.
Leon, Varsa - Expires December 2002 9
RTP retransmission framework June 2002
Appendix: FEC for retransmission
It is possible to retransmit the payload of an original packet by It is possible to retransmit the payload of an original packet by
sending a FEC packet as defined in [7] instead of using the sending a FEC packet as defined in [7] instead of using the
retransmission payload format. The base SN of the FEC header is the retransmission payload format. The base sequence number of the FEC
sequence number of the original packet that carried the same payload header is the sequence number of the original packet that carried
and the mask is set to zero. There are some advantages in using the the same payload and the mask is set to zero. There are some
FEC payload format in particular in multicast sessions as a single advantages in using the FEC payload format in particular in
FEC packet may repair the loss of different packets at different multicast sessions as a single FEC packet may repair the loss of
receivers. In a multicast session, FEC may be combined with different packets at different receivers. In a multicast session,
retransmission requests as described in [8] in order to achieve FEC may be combined with retransmission requests as described in [8]
scalable reliable multicast transmission. in order to achieve scalable reliable multicast transmission.
There are however some motivations to define the retransmission There are however the following motivations to define the
payload format in order to perform retransmission instead of using retransmission payload format in order to perform retransmission
the FEC payload format: instead of using the FEC payload format:
*The retransmission payload format has reduced overhead (3 bytes *The retransmission payload format has reduced overhead (3 bytes
instead of 12 bytes). instead of 12 bytes).
*In the retransmission payload format, the RTP header TS is the *In the retransmission payload format, the RTP header TS field is
actual TS of the (retransmitted) media carried in the packets. This the actual timestamp of the (retransmitted) media carried in the
is in line with RTP [5] specifications. This is useful in particular packets. This is in line with RTP [5] specifications. This is useful
for RTP mixers/translators which process the TS. On the other hand, in particular for RTP mixers/translators which process the TS field.
the FEC payload format uses the RTP transmission time (as the FEC On the other hand, the FEC payload format uses the RTP transmission
packet should be computed over data with different TS). time (as the FEC packet should be computed over data with different
timestamp).
*Assuming that no retransmission payload format were defined, the *Assuming that no retransmission payload format were defined, the
FEC payload format would then be used in different ways: sending FEC payload format would then be used in different ways: sending
computed FEC packets proactively for correction of lost packets at computed FEC packets proactively for correction of lost packets at
the receiver without requiring NACK messages (referred hereafter as the receiver without requiring NACK messages (referred hereafter as
proactive FEC) or sending retransmitted data upon receipt of a NACK proactive FEC) or sending retransmitted data upon receipt of a NACK
message from the receiver. message from the receiver.
Although they could use the same payload format, these two repair Although they could use the same payload format, these two repair
mechanisms are different. For a given amount of overhead, they offer mechanisms are different. For a given amount of overhead, they offer
a different residual packet loss vs. latency trade-off. a different residual packet loss vs. latency trade-off.
skipping to change at line 479 skipping to change at line 536
use of the FEC packet at the receiver. On the other hand, data which use of the FEC packet at the receiver. On the other hand, data which
are retransmitted are known to have been lost. are retransmitted are known to have been lost.
Therefore, a receiver may wish to use only retransmission and not Therefore, a receiver may wish to use only retransmission and not
receive any proactive FEC from the sender in order to trade-off receive any proactive FEC from the sender in order to trade-off
itself the buffering delay, the data-loss rate and the overhead. itself the buffering delay, the data-loss rate and the overhead.
There is thus a motivation to let the receiver decide at session There is thus a motivation to let the receiver decide at session
setup whether the sender may send proactive FEC or retransmission setup whether the sender may send proactive FEC or retransmission
only. only.
If the same payload format were used for these different purposes, If the same payload format were used for these different purposes,
the receiver would not know at session establishment which repair the receiver would not know at session establishment which repair
Leon, Varsa - Expires September 2002 9
RTP retransmission framework March 2002
mechanism is used by the sender (without defining out-of-band mechanism is used by the sender (without defining out-of-band
signalling). The sender would decide by itself whether FEC or signalling). The sender would decide by itself whether FEC or
retransmission (or both) is used and the receiver would not know retransmission (or both) is used and the receiver would not know
Leon, Varsa - Expires December 2002 10
RTP retransmission framework June 2002
until receiving the FEC packets whether proactive FEC or until receiving the FEC packets whether proactive FEC or
retransmission is used. retransmission is used.
On the other hand, having different payload formats or at least On the other hand, having different payload formats or at least
different out of band signalling for these two repair mechanisms different out of band signalling for these two repair mechanisms
(e.g. through defining the binding name 'RTX' SDP rtpmap attribute) (e.g. through defining the binding name 'RTX' SDP rtpmap attribute)
would allow the receiver to choose which mechanism to use (among would allow the receiver to choose which mechanism to use (among
those supported by the sender). The receiver would then have an those supported by the sender). The receiver would then have an
explicit way to tell the sender not to send proactive FEC. explicit way to tell the sender not to send proactive FEC.
Furthermore, if the receiver did not know at session establishment Furthermore, if the receiver did not know at session establishment
whether it will receive FEC packets or retransmission, it would have whether it will receive FEC packets or retransmission, it would have
to be prepared to receive FEC and thus be able to perform FEC packet to be prepared to receive FEC and thus be able to perform FEC packet
recovery operations. Implementers could thus not choose to implement recovery operations. Implementers would thus not be able choose to
only a FEC or retransmission scheme. implement only a FEC or retransmission scheme.
10. Security consideration
The security considerations of the profile under which the
retransmission scheme is used should be applied.
11. References References
1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", 1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media",
RFC 2354, June 1998. RFC 2354, June 1998.
2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and 2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and
VideoConferences with Minimal Control," Internet Draft draft- VideoConferences with Minimal Control," Internet Draft draft-
ietf-avt-profile-new-12.txt, November 2001. ietf-avt-profile-new-12.txt, November 2001.
3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, 3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi,
R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based
skipping to change at line 534 skipping to change at line 586
6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000
7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss
recovery for reliable multicast transmission", ACM SIGCOMM'97, recovery for reliable multicast transmission", ACM SIGCOMM'97,
Cannes, France, September 1997 Cannes, France, September 1997
Leon, Varsa - Expires September 2002 10
RTP retransmission framework March 2002
Author's Addresses Author's Addresses
David Leon David Leon
Leon, Varsa - Expires December 2002 11
RTP retransmission framework June 2002
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1860 6000 Connection Drive Phone: 1-972-374-1860
Irving, TX. USA Email: david.leon@nokia.com Irving, TX. USA Email: david.leon@nokia.com
Viktor Varsa Viktor Varsa
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1861 6000 Connection Drive Phone: 1-972-374-1861
Irving, TX. USA Email: viktor.varsa@nokia.com Irving, TX. USA Email: viktor.varsa@nokia.com
Leon, Varsa - Expires September 2002 11 Leon, Varsa - Expires December 2002 12
 End of changes. 

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