draft-ietf-avt-info-repair-02.txt   draft-ietf-avt-info-repair-03.txt 
Colin Perkins Colin Perkins
Orion Hodson Orion Hodson
University College London University College London
Options for Repair of Streaming Media Options for Repair of Streaming Media
draft-ietf-avt-info-repair-02 draft-ietf-avt-info-repair-03
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and 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 may be updated, replaced, or obsoleted by other documents at any time. It
skipping to change at line 40 skipping to change at line 40
This document summarizes a range of possible techniques This document summarizes a range of possible techniques
for the repair of continuous media streams subject to packet for the repair of continuous media streams subject to packet
loss. The techniques discussed include redundant transmission, loss. The techniques discussed include redundant transmission,
retransmission, interleaving and forward error correction. retransmission, interleaving and forward error correction.
The range of applicability of these techniques is noted, The range of applicability of these techniques is noted,
together with the protocol requirements and dependencies. together with the protocol requirements and dependencies.
1 Introduction 1 Introduction
A number of applications have emerged which use RTP/UDP transport to A number of applications have emerged which use RTP/UDP transport
deliver continuous media streams. Due to the unreliable nature of UDP to deliver continuous media streams. Due to the unreliable nature
packet delivery, the quality of the received stream will be adversely of UDP packet delivery, the quality of the received stream will be
affected by packet loss. A number of techniques exist by which the effects adversely affected by packet loss. A number of techniques exist
of packet loss may be repaired. These techniques by which the effects of packet loss may be repaired. These techniques
have a wide range of applicability and require varying degrees of have a wide range of applicability and require varying degrees of
protocol support. In this document, a number of such techniques protocol support. In this document, a number of such techniques
are discussed, and recommendations for their applicability made. 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].
2 Terminology and Protocol Framework 2 Terminology and Protocol Framework
A unit is defined to be a timed interval of media data, typically derived A unit is defined to be a timed interval of media data, typically
from the workings of the media coder. A packet comprises one or more derived from the workings of the media coder. A packet comprises
units, encapsulated for transmission over the network. For example, many one or more units, encapsulated for transmission over the network.
audio coders operate on 20ms units, which are typically combined to produce For example, many audio coders operate on 20ms units, which are typically
40ms or 80ms packets for transmission. 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 framework of RTP [15] is assumed. This implies that packets have a The use of RTP allows for several different media coders, with a
sequence number and timestamp. The sequence number denotes the order in payload type field being used to distinguish between these at the
which packets are transmitted, and is used to detect losses. The timestamp receiver. Some loss repair schemes send multiple copies of units,
is used to determine the playout order of units. Most loss recovery at different times and possibly with different encodings, to increase
schemes rely on units being sent out of order, so an application must use the probability that a receiver has something to decode. A receiver
the RTP timestamp to schedule playout. 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.
The use of RTP allows for several different media coders, with a payload A session is defined as interactive if the end-to-end delay is less
type field being used to distinguish between these at the receiver. Some then 250ms, including media coding and decoding, network transit and
loss recovery schemes send some units multiple times, using different host buffering.
encoding schemes. 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.
3 Network Loss Characteristics 3 Network Loss Characteristics
If it is desired to repair a media stream subject to packet loss, it is If it is desired to repair a media stream subject to packet loss,
useful to have some knowledge of the loss characteristics which are likely it is useful to have some knowledge of the loss characteristics which
to be encountered. A number of studies have been conducted on the loss are likely to be encountered. A number of studies have been conducted
characteristics of the Mbone [8,9] and although the results vary somewhat, on the loss characteristics of the Mbone [2, 8,21] and although the
the broad conclusion is clear: in a large conference it is inevitable that results vary somewhat, the broad conclusion is clear: in a large
some receivers will experience packet loss. Packet traces taken by Handley conference it is inevitable that some receivers will experience packet
[5] 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 loss. Packet traces taken by Handley [8] show a session in which
packets. Burst losses of two or more packets are around an order of most receivers experience loss in the range 2-5%, with a somewhat
magnitude less frequent than single packet loss, although they do occur smaller number seeing significantly higher loss rates. Other studies
more often than would be expected from a purely random process. Longer have presented broadly similar results.
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
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 overloaded, and large cases, a network link is found to be severely overloaded, and large
amount of loss results. amount of loss results.
The primary focus of a packet loss repair scheme must, therefore, be to The primary focus of a repair scheme must, therefore, be to correct
correct single packet loss, since this is by far the most frequent single packet loss, since this is by far the most frequent occurrence.
occurrence. It is desirable that losses of a relatively small number of It is desirable that losses of a relatively small number of consecutive
consecutive packets may also be repaired, since such losses represent a packets may also be repaired, since such losses represent a small
small but noticeable fraction of observed losses. The correction of large but noticeable fraction of observed losses. The correction of large
bursts of loss is of considerably less importance. bursts of loss is of considerably less importance.
4 Loss Mitigation Schemes 4 Loss Mitigation Schemes
In the following sections, four loss mitigation schemes are discussed. In the following sections, four loss mitigation schemes are discussed.
These schemes have been discussed in the literature a number of times, and These schemes have been discussed in the literature a number of times,
found to be of use in a number of scenarios. Each technique is briefly and found to be of use in a number of scenarios. Each technique
described, and its advantages and disadvantages noted. is briefly described, and its advantages and disadvantages noted.
4.1 Forward Error Correction 4.1 Retransmission
Forward error correction (FEC) is the means by which repair data is added Retransmission of lost packets is an obvious means by which loss
to a media stream, such that packet loss can be repaired by the receiver of may be repaired. It is clearly of value in non-interactive applications,
that stream with no further reference to the sender. There are two classes with relaxed delay bounds, but the delay imposed means that it does
of repair data which may be added to a stream: those which are independent not typically perform well for interactive use.
of the contents of the stream, and those which use knowledge of the stream
to improve the repair process.
4.1.1 Media-Independent FEC In addition to the possibly high latency, there is a potentially
large bandwidth overhead to the use of retransmission. Not only
are units of data sent multiple times, but additional control traffic
must flow to request the retransmission. It has been shown that,
in a large Mbone session, most packets are lost by at least one receiver
[8]. In this case the overhead of requesting retransmission for
most packets may be such that the use of forward error correction
is more acceptable. This leads to a natural synergy between the
two mechanisms, with a forward error correction scheme being used
to repair all single packet losses, and those receivers experiencing
burst losses, and willing to accept the additional latency, using
A number of media-independent FEC schemes have been proposed for use with retransmission based repair as an additional recovery mechanism. Similar
streamed media. These techniques add redundant data to a media stream mechanisms have been used in a number of reliable multicast schemes,
which is transmitted in separate packets. Traditionally, FEC techniques and have received some discussion in the literature [9, 13].
are described as loss detecting and/or loss correcting. In the case of
streamed media loss detection is provided by the sequence numbers in RTP
packets.
The redundant FEC data is typically calculated using the mathematics of In order to reduce the overhead of retransmission, the retransmitted
finite fields [1]. The simplest of finite field is GF(2) where addition is units may be piggy-backed onto the ongoing transmission, using a
just the eXclusive-OR operation. payload format such as that described in [15]. This also allows
for the retransmission to be recoded in a different format, to further
reduce the bandwidth overhead. As an alternative, FEC information
may be sent in response to retransmission requests [13], allowing
a single retransmission to potentially repair several losses.
The choice of a retransmission request algorithm which is both timely
and network friendly is an area of current study. An obvious starting
point is the SRM protocol [7], and experiments have been conducted
using this, and with a low-delay variant, STORM [20]. This work
shows the trade-off between latency and quality for retransmission
based repair schemes, and illustrates that retransmission is an effective
approach to repair for applications which can tolerate the latency.
Basic FEC schemes transmit k data packets with n-k parity packets allowing There is no standard protocol framework for requesting retransmission
the reconstruction of the original data from any k of the n transmitted of streaming media. An experimental RTP profile extension for SRM-style
packets. Budge et al [3] proposed applying the XOR operation across retransmission requests has described in [14].
different combinations of the media data with the redundant data
transmitted separately as parity packets. These vary the pattern of
packets over which the parity is calculated, and hence have different
bandwidth, latency and loss repair characteristics.
Luby et al [8] have discussed applying parity in layers. The first layer 4.2 Forward Error Correction
in their scheme is the parity bits generated from the media. The second
layer is calculated as the parity bits of the first layer and so on. This
obviously improves the repair properties, but consumes additional
bandwidth.
Parity-based FEC based techniques have a significant advantage in that they Forward error correction (FEC) is the means by which repair data
are media independent, and provide exact repair for lost packets. In is added to a media stream, such that packet loss can be repaired
addition, the processing requirements are relatively light, especially when by the receiver of that stream with no further reference to the sender.
compared with some redundancy schemes which use very low bandwidth, but There are two classes of repair data which may be added to a stream:
high complexity encodings. The disadvantage of parity-based FEC is that those which are independent of the contents of the stream, and those
the codings have higher latency in comparison with the media-specific which use knowledge of the stream to improve the repair process.
schemes discussed in following section. An RTP payload format for
parity-based FEC is defined in [14]. The format is generic, and can 4.2.1 Media-Independent FEC
specify many different parity encodings.
A number of media-independent FEC schemes have been proposed for
use with streamed media. These techniques add redundant data, which
is transmitted in separate packets, to a media stream. Traditionally,
FEC techniques are described as loss detecting and/or loss correcting.
In the case of streamed media, loss detection is provided by the
sequence numbers in RTP packets.
The redundant FEC data is typically calculated using the mathematics
of finite fields [1]. The simplest of finite field is GF(2) where
addition is just the eXclusive-OR operation.
Basic FEC schemes transmit k data packets with n-k parity packets
allowing the reconstruction of the original data from any k of the
n transmitted packets. Budge et al [4] proposed applying the XOR
operation across different combinations of the media data with the
redundant data transmitted separately as parity packets. These vary
the pattern of packets over which the parity is calculated, and hence
have different bandwidth, latency and loss repair characteristics.
Parity-based FEC based techniques have a significant advantage in
that they are media independent, and provide exact repair for lost
packets. In addition, the processing requirements are relatively
light, especially when compared with some media-specific FEC (redundancy)
schemes which use very low bandwidth, but high complexity encodings.
The disadvantage of parity based FEC is that the codings have higher
latency in comparison with the media-specific schemes discussed in
following section.
A number of FEC schemes exist which are based on higher-order finite A number of FEC schemes exist which are based on higher-order finite
fields. An example of such are Reed-Solomon (RS) codes which are more fields, for example Reed-Solomon (RS) codes, which are more sophisticated
sophisticated and computationally demanding. These are usually structured and computationally demanding. These are usually structured so that they
so that they have good burst loss protection. There has been much work have good burst loss protection, although this typically comes at the
conducted in this area, and it is believed that a number of streaming expense of increased latency. Dependent on the observed loss patterns,
applications use RS codes. such codes may give improved performance, compared to parity-based FEC.
4.1.2 Media-Specific FEC An RTP payload format for generic FEC, suitable for both parity based
and Reed-Solomon encoded FEC is defined in [17].
4.2.2 Media-Specific FEC
The basis of media-specific FEC is to employ knowledge of a media The basis of media-specific FEC is to employ knowledge of a media
compression scheme to achieve more efficient repair of a stream than can compression scheme to achieve more efficient repair of a stream than
otherwise be achieved. To repair a stream subject to packet loss, it is can otherwise be achieved. To repair a stream subject to packet
necessary to add redundancy to that stream: some information is added loss, it is necessary to add redundancy to that stream: some information
which is not required in the absence of packet loss, but which can be used is added which is not required in the absence of packet loss, but
to recover from that loss. which can be used to recover from that loss.
The nature of a media stream affects the means by which the redundancy is The nature of a media stream affects the means by which the redundancy
added. If units of media data are packets, or if multiple units are is added. If units of media data are packets, or if multiple units
included in a packet, it is logical to use the unit as the level of are included in a packet, it is logical to use the unit as the level
redundancy, and to send duplicate units. By recoding the redundant copy of of redundancy, and to send duplicate units. By recoding the redundant
a unit, significant bandwidth savings may be made, at the expense of copy of a unit, significant bandwidth savings may be made, at the
additional computational complexity and approximate repair. This approach expense of additional computational complexity and approximate repair.
has been advocated for use with streaming audio [5,6] and has been shown to This approach has been advocated for use with streaming audio [2,
perform well. An RTP payload format for this form of redundancy has been 10] and has been shown to perform well. An RTP payload format for
defined [12]. this form of redundancy has been defined [15].
If media units span multiple packets, for instance video, it is sensible to If media units span multiple packets, for instance video, it is sensible
include redundancy directly within the output of a codec. For example the to include redundancy directly within the output of a codec. For
proposed RTP payload for H.263+ [2] includes multiple copies of key example the proposed RTP payload for H.263+ [3] includes multiple
portions of the stream, separated to avoid the problems of packet loss. copies of key portions of the stream, separated to avoid the problems
The advantages of this second approach is efficiency: the codec designer of packet loss. The advantages of this second approach is efficiency:
knows exactly which portions of the stream are the codec designer knows exactly which portions of the stream are
most important to protect, and low complexity since each unit is coded once most important to protect, and low complexity since each unit is
only. coded once only.
An alternative approach is to apply media-independent FEC techniques to the An alternative approach is to apply media-independent FEC techniques to the
most significant bits of a codecs output, rather than applying it over the most significant bits of a codecs output, rather than applying it over the
entire packet. Several codec descriptions include bit sensitivities that entire packet. Several codec descriptions include bit sensitivities that
make this feasible. This approach has low computational cost and can be make this feasible. This approach has low computational cost and can be
tailored to represent an arbitrary fraction of the transmitted data. tailored to represent an arbitrary fraction of the transmitted data.
The use of media-specific FEC has the advantage of low-latency, with only a The use of media-specific FEC has the advantage of low-latency, with only a
single-packet delay being added. This makes it suitable for interactive single-packet delay being added. This makes it suitable for interactive
applications, where large end-to-end delays cannot be tolerated. In a applications, where large end-to-end delays cannot be tolerated. In a
uni-directional non-interactive environment it is possible to delay sending uni-directional non-interactive environment it is possible to delay sending
the redundant data, achieving improved performance in the presence of burst the redundant data, achieving improved performance in the presence of burst
losses [7], at the expense of additional latency. losses [11], at the expense of additional latency.
4.2 Retransmission
Retransmission of lost packets is an obvious means by which loss may be
repaired. It is clearly of value in non-interactive applications, with
relaxed delay bounds, but the delay imposed means that it does not
typically perform well for interactive use.
In addition to the possibly high latency, there is a potentially large
bandwidth overhead to the use of retransmission. Not only are units of
data sent multiple times, but additional control traffic must flow to
request the retransmission. It has been shown that, in a large Mbone
session, most packets are lost by at least one receiver [5]. In this case
the overhead of requesting retransmission for most packets may be such that
the use of forward error correction is more acceptable. This leads to a
natural synergy between the two mechanisms, with a forward error correction
scheme being used to repair all single packet losses, and those receivers
experiencing burst losses, and willing to accept the additional latency,
using retransmission based repair as an additional recovery mechanism.
Similar mechanisms have been used in a number of reliable multicast
schemes, and have received some discussion in the literature [10, 6].
In order to reduce the overhead of retransmission, the retransmitted units
may be piggy-backed onto the ongoing transmission. This also allows for
the retransmission to be recoded in a different format, to further reduce
the bandwidth overhead.
The choice of a retransmission request algorithm which is both timely
and network friendly is an area of current study. An obvious starting
point is the SRM protocol [4], and experiments have been conducted
using this, and with a low-delay variant, STORM [17]. This work
shows the trade-off between latency and quality for retransmission
based repair schemes, and illustrates that retransmission is an effective
approach to repair for applications which can tolerate the latency.
An RTP profile extension for SRM-style retransmission requests is
described in [11].
4.3 Interleaving 4.3 Interleaving
When the unit size is smaller than the packet size, and end-to-end delay is When the unit size is smaller than the packet size, and end-to-end delay is
unimportant, interleaving [13] is a useful technique for reducing the unimportant, interleaving [16] is a useful technique for reducing the
effects of loss. Units are resequenced before transmission, so that effects of loss. Units are resequenced before transmission, so that
originally adjacent units are separated by a guaranteed distance in the originally adjacent units are separated by a guaranteed distance in the
transmitted stream, and returned to their original order at the receiver. transmitted stream, and returned to their original order at the receiver.
Interleaving disperses the effect of packet losses. If, for example, units Interleaving disperses the effect of packet losses. If, for example, units
are 5ms in length and packets 20ms (ie: 4 units per packet), then the are 5ms in length and packets 20ms (ie: 4 units per packet), then the
first packet could contain units 1, 5, 9, 13; the second packet would first packet could contain units 1, 5, 9, 13; the second packet would
contain units 2, 6, 10, 14; and so on. It can be seen that the loss of a contain units 2, 6, 10, 14; and so on. It can be seen that the loss of a
single packet from an interleaved stream results in multiple small gaps in single packet from an interleaved stream results in multiple small gaps in
the reconstructed stream, as opposed to the single large gap which would the reconstructed stream, as opposed to the single large gap which would
occur in a non-interleaved stream. In many cases it is easier to occur in a non-interleaved stream. In many cases it is easier to
reconstruct a stream with such loss patterns, although this is clearly reconstruct a stream with such loss patterns, although this is clearly
media and codec dependent. The obvious disadvantage of interleaving is media and codec dependent. Note that the size of the gaps is dependent on
that it increases latency. This limits the use of this technique for the degree of interleaving used, and can be made arbitrarily small at the
interactive applications, although it performs well for non-interactive expense of additional latency.
use. The major advantage of interleaving is that it does not increase the
bandwidth requirements of a stream. The obvious disadvantage of interleaving is that it increases latency.
This limits the use of this technique for interactive applications,
although it performs well for non-interactive use. The major advantage
of interleaving is that it does not increase the bandwidth requirements
of a stream.
A potential RTP payload format for interleaved data is a simple extension A potential RTP payload format for interleaved data is a simple extension
of the redundant audio payload [12]. That payload requires that the of the redundant audio payload [15]. That payload requires that
redundant copy of a unit is sent after the primary. If this restriction is the redundant copy of a unit is sent after the primary. If this
removed, it is possible to transmit an arbitrary interleaving of units with restriction is removed, it is possible to transmit an arbitrary interleaving
this payload format. of units with this payload format.
5 Recommendations 5 Recommendations
If the desired scenario is a non-interactive uni-directional transmission, If the desired scenario is a non-interactive uni-directional transmission,
in the style of a radio or television broadcast for example, latency is of in the style of a radio or television broadcast, latency is of considerably
considerably less importance than reception quality. In this case, the use less importance than reception quality. In this case, the use of
of interleaving and/or retransmission based repair is appropriate, with interleaving, retransmission based repair or FEC is appropriate. If
interleaving being preferred due to its bandwidth efficiency (provided that approximate repair is acceptable, interleaving is clearly to be preferred,
approximate repair is acceptable). since it does not increase the bandwidth of a stream. Media independent
FEC is typically the next best option, since a single FEC packet
In an interactive session (typically defined as a session where the has the potential to repair multiple lost packets, providing efficient
end-to-end delay is less then 250ms, this includes media coding/decoding, transmission.
network transit and host buffering), the delay imposed by the use of
interleaving and retransmission is not acceptable, and a low-latency
FEC scheme is the only means of repair suitable. The choice between In an interactive session, the delay imposed by the use of interleaving
media independent and media specific forward error correction is less and retransmission is not acceptable, and a low-latency FEC scheme
clear-cut: media-specific FEC can be made more efficient, but requires is the only means of repair suitable. The choice between media independent
modification to the output of the codec. When defining the packetisation and media specific forward error correction is less clear-cut: media-specific
for a new codec, this is clearly an appropriate technique, and should FEC can be made more efficient, but requires modification to the
be encouraged. output of the codec. When defining the packet format for a new codec,
this is clearly an appropriate technique, and should be encouraged.
If an existing codec is to be used, a media independent forward error If an existing codec is to be used, a media independent forward error
correction scheme is usually easier to implement, and can perform correction scheme is usually easier to implement, and can perform
well. A media stream protected in this way may be augmented with well. A media stream protected in this way may be augmented with
retransmission based repair with minimal overhead, providing improved retransmission based repair with minimal overhead, providing improved
quality for those receivers willing to tolerate additional delay. quality for those receivers willing to tolerate additional delay,
Whilst the addition of error correction data to an media stream is and allowing interactivity for those receivers which desire it.
an effective means by which that stream may be protected against Whilst the addition of FEC data to an media stream is an effective
packet loss, application designers should be aware that the addition means by which that stream may be protected against packet loss,
of large amounts of repair data will increase network congestion, application designers should be aware that the addition of large
and hence packet loss, leading to a worsening of the problem which amounts of repair data when loss is detected will increase network
the use of error correction coding was intended to solve. congestion, and hence packet loss, leading to a worsening of the
problem which the use of error correction coding was intended to
solve.
At the time of writing, there is no standard solution to the problem At the time of writing, there is no standard solution to the problem
of congestion control for streamed media which can be used to solve of congestion control for streamed media which can be used to solve
this problem. There have, however, been a number of contributions this problem. There have, however, been a number of contributions
which show the likely form the solution will take [9, 16]. This which show the likely form the solution will take [12, 19]. This
work typically used some form of layered encoding of data over multiple work typically used some form of layered encoding of data over multiple
channels, with receivers joining and leaving layers in response to channels, with receivers joining and leaving layers in response to
packet-loss (which indicates congestion). The aim of such schemes packet-loss (which indicates congestion). The aim of such schemes
is to emulate the congestion control behaviour of a TCP stream, and is to emulate the congestion control behavior of a TCP stream, and
hence compete fairly with non-real-time traffic. This is necessary hence compete fairly with non-real time traffic. This is necessary
for stable network behaviour in the presence of much streamed media. for stable network behavior in the presence of much streamed media.
6 Acknowledgements Since streaming media applications are in use now, without congestion
control, it is important to give some advice to authors of those
tools as to the behavior which is acceptable, until congestion control
mechanisms can be deployed. The remainder of this section uses the
The authors wish to thank Phil Karn for his helpful comments. throughput of a TCP connection over a link with a given loss rate
as an example to indicate behavior which may be classified as reasonable.
7 Author's Address As a number of authors have noted (eg: [6]), the loss rate and throughput
of a TCP connection are approximately related as follows:
T = (s * c) / (RTT * sqrt(p))
where T is the observed throughput in octets per second, s is the
packet size in octets, RTT is the round-trip time for the session
in seconds, p is the packet loss rate and c is a constant in the
range 0.9...1.5 (a value of 1.22 has been suggested [6]). Using
this relation, one may determine the packet loss rate which would
result in a given throughput for a particular session, if a TCP connection
was used.
Whilst this relation between packet loss rate and throughput is specific
to the TCP congestion control algorithm, it also provides an estimate
of the acceptable loss rate for a streaming media application using
the same network path, which wishes to coexist fairly with TCP traffic.
Clearly this is not sufficient for fair sharing of a link with TCP
traffic, since it does not capture the dynamic behavior of the connection,
merely the average behavior, but it does provide one definition of
``reasonable'' behavior in the absence of real congestion control.
For example, an RTP audio session with DVI encoding and 40ms data
packets will have 40 bytes RTP/UDP/IP header, 4 bytes codec state
and 160 bytes of media data, giving a packet size, s, of 204 bytes.
It will send 25 packets per second, giving T = 4800. It is possible
to estimate the round-trip time from RTCP reception report statistics
(say 200 milliseconds for the purpose of example). Substituting these
values into the above equation, we estimate a ``reasonable'' packet
loss rate, p, of 6.7%. This would represent an upper bound on the
packet loss rate which this application should be designed to tolerate.
It should be noted that a round trip time estimate based on RTCP
reception report statistics is, at best, approximate; and that a
round trip time for a multicast group can only be an `average' measure.
This implies that the TCP equivalent throughput/loss rate determined
by this relation will be an approximation of the upper bound to the
rate a TCP connection would actually achieve.
6 Security Considerations
Some of the repair techniques discussed in this document result in
the transmission of additional traffic to correct for the effects
of packet loss. Application designers should be aware that the transmission
of large amounts of repair traffic will increase network congestion,
and hence packet loss, leading to a worsening of the problem which
the use of error correction was intended to solve. At its worst,
this can lead to excessive network congestion and may constitute
a denial of service attack. Section 5 discusses this in more detail,
and provides guidelines for prevention of this problem.
7 Summary
Streaming media applications using the Internet will be subject to
packet loss due to the unreliable nature of UDP packet delivery.
This document has summarized the typical loss patterns seen on the
public Mbone at the time of writing, and a range of techniques for
recovery from such losses. We have further discussed the need for
congestion control, and provided some guidelines as to reasonable
behavior for streaming applications in the interim until congestion
control can be deployed.
8 Acknowledgments
The authors wish to thank Phil Karn and Lorenzo Vicisano for their
helpful comments.
9 Authors' Address
Colin Perkins/Orion Hodson Colin Perkins/Orion Hodson
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
United Kingdom United Kingdom
Email: <c.perkins|o.hodson>@cs.ucl.ac.uk Email: <c.perkins|o.hodson>@cs.ucl.ac.uk
References References
[1] R.E. Blahut. Theory and Practice of Error Control Codes. [1] R.E. Blahut. Theory and Practice of Error Control Codes.
Addison Wesley, 1983. Addison Wesley, 1983.
[2] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, [2] J.-C. Bolot and A. Vega-Garcia. The case for FEC based
error control for packet audio in the Internet. To appear
in ACM Multimedia Systems.
[3] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,
D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload
format for the 1998 version of ITU-T rec. H.263 video format for the 1998 version of ITU-T reccomendation H.263
(H.263+). IETF Audio/Video Transport Working Group, video (H.263+). IETF Audio/Video Transport Working Group,
November 1997. Work in progress. November 1997. Work in progress.
[3] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long. [4] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long.
Media-independent error correction using RTP, May 1997. Media-independent error correction using RTP, May 1997.
Work in progress. Work in progress.
[4] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and [5] G. Carle and E. W. Biersack. Survey of error recovery
L. Zhang. A reliable multicast framework for light-weight techniques for IP-based audio-visual multicast applications.
sessions and applications level framing. IEEE/ACM IEEE Network, 11(6):24--36, November/December 1997.
Transactions on Networking, 1995.
[5] M. Handley. An examination of Mbone performance. USC/ISI [6] S. Floyd and K. Fall. Promoting the use of end-to-end
congestion control in the internet. Submitted to IEEE/ACM
Transactions on Networking, February 1998.
[7] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang.
A reliable multicast framework for light-weight sessions and
applications level framing. IEEE/ACM Transactions on Networking,
1995.
[8] M. Handley. An examination of Mbone performance. USC/ISI
Research Report: ISI/RR-97-450, April 1997. Research Report: ISI/RR-97-450, April 1997.
[6] M. Handley and J. Crowcroft. Network text editor (NTE): A [9] M. Handley and J. Crowcroft. Network text editor (NTE): A
scalable shared text editor for the Mbone. In Proceedings scalable shared text editor for the Mbone. In Proceedings
ACM SIGCOMM'97, Cannes, France, September 1997. ACM SIGCOMM'97, Cannes, France, September 1997.
[7] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft. [10] V. Hardman, M. A. Sasse, M. Handley, and A. Watson.
Redundancy control in real-time Internet audio Reliable audio for use over the Internet. In Proceedings
conferencing. In Proceedings of AVSPN'97, Aberdeen, of INET'95, 1995.
Scotland, September 1997.
[8] G.M. Luby, M. Mitzenmacher, M. Amin Shokrollahi, D.A. [11] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft.
Spielman, and V. Stemann. Practical loss-resilent codes. Redundancy control in real-time Internet audio conferencing.
In Twenty-Nineth Annual ACM Symposium on theTheory of In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.
Computing, 1997.
[9] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven [12] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven
layered multicast. In Proceedings ACM SIGCOMM'96, Stanford, layered multicast. In Proceedings ACM SIGCOMM'96, Stanford,
CA., August 1996. CA., August 1996.
[10] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based [13] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based
loss recovery for reliable multicast transmission. In loss recovery for reliable multicast transmission. In
Proceedings ACM SIGCOMM'97, Cannes, France, September 1997. Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[11] P. Parnes. RTP extension for scalable reliable multicast, [14] P. Parnes. RTP extension for scalable reliable multicast,
November 1996. Work in progress. November 1996. Work in progress.
[12] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman, [15] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley,
M. Handley, J.-C. Bolot, A. Vega-Garcia, and J.-C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis. RTP Payload
S. Fosse-Parisis. RTP Payload for redundant audio data. for redundant audio data. IETF Audio/Video Transport Working
IETF Audio/Video Transport Working Group, 1997. RFC2198. Group, 1997. RFC2198.
[13] J.L. Ramsey. Realization of optimum interleavers. IEEE [16] J.L. Ramsey. Realization of optimum interleavers. IEEE Transactions
Transactions on Information Theory, IT-16:338--345, May on Information Theory, IT-16:338--345, May 1970.
1970.
[14] J. Rosenberg and H. Schulzrinne. An A/V profile extension [17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for
for generic forward error correction in RTP. IETF generic forward error correction in RTP. IETF Audio/Video
Audio/Video Transport working group, July 1997. Work in Transport working group, July 1997. Work in progress.
progress.
[15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. [18] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson.
RTP: A transport protocol for real-time applications. IETF RTP: A transport protocol for real-time applications. IETF
Audio/Video Transport Working Group, January 1996. RFC1889. Audio/Video Transport Working Group, January 1996. RFC1889.
[16] L. Vicisano, L. Rizzo, and Crowcroft J. TCP-like congestion [19] L. Vicisano, L. Rizzo, and Crowcroft J. TCP-like congestion
control for layered multicast data transfer. In Proceedings control for layered multicast data transfer. In Proceedings
IEEE INFOCOM'98, 1998. IEEE INFOCOM'98, 1998.
[17] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar. [20] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar.
Resilient multicast support for continuous media Resilient multicast support for continuous media applications.
applications. In Proceedings of the 7th International In Proceedingsof the 7th International Workshop on Network and
Workshop on Network and Operating SystemsSupport for Operating Systems Support for Digital Audio and Video
Digital Audio and Video (NOSSDAV'97), Washington University (NOSSDAV'97), Washington University in St. Louis, Missouri,
in St. Louis, Missouri, May 1997. May 1997.
[21] M. Yajnik, J. Kurose, and D. Towsley. Packet loss correlation
in the Mbone multicast network. In Proceedings IEEE Global
Internet Conference, November 1996.
 End of changes. 54 change blocks. 
226 lines changed or deleted 325 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/