draft-ietf-avt-info-repair-00.txt   draft-ietf-avt-info-repair-01.txt 
INTERNET-DRAFT 3 August 1997 INTERNET-DRAFT 21 November 1997
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. have a wide range of applicability and require varying degrees of
protocol support. In this document, a number of such techniques
In this document, four such techniques (redundancy, interleaving, are discussed, and recommendations for their applicability made.
retransmission, and FEC) are discussed, and recommendations for their
applicability made.
The author's experience is with the development of a loss-resilient
multicast audio conferencing application. This document has, therefore,
been prepared with the underlying assumption that the media is streaming
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
to perform well. 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.
4.2 Retransmission 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.
Retransmission of lost packets is an obvious means by which loss Basic FEC schemes transmit k data packets with n-k parity packets
may be repaired. It is clearly of value in broadcast style applications, allowing the reconstruction of the original data from any k of the
with relaxed delay bounds, but many authors have discounted the use n transmitted packets. Budge et al [3]) proposed applying the XOR
of retransmission for interactive applications, due to the potentially operation across different combinations of the media data with the
large delay imposed. A recent paper [4] challenges this: in that redundant data transmitted separately as parity packets. These vary
paper it is noted that ``the desired degree of interactivity typically the pattern of packets over which the parity is calculated, and hence
varies from one participant to another'', and that this leads to have different bandwidth, latency and loss repair characteristics.
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 Luby et al [8] have discussed applying parity in layers. The first
large bandwidth overhead to the use of retransmission. Not only layer in their scheme is the parity bits generated from the media.
are units of data sent multiple times, but additional control traffic The second layer is calculated as the parity bits of the first layer
must flow to request the retransmission. It has been shown [8] that, and so on. This obviously improves the repair properties, but consumes
in a large Mbone session, most packets are lost by at least one receiver. additional bandwidth.
In this case the overhead of requesting retransmission for most packets
may be such that redundant transmission is more acceptable. This
leads to a natural synergy 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.
In order to reduce the overhead of retransmission, the retransmitted Parity-based FEC based techniques have a significant advantage in
units may be piggy-backed onto the ongoing transmission. This also that they are media independent, and provide exact repair for lost
allows for the retransmission to be recoded in a different format, packets. In addition, the processing requirements are relatively
to further reduce the bandwidth overhead. light, especially when compared with some 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.
An RTP payload format for parity-based FEC is defined in [14]. The
format is generic, and can specify many different parity encodings.
Note that the choice of a retransmission request algorithm which A number of FEC schemes exist which are based on higher-order finite
is both timely and network friendly is an area worthy of further fields. An example of such are Reed-Solomon (RS) codes which are
study. more sophisticated and computationally demanding. These are usually
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.
4.3 Interleaving 4.1.2 Media-Specific FEC
When the unit size is smaller than the packet size, and end-to-end The basis of media-specific FEC is to employ knowledge of a media
delay is unimportant, interleaving is a useful technique for reducing compression scheme to achieve more efficient repair of a stream than
the effects of loss. Units are resequenced before transmission, so can otherwise be achieved. To repair a stream subject to packet
that originally adjacent units are separated by a guaranteed distance loss, it is necessary to add redundancy to that stream: some information
in the transmitted stream, and returned to their original order at is added which is not required in the absence of packet loss, but
the receiver. Interleaving disperses the effect of packet losses. which can be used to recover from that loss.
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. This results in a noticeable increase in the perceived quality
of an audio stream, for example.
The obvious disadvantage of interleaving is that it increases latency. The nature of a media stream affects the means by which the redundancy
This limits the use of this technique for interactive applications, is added. If units of media data are packets, or if multiple units
although it performs well for broadcast use. The major advantage are included in a packet, it is logical to use the unit as the level
of interleaving is that it does not increase the bandwidth requirements of redundancy, and to send duplicate units. By recoding the redundant
of a stream. copy of a unit, significant bandwidth savings may be made, at the
expense of additional computational complexity and approximate repair.
This approach has been advocated for use with streaming audio [5,6]
and has been shown to perform well. An RTP payload format for this
form of redundancy has been defined [12].
A potential RTP payload format for interleaved data is a simple extension If media units span multiple packets, for instance video, it is sensible
of the redundant audio payload [1]. That payload requires that the to include redundancy directly within the output of a codec. For
redundant copy of a unit is sent after the primary. If this restriction example the proposed RTP payload for H.263+ [2] includes multiple
is removed, it is possible to transmit arbitrary interleaving-s of copies of key portions of the stream, separated to avoid the problems
units with this payload format. of packet loss. The advantages of this second approach is efficiency:
the codec designer knows exactly which portions of the stream are
most important to protect, and low complexity since each unit is
coded once only.
4.4 Forward Error Correction 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 entire packet. Several codec descriptions include bit
sensitivities that make this feasible. This approach has low computational
cost and can be tailored to represent an arbitrary fraction of the
transmitted data.
Forward error correction (FEC) schemes rely on the addition of repair The use of media-specific FEC has the advantage of low-latency, with
data to a media stream, from which lost packets may be recovered. only a single-packet delay being added. This makes it suitable for
That repair data takes the form of `parity' packets, calculated from interactive applications, where large end-to-end delays cannot be
the exclusive-or (XOR) of a number of data packets. A lost packet tolerated. In a broadcast-style environment, it is possible to delay
may be regenerated by XOR'ing the received data with the repair data. sending the redundant data, achieving improved performance in the
A number of FEC schemes have been proposed for use with continuous presence of burst losses [7], at the expense of additional latency.
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 4.2 Retransmission
media independent, and provide exact repair for lost packets. In
addition, the processing requirements are relatively light, especially
when compared with some redundancy schemes which use very low bandwidth
redundant encodings.
Disadvantages of FEC include high latency (in some cases), and Retransmission of lost packets is an obvious means by which loss may be
potentially high bandwidth overhead. It is possible to reduce the repaired. It is clearly of value in broadcast style applications, with
bandwidth used by the FEC data, but this can only be achieved at the relaxed delay bounds, but the delay imposed means that it does not
expense of reduced repair capability. If the bandwidth is available, typically perform well for interactive use.
FEC does, however, provide very good error recovery capabilities. Two
RTP payload formats have been proposed for FEC protected data: the
original by Budge et al [3], and an alternative from Rosenberg and
Schulzrinne [2] who generalize the protocol somewhat.
+--------------+-------+------------------+----------------------+ In addition to the possibly high latency, there is a potentially large
| |Latency|Bandwidth Overhead| Processing Overhead | bandwidth overhead to the use of retransmission. Not only are units of
+--------------+-------+------------------+----------------------+ data sent multiple times, but additional control traffic must flow to
|Redundancy |Small | Variable |Variable, may be large| request the retransmission. It has been shown that, in a large Mbone
|Retransmission|Medium | Variable | High | session, most packets are lost by at least one receiver [5]. In this case
|Interleaving |High | None | Low | the overhead of requesting retransmission for most packets may be such that
|FEC |High | High | Low | redundant transmission is more acceptable. This leads to a natural synergy
+--------------+-------+------------------+----------------------+ 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].
Table 1: Overheads of different repair schemes 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.
4.5 Summary 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.
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
media streaming applications do not employ congestion control, and being preferred due to its bandwidth efficiency (provided that approximate
the widespread use of techniques which allow operation of these tools repair is acceptable).
in the presence of high levels of congestive packet loss is dubious,
at best. It would clearly be useful if guidelines on this issue
could be derived before widespread deployment occurs.
6 Acknowledgments In an interactive session (typically defined as a session where the
end-to-end delay is less then 250ms, this includes media coding/decoding,
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
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. 59 change blocks. 
250 lines changed or deleted 271 lines changed or added

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