draft-ietf-avt-info-repair-01.txt   draft-ietf-avt-info-repair-02.txt 
INTERNET-DRAFT 21 November 1997 INTERNET-DRAFT 7 January 1998
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-01.txt draft-ietf-avt-info-repair-02
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 page 1, line 44 skipping to change at page 1, line 44
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 A number of applications have emerged which use RTP/UDP transport to
to deliver continuous media streams. Due to the unreliable nature deliver continuous media streams. Due to the unreliable nature of UDP
of UDP packet delivery, the quality of the received stream will be packet delivery, the quality of the received stream will be adversely
adversely affected by packet loss. A number of techniques exist affected by packet loss. A number of techniques exist by which the effects
by which the effects of packet loss may be repaired. These techniques 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.
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 derived
from the workings of the media coder. A packet comprises one or more from the workings of the media coder. A packet comprises one or more
units, encapsulated for transmission over the network. For example, many units, encapsulated for transmission over the network. For example, many
audio coders operate on 20ms units, which are typically combined to produce audio coders operate on 20ms units, which are typically combined to produce
skipping to change at page 2, line 43 skipping to change at page 2, line 43
useful to have some knowledge of the loss characteristics which are likely useful to have some knowledge of the loss characteristics which are likely
to be encountered. A number of studies have been conducted on the loss to be encountered. A number of studies have been conducted on the loss
characteristics of the Mbone [8,9] and although the results vary somewhat, characteristics of the Mbone [8,9] and although the results vary somewhat,
the broad conclusion is clear: in a large conference it is inevitable that the broad conclusion is clear: in a large conference it is inevitable that
some receivers will experience packet loss. Packet traces taken by Handley some receivers will experience packet loss. Packet traces taken by Handley
[5] show a session in which most receivers experience loss in the range [5] show a session in which most receivers experience loss in the range
2-5%, with a somewhat smaller number seeing significantly higher loss 2-5%, with a somewhat smaller number seeing significantly higher loss
rates. Other studies have presented broadly similar results. rates. Other studies have presented 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
of magnitude less frequent than single packet loss, although they magnitude less frequent than single packet loss, although they do occur
do occur more often than would be expected from a purely random process. more often than would be expected from a purely random process. Longer
Longer burst losses (of the order of tens of packets) occur infrequently. burst losses (of the order of tens of packets) occur infrequently. These
These results are consistent with a network where small amounts of results are consistent with a network where small amounts of transient
transient congestion cause the majority of packet loss. In a few 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 packet loss repair scheme must, therefore, be 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 of occurrence. It is desirable that losses of a relatively small number of
consecutive packets may also be repaired, since such losses represent a consecutive packets may also be repaired, since such losses represent a
small but noticeable fraction of observed losses. The correction of large small 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, These schemes have been discussed in the literature a number of times, and
and found to be of use in a number of scenarios. Each technique found to be of use in a number of scenarios. Each technique is briefly
is briefly described, and its advantages and disadvantages noted. described, and its advantages and disadvantages noted.
4.1 Forward Error Correction 4.1 Forward Error Correction
Forward error correction (FEC) is the means by which repair data Forward error correction (FEC) is the means by which repair data is added
is added to a media stream, such that packet loss can be repaired to a media stream, such that packet loss can be repaired by the receiver of
by the receiver of that stream with no further reference to the sender. that stream with no further reference to the sender. There are two classes
There are two classes of repair data which may be added to a stream: of repair data which may be added to a stream: those which are independent
those which are independent of the contents of the stream, and those of the contents of the stream, and those which use knowledge of the stream
which use knowledge of the stream to improve the repair process. to improve the repair process.
4.1.1 Media-Independent FEC 4.1.1 Media-Independent FEC
A number of media-independent FEC schemes have been proposed for use with A number of media-independent FEC schemes have been proposed for use with
streamed media. These techniques add redundant data to a media stream streamed media. These techniques add redundant data to a media stream
which is transmitted in separate packets. Traditionally, FEC techniques which is transmitted in separate packets. Traditionally, FEC techniques
are described as loss detecting and/or loss correcting. In the case of 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 streamed media loss detection is provided by the sequence numbers in RTP
packets. packets.
The redundant FEC data is typically calculated using the mathematics of 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 finite fields [1]. The simplest of finite field is GF(2) where addition is
just the eXclusive-OR operation. just the eXclusive-OR operation.
Basic FEC schemes transmit k data packets with n-k parity packets Basic FEC schemes transmit k data packets with n-k parity packets allowing
allowing the reconstruction of the original data from any k of the the reconstruction of the original data from any k of the n transmitted
n transmitted packets. Budge et al [3]) proposed applying the XOR packets. Budge et al [3] proposed applying the XOR operation across
operation across different combinations of the media data with the different combinations of the media data with the redundant data
redundant data transmitted separately as parity packets. These vary transmitted separately as parity packets. These vary the pattern of
the pattern of packets over which the parity is calculated, and hence packets over which the parity is calculated, and hence have different
have different bandwidth, latency and loss repair characteristics. bandwidth, latency and loss repair characteristics.
Luby et al [8] have discussed applying parity in layers. The first Luby et al [8] have discussed applying parity in layers. The first layer
layer in their scheme is the parity bits generated from the media. in their scheme is the parity bits generated from the media. The second
The second layer is calculated as the parity bits of the first layer layer is calculated as the parity bits of the first layer and so on. This
and so on. This obviously improves the repair properties, but consumes obviously improves the repair properties, but consumes additional
additional bandwidth. bandwidth.
Parity-based FEC based techniques have a significant advantage in Parity-based FEC based techniques have a significant advantage in that they
that they are media independent, and provide exact repair for lost are media independent, and provide exact repair for lost packets. In
packets. In addition, the processing requirements are relatively addition, the processing requirements are relatively light, especially when
light, especially when compared with some redundancy schemes which compared with some redundancy schemes which use very low bandwidth, but
use very low bandwidth, but high complexity encodings. The disadvantage high complexity encodings. The disadvantage of parity-based FEC is that
of parity-based FEC is that the codings have higher latency in comparison the codings have higher latency in comparison with the media-specific
with the media-specific schemes discussed in following section. schemes discussed in following section. An RTP payload format for
An RTP payload format for parity-based FEC is defined in [14]. The parity-based FEC is defined in [14]. The format is generic, and can
format is generic, and can specify many different parity encodings. specify many different parity encodings.
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 fields. An example of such are Reed-Solomon (RS) codes which are more
more sophisticated and computationally demanding. These are usually sophisticated and computationally demanding. These are usually structured
structured so that they have good burst loss protection. There has so that they have good burst loss protection. There has been much work
been much work conducted in this area, and it is believed that a conducted in this area, and it is believed that a number of streaming
number of streaming applications use RS codes. applications use RS codes.
4.1.2 Media-Specific FEC 4.1.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 compression scheme to achieve more efficient repair of a stream than can
can otherwise be achieved. To repair a stream subject to packet otherwise be achieved. To repair a stream subject to packet loss, it is
loss, it is necessary to add redundancy to that stream: some information necessary to add redundancy to that stream: some information is added
is added which is not required in the absence of packet loss, but which is not required in the absence of packet loss, but which can be used
which can be used to recover from that loss. to recover from that loss.
The nature of a media stream affects the means by which the redundancy The nature of a media stream affects the means by which the redundancy is
is added. If units of media data are packets, or if multiple units added. If units of media data are packets, or if multiple units are
are included in a packet, it is logical to use the unit as the level included in a packet, it is logical to use the unit as the level of
of redundancy, and to send duplicate units. By recoding the redundant redundancy, and to send duplicate units. By recoding the redundant copy of
copy of a unit, significant bandwidth savings may be made, at the a unit, significant bandwidth savings may be made, at the expense of
expense of additional computational complexity and approximate repair. additional computational complexity and approximate repair. This approach
This approach has been advocated for use with streaming audio [5,6] has been advocated for use with streaming audio [5,6] and has been shown to
and has been shown to perform well. An RTP payload format for this perform well. An RTP payload format for this form of redundancy has been
form of redundancy has been defined [12]. defined [12].
If media units span multiple packets, for instance video, it is sensible If media units span multiple packets, for instance video, it is sensible to
to include redundancy directly within the output of a codec. For include redundancy directly within the output of a codec. For example the
example the proposed RTP payload for H.263+ [2] includes multiple proposed RTP payload for H.263+ [2] includes multiple copies of key
copies of key portions of the stream, separated to avoid the problems portions of the stream, separated to avoid the problems of packet loss.
of packet loss. The advantages of this second approach is efficiency: The advantages of this second approach is efficiency: the codec designer
the codec designer knows exactly which portions of the stream are knows exactly which portions of the stream are
most important to protect, and low complexity since each unit is most important to protect, and low complexity since each unit is coded once
coded once only. only.
An alternative approach is to apply media-independent FEC techniques An alternative approach is to apply media-independent FEC techniques to the
to the most significant bits of a codecs output, rather than applying most significant bits of a codecs output, rather than applying it over the
it over the entire packet. Several codec descriptions include bit entire packet. Several codec descriptions include bit sensitivities that
sensitivities that make this feasible. This approach has low computational make this feasible. This approach has low computational cost and can be
cost and can be tailored to represent an arbitrary fraction of the tailored to represent an arbitrary fraction of the transmitted data.
transmitted data.
The use of media-specific FEC has the advantage of low-latency, with The use of media-specific FEC has the advantage of low-latency, with only a
only a single-packet delay being added. This makes it suitable for single-packet delay being added. This makes it suitable for interactive
interactive applications, where large end-to-end delays cannot be applications, where large end-to-end delays cannot be tolerated. In a
tolerated. In a broadcast-style environment, it is possible to delay uni-directional non-interactive environment it is possible to delay sending
sending the redundant data, achieving improved performance in the the redundant data, achieving improved performance in the presence of burst
presence of burst losses [7], at the expense of additional latency. losses [7], at the expense of additional latency.
4.2 Retransmission 4.2 Retransmission
Retransmission of lost packets is an obvious means by which loss may be Retransmission of lost packets is an obvious means by which loss may be
repaired. It is clearly of value in broadcast style applications, with repaired. It is clearly of value in non-interactive applications, with
relaxed delay bounds, but the delay imposed means that it does not relaxed delay bounds, but the delay imposed means that it does not
typically perform well for interactive use. typically perform well for interactive use.
In addition to the possibly high latency, there is a potentially large In addition to the possibly high latency, there is a potentially large
bandwidth overhead to the use of retransmission. Not only are units of bandwidth overhead to the use of retransmission. Not only are units of
data sent multiple times, but additional control traffic must flow to data sent multiple times, but additional control traffic must flow to
request the retransmission. It has been shown that, in a large Mbone 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 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 overhead of requesting retransmission for most packets may be such that
redundant transmission is more acceptable. This leads to a natural synergy the use of forward error correction is more acceptable. This leads to a
between the two mechanisms, with a redundant transmission being used to natural synergy between the two mechanisms, with a forward error correction
repair all single packet losses, and those receivers experiencing burst scheme being used to repair all single packet losses, and those receivers
losses, and willing to accept the additional latency, using retransmission experiencing burst losses, and willing to accept the additional latency,
based repair as an additional recovery mechanism. Similar mechanisms have using retransmission based repair as an additional recovery mechanism.
been used in a number of reliable multicast schemes, and have received some Similar mechanisms have been used in a number of reliable multicast
discussion in the literature [10, 6]. schemes, and have received some discussion in the literature [10, 6].
In order to reduce the overhead of retransmission, the retransmitted units In order to reduce the overhead of retransmission, the retransmitted units
may be piggy-backed onto the ongoing transmission. This also allows for 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 retransmission to be recoded in a different format, to further reduce
the bandwidth overhead. the bandwidth overhead.
The choice of a retransmission request algorithm which is both timely and The choice of a retransmission request algorithm which is both timely
network friendly is an area of current study. An obvious starting point is and network friendly is an area of current study. An obvious starting
the SRM protocol [4], and experiments have been conducted using this, and point is the SRM protocol [4], and experiments have been conducted
with a low-delay variant, STORM [17]. This work shows the trade-off using this, and with a low-delay variant, STORM [17]. This work
between latency and quality for retransmission shows the trade-off between latency and quality for retransmission
based repair schemes, and illustrates that retransmission is an effective based repair schemes, and illustrates that retransmission is an effective
approach to repair for applications which can tolerate the latency. approach to repair for applications which can tolerate the latency.
An RTP profile extension for SRM-style retransmission requests is An RTP profile extension for SRM-style retransmission requests is
described in [11]. 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 [13] is a useful technique for reducing the
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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. media and codec dependent. The obvious disadvantage of interleaving is
that it increases latency. This limits the use of this technique for
The obvious disadvantage of interleaving is that it increases latency. interactive applications, although it performs well for non-interactive
This limits the use of this technique for interactive applications, use. The major advantage of interleaving is that it does not increase the
although it performs well for broadcast use. The major advantage of bandwidth requirements of a stream.
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 [12]. That payload requires that the
redundant copy of a unit is sent after the primary. If this restriction is 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 removed, it is possible to transmit an arbitrary interleaving of units with
this payload format. this payload format.
5 Recommendations 5 Recommendations
If the desired scenario is a one-to-many transmission, in the style If the desired scenario is a non-interactive uni-directional transmission,
of a radio or television broadcast, latency is of considerably less in the style of a radio or television broadcast for example, latency is of
importance than reception quality. In this case, the use of interleaving considerably less importance than reception quality. In this case, the use
and/or retransmission based repair is appropriate, with interleaving of interleaving and/or retransmission based repair is appropriate, with
being preferred due to its bandwidth efficiency (provided that approximate interleaving being preferred due to its bandwidth efficiency (provided that
repair is acceptable). approximate repair is acceptable).
In an interactive session (typically defined as a session where the In an interactive session (typically defined as a session where the
end-to-end delay is less then 250ms, this includes media coding/decoding, end-to-end delay is less then 250ms, this includes media coding/decoding,
network transit and host buffering), the delay imposed by the use network transit and host buffering), the delay imposed by the use of
of interleaving and retransmission is not acceptable, and a low-latency interleaving and retransmission is not acceptable, and a low-latency
FEC scheme is the only means of repair suitable. The choice between FEC scheme is the only means of repair suitable. The choice between
media independent and media specific forward error correction is less media independent and media specific forward error correction is less
clear-cut: media-specific FEC can be made more efficient, but requires clear-cut: media-specific FEC can be made more efficient, but requires
modification to the output of the codec. When defining the packetisation modification to the output of the codec. When defining the packetisation
for a new codec, this is clearly an appropriate technique, and should for a new codec, this is clearly an appropriate technique, and should
be encouraged. be encouraged.
If an existing codec is to be used, a media independent redundant If an existing codec is to be used, a media independent forward error
transmission scheme is usually easier to implement, and can perform correction scheme is usually easier to implement, and can perform
well. If the processing requirements are not excessive, recoding well. A media stream protected in this way may be augmented with
the redundant data using a different codec is an effective means retransmission based repair with minimal overhead, providing improved
of reducing the bandwidth overhead of a stream. A media stream protected quality for those receivers willing to tolerate additional delay.
in this way may be augmented with retransmission based repair with
minimal overhead, providing improved quality for those receivers willing
to tolerate additional delay.
Whilst the addition of error correction data to an media stream is Whilst the addition of error correction data to an media stream is
an effective means by which that stream may be protected against an effective means by which that stream may be protected against
packet loss, application designers should be aware that the addition packet loss, application designers should be aware that the addition
of large amounts of repair data will increase network congestion, of large amounts of repair data will increase network congestion,
and hence packet loss, leading to a worsening of the problem which and hence packet loss, leading to a worsening of the problem which
the use of error correction coding was intended to solve. 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 [9, 16]. 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 behaviour 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 behaviour in the presence of much streamed media.
6 Author's Address 6 Acknowledgements
The authors wish to thank Phil Karn for his helpful comments.
7 Author's 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 ofError 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] 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 rec. H.263 video
(H.263+). IETF Audio/Video Transport Working Group, (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. [3] 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 L. Zhang. [4] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and
A reliable multicast framework for light-weight L. Zhang. A reliable multicast framework for light-weight
sessions and applications level framing. IEEE/ACM sessions and applications level framing. IEEE/ACM
Transactions on Networking, 1995. Transactions on Networking, 1995.
[5] M. Handley. An examination of Mbone performance. USC/ISI [5] 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 [6] 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. [7] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft.
Redundancy control in real-time Internet audio conferencing. Redundancy control in real-time Internet audio
In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997. conferencing. In Proceedings of AVSPN'97, Aberdeen,
Scotland, September 1997.
[8] G.M. Luby, M. Mitzenmacher, M. Amin Shokrollahi, D.A. [8] G.M. Luby, M. Mitzenmacher, M. Amin Shokrollahi, D.A.
Spielman, and V. Stemann. Practical loss-resilent codes. Spielman, and V. Stemann. Practical loss-resilent codes.
In Twenty-Nineth Annual ACM Symposium on theTheory of In Twenty-Nineth Annual ACM Symposium on theTheory of
Computing, 1997. Computing, 1997.
[9] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven [9] 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 [10] 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, [11] 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, [12] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman,
M. Handley, J.-C. Bolot, A. Vega-Garcia, and M. Handley, J.-C. Bolot, A. Vega-Garcia, and
S. Fosse-Parisis. RTP Payload for redundant audio data. S. Fosse-Parisis. RTP Payload for redundant audio data.
IETF Audio/Video Transport Working Group, 1997. RFC2198. IETF Audio/Video Transport Working Group, 1997. RFC2198.
[13] J.L. Ramsey. Realization of optimum interleavers. IEEE [13] J.L. Ramsey. Realization of optimum interleavers. IEEE
Transactions on Information Theory, IT-16:338--345, May Transactions on Information Theory, IT-16:338--345, May
1970. 1970.
[14] J. Rosenberg and H. Schulzrinne. An A/V profile extension [14] J. Rosenberg and H. Schulzrinne. An A/V profile extension
for generic forward error correction in RTP. IETF for generic forward error correction in RTP. IETF
Audio/Video Transport working group, July 1997. Work in Audio/Video Transport working group, July 1997. Work in
progress. progress.
[15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. [15] 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 J. Crowcroft. TCP-like congestion [16] 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. [17] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar.
Resilient multicast support for continuous media Resilient multicast support for continuous media
applications. In Proceedings of the 7th International applications. In Proceedings of the 7th International
Workshop on Network and Operating SystemsSupport for Workshop on Network and Operating SystemsSupport for
Digital Audio and Video (NOSSDAV'97), Washington University Digital Audio and Video (NOSSDAV'97), Washington University
in St. Louis, Missouri, May 1997. in St. Louis, Missouri, May 1997.
 End of changes. 34 change blocks. 
133 lines changed or deleted 130 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/