draft-ietf-avt-info-repair-00.txt   draft-ietf-avt-info-repair-01.txt 
Colin Perkins Colin Perkins
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-00 draft-ietf-avt-info-repair-01.txt
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working documents
documents of the Internet Engineering Task Force (IETF), its areas, of the Internet Engineering Task Force (IETF), its areas, and its working
and its working groups. Note that other groups may also distribute groups. Note that other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months and
and may be updated, replaced, or obsoleted by other documents at may be updated, replaced, or obsoleted by other documents at any time. It
any time. It is inappropriate to use Internet-Drafts as reference is inappropriate to use Internet-Drafts as reference material or to cite
material or to cite them other than as ``work in progress''. To them other than as ``work in progress''. To learn the current status of
learn the current status of any Internet-Draft, please check the any Internet-Draft, please check the ``1id-abstracts.txt'' listing
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow contained in the Internet-Drafts Shadow Directories on ftp.is.co.za
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Comments are solicited and should be addressed to the author(s) Comments are solicited and should be addressed to the author(s) and/or the
and/or the IETF Audio/Video Transport working group's mailing list IETF Audio/Video Transport working group's mailing list at rem-conf@es.net.
at rem-conf@es.net.
Abstract Abstract
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 IP multicast to deliver A number of applications have emerged which use RTP/UDP transport
continuous media streams. Due to the unreliable nature of IP multicast to deliver continuous media streams. Due to the unreliable nature
transport, the quality of the received stream will be adversely affected of UDP packet delivery, the quality of the received stream will be
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 have a wide range by which the effects of packet loss may be repaired. These techniques
of applicability and require varying degrees of protocol support.
In this document, four such techniques (redundancy, interleaving,
retransmission, and FEC) are discussed, and recommendations for their
applicability made.
The author's experience is with the development of a loss-resilient have a wide range of applicability and require varying degrees of
multicast audio conferencing application. This document has, therefore, protocol support. In this document, a number of such techniques
been prepared with the underlying assumption that the media is streaming are discussed, and recommendations for their applicability made.
audio. The techniques discussed are, however, expected to generalize
to other media types in many cases.
2 Terminology and Protocol Framework 2 Terminology and Protocol Framework
A unit is defined to be a timed interval of media data, typically A unit is defined to be a timed interval of media data, typically derived
derived from the workings of the media coder. A packet comprises one from the workings of the media coder. A packet comprises one or more
or more units, encapsulated for transmission over the network. For units, encapsulated for transmission over the network. For example, many
example, many audio coders operate on 20ms units, which are typically audio coders operate on 20ms units, which are typically combined to produce
combined to produce 40ms or 80ms packets for transmission. 40ms or 80ms packets for transmission.
The framework of RTP [10] is assumed. This implies that packets have The framework of RTP [15] is assumed. This implies that packets have a
a sequence number and timestamp. The sequence number denotes the sequence number and timestamp. The sequence number denotes the order in
order in which packets are transmitted, and is used to detect losses. which packets are transmitted, and is used to detect losses. The timestamp
The timestamp is used to determine the playout order of units. Most is used to determine the playout order of units. Most loss recovery
loss recovery schemes rely on units being sent out of order, so an schemes rely on units being sent out of order, so an application must use
application must use the RTP timestamp to schedule playout. The use the RTP timestamp to schedule playout.
of RTP allows for several different media coders, with a payload type
field being used to distinguish between these at the receiver. Some 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 recovery schemes send some units multiple times, using different loss recovery schemes send some units multiple times, using different
encoding schemes. A receiver is assumed to have a `quality' ranking encoding schemes. A receiver is assumed to have a `quality' ranking of the
of the differing encodings, and so is capable of choosing the `best' differing encodings, and so is capable of choosing the `best' unit for
unit for playout, given multiple options. 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, If it is desired to repair a media stream subject to packet loss, it is
it is useful to have some knowledge of the loss characteristics which useful to have some knowledge of the loss characteristics which are likely
are likely to be encountered. A number of studies have been conducted to be encountered. A number of studies have been conducted on the loss
on the loss characteristics of the Mbone [8,9] and although the results characteristics of the Mbone [8,9] and although the results vary somewhat,
vary somewhat, the broad conclusion is clear: in a large conference the broad conclusion is clear: in a large conference it is inevitable that
it is inevitable that some receivers will experience packet loss. some receivers will experience packet loss. Packet traces taken by Handley
Packet traces taken by Handley [8] show a session in which most receivers [5] show a session in which most receivers experience loss in the range
experience loss in the range 2-5%, with a somewhat smaller number 2-5%, with a somewhat smaller number seeing significantly higher loss
seeing significantly higher loss rates. Other studies have presented rates. Other studies have presented broadly similar results.
broadly similar results.
It has also been shown that the vast majority of losses are of single 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 packets. Burst losses of two or more packets are around an order
of magnitude less frequent than single packet loss, although they of magnitude less frequent than single packet loss, although they
do occur more often than would be expected from a purely random process. 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. Longer burst losses (of the order of tens of packets) occur infrequently.
These results are consistent with a network where small amounts of These results are consistent with a network where small amounts of
transient congestion cause the majority of packet loss. In a few 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 The primary focus of a packet loss repair scheme must, therefore, be to
to correct single packet loss, since this is by far the most frequent correct single packet loss, since this is by far the most frequent
occurrence. It is desirable that losses of a relatively small number occurrence. It is desirable that losses of a relatively small number of
of consecutive packets may also be repaired, since such losses consecutive packets may also be repaired, since such losses represent a
represent a small but noticeable fraction of observed losses. The small but noticeable fraction of observed losses. The correction of large
correction of large bursts of loss is of considerably less importance. bursts of loss is of considerably less importance.
4 Loss Repair Schemes 4 Loss Mitigation Schemes
In the following sections, four loss repair 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, These schemes have been discussed in the literature a number of times,
and found to be of use in a number of scenarios. Each technique and found to be of use in a number of scenarios. Each technique
is briefly described, and its advantages and disadvantages noted. is briefly described, and its advantages and disadvantages noted.
A summary and comparison follows.
4.1 Redundant Transmission 4.1 Forward Error Correction
The case for redundant transmission of audio data has been made in Forward error correction (FEC) is the means by which repair data
[5,6]. Each unit is coded multiple times, and sent in several packets. is added to a media stream, such that packet loss can be repaired
If a packet is lost, a subsequent packet contains a copy of the unit by the receiver of that stream with no further reference to the sender.
which may be used as a replacement. By recoding the redundant unit(s) There are two classes of repair data which may be added to a stream:
with a low bit-rate compression scheme the overhead of this technique those which are independent of the contents of the stream, and those
may be reduced, at the expense of a reduction in quality (but note which use knowledge of the stream to improve the repair process.
that even an LPC encoded fill-in sounds better than silence).
Unlike the other techniques discussed, the use of redundancy has
the advantage of low-latency, with only a single-packet delay being
added. This makes it suitable for interactive applications, where
large end-to-end delays cannot be tolerated. In a broadcast-style
environment, it is possible to delay the redundant copy of a packet,
achieving improved performance in the presence of burst losses [7],
at the expense of additional latency.
If the redundant copies of a unit are recoded with a low-bandwidth 4.1.1 Media-Independent FEC
compression scheme, the bandwidth overhead of this technique is small.
This does, however, result in an increased processor load which may
make this technique infeasible on low power workstations, particularly
if other media types are also being coded.
An RTP payload format for redundant data is defined in [1]. This A number of media-independent FEC schemes have been proposed for use with
has been implemented in a number of audio tools, and has been shown streamed media. These techniques add redundant data to a media stream
which is transmitted in separate packets. 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.
to perform well. 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.
4.2 Retransmission 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 [3]) 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.
Retransmission of lost packets is an obvious means by which loss Luby et al [8] have discussed applying parity in layers. The first
may be repaired. It is clearly of value in broadcast style applications, layer in their scheme is the parity bits generated from the media.
with relaxed delay bounds, but many authors have discounted the use The second layer is calculated as the parity bits of the first layer
of retransmission for interactive applications, due to the potentially and so on. This obviously improves the repair properties, but consumes
large delay imposed. A recent paper [4] challenges this: in that additional bandwidth.
paper it is noted that ``the desired degree of interactivity typically
varies from one participant to another'', and that this leads to
an interesting tradeoff between quality (reliability in delivery,
due to retransmission of lost packets) and interactivity (latency
in delivery).
In addition to the possibly high latency, there is a potentially Parity-based FEC based techniques have a significant advantage in
large bandwidth overhead to the use of retransmission. Not only that they are media independent, and provide exact repair for lost
are units of data sent multiple times, but additional control traffic packets. In addition, the processing requirements are relatively
must flow to request the retransmission. It has been shown [8] that, light, especially when compared with some redundancy schemes which
in a large Mbone session, most packets are lost by at least one receiver. use very low bandwidth, but high complexity encodings. The disadvantage
In this case the overhead of requesting retransmission for most packets of parity-based FEC is that the codings have higher latency in comparison
may be such that redundant transmission is more acceptable. This with the media-specific schemes discussed in following section.
leads to a natural synergy between the two mechanisms, with a redundant An RTP payload format for parity-based FEC is defined in [14]. The
transmission being used to repair all single packet losses, and those format is generic, and can specify many different parity encodings.
receivers experiencing burst losses, and willing to accept the additional
latency, using retransmission based repair as an additional recovery
mechanism.
In order to reduce the overhead of retransmission, the retransmitted A number of FEC schemes exist which are based on higher-order finite
units may be piggy-backed onto the ongoing transmission. This also fields. An example of such are Reed-Solomon (RS) codes which are
allows for the retransmission to be recoded in a different format, more sophisticated and computationally demanding. These are usually
to further reduce the bandwidth overhead. structured so that they have good burst loss protection. There has
been much work conducted in this area, and it is believed that a
number of streaming applications use RS codes.
Note that the choice of a retransmission request algorithm which 4.1.2 Media-Specific FEC
is both timely and network friendly is an area worthy of further
study.
4.3 Interleaving 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 otherwise be achieved. To repair a stream subject to packet
loss, it is necessary to add redundancy to that stream: some information
is added which is not required in the absence of packet loss, but
which can be used to recover from that loss.
When the unit size is smaller than the packet size, and end-to-end The nature of a media stream affects the means by which the redundancy
delay is unimportant, interleaving is a useful technique for reducing is added. If units of media data are packets, or if multiple units
the effects of loss. Units are resequenced before transmission, so are included in a packet, it is logical to use the unit as the level
that originally adjacent units are separated by a guaranteed distance of redundancy, and to send duplicate units. By recoding the redundant
in the transmitted stream, and returned to their original order at copy of a unit, significant bandwidth savings may be made, at the
the receiver. Interleaving disperses the effect of packet losses. expense of additional computational complexity and approximate repair.
If, for example, units are 5ms in length and packets 20ms (ie: 4 This approach has been advocated for use with streaming audio [5,6]
units per packet), then the first packet could contain units 1, 5, and has been shown to perform well. An RTP payload format for this
9, 13; the second packet would contain units 2, 6, 10, 14; and so form of redundancy has been defined [12].
on. It can be seen that the loss of a single packet from an interleaved If media units span multiple packets, for instance video, it is sensible
stream results in multiple small gaps in the reconstructed stream, to include redundancy directly within the output of a codec. For
as opposed to the single large gap which would occur in a non-interleaved example the proposed RTP payload for H.263+ [2] includes multiple
stream. This results in a noticeable increase in the perceived quality copies of key portions of the stream, separated to avoid the problems
of an audio stream, for example. of packet loss. The advantages of this second approach is efficiency:
the codec designer knows exactly which portions of the stream are
The obvious disadvantage of interleaving is that it increases latency. most important to protect, and low complexity since each unit is
This limits the use of this technique for interactive applications, coded once only.
although it performs well for broadcast 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 An alternative approach is to apply media-independent FEC techniques
of the redundant audio payload [1]. That payload requires that the to the most significant bits of a codecs output, rather than applying
redundant copy of a unit is sent after the primary. If this restriction it over the entire packet. Several codec descriptions include bit
is removed, it is possible to transmit arbitrary interleaving-s of sensitivities that make this feasible. This approach has low computational
units with this payload format. cost and can be tailored to represent an arbitrary fraction of the
transmitted data.
4.4 Forward Error Correction 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 applications, where large end-to-end delays cannot be
tolerated. In a broadcast-style environment, it is possible to delay
sending the redundant data, achieving improved performance in the
presence of burst losses [7], at the expense of additional latency.
Forward error correction (FEC) schemes rely on the addition of repair 4.2 Retransmission
data to a media stream, from which lost packets may be recovered.
That repair data takes the form of `parity' packets, calculated from
the exclusive-or (XOR) of a number of data packets. A lost packet
may be regenerated by XOR'ing the received data with the repair data.
A number of FEC schemes have been proposed for use with continuous
media streams by Budge et al [3]. These vary the bandwidth, latency
and repair capabilities by XOR'ing different combinations of packets
to generate the parity packets.
FEC based techniques have a significant advantage in that they are Retransmission of lost packets is an obvious means by which loss may be
media independent, and provide exact repair for lost packets. In repaired. It is clearly of value in broadcast style applications, with
addition, the processing requirements are relatively light, especially relaxed delay bounds, but the delay imposed means that it does not
when compared with some redundancy schemes which use very low bandwidth typically perform well for interactive use.
redundant encodings.
Disadvantages of FEC include high latency (in some cases), and In addition to the possibly high latency, there is a potentially large
potentially high bandwidth overhead. It is possible to reduce the bandwidth overhead to the use of retransmission. Not only are units of
bandwidth used by the FEC data, but this can only be achieved at the data sent multiple times, but additional control traffic must flow to
expense of reduced repair capability. If the bandwidth is available, request the retransmission. It has been shown that, in a large Mbone
FEC does, however, provide very good error recovery capabilities. Two session, most packets are lost by at least one receiver [5]. In this case
RTP payload formats have been proposed for FEC protected data: the the overhead of requesting retransmission for most packets may be such that
original by Budge et al [3], and an alternative from Rosenberg and redundant transmission is more acceptable. This leads to a natural synergy
Schulzrinne [2] who generalize the protocol somewhat. between the two mechanisms, with a redundant transmission 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
| |Latency|Bandwidth Overhead| Processing Overhead | may be piggy-backed onto the ongoing transmission. This also allows for
+--------------+-------+------------------+----------------------+ the retransmission to be recoded in a different format, to further reduce
|Redundancy |Small | Variable |Variable, may be large| the bandwidth overhead.
|Retransmission|Medium | Variable | High |
|Interleaving |High | None | Low |
|FEC |High | High | Low |
+--------------+-------+------------------+----------------------+
Table 1: Overheads of different repair schemes 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
4.5 Summary based repair schemes, and illustrates that retransmission is an effective
approach to repair for applications which can tolerate the latency.
A comparison of the relative overheads of the four schemes discussed An RTP profile extension for SRM-style retransmission requests is
is provided in table 1. It can be seen that the latency overhead described in [11].
is such that the use of redundant transmission is preferable for
interactive use, whereas interleaved streams or FEC are preferable
for broadcast style applications. The use of retransmission together
with redundant transmission offers an interesting trade-off between
the two approaches, with participants requiring interactivity relying
on the redundant data only, and other participants using retransmission
to correct losses at the expense of additional delay.
In terms of error recovery capability, the clear winner must be the 4.3 Interleaving
use of retransmission, since this will eventually recovery all lost
packets (the time required to achieve this may be large, however).
Of the other schemes, the use of FEC as proposed by Budge et al
[3], is typically the most effective repair mechanism. The use of
multiple redundant encodings can achieve similar repair capability,
although the processing requirements are likely to be excessive if
differing encodings are used for the multiple redundant units.
5 Open Issues 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
effects of loss. Units are resequenced before transmission, so that
originally adjacent units are separated by a guaranteed distance in the
transmitted stream, and returned to their original order at the receiver.
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
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
single packet from an interleaved stream results in multiple small gaps in
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
reconstruct a stream with such loss patterns, although this is clearly
media and codec dependent.
Of the four techniques discussed, only redundant transmission has The obvious disadvantage of interleaving is that it increases latency.
a well defined, standard, protocol framework (although this may clearly This limits the use of this technique for interactive applications,
be reused for the retransmission of media data). A simple extension although it performs well for broadcast use. The major advantage of
to this protocol provides a possibility for transporting interleaved interleaving is that it does not increase the bandwidth requirements of a
media streams. stream.
The choice of a retransmission algorithm which is both timely and A potential RTP payload format for interleaved data is a simple extension
network friendly, together with a suitable control protocol, is an of the redundant audio payload [12]. That payload requires that the
area worthy of further study. redundant copy of a unit is sent after the primary. If this restriction is
removed, it is possible to transmit an arbitrary interleaving of units with
this payload format.
Two conflicting proposals exist for the transport of FEC protected 5 Recommendations
data. This must clearly be resolved.
Experience with redundant audio (using a single, low bandwidth, redundant If the desired scenario is a one-to-many transmission, in the style
encoding) has shown that this is sufficient to protect against 30% of a radio or television broadcast, latency is of considerably less
packet loss in many cases. It is possible to protect against much importance than reception quality. In this case, the use of interleaving
higher packet loss rates, but this may not be desirable. Many current and/or retransmission based repair is appropriate, with interleaving
being preferred due to its bandwidth efficiency (provided that approximate
repair is acceptable).
media streaming applications do not employ congestion control, and In an interactive session (typically defined as a session where the
the widespread use of techniques which allow operation of these tools end-to-end delay is less then 250ms, this includes media coding/decoding,
in the presence of high levels of congestive packet loss is dubious, network transit and host buffering), the delay imposed by the use
at best. It would clearly be useful if guidelines on this issue of interleaving and retransmission is not acceptable, and a low-latency
could be derived before widespread deployment occurs.
6 Acknowledgments FEC scheme is the only means of repair suitable. The choice between
media independent and media specific forward error correction is less
clear-cut: media-specific FEC can be made more efficient, but requires
modification to the output of the codec. When defining the packetisation
for a new codec, this is clearly an appropriate technique, and should
be encouraged.
The author wishes to thanks Orion Hodson for his helpful comments If an existing codec is to be used, a media independent redundant
on an early version of this document. transmission scheme is usually easier to implement, and can perform
well. If the processing requirements are not excessive, recoding
the redundant data using a different codec is an effective means
of reducing the bandwidth overhead of a stream. A media stream protected
in this way may be augmented with retransmission based repair with
minimal overhead, providing improved quality for those receivers willing
to tolerate additional delay.
7 Author's Address Whilst the addition of error correction data to an media stream is
an effective means by which that stream may be protected against
packet loss, application designers should be aware that the addition
of large amounts of repair data will increase network congestion,
and hence packet loss, leading to a worsening of the problem which
the use of error correction coding was intended to solve.
Colin Perkins 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
this problem. There have, however, been a number of contributions
which show the likely form the solution will take [9, 16]. This
work typically used some form of layered encoding of data over multiple
channels, with receivers joining and leaving layers in response to
packet-loss (which indicates congestion). The aim of such schemes
is to emulate the congestion control behaviour of a TCP stream, and
hence compete fairly with non-real-time traffic. This is necessary
for stable network behaviour in the presence of much streamed media.
6 Author's Address
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@cs.ucl.ac.uk Email: <c.perkins|o.hodson>@cs.ucl.ac.uk
8 References References
[1] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.-C. [1] R.E. Blahut. Theory and Practice ofError Control Codes.
Bolot, A. Vega-Garcia and S. Fosse-Parisis, ``RTP Payload for Addison Wesley, 1983.
Redundant Audio Data'', Internet draft, IETF Audio/Video Transport
working group, July 1997, draft-ietf-avt-rtp-redundancy-01.txt.
[2] J. Rosenberg and H. Schulzrinne, ``An A/V Profile Extension for [2] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,
Generic Forward Error Correction in RTP'', Internet draft, IETF D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload
Audio/Video Transport working group, July 1997, draft-ietf-avt-fec-00.txt format for the 1998 version of ITU-T rec. H.263 video
(H.263+). IETF Audio/Video Transport Working Group,
November 1997. Work in progress.
[3] D. Budge, R. McKenzie, W. Mills and P. Long, ``Media-Independent Error [3] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long.
Correction using RTP'', May 1997, draft-budge-media-error-correction-00.txt Media-independent error correction using RTP, May 1997.
Work in progress.
[4] X. Rex Xu, A. C. Myers, H. Zhang, R. Yavatker, ``Resilient Multicast [4] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang.
Support for Continuous-Media Applications'', Proceedings NOSSDAV'97. A reliable multicast framework for light-weight
sessions and applications level framing. IEEE/ACM
Transactions on Networking, 1995.
[5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error [5] M. Handley. An examination of Mbone performance. USC/ISI
control for packet audio in the Internet; ACM Multimedia Systems, Research Report: ISI/RR-97-450, April 1997.
1997
[6] V. J. Hardman, M. A. Sasse, M. Handley and A. Watson, ``Reliable [6] M. Handley and J. Crowcroft. Network text editor (NTE): A
Audio for Use over the Internet'', Proceedings INET'95, Honalulu, scalable shared text editor for the Mbone. In Proceedings
Oahu, Hawaii, September 1995. http://www.isoc.org/in95prc/ ACM SIGCOMM'97, Cannes, France, September 1997.
[7] I. Kouvelas, O. Hodson, V. Hardman and J. Crowcroft, ``Redundancy [7] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft.
Control in Real-Time Internet Audio Conferencing'', Proceedings of Redundancy control in real-time Internet audio conferencing.
AVSPN'97, September 1997. In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.
[8] M. Handley, ``An Examination of Mbone performance'', USC/ISI Research [8] G.M. Luby, M. Mitzenmacher, M. Amin Shokrollahi, D.A.
Report: ISI/RR-97-450, http://buttle.lcs.mit.edu/ mjh/mbone.ps Spielman, and V. Stemann. Practical loss-resilent codes.
In Twenty-Nineth Annual ACM Symposium on theTheory of
Computing, 1997.
[9] M. Yajnik, J. Kurose and D. Towsley, ``Packet loss correlation [9] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven
in the Mbone multicast network'', Proceedings of IEEE Globecom'96, layered multicast. In Proceedings ACM SIGCOMM'96, Stanford,
November 1996. CA., August 1996.
[10] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: [10] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based
A Transport protocol for Real-Time Applications'', IETF loss recovery for reliable multicast transmission. In
Audio/Video Transport working group, January 1996, RFC 1889. Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[11] P. Parnes. RTP extension for scalable reliable multicast,
November 1996. Work in progress.
[12] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman,
M. Handley, J.-C. Bolot, A. Vega-Garcia, and
S. Fosse-Parisis. RTP Payload for redundant audio data.
IETF Audio/Video Transport Working Group, 1997. RFC2198.
[13] J.L. Ramsey. Realization of optimum interleavers. IEEE
Transactions on Information Theory, IT-16:338--345, May
1970.
[14] J. Rosenberg and H. Schulzrinne. An A/V profile extension
for generic forward error correction in RTP. IETF
Audio/Video Transport working group, July 1997. Work in
progress.
[15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson.
RTP: A transport protocol for real-time applications. IETF
Audio/Video Transport Working Group, January 1996. RFC1889.
[16] L. Vicisano, L. Rizzo, and J. Crowcroft. TCP-like congestion
control for layered multicast data transfer. In Proceedings
IEEE INFOCOM'98, 1998.
[17] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar.
Resilient multicast support for continuous media
applications. In Proceedings of the 7th International
Workshop on Network and Operating SystemsSupport for
Digital Audio and Video (NOSSDAV'97), Washington University
in St. Louis, Missouri, May 1997.
 End of changes. 64 change blocks. 
249 lines changed or deleted 271 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/