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/ |