David Leon
   Internet Draft                                          Viktor Varsa
   Document:                                                      Nokia
   Expires: December 2002                                     June 2002

                       RTP retransmission framework

   Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at


   RTP retransmission is an effective packet loss recovery scheme for
   real-time applications with relaxed delay bounds.
   This document describes an RTP retransmission framework. It defines
   a payload format for retransmitted packets and recommends rules for
   sending these packets. Retransmitted RTP packets are sent in a
   separate stream from the original RTP stream. It is assumed that
   feedback from receivers to senders indicating the occurred packet
   losses is available by some means not defined here.

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
   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
   concluded that RFC 2198 was not intended to such a use. Piggybacking
   retransmitted packets was thus removed from the draft.

Table of Contents

   Main changes.......................................................1
   1. Introduction....................................................2
   2. Terminology.....................................................3
   3. Applicability statement.........................................3
   4. Retransmission framework basic principles.......................4
   5. Retransmission payload format...................................5
   6. Use with the Extended RTP profile for RTCP-based feedback.......6
   7. Congestion control..............................................8
   8. Example scenario of unicast streaming...........................8
   9. SDP usage.......................................................9
   10. Security consideration.........................................9
   Appendix: FEC for retransmission..................................10
   Author's Addresses................................................11

1. Introduction

   Packet losses between an RTP sender and receiver may significantly
   degrade the quality of the received signal. Several techniques, such
   as forward error correction (FEC), retransmissions or application
   layer (e.g. video) error resilience adaptation based on back-channel
   messages may be considered to increase the robustness to packet
   loss. RFC-2354 [1] discusses the different options.

   When choosing a technique for a particular system, the tolerable
   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
   few hundred milliseconds in order to guarantee interactivity, which
   usually excludes the use of retransmission. On the other hand, in
   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
   several seconds is possible. Retransmission may thus be considered
   for such applications.

   This document proposes a retransmission framework. It defines a
   payload format for retransmitted RTP packets and retransmission
   rules. This RTP retransmission scheme requires frequent packet loss
   indication feedback to the RTP entity performing retransmission. The
   AV profile [2] does not provide this feature and could therefore not
   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
   message that can be sent as part of a compound RTCP packet.

2. Terminology

   The following terms are used in this document:

   Original packet: refers to an RTP packet which carries user data
   sent for the first time by an RTP sender.

   Original stream: refers to the stream of original packets.

   Retransmission packet: refers to an RTP packet whose payload
   includes the payload of an already sent original packet. Such a
   retransmission packet is said to be associated with the original RTP
   packet whose payload is included in the retransmission packet.

   Retransmission request: a means by which an RTP receiver is able to
   request that the RTP sender send a retransmission packet associated
   with a given original packet. In [3], a retransmission request is
   sent as a packet loss indication in a NACK message.

   Retransmission stream: the stream of retransmission packets
   associated to with an original stream.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [4].

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

   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

   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)
   space with the original stream. The retransmission stream SHOULD use
   a different RTP session (as defined in RTP [5]) from that of the
   original stream. Since a separate session is used, the original and
   retransmission streams are sent to different multicast group/unicast
   addresses and/or port numbers.

   There are several reasons why the SN space must not be shared:

   Since retransmission packets do not share the SN space with the
   original packets, the receiver is able to distinguish between the
   loss of original packets and retransmission packets. Otherwise,
   reliable loss detection of user data would not be possible. Reliable
   data loss detection of user data is mandated for example in RTP
   conversational text [6].

   RTP Timestamp (TS) estimation of missing original packets is
   necessary at the receiver in order to decide whether a
   retransmission is useful or not. A retransmission is useful if the
   retransmission packet sent as a response to the retransmission
   request may still be used when it arrives at the receiver. The
   missing original packet timestamp can be estimated from timestamp of
   packets preceding and/or following the sequence number gap caused by
   the missing packet in the original stream.

   The fact that RTP streams for original and retransmission packets do
   not share the same SN space guarantees that the RTP timestamp
   estimation method is reliable. Reliability would be sacrificed if
   original and retransmission packets were sent in the same RTP stream
   as the timestamp estimate for a lost retransmission packet would

   Leon, Varsa          - Expires December 2002                      4
                     RTP retransmission framework            June 2002

   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,
   receivers may choose whether to subscribe or not to the RTP session
   carrying the retransmission stream. Therefore, a multicast streaming
   application can use retransmission and still be backwards compatible
   as receivers which do not implement the retransmission payload
   format only join the RTP session carrying the original stream. A
   scenario where the original session is multicast and separate
   unicast sessions carry the retransmission stream to each
   participant, is also possible. In this scenario, a receiver receives
   only the retransmission packets it has itself requested and not the
   retransmission packets that are requested by other receivers.

   Mixers, translators and packet caches may be able to separate
   retransmission packets from original packets at an RTP session level
   and process them differently if necessary.

   As a consequence of having separate RTP sessions for original and
   retransmission streams, there are also separate RTCP streams and
   statistics for these two sessions. There is thus no corruption of
   the original stream RTCP statistics. The RTP sender is able to know
   the packet loss and jitter of the original stream. It can thus
   estimate what the quality of the received signal would be without
   the use of retransmission.

5. Retransmission payload format

   The payload format of a retransmission packet is shown below.

   |                         RTP Header                            |
   |E|   OPT       |            OSN                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                  Original RTP Packet Payload                  |
   |                                                               |

   RTP header usage:
   The same SSRC value SHOULD be used for the original stream and the
   retransmission stream. In the RTP header, SN has the standard
   definition, i.e. it MUST be one higher than the sequence number of
   the preceding retransmission packet. The payload type is dynamic and
   indicates the use of the retransmission payload format. All other
   fields of the RTP header have the same value as in the original RTP

   Leon, Varsa          - Expires December 2002                      5
                     RTP retransmission framework            June 2002

   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
   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
   packet payload that is being retransmitted. The OSN field is the
   sequence number of the original packet that originally carried the
   same payload.

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,
   it is RECOMMENDED that receivers send retransmission requests
   according to the rules in this section. The rules described
   hereafter aim at limiting the maximum delay before a retransmission
   request can be sent and are compliant to the more general rules
   described in the profile itself.

   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.

   Any other rules to send feedback may be used as long as they are
   compliant with the profile. In particular, a receiver may send NACK
   messages in early RTCP packets. However, in that case the time when
   the next RTCP packet following this early RTCP packet can be sent
   could be too late to report a loss occurring right after the early
   RTCP packet was sent. Sending RTCP packets at regular 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 RTCP interval.

6.2 Receiver algorithm for generating retransmission requests

   This section gives some general guidelines on how a receiver should
   decide whether or not to request a packet retransmission. An actual
   receiver implementation should take into account such factors as the
   network environment and the media type.

   A receiver should compute an estimate of the delay D to receive a
   retransmission packet after a NACK message has been sent. This
   estimate may be obtained from past observations, RTCP report round-
   trip time if available or any other means.

   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
   RTCP reporting interval added to the delay estimate D, which
   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.
   i.e. B>T_rr+D

   It can be seen that the needed receiver buffering delay is dependent
   on the amount of RTCP traffic allowed in the session. It is
   illustrated in Section 8 that moderate RTCP feedback traffic is
   enough to perform retransmission with reasonable receiver buffering

   A receiver should maintain a list of missing original packet
   sequence numbers. A receiver needs also to store for each missing
   original packet an estimated RTP timestamp as described in Section
   4. At the next scheduled RTCP packet sending time, the receiver
   estimates which of the missing packets should be requested in the
   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
   should be requested if it is estimated the associated retransmission
   packet could still be used at the time it arrives at the receiver.
   The receiver should remove from its list of missing packets, the
   packets which were deemed too old to be requested.

   If the retransmission stream is sent to a multicast session, the
   receiver should listen to NACK messages from other receivers. If a
   NACK message for the sequence number of a missing packet has been
   sent by another receiver, the receiver should ignore that sequence
   number in its list of missing packets and refrain from sending a
   retransmission request for that sequence number.

   The same retransmission request may be resent in the original RTP
   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

   The receiver should upon reception of a retransmission packet remove
   the corresponding original packet sequence number(OSN in the
   retransmission payload format) from the list of missing sequence

6.3 RTCP sending rules in the retransmission RTP session

   Since the original stream and the retransmission stream are carried
   in separate RTP sessions, the retransmission stream has its own RTCP
   stream as well. The amount of RTCP sent for the retransmission
   stream is computed as a fraction of the retransmission RTP session
   bandwidth. Since the retransmission traffic is limited, the overhead
   caused by the additional RTCP packets in the retransmission RTP
   session is moderate. For example, assuming a 64 kbps original RTP
   session and on average 3% packet loss and all lost original packets
   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
   the retransmission RTP session would be 0.1 kbps.

   Early RTCP packets and RTCP feedback messages SHOULD NOT be used in
   the retransmission RTP session.

7. Congestion control

   RTP retransmission poses a risk of increased network congestion. In
   a best-effort environment, packet loss is caused by congestion.
   Reacting to loss by retransmitting older packets in addition to the
   current data would thus further increase congestion. Implementations
   SHOULD follow the recommendations below in order to use

   The RTP profile under which the retransmission scheme is used
   defines an appropriate congestion control mechanism in different
   environments. Following the rules under the profile, an RTP
   application can determine its acceptable bitrate and packet rate in
   order to be fair to other applications such as TCP flows and other
   RTP flows.

   If an RTP application uses retransmission, the acceptable packet
   rate and bitrate SHOULD include both the original and retransmitted
   data. This guarantees that an application using retransmission
   should be fair to any other RTP or TCP flows. Such a rule would
   translate in practice into the following actions:

   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.
   It should be further monitored that the requested services are
   actually delivered. In a best-effort environment, the sender SHOULD
   NOT send retransmission packets without reducing the packet rate and
   bitrate of the original stream (for example by encoding the data at
   a lower rate).

   In addition, the sender MAY retransmit only the packets that it
   deems important and ignore NACK messages for other packets in order
   to limit the bitrate

   These congestion control mechanisms should keep the congestion level
   under an acceptable limit. This would in turn guarantee that the
   packet loss should be moderate. Too high a packet loss would mean
   that congestion is not kept under control and retransmission should
   then not be used.

8. Example scenario of unicast streaming

   Let us assume that the RTP session bandwidth is 64 kbps and the
   receiver buffering delay is 3 seconds. The network round trip time
   is 500 ms and Receiver RTCP packets (including NACK messages ) are

   Leon, Varsa          - Expires December 2002                      8
                     RTP retransmission framework            June 2002

   sent at 2-second intervals. With these time limitations, when the
   receiver algorithm for generating retransmission requests described
   in Section 6.2 is followed, only one request per packet loss can be
   sent. Let us assume an original packet rate of 50 packets per second
   (1 packet every 20 ms). At this packet rate, with the packet loss
   distribution worst case scenario where every 17th original packet is
   lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages
   need to be appended to the RTCP compound packet that is sent every 2
   seconds. The 6 NACK messages can report any packet losses in an SN
   range of 6*17=102, thus the number of required NACK messages would
   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

   The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+
   RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The
   needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP
   bandwidth is well below the recommended RTCP bandwidth. The receiver
   RTCP recommended bandwidth in an RTP session with 64 kbps is about
   0.25*64 = 1.6 kbps.

9. SDP usage

   The binding to the payload type number is indicated by an rtpmap
   attribute. The name used in the binding is "RTX".

   c=IN IP4
   m=video 49170 RTP/AVPF 96
   a=rtpmap:96 H263-1998/90000
   a=fmtp:96 rtcp-fb nack
   m=video 49172 RTP/AVPF 97
   a=rtpmap:97 RTX/90000

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
   sending a FEC packet as defined in [7] instead of using the
   retransmission payload format. The base sequence number of the FEC
   header is the sequence number of the original packet that carried
   the same payload and the mask is set to zero. There are some
   advantages in using the FEC payload format in particular in
   multicast sessions as a single FEC packet may repair the loss of
   different packets at different receivers. In a multicast session,
   FEC may be combined with retransmission requests as described in [8]
   in order to achieve scalable reliable multicast transmission.

   There are however the following motivations to define the
   retransmission payload format in order to perform retransmission
   instead of using the FEC payload format:

   *The retransmission payload format has reduced overhead (3 bytes
   instead of 12 bytes).

   *In the retransmission payload format, the RTP header TS field is
   the actual timestamp of the (retransmitted) media carried in the
   packets. This is in line with RTP [5] specifications. This is useful
   in particular for RTP mixers/translators which process the TS field.
   On the other hand, the FEC payload format uses the RTP transmission
   time (as the FEC packet should be computed over data with different

   *Assuming that no retransmission payload format were defined, the
   FEC payload format would then be used in different ways: sending
   computed FEC packets proactively for correction of lost packets at
   the receiver without requiring NACK messages (referred hereafter as
   proactive FEC) or sending retransmitted data upon receipt of a NACK
   message from the receiver.
   Although they could use the same payload format, these two repair
   mechanisms are different. For a given amount of overhead, they offer
   a different residual packet loss vs. latency trade-off.
   Retransmission provides higher packet loss recovery at the expense
   of higher delay. If a sender uses proactive FEC and none of the
   packets protected by a given FEC packet is lost, there is then no
   use of the FEC packet at the receiver. On the other hand, data which
   are retransmitted are known to have been lost.
   Therefore, a receiver may wish to use only retransmission and not
   receive any proactive FEC from the sender in order to trade-off
   itself the buffering delay, the data-loss rate and the overhead.
   There is thus a motivation to let the receiver decide at session
   setup whether the sender may send proactive FEC or retransmission
   If the same payload format were used for these different purposes,
   the receiver would not know at session establishment which repair
   mechanism is used by the sender (without defining out-of-band
   signalling). The sender would decide by itself whether FEC or
   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
   retransmission is used.
   On the other hand, having different payload formats or at least
   different out of band signalling for these two repair mechanisms
   (e.g. through defining the binding name 'RTX' SDP rtpmap attribute)
   would allow the receiver to choose which mechanism to use (among
   those supported by the sender). The receiver would then have an
   explicit way to tell the sender not to send proactive FEC.
   Furthermore, if the receiver did not know at session establishment
   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
   recovery operations. Implementers would thus not be able choose to
   implement only a FEC or retransmission scheme.


   1  Perkins, C., Hodson, O., "Options for Repair of Streaming Media",
      RFC 2354, June 1998.

   2  Schulzrinne, H and Casner, S. " RTP Profile for Audio and
      VideoConferences with Minimal Control," Internet Draft draft-
      ietf-avt-profile-new-12.txt, November 2001.

   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
      feedback", November 2001

   4  RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997

   5  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
      A Transport Protocol for Real-Time Applications", Internet Draft
      draft-ietf-avt-rtp-new-11.txt, November 2001.

   6  Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000

   7  Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for
      Generic Forward Error Correction", RFC 2733, December 1999.

   8  Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss
      recovery for reliable multicast transmission", ACM SIGCOMM'97,
      Cannes, France, September 1997

Author's Addresses

   David Leon

   Leon, Varsa          - Expires December 2002                     11
                     RTP retransmission framework            June 2002

   Nokia Research Center
   6000 Connection Drive            Phone:  1-972-374-1860
   Irving, TX. USA                  Email:  david.leon@nokia.com

   Viktor Varsa
   Nokia Research Center
   6000 Connection Drive            Phone:  1-972-374-1861
   Irving, TX. USA                  Email:  viktor.varsa@nokia.com

   Leon, Varsa          - Expires December 2002                     12