rfc2736.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            M. Handley
Request for Comments: 2736                                            ACIRI
BCP: 36                                                          C. Perkins
Category: Best Current Practice                                         UCL
                                                              December 1999


      Guidelines for Writers of RTP Payload Format Specifications

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document provides general guidelines aimed at assisting the
   authors of RTP Payload Format specifications in deciding on good
   formats.  These guidelines attempt to capture some of the experience
   gained with RTP as it evolved during its development.

1.  Introduction

   This document provides general guidelines aimed at assisting the
   authors of RTP [9] Payload Format specifications in deciding on good
   formats.  These guidelines attempt to capture some of the experience
   gained with RTP as it evolved during its development.

   The principles outlined in this document are applicable to almost all
   data types, but are framed in examples of audio and video codecs for
   clarity.

2.  Background

   RTP was designed around the concept of Application Level Framing
   (ALF), first described by Clark and Tennenhouse [2]. The key argument
   underlying ALF is that there are many different ways an application
   might be able to cope with misordered or lost packets.  These range
   from ignoring the loss, to re-sending the missing data (either from a
   buffer or by regenerating it), and to sending new data which
   supersedes the missing data.  The application only has this choice if
   the transport protocol is dealing with data in "Application Data
   Units" (ADUs). An ADU contains data that can be processed out-of-



Handley & Perkins        Best Current Practice                  [Page 1]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   order with respect to other ADUs.  Thus the ADU is the minimum unit
   of error recovery.

   The key property of a transport protocol for ADUs is that each ADU
   contains sufficient information to be processed by the receiver
   immediately.  An example is a video stream, wherein the compressed
   video data in an ADU must be capable of being decompressed regardless
   of whether previous ADUs have been received.  Additionally the ADU
   must contain "header" information detailing its position in the video
   image and the frame from which it came.

   Although an ADU need not be a packet, there are many applications for
   which a packet is a natural ADU.  Such ALF applications have the
   great advantage that all packets that are received can be processed
   by the application immediately.

   RTP was designed around an ALF philosophy.  In the context of a
   stream of RTP data, an RTP packet header provides sufficient
   information to be able to identify and decode the packet irrespective
   of whether it was received in order, or whether preceding packets
   have been lost. However, these arguments only hold good if the RTP
   payload formats are also designed using an ALF philosophy.

   Note that this also implies smart, network aware, end-points. An
   application using RTP should be aware of the limitations of the
   underlying network, and should adapt its transmission to match those
   limitations.  Our experience is that a smart end-point implementation
   can achieve significantly better performance on real IP-based
   networks than a naive implementation.

3.  Channel Characteristics

   We identify the following channel characteristics that influence the
   best-effort transport of RTP over UDP/IP in the Internet:

   o  Packets may be lost

   o  Packets may be duplicated

   o  Packets may be reordered in transit

   o  Packets will be fragmented if they exceed the MTU of the
      underlying network

   The loss characteristics of a link may vary widely over short time
   intervals.





Handley & Perkins        Best Current Practice                  [Page 2]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   Although fragmentation is not a disastrous phenomenon if it is a rare
   occurrence, relying on IP fragmentation is a bad design strategy as
   it significantly increases the effective loss rate of a network and
   decreases goodput.  This is because if one fragment is lost, the
   remaining fragments (which have used up bottleneck bandwidth) will
   then need to be discarded by the receiver.  It also puts additional
   load on the routers performing fragmentation and on the end-systems
   re-assembling the fragments.

   In addition, it is noted that the transit time between two hosts on
   the Internet will not be constant.  This is due to two effects -
   jitter caused by being queued behind cross-traffic, and routing
   changes.  The former is possible to characterise and compensate for
   by using a playout buffer, but the latter is impossible to predict
   and difficult to accommodate gracefully.

4.  Guidelines

   We identify the following requirements of RTP payload format
   specifications:

   +  A payload format should be devised so that the stream being
      transported is still useful even in the presence of a moderate
      amount of packet loss.

   +  Ideally all the contents of every packet should be possible to be
      decoded and played out irrespective of whether preceding packets
      have been lost or arrive late.

   The first of these requirements is based on the nature of the
   Internet.  Although it may be possible to engineer parts of the
   Internet to produce low loss rates through careful provisioning or
   the use of non-best-effort services, as a rule payload formats should
   not be designed for these special purpose environments.  Payload
   formats should be designed to be used in the public Internet with
   best effort service, and thus should expect to see moderate loss
   rates.  For example, a 5% loss rate is not uncommon.  We note that
   TCP steady state models [3][4][6] indicate that a 5% loss rate with a
   1KByte packet size and 200ms round-trip time will result in TCP
   achieving a throughput of around 180Kbit/s.  Higher loss rates,
   smaller packet sizes, or a larger RTT are required to constrain TCP
   to lower data rates.  For the most part, it is such TCP traffic that
   is producing the background loss that many RTP flows must co-exist
   with.  Without explicit congestion notification (ECN) [8], loss must
   be considered an intrinsic property of best-effort parts of the
   Internet.





Handley & Perkins        Best Current Practice                  [Page 3]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   When payload formats do not assume packet loss will occur, they
   should state this explicitly up front, and they will be considered
   special purpose payload formats, unsuitable for use on the public
   Internet without special support from the network infrastructure.

   The second of these requirements is more explicit about how RTP
   should cope with loss.  If an RTP payload format is properly
   designed, every packet that is actually received should be useful.
   Typically this implies the following guidelines are adhered to:

   +  Packet boundaries should coincide with codec frame boundaries.
      Thus a packet should normally consist of one or more complete
      codec frames.

   +  A codec's minimum unit of data should never be packetised so that
      it crosses a packet boundary unless it is larger than the MTU.

   +  If a codec's frame size is larger than the MTU, the payload format
      must not rely on IP fragmentation.  Instead it must define its own
      fragmentation mechanism.  Such mechanisms may involve codec-
      specific information that allows decoding of fragments.
      Alternatively they might allow codec-independent packet-level
      forward error correction [5] to be applied that cannot be used
      with IP-level fragmentation.

   In the abstract, a codec frame (i.e., the ADU or the minimum size
   unit that has semantic meaning when handed to the codec) can be of
   arbitrary size.  For PCM audio, it is one byte.  For GSM audio, a
   frame corresponds to 20ms of audio.  For H.261 video, it is a Group
   of Blocks (GOB), or one twelfth of a CIF video frame.

   For PCM, it does not matter how audio is packetised, as the ADU size
   is one byte.  For GSM audio, arbitrary packetisation would split a
   20ms frame over two packets, which would mean that if one packet were
   lost, partial frames in packets before and after the loss are
   meaningless.  This means that not only were the bits in the missing
   packet lost, but also that additional bits in neighboring packets
   that used bottleneck bandwidth were effectively also lost because the
   receiver must throw them away.  Instead, we would packetise GSM by
   including several complete GSM frames in a packet; typically four GSM
   frames are included in current implementations.  Thus every packet
   received can be decoded because even in the presence of loss, no
   incomplete frames are received.

   The H.261 specification allows GOBs to be up to 3KBytes long,
   although most of the time they are smaller than this.  It might be
   thought that we should insert a group of blocks into a packet when it
   fits, and arbitrarily split the GOB over two or more packets when a



Handley & Perkins        Best Current Practice                  [Page 4]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   GOB is large.  In the first version of the H.261 payload format, this
   is what was done.  However, this still means that there are
   circumstances where H.261 packets arrive at the receiver and must be
   discarded because other packets were lost - a loss multiplier effect
   that we wish to avoid.  In fact there are smaller units than GOBs in
   the H.261 bit-stream called macroblocks, but they are not
   identifiable without parsing from the start of the GOB.  However, if
   we provide a little additional information at the start of each
   packet, we can reinstate information that would normally be found by
   parsing from the start of the GOB, and we can packetise H.261 by
   splitting the data stream on macroblock boundaries.  This is a less
   obvious packetisation for H.261 than the GOB packetisation, but it
   does mean that a slightly smarter depacketiser at the receiver can
   reconstruct a valid H.261 bitstream from a stream of RTP packets that
   has experienced loss, and not have to discard any of the data that
   arrived.

   An additional guideline concerns codecs that require the decoder
   state machine to keep step with the encoder state machine.  Many
   audio codecs such as LPC or GSM are of this form.  Typically they are
   loss tolerant, in that after a loss, the predictor coefficients
   decay, so that after a certain amount of time, the predictor error
   induced by the loss will disappear.  Most codecs designed for
   telephony services are of this form because they were designed to
   cope with bit errors without the decoder predictor state permanently
   remaining incorrect.  Just packetising these formats so that packets
   consist of integer multiples of codec frames may not be optimal, as
   although the packet received immediately after a packet loss can be
   decoded, the start of the audio stream produced will be incorrect
   (and hence distort the signal) because the decoder predictor is now
   out of step with the encoder.  In principle, all of the decoder's
   internal state could be added using a header attached to the start of
   every packet, but for lower bit-rate encodings, this state is so
   substantial that the bit rate is no longer low.  However, a
   compromise can usually be found, where a greatly reduced form of
   decoder state is sent in every packet, which does not recreate the
   encoders predictor precisely, but does reduce the magnitude and
   duration of the distortion produced when the previous packet is lost.
   Such compressed state is, by definition, very dependent on the codec
   in question.  Thus we recommend:

   +  Payload formats for encodings where the decoder contains internal
      data-driven state that attempts to track encoder state should
      normally consider including a small additional header that conveys
      the most critical elements of this state to reduce distortion
      after packet loss.





Handley & Perkins        Best Current Practice                  [Page 5]