Guidelines for Writers of RTP Payload Format Specifications
RFC 2736

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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.