Options for Repair of Streaming Media
RFC 2354

Document Type RFC - Informational (June 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2354 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Perkins
Request for Comments: 2354                                     O. Hodson
Category: Informational                        University College London
                                                               June 1998

                 Options for Repair of Streaming Media

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

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

Abstract

   This document summarizes a range of possible techniques for the
   repair of continuous media streams subject to packet loss.  The
   techniques discussed include redundant transmission, retransmission,
   interleaving and forward error correction.  The range of
   applicability of these techniques is noted, together with the
   protocol requirements and dependencies.

1  Introduction

   A number of applications have emerged which use RTP/UDP transport to
   deliver continuous media streams.  Due to the unreliable nature of
   UDP packet delivery, the quality of the received stream will be
   adversely affected by packet loss.  A number of techniques exist by
   which the effects of packet loss may be repaired.  These techniques
   have a wide range of applicability and require varying degrees of
   protocol support.  In this document, a number of such techniques are
   discussed, and recommendations for their applicability made.

   It should be noted that this document is introductory in nature, and
   does not attempt to be comprehensive.  In particular, we restrict our
   discussion to repair techniques which require the involvement of the
   sender of a media stream, and do not discuss possibilities for
   receiver based repair.

   For a more detailed survey, the reader is referred to [5].

Perkins & Hodson             Informational                      [Page 1]
RFC 2354         Options for Repair of Streaming Media         June 1998

2  Terminology and Protocol Framework

   A unit is defined to be a timed interval of media data, typically
   derived from the workings of the media coder.  A packet comprises one
   or more units, encapsulated for transmission over the network.  For
   example, many audio coders operate on 20ms units, which are typically
   combined to produce 40ms or 80ms packets for transmission.  The
   framework of RTP [18] is assumed.  This implies that packets have a
   sequence number and timestamp.  The sequence number denotes the order
   in which packets are transmitted, and is used to detect losses.  The
   timestamp is used to determine the playout order of units.  Most loss
   recovery schemes rely on units being sent out of order, so an
   application must use the RTP timestamp to schedule playout.

   The use of RTP allows for several different media coders, with a
   payload type field being used to distinguish between these at the
   receiver.  Some loss repair schemes send multiple copies of units, at
   different times and possibly with different encodings, to increase
   the probability that a receiver has something to decode.  A receiver
   is assumed to have a `quality' ranking of the differing encodings,
   and so is capable of choosing the `best' unit for playout, given
   multiple options.

   A session is defined as interactive if the end-to-end delay is less
   then 250ms, including media coding and decoding, network transit and
   host buffering.

3  Network Loss Characteristics

   If it is desired to repair a media stream subject to packet loss, it
   is useful to have some knowledge of the loss characteristics which
   are likely to be encountered.  A number of studies have been
   conducted on the loss characteristics of the Mbone [2, 8, 21] and
   although the results vary somewhat, the broad conclusion is clear:
   in a large conference it is inevitable that some receivers will
   experience packet loss.  Packet traces taken by Handley [8] show a
   session in which most receivers experience loss in the range 2-5%,
   with a somewhat smaller number seeing significantly higher loss
   rates.  Other studies have presented broadly similar results.

   It has also been shown that the vast majority of losses are of single
   packets.  Burst losses of two or more packets are around an order of
   magnitude less frequent than single packet loss, although they do
   occur more often than would be expected from a purely random process.
   Longer burst losses (of the order of tens of packets) occur
   infrequently.  These results are consistent with a network where
   small amounts of transient congestion cause the majority of packet
   loss.  In a few cases, a network link is found to be severely

Perkins & Hodson             Informational                      [Page 2]
RFC 2354         Options for Repair of Streaming Media         June 1998
Show full document text