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

Versions: 00 01 02 03 04 05                                             
Audio/Video Transport Working Group                         A.Miyazaki
Internet Draft                                             H.Fukushima
draft-ietf-avt-rtp-selret-05.txt                                K.Hata
Expires: December 2002                                        T.Wiebke
                                                           R.Hakenberg
                                                          C.Burmeister
                                                            Matsushita

                                                             June 2002

   RTP Payload Formats to Enable Multiple Selective Retransmissions


   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

   This document describes new RTP payload formats, i.e. RTX and SEL,
   to enable multiple and optional selective retransmissions in RTP.
   These are especially applicable to environments where enhanced RTCP-
   based feedback, as per the RTP/AVPF profile [4], is available. Using
   these payload formats it is possible  to classify the media stream
   according to prioritisation of packets or according to the
   transmissions status of the packet ( i.e. transmission or
   retransmission). These payload formats can be tailored to fit
   different scenarios, with different requirements and where different
   solutions are needed. Typical scenarios are unicast transmission and
   small multicast groups. In this document we give examples how  these
   payload formats can be used to accommodate different retransmission
   schemes.





Miyazaki, et. al.      Expires - December 2002               [Page 1]

                Multiple Selective RTP Retransmissions       June 2002




   Changes from draft-ietf-avt-rtp-selret-02.txt

   The main changes from version 02 to 03 were a new section about how
   to indicate the payload format usage in SDP, many clarifications
   regarding how to use the headers of the payload formats, especially
   regarding combination of headers and two new examples retransmission
   schemes including examples how to describe those with SDP. The
   following list describes the detailed changes:

   All sections:
     - editorial changes

   Section 3, Requirements for Retransmissions in RTP
     - new section, highlighting identified requirements

   Section 4, General Use of the Payload Formats
     - clarification about having several headers in one packet
     - list of possible header combinations
     - general rules of how to use the payload formats

   Section 5, Retransmission Payload Format
     - changes in the header format to include the possibility to
       signal the complete original sequence number or the delta
       sequence number

   Section 6, Selective Payload Format
     - changes in the header format to include the possibility to
       signal the complete referenced sequence number

   Section 9, Relation to SDP
     - new section, describing how to use SDP to indicate the usage of
       the payload formats

   Section 10, Example Usages of the Payload Formats
     - adding SDP descriptions to all examples
     - two new example usages:
       - retransmissions on a different stream
       - retransmissions in layered transmissions

   Changes from draft-ietf-avt-rtp-selret-03.txt

   The changes from version 03 are mainly editorial. Minor errors were
   corrected and some clarifications added.

   Changes from draft-ietf-avt-rtp-selret-04.txt

   All sections
     - minor editorial changes and wording.




Miyazaki, et. al.       Expires December 2002                       2
                Multiple Selective RTP Retransmissions       June 2002



   Section 4 Applicability Statement
     - This section is fully new. In the IETF#53 it was decided to
       proceed with both this draft-ietf-avt-rtp-selret-05.txt and
       draft-ietf-avt-rtp-retransmission-00.txt for Last Call, as it
       was understood by the chairs, that they solve different
       problems. It was then decided both drafts must include an
       applicability statement.

   Section 7 Selective Payload Format
     - Rewritten: the importance of timely feedback is emphasized.

   Section 8 Feedback
     - minor corrections
     - the Generic ACK message format is included.

   Section 11 Example usages
     - Whole Section was rearranged:
       - Section 11.2: example of a more intelligent client using the
         ACK scheme is new. SDP description included
       - Section 11.3 Selective Payload Format example usage: re-
         written.
       - Section Sending Retransmissions on a Different Stream (was
         Section 10.3) removed: the two session approach example was
         removed from the draft.





























Miyazaki, et. al.       Expires December 2002                       3
                Multiple Selective RTP Retransmissions       June 2002



   Table of Contents

   1. Conventions used in this document..............................5
   2. Introduction to the problem....................................5
   3. Requirements for Retransmissions in RTP........................6
   4. Applicability Statement........................................8
   5. General Usage of the Payload Formats..........................10
      5.1 General Usage Rules.......................................10
      5.2 Header Usage and Encapsulation............................11
      5.3 Header Examples...........................................11
   6. Retransmission Payload Format.................................14
   7. Selective Payload Format......................................15
   8. Feedback......................................................17
   9. Congestion Control............................................18
   10. Relation to SDP..............................................19
      10.1 Indicating RTX Usage in SDP..............................19
      10.2 Indicating SEL Usage in SDP..............................20
      10.3 Indicating RTX and SEL Usage in SDP......................21
   11. Example Usages of the Payload Formats........................21
      11.1 A Simple Multiple Retransmission Algorithm...............22
      11.2 A Client-oriented Retransmission Algorithm...............24
      11.3 Selective Retransmission Algorithm.......................25
      11.4 Using Retransmissions in Layered Transmissions...........26
   Security Considerations..........................................28
   Acknowledgements.................................................28
   Intellectual property considerations.............................28
   References.......................................................28
   AuthorÆs Addresses...............................................29

























Miyazaki, et. al.       Expires December 2002                       4
                Multiple Selective RTP Retransmissions       June 2002



1. Conventions used in this document

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


2. Introduction to the problem

   The Real-time Transport Protocol RTP [3] was designed as an
   Internet protocol to transmit real-time (or near real-time) data
   over large multicast sessions. Even though the multicast capability
   is a strong feature of RTP, a common use of it is non-interactive
   unicast or small multicast transmission of media streams. These
   applications, further referred to as media streaming, have relaxed
   delay bounds. Thus, a constant offset delay, used to store received
   packets at the client, is tolerable and used for different purposes,
   such as delay jitter compensation.

   Typically RTP is run over the User Datagram Protocol (UDP). While
   the unreliable UDP performs good for reliable channels, the quality
   of the received media stream is bad, when transmitted over error-
   prone links. Especially compressed streams, such as MPEG video-data,
   are highly susceptible to packet loss, which will lead to a bad
   video quality at the clients. E.g. in a wireless environment with an
   unstable transmission quality (bit error rate (BER) about 10E-3 ..
   10E-6) a sufficient quality of video and voice transmitted by RTP
   cannot be achieved in most of the cases.

   The scenario for media streaming over an error-prone link
   might be the one in Figure 1. Media files are stored on a media
   server which is connected via an Internet link to a mobile network.
   A client using a mobile terminal is connected to the mobile network
   via a wireless link. Both, the Internet link and the wireless link
   are generally unreliable and subject to packet losses, either due to
   congestion or to bit errors.


   This scenario is depicted below.














Miyazaki, et. al.       Expires December 2002                       5
                Multiple Selective RTP Retransmissions       June 2002



     Media                   Mobile                  Mobile
     Server                  Network                Terminal
                                                    (Client)

                               ***                       |
     +----+                  **   **                  +--+
     |    |                 *       *                 |  |
     |    | -------------- *         *  ~ ~ ~ ~ ~ ~ ~ |  |
     +----+                 *       *                 +--+
                             **   **
               Internet        ***        Wireless
                 Link                       Link

                 Figure 1 : Scenario for media streaming


   To achieve a better quality of the received media stream, especially
   over error-prone links, retransmissions of lost packets of the
   stream is a possible solution.


3. Requirements for Retransmissions in RTP

   There are several issues that have to be considered for
   retransmissions in RTP. We describe in this section some of those,
   which lead to a set of requirements for the retransmission scheme.

   As the RTP sender SHOULD employ a congestion control algorithm if
   the session is transmitted over a best effort environment (see RTP
   [3]), the sending rate is typically limited. Packet losses might
   also decrease the allowed sending rate, if these are interpreted as
   congestion signal. What is more, in case of transmission over a
   mobile channel the bandwidth is a very scarce resource and has to be
   used with great care. Thus, RTP senders (especially when
   transmitting data over wireless channels) are often confronted with
   strictly limited available bit rates.
   Hence, it is in most cases not useful or even not allowed to send
   retransmissions of all lost packets additionally to the original
   stream (note however that there are scenarios of Quality of Service
   (QoS) controlled networks, where it can be possible to reserve
   enough bandwidth in advance to transmit retransmission of all lost
   packets in addition to the original stream).

   On the other hand, the media data is typically coded for compression
   before transmission. This reduction in redundancy leads to the
   streams being more susceptible to errors. Another property of some
   encoded media streams (e.g. video) is that they may consist of data
   of different importance. Some parts of the data might be absolutely
   vital for displaying the media, while other parts may only be
   required to enhance the quality of the displayed stream.
   A common mechanism to achieve different QoS for different parts of


Miyazaki, et. al.       Expires December 2002                       6
                Multiple Selective RTP Retransmissions       June 2002



   the data is to split the data in layers and transmit these layers in
   different RTP sessions, i.e. layered encoding and transmission. The
   layers are typically hierarchically ordered, which means that one
   layer (i.e. the base layer, 1st layer) is independently decodable;
   the next layer (2nd, i.e. the first enhancement layer) enhances the
   quality of the received stream, but depends on the base layer to be
   decoded; the next layer (3rd) depends on the first enhancement layer
   and so on. As the layers are transmitted in different sessions, the
   client can choose how many layers it would like to receive,
   according to available bandwidth or other criteria. Layered encoding
   and transmission is an accepted technique, especially for multicast
   transmissions, to achieve different QoS levels within one media
   stream or to perform congestion control in multicast.
   For such a scheme to be feasible with retransmissions in RTP, it
   should be possible to keep the service differentiation between the
   layers, i.e. to differentiate between retransmissions of different
   streams.

   Thus, when transmitting compressed media (e.g. MPEG video) over
   strictly limited bandwidth links (as described above), it has to be
   taken care that important data is retransmitted. Thereby, it might
   be possible to skip the transmission of non-important data, for the
   benefit of transmitting important data. With a strategy of this
   kind, the bandwidth requirements may be kept, while the quality of
   the received stream can be increased.

   For all these reasons, a retransmission scheme that enables the
   retransmission of all or selected packets and attempts to retransmit
   these packets one or several times without introducing avoidable
   delay is needed. Additionally, layered encoding has to be supported.

   We see already that there is the need for retransmission schemes
   with sophisticated functionalities. It might not be possible to
   design one scheme that fits all requirements in an optimum way.
   Therefore, we define in this document two new RTP payload formats.
   With these formats it is possible to design retransmission schemes
   (where the intelligence is at the server or at the client side) that
   fulfill the requirements written above. We will give examples of how
   to use the payload formats to enable different retransmission
   schemes at the end of this document.













Miyazaki, et. al.       Expires December 2002                       7
                Multiple Selective RTP Retransmissions       June 2002



4. Applicability Statement



   There are two proposals for adding retransmissions to RTP (this
   draft-ietf-avt-rtp-selret-05.txt and draft-ietf-avt-rtp-
   retransmission-01.txt). Both proposals may be optimum under a
   different set of constraints, as they solve different problems. This
   section describes the applicability of the "RTP Payload Formats to
   Enable Multiple Selective Retransmissions". Herewith, we present
   applications that benefit from these retransmission payload formats,
   i.e. RTX and SEL, and mention those for which it is not applicable.

   The main difference between both retransmission proposals is the way
   the retransmissions are sent, i.e. in the same RTP session for this
   proposal and in an additional session for the "RTP Retransmission
   Framework" proposal. We put our emphasis on the effects of this
   difference.

   Using the RTX payload format to send the retransmissions in the same
   RTP session as the original media data, it is always possible to
   reliably detect the loss of  RTP packets. As soon as the receiver
   detects a gap in the sequence number space it knows an RTP packet
   was lost. However, it is not immediately possible to detect the
   nature of the lost data, as it might be a retransmission or new user
   data. Using the payload format to multiplex the retransmissions with
   the RTP sequence number can result in gaps in the final sequence
   number space. More exactly: there will be one gap for each
   retransmission. While this is generally not a problem, the
   implementer should check carefully whether the application can cope
   with this. The authors are aware of the fact that the "RTP
   Conversational Text" (RFC2793) requires RTP to indicate lost data
   packets to the application. For this application the sequence number
   multiplexing should not be used.

   In the following, some implementation examples of this proposal are
   presented. The examples are described in detail in section 11 and
   are shortly mentioned here to help in understanding the
   applicability of the proposed payload formats.

   A simple retransmission mechanism that can run on thin clients can
   be built with the RTX payload format. It needs no additional timers.
   The client will detect lost RTP packets (transmissions or
   retransmissions) immediately by a gap in the received sequence
   numbers. After detecting lost RTP data the client can request a
   retransmission as soon as it is allowed to send an RTCP feedback
   message.
   For this simple solution, the server should take the final decision
   regarding retransmissions according to a judgment of the time after
   which packets become invalid at the client. Additional timers, e.g.
   for RTT estimation or for retransmissions, are therefore not



Miyazaki, et. al.       Expires December 2002                       8
                Multiple Selective RTP Retransmissions       June 2002



   required at the client. However, when using this simple scheme it is
   not possible to detect the loss of a retransmission request. A
   solution for this case is presented in the next paragraph.


   In some environments, feedback is limited due to back-channel
   constraints or by the application running over RTP, as per [4]. For
   such environments, it is important to limit the quantity of feedback
   messages and to schedule them appropriately so that they are still
   useful to the server. In order to meet these two requirements the
   SEL payload format, i.e. Selective Payload Format, is presented in
   this document in section 7. The SEL payload format enables the
   server to signal the priority of a packet in-band. The SEL payload
   format also enables the client to resolve the time stamp of lost
   high priority RTP packets, thus enabling the detection of lost
   retransmission requests for high priority packets. For details see
   section 7 of this document.

   Until now, the server was in charge of taking the final decision
   regarding retransmissions. For those environments in which the
   server load is an issue, a more client-oriented retransmission
   scheme can be built using the payload formats described in this
   draft. Thereby, this scheme requires slightly more intelligence at
   the client, but less complexity at the server: the client issues
   periodically (maybe additionally to the retransmission requests)
   cumulative acknowledgements. By doing this, the server is informed
   about the outdated packets, complexity is removed from the server
   and the scheme is made scalable. See section 11.2 for details.

   Retransmissions imply overhead. Every retransmission that is sent
   using this payload format includes at least two additional bytes
   overhead. A retransmission of a retransmission increases this
   overhead again by two bytes, e.g. the second retransmission of one
   packet will carry four bytes overhead. This is needed to enable the
   receiver to 1) resolve the RTP sequence number used for the
   transmission and possible retransmissions and to 2) simplify the
   encapsulation at the server.

   Retransmissions lead to a highly increased RTCP jitter calculation.
   As the retransmission usually is received highly out of order, the
   RTCP jitter will increase. While one could argue whether the jitter
   calculation is usable this way or not, the implementer should take
   this fact into consideration.

   If RTP mixers or translators wanted to separate the stream in
   original data and retransmissions they could do that according to
   the Payload Type field in the RTP header.






Miyazaki, et. al.       Expires December 2002                       9
                Multiple Selective RTP Retransmissions       June 2002



5. General Usage of the Payload Formats

   The payload formats presented in this document, i.e. the RTX
   retransmission payload format and the SEL selective retransmission
   payload format, are meant as a solution to enable retransmissions in
   RTP. Based on this scheme we present examples how the payload
   formats could be used to realize different retransmission schemes.
   Thereby, the focus may lay, for example, on optimizing bandwidth
   efficiency within the media stream (or on the back-channel), on
   reducing the server( or client) load or on the need for supporting
   layered encoding.

   The payload formats are not meant to replace a media RTP payload
   format, but to be used additionally. This means that an RTP packet
   using one or both of the formats defined below, can have several
   encapsulated headers, where the outer header always indicates the
   payload type of the next inner header (see examples at the end of
   this section).


5.1 General Usage Rules

   If the RTX payload format is used, e.g. a payload type number is
   dynamically assigned, all retransmissions SHOULD be sent using this
   RTX payload type. Thereby the header encapsulation scheme, which is
   described in section 5.2 SHOULD be used.

   The sender of RTP packets, using the payload formats specified in
   This document has different possibilities for transmitting RTP
   packets. The sender MAY use the Selective (SEL) payload format to
   signal the packet's priority and the sequence number of the last
   high priority packet in-band. This can be used at the receiver of
   the packets to detect if lost packets had high or low priority.
   Additionally, information on the time stamp of the lost packet might
   also be conveyed by the SEL payload format. This can help the
   receiver when judging whether or not a retransmission request should
   be issued or not and to detect the loss of a retransmission request.

   If the SEL payload format is specified for an RTP session, e.g. a
   payload type number is dynamically assigned, the client SHOULD
   report the loss of high priority packets in the first place. After
   that and, as long as RTCP feedback bandwidth allows, the client MAY
   additionally report the loss of low priority packets. Furthermore,
   the client MAY send a retransmission request for several packets,
   including low priority packets (using the BLP field of the generic
   NACK packet, see section 8), as long as there is, either at least
   one high priority packet lost or the client cannot judge if there
   might be a high priority packet lost within the lost packets.





Miyazaki, et. al.       Expires December 2002                      10
                Multiple Selective RTP Retransmissions       June 2002



5.2 Header Usage and Encapsulation

   For the encapsulation of retransmissions in the RTX packet the
   following rules apply:

   1. The sender of the retransmission SHOULD strip off the RTP header
      of the original RTP packet, that is to be retransmitted, but
      store the values of the header fields temporarily for use in
      this packet's header fields (see step 2 and 4). It is important
      to note that only the RTP header is stripped off, payload format
      specific headers are kept as they are. Hence, particularly RTX
      and SEL specific headers SHOULD NOT be stripped off, but SHOULD
      be transmitted together with the headers that are generated in
      the next steps.

   2. An RTX header is generated and placed before the packet. If the
      difference between the RTP sequence number used for this RTP
      packet and the sequence number used for the original transmission
      fits into 8-bits, then the 8-bit delta SN field MAY be used
      instead of the full sequence number. If it exceeds the 8 bits,
      the complete sequence number of the original RTP transmissions
      MUST be included in the header. Receivers MUST be able to handle
      either RTX format.

   3. A SEL header MAY be placed before the packet, if the sender
      wishes to signal the priority of the packet in-band.

   4. The RTP header is generated. Thereby the fields of the header
      are filled as usual, e.g. as described in the payload format
      that is used for the media to be transported. However, the RTP
      sequence number MUST be increased by one to the previous RTP
      packet and the timestamp and marker bit MUST be set to the
      values of the original transmission's RTP header.

5.3 Header Examples

   In the following, we give examples of RTP packets using the RTX
   and SEL payload format:

   1. Transmission of an RTP packet, using the SEL format to signal the
   priority of the packet in-band:












Miyazaki, et. al.       Expires December 2002                      11
                Multiple Selective RTP Retransmissions       June 2002



     +---------------------------------------------+
     |            RTP header with PT=SEL           |
     |                                             |
     +---------------------------------------------+
     |      SEL Payload Type specific header       |
     |              with PT=media_pt               |
     +---------------------------------------------+
     :     Media Payload Type specific header      :
     :                                             :
     +---------------------------------------------+
     |                                             |
     |               Media Payload                 |
     :                                             :
     :.........................  .  .  .  .  .  .  :

   2. Retransmission of an RTP packet, using the RTX format for the
   retransmission:

     +---------------------------------------------+
     |            RTP header with PT=RTX           |
     |                                             |
     +---------------------------------------------+
     |      RTX Payload Type specific header       |
     |              with PT=media_pt               |
     +---------------------------------------------+
     :     Media Payload Type specific header      :
     :                                             :
     +---------------------------------------------+
     |                                             |
     |               Media Payload                 |
     :                                             :
     :.........................  .  .  .  .  .  .  :


   3. Retransmission of an RTP packet, which was originally transmitted
   using the SEL format to signal the priority of the packet in-band.
   The RTX format for the retransmission is used as an additional
   header, as well as a new SEL header to signal the new priority of
   the packet:














Miyazaki, et. al.       Expires December 2002                      12
                Multiple Selective RTP Retransmissions       June 2002



     +---------------------------------------------+
     |            RTP header with PT=SEL           |
     |                                             |
     +---------------------------------------------+
     |      SEL Payload Type specific header       |
     |              with PT=RTX                    |
     +---------------------------------------------+
     |      RTX Payload Type specific header       |
     |              with PT=SEL                    |
     +---------------------------------------------+
     |      SEL Payload Type specific header       |
     |              with PT=media_pt               |
     +---------------------------------------------+
     :     Media Payload Type specific header      :
     :                                             :
     +---------------------------------------------+
     |                                             |
     |               Media Payload                 |
     :                                             :
     :.........................  .  .  .  .  .  .  :

   4. Retransmission of a retransmitted RTP packet, using the RTX
      format twice, conform to the rules given above:

     +---------------------------------------------+
     |            RTP header with PT=RTX           |
     |                                             |
     +---------------------------------------------+
     |      RTX Payload Type specific header       |
     |              with PT=RTX                    |
     +---------------------------------------------+
     |      RTX Payload Type specific header       |
     |              with PT=media_pt               |
     +---------------------------------------------+
     :     Media Payload Type specific header      :
     :                                             :
     +---------------------------------------------+
     |                                             |
     |               Media Payload                 |
     :                                             :
     :.........................  .  .  .  .  .  .  :

   The previous examples show that there might be quite some headers
   involved in sending a single RTP packet. There are some observations
   to be done on this; first, the header encapsulation is straight
   forward regarding server side implementation of retransmissions and
   buffering of transmitted packets. Second, the overhead because of
   the retransmission headers is quite small. Usually only one RTX
   header is used for retransmissions and thus the additional overhead
   is two or four bytes. Retransmitted retransmissions have two RTX
   headers, which sums up to 4 to 8 bytes of additional overhead.


Miyazaki, et. al.       Expires December 2002                      13
                Multiple Selective RTP Retransmissions       June 2002



   Multiple retransmissions can happen and enhance the performance, but
   still these are quite rare cases. Considering that RTP is designed
   for real-time or near-real-time services, several retransmission
   attempts will soon run out of time.


6. Retransmission Payload Format

   Retransmissions in RTP SHOULD be sent using RTX payload format.
   This enables the receiver to reconstruct exactly the original RTP
   header and all its containing information. Additionally, multiple
   retransmissions are enabled. The syntax of the payload type specific
   header is as follows:

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | X | PT of inner packet header |
    +---+---+---+---+---+---+---+---+
    |  (Delta) RTP Sequence Number  |
    +---+---+---+---+---+---+---+---+
    : original RTP Sequence Number  :  if X=1
    +...............................+

   Extended Sequence Number (X): 1 bit
     This bit indicates whether a Delta RTP Sequence Number is used or
     the complete original RTP sequence number. For X=0 the Delta RTP
     Sequence Number are transmitted, for X=1 the original RTP
     sequence number is inserted in the header.

   Payload Type of inner packet header: 7 bit
     This field contains the original payload type information, i.e.
     the payload type of the payload that is transported in this
     packet. This might be the payload type of the media itself or of
     another encapsulating payload type, e.g. the SEL payload type.

   (Delta) RTP Sequence Number: 8 bit
     The value of this field is dependent on the setting of the X-bit
     (see above). If the X-bit is set to zero, this field contains the
     difference of this packet's RTP sequence number to the RTP
     sequence number of the original transmission of this packet's
     payload, i.e. Delta SN = (SN(this) - SN(original)) mod 2^16. If
     the number of bits that are needed to encode the difference
     exceeds 8, X=1 MUST be set and the complete original RTP sequence
     number is transmitted in the following two bytes (in network byte
     order), i.e. covering this field and the following

   original RTP Sequence Number: 8 bit
     For X=1 this field is used together with the previous eight bits
     to carry the complete original RTP sequence number (see also
     "(Delta) RTP Sequence Number").



Miyazaki, et. al.       Expires December 2002                      14
                Multiple Selective RTP Retransmissions       June 2002



7. Selective Payload Format

   In certain scenarios it is necessary to either 1) limit the amount
   of feedback sent to the server or 2) be able to schedule feedback
   appropriately so that it can still be used to repair the stream or
   3) both.

   In such cases it is required to provide the client with means of
   deciding which packets are more important than others. The selective
   payload format (SEL) allows to indicate the priority of a packet in-
   band.

   The low priority packets are needed to detect the loss of high
   priority packets, as they contain the sequence number of the last
   important packet sent. If the receiver gets a low priority packet,
   it has only to check whether it has received the indicated last high
   priority packet or not. If a high priority packet is lost the
   receiver SHOULD report the loss of this packet. If packets of low
   priority are lost the receiver MAY report this.

   Additionally, the SEL payload type provides resilience against the
   feedback loss. The SEL payload format enables the client to detect
   the loss of retransmission requests of high priority packets. By
   using the timestamp information of lost high priority packets, which
   may be conveyed in the SEL header, the client is able to estimate if
   a retransmission request for these high priority packets would be
   useful. If it is, the client reports these losses via RTCP feedback.
   If after an estimated RTT afterwards the requested packets didnÆt
   arrive at the client, it may conclude that the retransmission
   request was lost and a new one should be issued. Hereby, an RTT
   estimation at the client would help in estimating when a
   retransmission should have arrived at the client.


   The syntax of the SEL header is as follows:

     0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+
     |DTI| PT of inner packet header |
     +---+---+---+---+---+---+---+---+
     |PRI| X |     (Delta) SN        |
     +---+---+---+---+---+---+---+---+
     :                               :
     +          complete SN          +  if X==1
     :                               :
     +...............................+
     :                               :
     +          Delta Time           +  if DTI==1
     :                               :
     +...............................+



Miyazaki, et. al.       Expires December 2002                      15
                Multiple Selective RTP Retransmissions       June 2002




   DTI (Delta Time Indicator): 1 bit
     DTI=1 indicates that the delta time field is present. DTI=0 means
     that the Delta Time field is not used.

   Payload Type of inner packet header: 7 bit
     This field contains the original payload type information, i.e.
     the payload type of the payload that is transported in this
     packet.

   PRI (Priority): 1 bit
     This field indicates the priority of the packet. PRI=1 means a
     high priority packet, where PRI=0 is sent for low priority
     packets.

   X (Extended RTP Sequence Number): 1 bit
     his field indicates whether a short "Delta SN" is used to
     indicate the last high priority packet (X=0) or the complete RTP
     sequence number of the last high priority packet is transmitted
     (X=1).

   Delta SN (Delta Sequence Number): 6 bit
     This field is only present in case of X=0, where it contains
     the offset in sequence number space to the previous important
     packet. It is calculated as DSN = SN_this - SN_important.
     If X=1 this field MUST be ignored.

   Complete SN (complete referenced RTP Sequence Number): 16 bit
     This field is present if X=1. In this case it contains the
     complete RTP sequence number of the last high priority packet.

   Delta Time: 16 bit
     This field indicates the difference between the time stamp of the
     last important RTP packet (that should be retransmitted if lost)
     and that of the current RTP packet. It can be used by the
     receiver to compute the timestamp of a lost important packet.
     The default unit of this field is [ms] and by default the
     following table is used to encode the Delta Time values:















Miyazaki, et. al.       Expires December 2002                      16
                Multiple Selective RTP Retransmissions       June 2002



          Delta Time [ms]  |    bits
          -----------------+--------------------
          more than 32766  | 0111 1111 1111 1111
                    32766  | 0111 1111 1111 1110
                    32765  | 0111 1111 1111 1101
                      :    |         :
                      2    | 0000 0000 0000 0010
                      1    | 0000 0000 0000 0001
                      0    | 0000 0000 0000 0000
                     -1    | 1111 1111 1111 1111
                     -2    | 1111 1111 1111 1110
                      :    |         :
                   -32766  | 1000 0000 0000 0010
                   -32767  | 1000 0000 0000 0001
         less than -32767  | 1000 0000 0000 0000

     It is possible to define other units or coding tables, however,
     how to specify and negotiate this is outside the scope of this
     document.


8. Feedback

   Feedback is an important part of any retransmission scheme. To be
   efficient, also under near real-time conditions, it might be needed
   to receive this feedback with the lowest delay that is possible. The
   basic RTP sets constraints about feedback timing rules, which might
   not be suitable for a retransmission scheme under real-time or near
   real-time conditions.

   To enable low delay feedback a new extended RTP profile for RTCP-
   based feedback was defined, i.e. RTP/AVPF [4]. This profile
   redefines RTCP feedback timing rules according to the group size of
   the multicast session. In unicast sessions it is possible to send
   feedback virtually immediately. In the RTP/AVPF profile [4], two
   major changes are introduced: 1) the 5 second rule from RTP [3] is
   not enforced anymore and 2) the application MAY introduce an
   application-defined minimum interval between Receiver Reports. See
   [4] for details.
   In [4] RTCP feedback messages are defined, which are suited for
   retransmission requests and acknowledgements. Generally, a simple
   feedback message, called Generic NACK is suitable to be used as a
   retransmission request. Similarly, a Generic ACK is suitable to
   acknowledge packets, whereas a range of packets or, selectively, a
   subset from it.

   The packet format for a Generic NACK Feedback message is defined in
   [4] as follows:





Miyazaki, et. al.       Expires December 2002                      17
                Multiple Selective RTP Retransmissions       June 2002



   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|0| FMT=1 |    PT=RTPFB   |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PID                |             BLP               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PID is used to indicate a lost packet for which the retrans-
   mission is requested and the BLP might be used to indicate several
   lost packets in one NACK message.

   The Generic ACK Feedback Message would look like this:

   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|0| FMT=2 |    PT=RTPFB   |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PID                |R|       BLP/#packets          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hereby, the PID is used to acknowledge reception of a packet and R
   to switch the meaning of the field BLP/#packets to indicate either
   selective acknowledgement (R=0) or acknowledgement of a range of
   packets (R=1). If R=0 the ACK carries a bit mask (BLP) acknowledging
   a number of packets (#packets) following the one indicated by PID.
   If R=1 the this message acknowledges a range of packets. A detailed
   description of this and other low delay feedback messages can be
   found in [4].


9. Congestion Control

   In general, retransmission schemes contradict congestion control. If
   packets are lost, which is generally accepted to be an indication of
   congestion, the sender increases the network load by sending
   additional retransmissions. While this behavior cannot be accepted
   in a best effort environments such as the Internet, it is reasonable
   in quality of service (QoS) controlled networks, e.g. by reserving a
   certain bit rate for the RTP session. However the used bit rate MUST
   be monitored to control that the maximum rate is by no means
   exceeded.


Miyazaki, et. al.       Expires December 2002                      18
                Multiple Selective RTP Retransmissions       June 2002




   Therefore, even though retransmission algorithms normally contradict
   congestion control, they could enhance the quality of service, in
   environments where losses occur not only due to congestion but also
   (or mainly) due to bit errors on the link. Taking this information
   into account the following rule MUST be followed, if the
   retransmissions are used in a best effort environment (e.g. the
   Internet).

   At reception of a retransmission request or detecting packet loss by
   other means, the sender MUST NOT increase the sending bit rate on
   mid-term timescales. Retransmissions MAY be sent within the current
   bit rate, e.g. by skipping or delaying the transmission of other
   scheduled packets.

   The rules for congestion control of RTP [3] and RTP/AVPF [4] MUST be
   followed, where applies.


10. Relation to SDP


   The payload formats, described in this document can be indicated
   using SDP. This section specifies the usage of SDP in relation to
   the RTX and SEL payload format.


10.1 Indicating RTX Usage in SDP

   RTX packets are retransmissions of RTP packets. The original RTP
   packets get a payload type value assigned, dynamically or
   statically. There is no static payload type assignment for RTX, so
   dynamic payload type numbers MUST be used. The binding to the number
   is indicated by an "rtpmap" attribute. The name used in this binding
   is "rtx". The payload type number is indicated in the "m" line of
   the media as an (additional) payload type.

   We define an OPTIONAL payload format-specific parameter in SDP for
   use with "a=fmtp", namely "rtx-time". "rtx-time" is used to indicate
   the maximum time a server will try to retransmit a lost packet. This
   is indicated by <rtx-time-value>.

   The syntax is as follows:

    a=fmtp:<number> rtx-time=<rtx-time-val>

   where,

     <number> indicates the assigned payload type number (indicated in
     the "m" line) to the 'rtx' payload format.



Miyazaki, et. al.       Expires December 2002                      19
                Multiple Selective RTP Retransmissions       June 2002



     <rtx-time-val> indicates the time in [ms], measured from the first
     sending of a packet until when the server will not try to
     retransmit the packet again. This is a maximum time, the client
     can decrease this (e.g. because of limited memory resources), by
     not sending retransmission requests earlier.

   The "rtx-time" parameter MAY be used only with the retransmission
   payload format "rtx" specified in this document.

   No fmtp attribute line present for a retransmission stream means
   that the maximum retransmission time is not defined, but MAY be
   negotiated by other means.

   A sample indication of the RTX payload format in SDP is as follows:

   m = video 8000 RTP/AVPF 98 99
   a = rtpmap:98 MP4V-ES/90000
   a = rtpmap:99 rtx/90000


   An additional line


   a = fmtp:99 rtx-time=3500

   will indicate that the server will try to retransmit packets only
   3.5 seconds, after which it will not try again.


10.2 Indicating SEL Usage in SDP

   SEL packets are RTP packets with an additional SEL specific header,
   which enables a priority detection (also of lost packets). It is
   expected that the SEL packets are typically sent either instead of
   all other media packets, or in combination with other media packets.
   E.g. all media packets might be encapsulated in SEL packets, or only
   one importance level is encapsulated, where the other packets are
   sent with their original payload type.

   There is no static payload type assignment for SEL, so dynamic
   payload type numbers MUST be used. The binding to the number is
   indicated by an rtpmap attribute. The name used in this binding is
   "sel". The payload type number is indicated in the "m" line of the
   media as an additional payload type to the original one.

   The priority indicating packets, using the SEL payload type, are
   sent to the same transport address and port as the media stream is
   sent or would have been sent.

   A sample indication of SEL in SDP is as follows:



Miyazaki, et. al.       Expires December 2002                      20
                Multiple Selective RTP Retransmissions       June 2002



   m = video 8000 RTP/AVPF 98 99
   a = rtpmap:98 sel/90000
   a = rtpmap:99 MP4V-ES/90000


10.3 Indicating RTX and SEL Usage in SDP

   Both payload formats, SEL and RTX, MAY be used together. The
   following is an example of how to indicate the usage of both
   formats:

   m = video 8000 RTP/AVPF 98 99 100
   c = IN IP4 192.129.35.13
   a = rtpmap:98 sel/90000
   a = rtpmap:99 MP4V-ES/90000
   a = rtpmap:100 rtx/90000

   An additional line


   a = fmtp:100 rtx-time=3500

   will indicate that the server will try to retransmit packets only
   3.5 seconds, after which it will not try again.


11. Example Usages of the Payload Formats

   In section 3 we investigated the requirements for a retransmission
   scheme to be used for RTP. We saw that different applications and
   environments have different requirements on a retransmission scheme,
   which are not necessarily compatible. Thus, there is a need for
   different retransmission schemes, depending on the environment and
   application that it should be used for.

   In this section we show four examples how the two payload formats,
   RTX and SEL, can be used to build efficient retransmission schemes.
   Note that it is not necessarily needed that client and server have
   negotiated the same retransmission scheme. The rules of how to use
   the payload formats, see section 5 for details, describe the general
   behavior that the client (server) can expect from the server
   (client). However certain algorithms and behaviors of clients or
   servers may enhance the retransmission scheme or make it efficient
   in certain environments. These kind of schemes are described below,
   where no standardized coordinated behavior of client and server is
   needed, but both enhance the functionality rather independently from
   each other.

   First, we consider a quite simple retransmission algorithm suitable
   for the most common applications and environments. With this
   algorithm it is possible to retransmit lost RTP packets, detect the


Miyazaki, et. al.       Expires December 2002                      21
                Multiple Selective RTP Retransmissions       June 2002



   loss of retransmissions efficiently and retransmit lost packets
   several times, if needed.

   A second example gives a sample implementation of a more intelligent
   client. In this case the client sends, in addition to the Generic
   NACK messages, periodic Generic ACK messages. This enables the
   client to influence the retransmission decisions. Also some workload
   is shifted from server to the client, which makes the scheme
   scalable.

   The third example uses the SEL payload format additionally to
   signal the need for a retransmission request from the server to the
   client in-band. This leads to the client being able to judge the
   priority of lost packets and selectively request retransmissions.
   Thus, bandwidth on the feedback channel can be saved. The server, in
   turn, is aware of which packets should be given priority when
   retransmitting, thus enhancing the transmission quality.

   The fourth example shows how retransmissions can be performed for a
   layered encoded stream. Different layers are sent in different RTP
   sessions and retransmissions in this case are done per RTP session.
   In this fashion, the retransmissions fit well into the layered
   principle of the coding.


11.1 A Simple Multiple Retransmission Algorithm

   This section gives an examples how the RTX payload format is used to
   enable multiple retransmissions in RTP. It is assumed that Generic
   NACK feedback messages are used. A sample indication in SDP could
   be:

   m = video 8000 RTP/AVPF 98 99
   a = rtpmap:98 MP4V-ES/90000
   a = rtpmap:99 rtx/90000
   a = fmtp:99 rtcp-fb nack

   An additional line

   a = fmtp:99 rtx-time=3500

   would indicate also that the server will try to retransmit packets
   for 3.5 seconds, after which the packets are deleted from the
   retransmission buffer and should never be sent again.

   The sender transmits the media data in normal RTP packets using an
   RTP payload format for that media (e.g. MPEG-4 as described in [5])
   If packets get lost the receiver will detect that by the gap in the
   sequence number. To signal lost packets the NACK message, described
   in section 8 is used. The PID field is used to specify a lost
   packet. The default method, which is to use the RTP sequence number


Miyazaki, et. al.       Expires December 2002                      22
                Multiple Selective RTP Retransmissions       June 2002



   to indicate the lost packet, is used. The BLP field can be used to
   indicate several lost packets in one NACK message. The detailed
   semantics is described in [4].

   At receiving a retransmission request the sender decides, according
   to the priority of the packet, the network conditions (see
   section 8) and maybe other factors, if the packet is to be
   retransmitted. The maximum transmission time (e.g. 3.5 seconds as
   indicated with the fmtp attribute above) SHOULD be taken into
   account if it was signaled, because the client MAY size its playout
   buffer accordingly. Other negotiations, which are not in the scope
   of this document, MAY define a different value for a maximum
   retransmission time. In this case the negotiated value SHOULD be
   used. In case of a positive decision, the server uses the RTX
   payload format (see section 6) to retransmit the packet. The
   sequence number of the RTP packet is increased by one over the
   previous packet sent. This enables the receiver to detect also a
   lost retransmission.


   Example of a retransmission packet:

    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|X| CC=0  |    PT=RTX     |      RTP sequence number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       RTP timestamp = timestamp of original transmission      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of media source                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| PT=media_pt |0|   DSN=12    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   :                                                               :
   :                         Media Payload                         :
   :                                                               :
   :.........................  .  .  .  .  .  . .  .  .  . .  .  . :


   Note that the client is able to detect the loss of a retransmission
   by a gap in the sequence number. For the client this looks just like
   another lost packet, and thus a retransmission request will be sent.
   If the server, after receiving the request, decided that the packet
   is still to be retransmitted another time, an additional RTX header
   is placed in the header. The client, after receiving the packet, can
   then detect to which retransmission request(s) the packet belongs.







Miyazaki, et. al.       Expires December 2002                      23
                Multiple Selective RTP Retransmissions       June 2002




11.2 A Client-oriented Retransmission Algorithm

   In the simple retransmission scheme described in the previous
   section  the server judges every requested packet for retransmission
   before actually sending it. In the case of a large number of clients
   the processing load at the server might become considerable. This
   can be avoided by adding a little more intelligence to the client.

   A simplified server would retransmit every requested packet without
   performing any judgment. By doing this and if retransmissions of a
   packet are lost several times, it might well happen that the packet
   becomes too old to be used by the client. However, the server keeps
   on sending it, unaware of the situation.

   Thus, it is necessary to eliminate those packets that have been
   requested for retransmission but would not arrive on time. For this
   purpose, an intelligent client MAY make additional use of periodic
   Generic ACK feedback messages. These Generic ACKs, as per [4], would
   acknowledge cumulatively the last outdated packets and selectively
   acknowledge those packets following it. These Generic ACKs MAY also
   contain pseudo-ACKs, that is, bits in the BLP field that acknowledge
   packets which didn't arrive at the client but the client estimates
   to be outdated or doesn't wish to receive anymore. In a simple case
   the client might judge a packet as outdated when the display time is
   older than the current time. A more complex judgment might involve
   an RTT estimation at the client.

   A sample indication in SDP would be:

    m = video 8000 RTP/AVPF 98 99
    a = rtpmap:98 MP4V-ES/90000
    a = rtpmap:99 rtx/90000
    a = rtcp-fb:99 nack
    a = rtcp-fb:99 ack

   We have seen that the retransmission judgment is not performed at
   the server anymore; the functionality of the server is reduced to
   resolving which packets are not to be sent anymore as indicated by
   the Generic ACK messages. This reduces processing load at the server
   and increases scalability.

   Furthermore, this scheme allows the client to dynamically adjust its
   buffer space available dynamically in-band, without having to
   previously communicate this to the server by other means, e.g. SDP.
   If the client decides to increase (decrease) the buffer space, it
   might do this by just incrementing (decrementing) the spacing
   between ACK messages. A client might dynamically decide to increase
   its buffer space if, for example, the packet loss rate or/and other
   factors, prevent it from receiving an acceptable quality.



Miyazaki, et. al.       Expires December 2002                      24
                Multiple Selective RTP Retransmissions       June 2002




11.3 Selective Retransmission Algorithm

   A special case, where the above described multiple
   retransmission algorithm does not work well, is if the feedback
   channel has a very limited capacity. Possible scenarios are 1) small
   multicast groups, where according to the defined timing rules for
   RTCP it is seldom possible to send immediate feedback, 2) scenarios
   where the feedback channel is mainly used for other purposes, e.g.
   wireless control channel and 3) asymmetric channels, where the
   feedback channel is smaller than the forward channel, e.g. satellite
   links.
   In this kind of scenarios it is very important to limit the
   feedback to the very minimum, which could mean that feedback is only
   sent in form of retransmission requests for really important data
   and the feedback on other less important packets is sent as long as
   the thereÆs remaining feedback bandwidth.
   Another scenario is that of a client having several applications
   running on the same terminal, e.g. streaming and down-/uploads. To
   manage the different applications, the client may decide to limit
   the bandwidth reserved for each application. If the application in
   particular runs over RTP with extended feedback capabilities (as per
   [4]) the application might set an application-defined maximum RTCP
   feedback bandwidth. This application-defined maximum RTCP feedback
   bandwidth should ensure the correct working of the application under
   the most common network conditions. Nevertheless, this maximum
   bandwidth may be surpassed with on-demand feedback messages (always
   remaining under the RTCP bandwidth share, as defined in RTP [3]).
   On-demand feedback can be sent to report the loss of those packets
   considered to be important and which need immediate feedback. By
   doing this, bandwidth on the feedback channel is saved in a way that
   ensures the correct functioning of all applications and the loss of
   important packets is reported as soon as allowed by the timing rules
   defined in RTP/AVPF [4]. Please refer to [4] for details.

   We have seen that to solve the above described requirements on the
   retransmission scheme, it is necessary that the receiver knows the
   priority of the lost packets to decide if a retransmission request
   should be sent or not and also, when. In this case, the selective
   packet format is used.

   Hence, in scenarios as described above, where feedback can be sent
   only very infrequently and/or when the feedback timeliness is
   critical, a solution which uses the selective payload format might
   be the only possible solution at all.

   The mechanism signaled in SDP, assuming 3.5 seconds buffering delay
   and NACK-based feedback, is as follows:





Miyazaki, et. al.       Expires December 2002                      25
                Multiple Selective RTP Retransmissions       June 2002




    m = video 8000 RTP/AVPF 98 99 100
    a = rtpmap:98 sel/90000
    a = rtpmap:99 MP4V-ES/90000
    a = rtpmap:100 rtx/90000
    a = fmtp:100 rtcp-fb nack
    a = fmtp:100 rtx-time=3500

   The sender may send all (or a part of the) media data in RTP packets
   using the SEL payload type plus additionally the media payload type.
   The priority field is set according to the packet's priority. In all
   SEL packets the Delta SN field is used to signal the delta to the
   sequence number of the previous high priority packet. The receiver
   can use this information to check if the last high priority packet
   was received correctly or not. If this packet was not received or he
   cannot reliable detect the priority of lost packets (if many packets
   were lost in a row), a retransmission request is sent. If the
   receiver detects that low priority packets were lost it can
   additionally report this fact as long as the RTCP feedback bandwidth
   allows.

   The receiver can also reconstruct the timestamp of the lost packet
   if the sender used the Delta Time field. Using this time information
   it is possible to calculate the time after which the packet cannot
   be used any more (display time). In this case the receiver may
   maintain a round trip time (RTT) measurement and compare the
   calculated display time with the estimated time when the
   retransmission could arrive. If the retransmission would arrive
   already outdated, a retransmission request should not be sent.
   At receiving a retransmission request from the receiver, the server
   may make the same decision as described in the previous section,
   i.e. it judges according to the packets priority (which is most
   probably quite high, because a retransmission request for it was
   sent), network status etc. if the packet should be retransmitted. If
   so, it uses the retransmission packet type, to enable multiple
   retransmissions as described in the previous section. The SEL
   payload type is additionally used to enable the priority detection
   at the client.

   If after an estimated time the requested high priority packet has
   not arrived at the receiver, the receiver may conclude that the
   retransmission request was lost and issue a new one, if the timing
   allows.


11.4 Using Retransmissions in Layered Transmissions

   As described above in section 3, layered encoding and transmission
   is a well accepted mechanism to perform rate control, especially in
   multicast. In this section we will show a sample mechanism how the
   retransmission framework interacts with layered transmissions. Note


Miyazaki, et. al.       Expires December 2002                      26
                Multiple Selective RTP Retransmissions       June 2002



   that retransmissions in multicast is still an open research topic.
   We do not intend to solve this and/or specify a retransmission
   scheme for multicast. However, we specify how the retransmission
   framework can support a layered retransmission scheme syntactically.
   The loss detection and decisions when to retransmit a packet to
   which receiver group is clearly outside the scope of this document.

   As packets of different priorities or importance are sent in
   different RTP streams, the retransmissions should be sent in the
   corresponding layer. The rationale for this is that the
   retransmission will probably have the same or even greater
   importance over time.

   An SDP indication would be:

    m = video 8000 RTP/AVPF 98 99
    a = rtpmap:98 MP4V-ES/90000
    a = rtpmap:99 rtx/90000
    a = fmtp:99 rtcp-fb nack
    a = fmtp:99 rtx-time=3500
    c = IN IP4 224.2.1.1/127/3

   for multicast or

    m = video 8000/3 RTP/AVPF 98 99
    a = rtpmap:98 MP4V-ES/90000
    a = rtpmap:99 rtx/90000
    a = fmtp:99 rtcp-fb nack
    a = fmtp:99 rtx-time=3500

   for unicast.

   In both cases NACK-based feedback and 3.5 seconds buffering delay is
   assumed.

   Thus, three addresses/ports are allocated, each transmitting the
   original data of the corresponding layer. After a loss detection the
   receiver(s) signal the lost packet to the server. If the simple
   retransmission scheme is used, the server has to make a
   retransmission decision, which can be based, beside the arguments
   given in the previous examples, on the layer, where the
   packet was lost. In case of a positive retransmission decision, the
   server uses the RTX payload format to retransmit the packet on its
   corresponding layer and within the corresponding sequence number
   space. With this it is immediately possible for the receivers to
   detect a lost retransmission.







Miyazaki, et. al.       Expires December 2002                      27
                Multiple Selective RTP Retransmissions       June 2002



Security Considerations

   RTP packets transporting information with the proposed payload
   formats are subject to the security considerations discussed in RTP
   specification [3], in the RTP/AVPF profile specification [4] and in
   the RTP/AVP profile specification [6].
   This profile does not specify any additional security services.


Acknowledgements

   For the work on this retransmission framework, we received a lot of
   help and advice from the AVT working group and the chairs, Colin
   Perkins and Stephen Casner. Especially the mechanism of sending
   retransmissions with a new sequence number in the same sequence
   number space, using a different payload type was initiated by Colin
   Perkins.

   Furthermore, we would like to thank Norihito Takatori, Seiji Okumura
   and Tsugihiko Ohno from the Mitsubishi Electric Corporation, in
   Kanagawa (Japan) for the constant support during the generation of
   this document.


Intellectual property considerations

   Matsushita has filed patent applications that might possibly have
   technical relation to this contribution.
   If part(s) of the contribution by Matsushita employee is (are)
   included in a standard and Matsushita has patents and/or patent
   application(s) that are essential to implementation of such included
   part(s) in said standard, Matsushita is prepared to grant - on the
   basis of reciprocity (grantback) - a license on such included
   part(s) on reasonable, non-discriminatory terms and conditions (in
   according with paragraph 10.3.3 of the RFC 2026).


References

   1  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.

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

   3  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
      A Transport Protocol for real-time applications", RFC 1889,
      January 1996.

   4  Ott,J. et al., "Extended RTP Profile for RTCP-based Feedback",
      IETF Internet Draft, draft-ietf-avt-rtcp-feedback-03,


Miyazaki, et. al.       Expires December 2002                      28
                Multiple Selective RTP Retransmissions       June 2002



      work in progress, June 2002.

   5  Kikuchi, et al., "RTP Payload Format for MPEG-4 Audio/Visual
      Streams", RFC 3016, November 2000.


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


AuthorÆs Addresses

   Akihiro Miyazaki
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   Mail  akihiro@isl.mei.co.jp

   Hideaki Fukushima
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   Mail  fukusima@isl.mei.co.jp

   Koichi Hata
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   Mail  hata@isl.mei.co.jp

   Thomas Wiebke
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Mail  wiebke@panasonic.de

   Rolf Hakenberg
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Mail  hakenberg@panasonic.de

   Carsten Burmeister
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Mail  burmeister@panasonic.de











Miyazaki, et. al.       Expires December 2002                      29