[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                   AVT WG
Internet Draft                                               Koichi Yano
draft-ietf-avt-rtprx-00.txt                             Matthew Podolsky
July 14, 2000                                             Steven McCanne
Expires:  January 14, 2001

           RTP Profile for RTCP-based Retransmission Request
                          for Unicast session.

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


   This document specifies a new RTP profile for retransmission of lost
   packets of unicast multimedia sessions.  We refer to this profile as
   "RTP/AVP-RX".  This profile follows RFC 1889 as it is for data
   exchange.  Specifically for unicast session, it changes the RTCP
   interval and defines a new RTCP packet type for retransmission
   requests.  This document also describes how retransmission requests
   and retransmission data may be sent within RTP.

1.  Conventions and Acronyms

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [2].

Yano, Podolsky, McCanne                                         [Page 1]

Internet Draft         RTCP-based Retransmission              July, 2000

2. Introduction

   RTP was designed as a flexible protocol capable of transporting real-
   time data over multicast or unicast.  It has been widely deployed and
   used extensively for transmitting real-time (or "near" real-time)
   multimedia signals, commonly called media streams.  And although
   considerable effort went into the design of RTP so that it could
   support multi-party interactive conferencing over multicast, a common
   use of it today is for one-way non-interactive transmission of media
   streams.  Because the communication is non-interactive, extra
   playback buffering and delay may be tolerable, which in turn enables
   receivers to request and receive retransmissions of lost RTP packets
   before their scheduled play-out times.  For example, popular
   commercial products like RealNetworks' G2 Player and Microsoft's
   NetShow use RTP as the underlying transport protocol for their media
   streams, and use retransmissions in unicast delivery sessions.

   However, as noted in [4], no standard exists for requesting the
   retransmission of streaming media.  As a result, various independent
   and incompatible research and commercial schemes have been developed
   for retransmission of RTP streams [3, 5].  This purpose of this note
   is to define a standard retransmission request framework for use with
   unicast RTP streams.  Additionally, potential deployment of RTCP
   packets for congestion control is described.

3.  RTCP Packet Forms and Protocol Behavior

   The section "RTP Profiles and Payload Format Specification" of RFC
   1889 enumerates a number of items that can be specified or modified
   in a profile.  This new profile is referred to RTP/AVP-RX or AVP-RX
   in this note.  The profile, RTP/AVP-RX, follows all of the default
   and/or recommended aspects of the Audio and Video Profile,
   RTP/AVP[6], except for the items which are described below.

   RTCP packet types:
      A new RTCP packet type, RTCP_NACK, is defined for requesting a
      retransmission.  The packet format is specified in section 4.2.

   RTCP report interval:
      In order to allow immediate RTCP response to packet loss, the RTCP
      report interval restriction in RFC 1889 SHOULD be relaxed.
      However, in order to prevent RTCP packets from flooding the
      network, the bandwidth constraint of RFC 1889 should be preserved.
      Recommendations about the RTCP transmission frequency are
      specified in section 4.1.

   This profile SHOULD be referred to as "RTP/AVP-RX" by applications
   such as session directories.  A payload type which is transmitted on

Yano, Podolsky, McCanne                                         [Page 2]

Internet Draft         RTCP-based Retransmission              July, 2000

   "RTP/AVP-RX" MAY be designated through high level control protocols
   such as SDP[8], as described in Audio/Video Profile [6] or a
   succeeding draft.  A payload type which is defined for Audio/Video
   profile may be used as it is by deploying a default NACK format shown
   in section 4.3.  The following is an example of SDP media

   m=video 49170 RTP/AVP-RX 31

   In this example, the media format 31 indicates that video uses H.261.
   The payload format in RFC2032 [9] is used for RTP data transmission
   and NACK packets are sent with the packet format described in section
   4.3.  RTP/AVP-RX uses the same RTCP port for NACKs as for original
   RTCP packets, so a separate connection does not need to be specified.
   A new payload type may be defined in a succeeding draft specifically
   for this profile.  For any such payload type, a dynamic payload type
   number MUST be used.

   The decision of whether and when to send retransmission packets is
   left to a sender application and is out of the scope of this
   document.  If a sender decides to retransmit packets, the sender
   SHOULD send them as soon as possible after the reception of the NACK
   packet requesting the retransmission.  In addition, the total
   transmission rate SHOULD be regulated within a session bandwidth
   limit that includes the retransmitted packets.  The deployment of
   congestion control is RECOMMENDED as described in section 5.

4. Control packets for unicast session

   This note proposes extending the RTCP specification to accommodate
   retransmission requests.  We define a new RTCP type, RTCP_NACK, for
   notifying the sender of lost packets.  RTCP is a reasonable place for
   inserting these requests because it is a well-established control
   protocol and no extra connections need to be established.  However,
   the RTCP interval specified in [1] is too large for timely
   retransmission requests.  Thus, the current RTCP minimum transmission
   interval should be relaxed.

4.1. RTCP Transmission Bandwidth

   The RTCP transmission interval specified in [1] is not frequent
   enough to allow efficient control of a unicast session needing to
   request retransmissions of lost packets.  RFC 1889 recommends a
   minimum interval of 5 seconds between control packets.  In order to
   make RTCP applicable for unicast retransmission, a packet-granularity
   RTCP interval is necessary.

   The minimum interval restriction SHOULD be removed for unicast RTP

Yano, Podolsky, McCanne                                         [Page 3]

Internet Draft         RTCP-based Retransmission              July, 2000

   sessions so that retransmission requests are allowed to be sent
   immediately after loss detection.  In order to prevent  RTCP packets
   from causing network congestion, it is RECOMMENDED that the average
   bandwidth allocated to RTCP be fixed at 5% of the overall session
   bandwidth.  The recommended default sender-receiver allocation values
   are 1/4 of the RTCP bandwidth (1.25%) for the data sender and the
   remainder of the bandwidth (3.75%) for the receiver, following the
   conventions of RFC 1889.

   If the size of RTP payload packets is 1 KBytes and the size of RTCP
   packets is 40 bytes, the 3.75% limitation is large enough for a
   receiver to send an RTCP packet at every other data packet interval.
   The interval is frequent enough to allow timely retransmission
   requests.  In the case of consecutive lost packets, a NACK packet can
   aggregate loss information of up to 16 packets when the default NACK
   format is used.

   In order to regulate the sending rate of RTCP packets within the RTCP
   bandwidth, the deployment of a traffic shaping scheme such as a token
   backet is RECOMMENDED. The token rate SHOULD be set at (rtcp_bw /
   rtcp_size), where rtcp_bw is the RTCP bandwidth and rtcp_size is the
   size of RTCP packets.  The bucket size SHOULD be determined according
   to the playback buffer size.  As long as a token is in the bucket,
   the RTCP packet is sent immediately, and the long-term RTCP rate is
   regulated within the RTCP bandwidth limit.

4.2. Generic Packet format for requesting retransmission

   This section defines a generic packet format for a negative
   acknowledgment (NACK) packet, which is sent from the receiver to the
   sender and which notifies the packet loss of one or more RTP packets.
   This generic packet format provides a way of identifying a packet and
   a 16 bit field for payload specific use.  When a payload format does
   not specify the use of the field, the default format in 4.3 MUST be
   used.  The generic format of NACK packets is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |V=2|P|   RC    | PT=RTCP_NACK  |          length               |
   |                  SSRC of packet sender                        |
   |                  SSRC_1                                       |
   |            PID                |      Payload Specific         |
   |                  SSRC_2                                       |

Yano, Podolsky, McCanne                                         [Page 4]

Internet Draft         RTCP-based Retransmission              July, 2000

   |            PID                |      Payload Specific         |
   |                                                               |

   The various fields V, P, RC, SSRC and length are defined in the RTP
   specification [1].  We summarize the meaning of all of the fields

   version (V): 2 bits
      This field identifies the RTP version.  The current version is 2.

   padding (P): 1 bit
      If set, the padding bit indicates that the RTCP NACK packet
      contains additional padding octets at the end which are not part
      of the retransmission control information but are included in the
      length field.

   report count (RC): 5 bits
      The number of NACK blocks for different SSRC.

   packet type (PT): 8 bits
      This is the RTCP packet type which identifies the packet as being
      an RTCP NACK.

   length: 16 bits
      The length of this RTCP NACK packet in 32-bit words minus one,
      including the header and any padding.  This conforms with the
      definition of the length field used in RTCP sender and receiver
      reports [1].

   SSRC: 16 bits
      The synchronization source identifier for the originator of this
      NACK packet.

   SSRC_n: 16 bits
      The SSRC identifier of the source to which the information in this
      NACK report block pertains.

   Packet ID (PID): 16 bits
      The PID field is used to specify a lost packet.  Payload
      definition can decide how to identify a packet.  Typically RTP
      sequence number is used for PID as the default format.

   Payload Specific: 16 bits
      This 16 bit field can be used for payload specific purposes. If a
      payload type does not specify the use of this field, the default
      packet format in 4.3 must be used.

Yano, Podolsky, McCanne                                         [Page 5]

Internet Draft         RTCP-based Retransmission              July, 2000

   Note that the receiver may detect RTP packet loss via sequence number
   gaps, timer expirations, or other methods; however, details of the
   loss detection scheme are outside of the scope of this document.

4.3. Default NACK format

   This section shows the default use of the packet id field and the
   payload specific field. RTP/AVP-RX profile MAY be deployed for
   transmitting a payload which is defined for RTP/AVP profile.  Unless
   any specific packet format for AVP-RX profile is defined in a payload
   type, this default packet format MUST be used for NACKs.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |V=2|P|   RC    | PT=RTCP_NACK  |          length               |
   |                  SSRC of packet sender                        |
   |                  SSRC_1                                       |
   |            FSN                |R|           BLP               |
   |                  SSRC_2                                       |
   |            FSN                |R|           BLP               |
   |                                                               |

   The FSN and BLP fields have similar definitions to those given for
   the RTCP_NACK packet specified in [3].  The R bit is used to notify
   the sender whether lost packets need to be retransmitted.  NACK
   packets SHOULD be sent for all lost packets, even packets the
   receiver may no longer need to be retransmitted, in order to allow
   effective operation of congestion control.  The receiver can notify
   the sender whether the packet needs retransmission through the R
   field in a NACK packet.  The meanings of these fields are as follows:

   first sequence number (FSN): 16 bits
      The FSN corresponds to an RTP sequence number of a media stream.
      A NACK packet with a FSN field set to N is to be interpreted as a
      signal that the receiver has detected loss of RTP data packet N.

   requirement of retransmission (R): 1 bit
      This field indicates whether the receiver is requesting
      retransmission of the lost packets designated by the FSN and BLP
      fields.  If this bit is set to 1, the lost packets of this NACK
      block are requested to be retransmitted.  If the bit is set to 0,

Yano, Podolsky, McCanne                                         [Page 6]

Internet Draft         RTCP-based Retransmission              July, 2000

      the lost packets are not to be retransmitted, and this NACK packet
      was sent only for the purpose of reporting packet loss.

   bitmask of following lost packets (BLP): 15 bits
      The BLP allows for reporting losses of any of the 15 RTP packets
      immediately following the RTP packet indicated by the FSN.  The
      BLP's definition is identical to that given in [3].  Denoting the
      BLP's least significant bit as bit 1, and its most significant bit
      as bit 15, then bit i of the bitmask is set to 1 if the sender has
      not received RTP packet number FSN+i (modulo 2^16) and the
      receiver decides this packet is lost; bit i is set to 0 otherwise.
      Note that the sender MUST NOT assume that a receiver has received
      a packet because its bitmask was set to 0.  For example, the least
      significant bit of the BLP would be set to 1 if the packet
      corresponding to the FSN and the following packet have been lost.
      However, the sender cannot infer that packets FSN+2 through FSN+15
      have been received simply because bits 2 through 15 of the BLP are
      0; all the sender knows is that the receiver has not reported them
      as lost at this time.

4.4. Sender and Receiver Report

   The original RTCP packets (SR/RR) SHOULD also be sent based on RFC
   1889.  Loss fraction and other fields in SR and RR SHOULD be
   generated based on original data transmissions and without taking
   into account requested retransmissions that did not arrive.  The
   reason is that although the loss fraction in RR should ideally
   account for loss of any data in the forward transmission path, it is
   difficult to identify the reason of an undelivered retransmission
   packet.  There are three possible reasons a requested retransmission
   may be missing: the retransmitted packet was lost in the forward
   transmission path, the retransmission request was lost in the reverse
   transmission path,  or the sender chose not to respond to the
   retransmission request.

   The Receiver Reports SHOULD be issued more frequently than specified
   in RFC 1889 for use in congestion control (Section 5).  A receiver
   SHOULD send a RR within the RTT intervals and can estimate the RTT
   through the elapsed time between transmission of a NACK packet and
   reception of the corresponding retransmission packet.

5. Congestion Control

   Fair behavior against other types of traffic (mainly TCP) has come to
   be a significant issue for the stability of the Internet.  The need
   to employ congestion control to make RTP streams share bandwidth
   fairly with other streams has become more important now than ever
   before.  The deployment of congestion control is RECOMMENDED for a

Yano, Podolsky, McCanne                                         [Page 7]

Internet Draft         RTCP-based Retransmission              July, 2000

   stream following the AVP-RX profile.  In conjunction with the
   frequent RTCP interval formulated in this proposal, NACKs and RRs can
   provide the necessary information for effective congestion control.
   This section describes the applicability of the RTCP (RR and NACK)
   information for congestion control.

   For many congestion control schemes[10,11] to operate, the loss rate
   and RTT is required.  Because RRs include the loss fraction, and
   because the RTT can be calculated by the sender based on the RRs as
   described in RFC1889[1], if RRs are sent frequently enough (section
   4.3) then a sender can execute a congestion control scheme such as a
   TCP fair equation-based scheme[10].

   A congestion control scheme, TFRC[11], recommends the use of the loss
   interval rate instead of the loss rate.  By keeping track of sequence
   number of lost packets provided by NACK packets, the sender can
   calculate the loss interval and execute the congestion control
   described in [11].  The RTT is calculated based on RR reception
   timing in this case as well.

6. Examples of retransmission decisions

   Retransmitted packets which arrive after their scheduled playout time
   waste network resources even when successfully received. This section
   gives  examples of how the decision to retransmit a packet may be
   made and how the  R bit in the NACK packets is used.

6.1  A simple retransmission request system

   The simplest way to realize loss recovery using retransmissions is to
   let the receiver decide whether a NACK packet with R bit set should
   be sent and have the sender respond to all retransmission requests
   with retransmitted packets.  In this case the receiver sends NACKs
   with the R bit set whenever it determines that one or more data
   packets have been lost and that their playback times have not yet
   passed. If the receiver detects lost packets after the playback time
   passed, the R bit in NACK packets is set to 0.

   This scheme can be realized without an extra control packet between
   the sender and the receiver. However it could result in many late
   packets that arrive after play out time because it does not account
   for the delay between the time a receiver transmits a NACK and the
   time at which the retransmitted packet(s) corresponding to that NACK
   arrive (which is one RTT or greater).

Yano, Podolsky, McCanne                                         [Page 8]

Internet Draft         RTCP-based Retransmission              July, 2000

6.2.  Receiver-based decisions on requesting retransmissions

   Before making a retransmission request at time Tr of packet N
   (scheduled for play-out at time Tp[N]), the receiver checks if

   Tr + eRTT < Tp[N]

   where eRTT is an estimate of the round trip time (RTT).  If true then
   the receiver assumes the retransmission will arrive in time, and it
   sends the request for packet N with R bit set.  If false the receiver
   sends a NACK whose R bit is set to 0.  The above check can be made
   more general to account for receiver decoding delays and the sender's
   delay in responding to the retransmission request. The RTT estimate
   can be based on the measured elapsed time between the transmission of
   each NACK and the reception of each retransmitted packet.  eRTT is
   calculated from these RTT measurements through Karn's algorithm[7].

7. References

   [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
   "RTP: A transport protocol for real-time applications," RFC 1889,
   January 1996.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments (Best Current Practice) 2119, Internet
   Engineering Task Force, Mar. 1997.

   [3] Turletti, T. and Huitema, C., "RTP Payload Format for H.261 Video
   Streams," RFC 2032, October 1996.

   [4] Perkins, C. and Hodson, O., "Options for Repair of Streaming
   Media" RFC 2354, June 1998.

   [5] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar.  Resilient
   multicast support for continuous media applications.  In Proceedings
   of the 7th International Workshop on Network and Operating Systems
   Support for Digital Audio and Video (NOSSDAV'97), Washington
   University in St. Louis, Missouri, May 1997.

   [6] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
   with Minimal Control," RFC 1890, January 1996.

   [7] P. Karn and C. Partridge, "Improving Round-Trip Time Estimates in
   Reliable Transport Protocol."  ACM Transactions on Computer Systems
   (TOCS), Vol. 9, No. 4, pp. 364-373, November 1991

   [8] M. Handley and V. Jacobson, "SDP: Session Description Protocol."

Yano, Podolsky, McCanne                                         [Page 9]

Internet Draft         RTCP-based Retransmission              July, 2000

   Request for Comments RFC 2327.

   [9] T. Turletti and C. Huitema, "RTP Payload Format for H.261 Video
   Streams."  Request for Comments RFC 2032, October 1996.

   [10] J. Mahdavi, S. Floyd, "TCP-Friendly Unicast Rate-Based Flow
   Control", Technical note sent to the end2end-interest mailing list,
   January 8, 1997.

   [11] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
   Congestion Control for Unicast Applications."  ACM SIGCOMM 2000.


   Koichi Yano
   UC Berkeley Computer Science Dept.
   Phone: 510-642-9513
   Email: yano@cs.berkeley.edu
   URL: http://www.cs.berkeley.edu/~yano

   Matthew Podolsky
   UC Berkeley Computer Science Dept.
   Phone: 510-642-8905
   Email: podolsky@eecs.berkeley.edu
   URL: http://www.eecs.berkeley.edu/~podolsky

   Steven McCanne
   FastForward Networks
   Email: mccanne@cs.berkeley.edu

   This draft was created in July, 2000.
   It expires  Jan, 2001.

Yano, Podolsky, McCanne                                        [Page 10]