David Leon
   Internet Draft                                          Viktor Varsa
   Document: draft-leon-rtp-retransmission-01.txt                 Nokia
   Expires: April 2002                                    November 2001


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

   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
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   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.


Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1].





   Leon, Varsa     IETF draft - Expires April 2002                  1
                     RTP retransmission framework        November 2001

Table of Contents

   Abstract...........................................................1
   Terminology........................................................1
   1. Introduction....................................................2
   2. Retransmission payload format...................................2
   3. Use with extended RTP profile for RTCP feedback.................4
   4. Congestion control and scheme efficiency........................5
   5. Example scenario................................................6
   6. SDP usage.......................................................6
   7. Security consideration..........................................6
   8. References......................................................7
   Author's Addresses.................................................7


1. Introduction

   RTP packet loss between a source and a receiver may significantly
   degrade the quality of the received signal. Several techniques, such
   as forward error correction (FEC), retransmissions or adaptation of
   application layer (e.g. video) error resilience techniques based on
   back-channel messages may be considered to increase the robustness
   to packet loss. RFC-2354 [2] 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 streaming, latency is perceived by the user as part of
   the session setup delay and thus a latency of several seconds is
   tolerable. Retransmission may thus be considered for such
   applications.

   This document proposes a retransmission framework. It defines a
   payload format for retransmitted RTP streams and retransmission
   rules. This RTP retransmission scheme requires frequent enough RTCP
   feedback as well as packet request feedback messages. The AV profile
   [3] does not provide these features and could therefore not be used.
   However, the retransmission scheme could be run under the extended
   RTP profile for RTCP-based feedback[4].


2. Retransmission payload format
   In this document, an original packet refers to any media packet sent
   by an RTP source. A retransmission packet is an RTP packet which
   includes the original payload and is sent on a request of a
   receiver.

   Retransmission packets MUST be sent to a different RTP session (as
   defined in RTP [5]) from that of the original RTP media. The

   Leon, Varsa          - Expires December 2001                      2
                     RTP retransmission framework        November 2001

   original and retransmission streams must therefore be sent to
   different multicast group/unicast addresses and/or port numbers.

   The payload format of a retransmission packet (RTX packet) is as
   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, the sequence number has
   the standard definition, i.e. it MUST be one higher than the
   sequence number in the previously retransmitted packet. All other
   fields of the RTP header have the same value as in the original RTP
   packet.

   The retransmitted packet payload carries an E bit, a OPT field (7
   bits) and an OSN field (2 bytes) followed by the original RTP
   payload data. The E bit is an extension bit for future-proofing. It
   MUST be set to zero. The OPT and OSN field are respectively the
   payload type and sequence number of the original RTP packet that is
   being retransmitted.

   There are several advantages when using a separate RTP session for
   the retransmission stream as described below.

   *There are no modifications to the payload format of the original
   packets. Retransmission can thus work with any existing payload
   format.

   *When the RTX stream is sent to a multicast session, receivers may
   choose to subscribe to the retransmission session or not. Therefore,
   a multicast streaming session may be joined by receivers which may
   or may not implement the retransmission payload format.

   *In particular, the original RTP session may be multicast while
   there may be separate unicast retransmission sessions to each
   participant. Each sender will then receive retransmissions only for
   packets it has himself requested.

   *Mixers/translators may ignore the retransmitted packets.

   *As a consequence of having separate sessions for original and
   retransmission traffic, there are also separate RTCP streams and
   statistics for these two sessions. There is thus no corruption of

   Leon, Varsa          - Expires December 2001                      3
                     RTP retransmission framework        November 2001

   the original data 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.


3. Use with extended RTP profile for RTCP feedback

   When the extended RTP profile is used, it is RECOMMENDED that
   receivers send retransmission requests according to the rules in the
   present section. The rules described hereafter aim at minimizing the
   bandwidth required for RTCP and are compliant to the more general
   rules described in the profile itself.

   The minimum RTCP report interval is computed according to the
   allowed RTCP bandwidth of a given session (obtained explicitly or
   calculated as a percentage of the RTP session bandwidth). The NACK
   message format defined in the profile is used. Early feedback
   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.

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

   The playout buffer delay B at the receiver needs to be higher than
   the RTCP reporting interval added to the delay estimate, i.e.
   B>T_rr+D

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

   A receiver needs to maintain a list of missing packet sequence
   numbers since it last sent RTCP packet. If the retransmission stream
   is sent to a multicast session, the receiver SHOULD listen to
   retransmission requests from other receivers. If a request for one
   of the missing packets has been sent by another receiver, the
   receiver SHOULD remove the stored sequence number. Also, the
   receiver should upon a retransmission reception remove the
   corresponding request from the list of missing SNs.

   A receiver needs also to store for each missing packet an estimated
   RTP timestamp. The estimate can be calculated using the TS of
   consecutive packets to the missing packet. At the next scheduled
   RTCP packet time, the receiver estimates based on the estimated RTP
   timestamp of the missing packet if its retransmission could be
   received before its playout time. If not, it removes the packet from
   its list of missing packets (it might also choose to adapt its

   Leon, Varsa          - Expires December 2001                      4
                     RTP retransmission framework        November 2001

   playout delay). The receiver then adds the request for the missing
   packets to the scheduled RTCP compound packet using the PID and BLP
   fields of the NACK packet format. If needed, there should be
   multiple PID and BLP fields in the sent packets. Since the RTCP
   packet is a regularly scheduled packet, the E bit should not be set.

   The same retransmission request may be resent by the receiver if the
   requested packet was not received after its estimated retransmission
   reception time. This increases robustness to the loss of
   retransmission request or of a retransmission packet. The next
   retransmission request may be sent at the earliest at the next RTCP
   report scheduled time.

   Any other rules to send feedback MAY be used as long as they are
   compliant with the profile in use. In particular, a receiver MAY
   send NACK packets as early feedback packets. However, in that case
   the time when the next RTCP packet following this early RTCP packet
   can be sent may 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 a packet loss
   and being able to send a request for that packet is no longer than
   the regular RTCP interval. In addition, if packet loss is caused by
   congestion, it is better to retransmit the packet at a latter point
   of time to increase the probability that the retransmission succeeds
   since network conditions may have improved by then.

   Since the original RTP stream and the retransmission stream are sent
   into separate RTP sessions, there needs to be two different RTCP
   streams as well. The amount of RTCP sent for the retransmission
   stream is computed as a fraction of the retransmission session
   bandwidth. Since, the retransmission traffic should be limited, the
   overhead caused by the retransmission session should be moderate.
   For example, assuming a 64 kbps original RTP session and on average
   3% packet loss and all lost packets retransmitted once, the
   bandwidth of the retransmission session would be about 2 kbps. In
   this case the recommended RTCP traffic for the retransmission
   session would be 0.1 kbps.

   Extended or early feedback messages SHOULD NOT be used in the
   retransmission session.


4. Congestion control and scheme efficiency

   Use of retransmission should not increase the packet loss in the
   original stream. The client should monitor the RTCP statistics of
   the original stream and check that they do not deteriorate with the
   use of retransmission.

   RTP with retransmissions should be fair to RTP without
   retransmissions and TCP. An RTP sender using retransmission must
   follow the congestion control rules of its RTP profile.


   Leon, Varsa          - Expires December 2001                      5
                     RTP retransmission framework        November 2001

   The sender SHOULD retransmit only the packets that it deems
   important and ignore retransmission requests for other packets in
   order to limit the sent bitrate. It should further reduce its packet
   rate and bitrate (by encoding the data at a lower rate) in a best-
   effort network to avoid congestion.

   The scheme should be applied to moderate packet loss. The maximum
   tolerable packet loss rate depends on the application but probably
   not more than 5 to 10% at a maximum. Higher packet loss would mean
   that the level of congestion is too high on a best-effort network.


5. Example scenario

   Unicast video streaming to a mobile client

   In this scenario, packet loss is caused by bit errors over the radio
   interface. Let us assume that the packet loss is 6%, the receiver
   playout buffering is 3 seconds, the round trip time 500 ms. A 2-
   second RTCP interval would thus allow the receiver to perform one
   retransmission attempt. Let us assume a packet rate of 50 packets
   per second. The average loss rate is thus 3 packets per second. The
   maximum overhead of a NACK report packet to request 3 packet losses
   is a NACK packet of length 24 bytes (length field in fixed header is
   set to 5) which carries three PIDs and three BLPs.
   Compound RTCP packets sent by the mobile may be as follows:
   IPv4 (20), UDP (8), RR(header 8 + report 24), CNAME(12), NACK (24).
   The total size would thus be 96 bytes. The needed uplink RTCP
   overhead would then be 0,384 kbps.

   Let us assume that the RTP session bandwidth is 64 kbps, the
   recommended RTCP bandwidth is 2.5% of this, that is 1.6 kbps.
   Therefore, the feedback can be easily accommodated with the RTCP
   recommended bandwidth.

6. SDP usage

   The binding to the payload type number is indicated by an rtpmap
   attribute. The name used in the binding is "RTX". An example SDP
   description is shown below.

   c=IN IP4 113.3.12.11
   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





   Leon, Varsa          - Expires December 2001                      6
                     RTP retransmission framework        November 2001


7. Security consideration

   The security considerations of the profile under which the
   retransmission scheme is used should be applied.


8. References

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

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

   3  Schulzrinne, H and Casner, S. " RTP Profile for Audio and
      VideoConferences with Minimal Control," Internet Draft draft-
      ietf-avt-profile-new-09.txt, July 2000.

   4  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"

   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-08.txt, July 2000.




Author's Addresses

   David Leon
   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 2001                      7