Network Working Group C. Perkins
Request for Comments: 2354 O. Hodson
Category: Informational University College London
June 1998
Network Working Group C. Perkins
Request for Comments: 2354 O. Hodson
Category: Informational University College London
June 1998
Options for Repair of Streaming Media
修复流媒体的选项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。本备忘录未规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies.
本文档总结了一系列可能的技术，用于修复受到分组丢失影响的连续媒体流。讨论的技术包括冗余传输、重传、交织和前向纠错。注意这些技术的适用范围，以及协议要求和依赖性。
1 Introduction
1导言
A number of applications have emerged which use RTP/UDP transport to deliver continuous media streams. Due to the unreliable nature of UDP packet delivery, the quality of the received stream will be adversely affected by packet loss. A number of techniques exist by which the effects of packet loss may be repaired. These techniques have a wide range of applicability and require varying degrees of protocol support. In this document, a number of such techniques are discussed, and recommendations for their applicability made.
许多应用程序已经出现，它们使用RTP/UDP传输来传输连续的媒体流。由于UDP数据包传输的不可靠性，数据包丢失将对接收流的质量产生不利影响。有许多技术可以用来修复数据包丢失的影响。这些技术具有广泛的适用性，需要不同程度的协议支持。在本文件中，讨论了许多此类技术，并对其适用性提出了建议。
It should be noted that this document is introductory in nature, and does not attempt to be comprehensive. In particular, we restrict our discussion to repair techniques which require the involvement of the sender of a media stream, and do not discuss possibilities for receiver based repair.
应该指出的是，本文件是介绍性的，并不试图全面。特别是，我们将讨论限制在需要媒体流的发送者参与的修复技术上，而不讨论基于接收者的修复的可能性。
For a more detailed survey, the reader is referred to [5].
有关更详细的调查，请参阅[5]。
2 Terminology and Protocol Framework
2术语和议定书框架
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 units, encapsulated for transmission over the network. For example, many audio coders operate on 20ms units, which are typically combined to produce 40ms or 80ms packets for transmission. The framework of RTP [18] is assumed. This implies that packets have a sequence number and timestamp. The sequence number denotes the order in which packets are transmitted, and is used to detect losses. The timestamp is used to determine the playout order of units. Most loss recovery schemes rely on units being sent out of order, so an application must use the RTP timestamp to schedule playout.
单位定义为媒体数据的定时间隔，通常从媒体编码器的工作中派生。一个分组包括一个或多个单元，封装用于在网络上传输。例如，许多音频编码器以20ms为单位工作，通常组合起来产生40ms或80ms的数据包进行传输。RTP[18]的框架是假定的。这意味着数据包具有序列号和时间戳。序列号表示数据包的传输顺序，用于检测丢失。时间戳用于确定单元的播放顺序。大多数损失恢复方案依赖于无序发送的单元，因此应用程序必须使用RTP时间戳来安排播放。
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 repair schemes send multiple copies of units, at different times and possibly with different encodings, to increase the probability that a receiver has something to decode. A receiver is assumed to have a `quality' ranking of the differing encodings, and so is capable of choosing the `best' unit for playout, given multiple options.
RTP的使用允许多个不同的媒体编码器，其中有效负载类型字段用于在接收器处区分这些编码器。一些丢失修复方案在不同的时间发送单元的多个副本，可能使用不同的编码，以增加接收器有东西要解码的概率。假定接收机对不同的编码有“质量”排名，因此在给定多个选项的情况下，能够选择“最佳”播放单元。
A session is defined as interactive if the end-to-end delay is less then 250ms, including media coding and decoding, network transit and host buffering.
如果端到端延迟小于250ms，则会话被定义为交互式会话，包括媒体编码和解码、网络传输和主机缓冲。
3 Network Loss Characteristics
3网络损耗特性
If it is desired to repair a media stream subject to packet loss, it is 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 characteristics of the Mbone [2, 8, 21] and although the results vary somewhat, the broad conclusion is clear: in a large conference it is inevitable that some receivers will experience packet loss. Packet traces taken by Handley [8] show a session in which most receivers experience loss in the range 2-5%, with a somewhat smaller number seeing significantly higher loss rates. Other studies have presented broadly similar results.
如果希望修复遭受分组丢失的媒体流，则对可能遇到的丢失特性有一些了解是有用的。已经对Mbone的丢失特性进行了大量研究[2,8,21]，尽管结果有所不同，但总体结论是明确的：在大型会议中，一些接收器不可避免地会经历数据包丢失。Handley[8]所做的数据包跟踪显示，在一个会话中，大多数接收者的丢失率在2-5%之间，少数接收者的丢失率明显较高。其他研究也给出了大致相似的结果。
It has also been shown that the vast majority of losses are of single packets. Burst losses of two or more packets are around an order of magnitude less frequent than single packet loss, although they do occur more often than would be expected from a purely random process. Longer burst losses (of the order of tens of packets) occur infrequently. These results are consistent with a network where small amounts of transient congestion cause the majority of packet loss. In a few cases, a network link is found to be severely
它还表明，绝大多数的损失是单个数据包造成的。两个或多个数据包的突发丢失的频率比单个数据包丢失的频率低约一个数量级，尽管它们发生的频率比纯随机过程预期的要高。较长的突发丢失（几十个数据包的数量级）很少发生。这些结果与少量瞬时拥塞导致大部分数据包丢失的网络一致。在少数情况下，发现网络链路严重损坏
overloaded, and large amount of loss results.
超载，造成大量损失。
The primary focus of a repair scheme must, therefore, be to correct single packet loss, since this is by far the most frequent occurrence. It is desirable that losses of a relatively small number of consecutive packets may also be repaired, since such losses represent a small but noticeable fraction of observed losses. The correction of large bursts of loss is of considerably less importance.
因此，修复方案的主要重点必须是纠正单个数据包丢失，因为这是迄今为止最常见的情况。期望的是，相对较少数量的连续分组的丢失也可以被修复，因为这样的丢失代表观察到的丢失的一小部分，但值得注意。纠正大量损失的重要性要小得多。
4 Loss Mitigation Schemes
4减少损失计划
In the following sections, four loss mitigation schemes are discussed. 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 is briefly described, and its advantages and disadvantages noted.
在以下章节中，将讨论四种损失缓解方案。这些方案在文献中已经讨论过多次，并且发现在许多场景中都有用。简要描述了每种技术，并指出了其优缺点。
Retransmission of lost packets is an obvious means by which loss may be repaired. It is clearly of value in non-interactive applications, with relaxed delay bounds, but the delay imposed means that it does not typically perform well for interactive use.
丢失数据包的重新传输是修复丢失的一种明显方法。在非交互式应用程序中，它显然很有价值，延迟限制比较宽松，但所施加的延迟意味着它在交互式使用中通常表现不好。
In addition to the possibly high latency, there is a potentially large bandwidth overhead to the use of retransmission. Not only are units of data sent multiple times, but additional control traffic must flow to request the retransmission. It has been shown that, in a large Mbone session, most packets are lost by at least one receiver [8]. In this case the overhead of requesting retransmission for most packets may be such that the use of forward error correction is more acceptable. This leads to a natural synergy between the two mechanisms, with a forward error correction scheme being used to repair all single packet losses, and those receivers experiencing burst losses, and willing to accept the additional latency, using 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 [9, 13].
除了可能的高延迟之外，使用重传还可能带来巨大的带宽开销。不仅要多次发送数据单元，还必须有额外的控制流量才能请求重传。已经证明，在大型Mbone会话中，大多数数据包至少被一个接收器丢失[8]。在这种情况下，对于大多数分组请求重传的开销可以使得使用前向纠错更为可接受。这导致了两种机制之间的自然协同作用，使用前向纠错方案修复所有单包丢失，以及那些经历突发丢失并愿意接受额外延迟的接收机，使用基于重传的修复作为额外的恢复机制。类似的机制已经在许多可靠的多播方案中使用，并在文献[9,13]中得到了一些讨论。
In order to reduce the overhead of retransmission, the retransmitted units may be piggy-backed onto the ongoing transmission, using a payload format such as that described in [15]. This also allows for the retransmission to be recoded in a different format, to further reduce the bandwidth overhead. As an alternative, FEC information may be sent in response to retransmission requests [13], allowing a single retransmission to potentially repair several losses. The choice of a retransmission request algorithm which is both timely and
为了减少重传的开销，可以使用如[15]中所述的有效载荷格式，将重传单元背驮到正在进行的传输上。这还允许以不同的格式重新编码重传，以进一步减少带宽开销。作为替代方案，可以发送FEC信息以响应重传请求[13]，从而允许单个重传可能修复多个丢失。选择一种既及时又可靠的重传请求算法
network friendly is an area of current study. An obvious starting point is the SRM protocol [7], and experiments have been conducted using this, and with a low-delay variant, STORM [20]. This work shows the trade-off between latency and quality for retransmission based repair schemes, and illustrates that retransmission is an effective approach to repair for applications which can tolerate the latency.
网络友好是当前研究的一个领域。一个明显的起点是SRM协议[7]，已经使用该协议以及低延迟变量STORM[20]进行了实验。这项工作显示了基于重传的修复方案在延迟和质量之间的权衡，并说明了重传是一种有效的修复方法，适用于能够容忍延迟的应用程序。
There is no standard protocol framework for requesting retransmission of streaming media. An experimental RTP profile extension for SRM-style retransmission requests has described in [14].
没有标准的协议框架来请求流媒体的重新传输。[14]中描述了用于SRM类型重传请求的实验性RTP配置文件扩展。
Forward error correction (FEC) is the means by which repair data is added to a media stream, such that packet loss can be repaired by the receiver of that stream with no further reference to the sender. There are two classes of repair data which may be added to a stream: those which are independent of the contents of the stream, and those which use knowledge of the stream to improve the repair process.
前向纠错（FEC）是将修复数据添加到媒体流的方法，使得该流的接收器可以修复分组丢失，而无需进一步参考发送者。有两类修复数据可以添加到流中：独立于流内容的修复数据，以及使用流知识改进修复过程的修复数据。
A number of media-independent FEC schemes have been proposed for use with streamed media. These techniques add redundant data, which is transmitted in separate packets, to a media stream. Traditionally, FEC techniques are described as loss detecting and/or loss correcting. In the case of streamed media, loss detection is provided by the sequence numbers in RTP packets.
许多与媒体无关的FEC方案已被提出用于流媒体。这些技术将冗余数据添加到媒体流中，这些数据以单独的数据包传输。传统上，FEC技术被描述为丢失检测和/或丢失校正。在流媒体的情况下，通过RTP数据包中的序列号提供丢失检测。
The redundant FEC data is typically calculated using the mathematics of finite fields [1]. The simplest of finite field is GF(2) where addition is just the eXclusive-OR operation. Basic FEC schemes transmit k data packets with n-k parity packets allowing the reconstruction of the original data from any k of the n transmitted packets. Budge et al [4] proposed applying the XOR operation across different combinations of the media data with the redundant data transmitted separately as parity packets. These vary the pattern of packets over which the parity is calculated, and hence have different bandwidth, latency and loss repair characteristics.
冗余FEC数据通常使用有限域的数学计算[1]。最简单的有限域是GF（2），其中加法就是异或运算。基本FEC方案使用n-k奇偶校验分组发送k个数据分组，允许从n个发送分组中的任意k个重构原始数据。Budge等人[4]建议在媒体数据的不同组合上应用异或操作，冗余数据作为奇偶校验包单独传输。这些改变了计算奇偶校验的数据包的模式，因此具有不同的带宽、延迟和丢失修复特性。
Parity-based FEC based techniques have a significant advantage in that they are media independent, and provide exact repair for lost packets. In addition, the processing requirements are relatively light, especially when compared with some media-specific FEC (redundancy) schemes which use very low bandwidth, but high complexity encodings. The disadvantage of parity based FEC is that the codings have higher latency in comparison with the media-specific
基于奇偶校验的FEC技术具有显著的优势，因为它们与媒体无关，并且能够精确地修复丢失的数据包。此外，处理要求相对较低，尤其是与一些使用非常低带宽但高复杂度编码的媒体特定FEC（冗余）方案相比。基于奇偶校验的FEC的缺点是，与特定于媒体的编码相比，编码具有更高的延迟
schemes discussed in following section.
在下一节中讨论的方案。
A number of FEC schemes exist which are based on higher-order finite fields, for example Reed-Solomon (RS) codes, which are more sophisticated and computationally demanding. These are usually structured so that they have good burst loss protection, although this typically comes at the expense of increased latency. Dependent on the observed loss patterns, such codes may give improved performance, compared to parity-based FEC.
存在许多基于高阶有限域的FEC方案，例如Reed-Solomon（RS）码，其更复杂且计算要求更高。它们的结构通常使它们具有良好的突发丢失保护，尽管这通常是以增加延迟为代价的。与基于奇偶校验的FEC相比，依赖于观察到的丢失模式，这样的码可以提供改进的性能。
An RTP payload format for generic FEC, suitable for both parity based and Reed-Solomon encoded FEC is defined in [17].
[17]中定义了通用FEC的RTP有效载荷格式，适用于基于奇偶校验和里德-所罗门编码的FEC。
The basis of media-specific FEC is to employ knowledge of a media compression scheme to achieve more efficient repair of a stream than can otherwise be achieved. To repair a stream subject to packet loss, it is necessary to add redundancy to that stream: some information is added which is not required in the absence of packet loss, but which can be used to recover from that loss.
媒体特定FEC的基础是利用媒体压缩方案的知识来实现比其他方式更有效的流修复。要修复遭受数据包丢失的流，必须向该流添加冗余：添加一些信息，这些信息在没有数据包丢失的情况下是不需要的，但可以用于从该丢失中恢复。
The nature of a media stream affects the means by which the redundancy is added. If units of media data are packets, or if multiple units are included in a packet, it is logical to use the unit as the level of redundancy, and to send duplicate units. By recoding the redundant 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 [2, 10] and has been shown to perform well. An RTP payload format for this form of redundancy has been defined [15].
媒体流的性质会影响添加冗余的方式。如果媒体数据单元是数据包，或者数据包中包含多个单元，则使用该单元作为冗余级别并发送重复单元是合乎逻辑的。通过重新编码单元的冗余副本，可以显著节省带宽，但代价是额外的计算复杂性和近似修复。这种方法被提倡用于流式音频[2,10]，并被证明表现良好。已经定义了这种冗余形式的RTP有效负载格式[15]。
If media units span multiple packets, for instance video, it is sensible to include redundancy directly within the output of a codec. For example the proposed RTP payload for H.263+ [3] includes multiple copies of key portions of the stream, separated to avoid the problems 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.
If media units span multiple packets, for instance video, it is sensible to include redundancy directly within the output of a codec. For example the proposed RTP payload for H.263+ [3] includes multiple copies of key portions of the stream, separated to avoid the problems 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.translate error, please retry
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.
另一种方法是将独立于媒体的FEC技术应用于编解码器输出的最高有效位，而不是将其应用于整个数据包。一些编解码器描述包括使这成为可能的位敏感性。这种方法具有较低的计算成本，并且可以定制为表示传输数据的任意部分。
The use of media-specific FEC has the advantage of low-latency, with only a single-packet delay being added. This makes it suitable for interactive applications, where large end-to-end delays cannot be tolerated. In a uni-directional non-interactive environment it is possible to delay sending the redundant data, achieving improved performance in the presence of burst losses [11], at the expense of additional latency.
使用特定于媒体的FEC具有低延迟的优点，仅添加单个分组延迟。这使得它适用于交互式应用程序，在这些应用程序中无法容忍较大的端到端延迟。在单向非交互环境中，可以延迟发送冗余数据，以牺牲额外延迟为代价，在突发丢失的情况下提高性能[11]。
When the unit size is smaller than the packet size, and end-to-end delay is unimportant, interleaving [16] 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. Note that the size of the gaps is dependent on the degree of interleaving used, and can be made arbitrarily small at the expense of additional latency.
当单元大小小于数据包大小，且端到端延迟不重要时，交织[16]是一种减少丢失影响的有用技术。单元在传输之前被重新排序，以便最初相邻的单元在传输流中被保证的距离分开，并在接收器处返回到它们的原始顺序。交织分散了数据包丢失的影响。例如，如果单位长度为5ms，数据包长度为20ms（即：每个数据包4个单位），则第一个数据包可能包含单位1、5、9、13；第二个包将包含单元2、6、10、14；等等可以看出，来自交织流的单个分组的丢失导致重构流中的多个小间隙，而不是在非交织流中出现的单个大间隙。在许多情况下，重建具有这种丢失模式的流更容易，尽管这显然取决于媒体和编解码器。注意，间隙的大小取决于所使用的交织程度，并且可以以额外延迟为代价使间隙任意小。
The obvious disadvantage of interleaving is that it increases latency. This limits the use of this technique for interactive applications, although it performs well for non-interactive use. The major advantage of interleaving is that it does not increase the bandwidth requirements of a stream.
交织的明显缺点是增加了延迟。这限制了该技术在交互式应用程序中的使用，尽管它在非交互式应用程序中表现良好。交织的主要优点是它不会增加流的带宽要求。
A potential RTP payload format for interleaved data is a simple extension of the redundant audio payload [15]. That payload requires that the 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.
交织数据的潜在RTP有效载荷格式是冗余音频有效载荷的简单扩展[15]。该有效负载要求在主设备之后发送单元的冗余副本。如果取消此限制，则可以使用此有效负载格式发送单元的任意交错。
5 Recommendations
5项建议
If the desired scenario is a non-interactive uni-directional transmission, in the style of a radio or television broadcast, latency is of considerably less importance than reception quality. In this case, the use of interleaving, retransmission based repair or FEC is appropriate. If approximate repair is acceptable, interleaving is clearly to be preferred, since it does not increase
如果所需场景是无线电或电视广播风格的非交互式单向传输，则延迟的重要性远远低于接收质量。在这种情况下，使用交织、基于重传的修复或FEC是合适的。如果近似修复是可接受的，则交错显然是首选，因为它不会增加
the bandwidth of a stream. Media independent FEC is typically the next best option, since a single FEC packet has the potential to repair multiple lost packets, providing efficient transmission.
流的带宽。与媒体无关的FEC通常是次优选择，因为单个FEC数据包有可能修复多个丢失的数据包，从而提供高效传输。
In an interactive session, 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 packet format for a new codec, this is clearly an appropriate technique, and should be encouraged.
在交互式会话中，由于使用交织和重传而施加的延迟是不可接受的，并且低延迟FEC方案是唯一合适的修复方法。独立于媒体和特定于媒体的前向纠错之间的选择不那么明确：特定于媒体的FEC可以更有效，但需要修改编解码器的输出。在为新的编解码器定义数据包格式时，这显然是一种合适的技术，应该予以鼓励。
If an existing codec is to be used, a media independent forward error correction scheme is usually easier to implement, and can perform well. 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, and allowing interactivity for those receivers which desire it. Whilst the addition of FEC 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 when loss is detected 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.
如果要使用现有的编解码器，则与媒体无关的前向纠错方案通常更容易实现，并且性能良好。以这种方式保护的媒体流可以用最小开销的基于重传的修复来增强，为那些愿意容忍额外延迟的接收器提供改进的质量，并允许那些想要它的接收器的交互性。虽然向媒体流添加FEC数据是保护该流免受分组丢失的有效手段，但应用程序设计者应意识到，在检测到丢失时添加大量修复数据将增加网络拥塞，从而导致分组丢失，导致使用纠错编码想要解决的问题恶化。
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 [12, 19]. 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 behavior of a TCP stream, and hence compete fairly with non-real time traffic. This is necessary for stable network behavior in the presence of much streamed media.
在撰写本文时，对于流媒体的拥塞控制问题没有标准解决方案可用于解决此问题。然而，有许多贡献表明了解决方案可能采取的形式[12,19]。这项工作通常在多个信道上使用某种形式的数据分层编码，接收机加入和离开层以响应数据包丢失（这表示拥塞）。此类方案的目的是模拟TCP流的拥塞控制行为，从而与非实时流量公平竞争。这对于存在大量流媒体时的稳定网络行为是必要的。
Since streaming media applications are in use now, without congestion control, it is important to give some advice to authors of those tools as to the behavior which is acceptable, until congestion control mechanisms can be deployed. The remainder of this section uses the throughput of a TCP connection over a link with a given loss rate as an example to indicate behavior which may be classified as reasonable.
由于流媒体应用程序现在正在使用，没有拥塞控制，因此在部署拥塞控制机制之前，向这些工具的作者提供一些关于可接受行为的建议是很重要的。本节的其余部分使用具有给定丢失率的链路上TCP连接的吞吐量作为示例，以指示可归类为合理的行为。
As a number of authors have noted (eg: [6]), the loss rate and throughput of a TCP connection are approximately related as follows:
正如许多作者所指出的（例如：[6]），TCP连接的丢失率和吞吐量大致如下：
T = (s * c) / (RTT * sqrt(p))
T = (s * c) / (RTT * sqrt(p))
where T is the observed throughput in octets per second, s is the packet size in octets, RTT is the round-trip time for the session in seconds, p is the packet loss rate and c is a constant in the range 0.9...1.5 (a value of 1.22 has been suggested [6]). Using this relation, one may determine the packet loss rate which would result in a given throughput for a particular session, if a TCP connection was used.
式中，T是以八位字节/秒为单位的观测吞吐量，s是以八位字节为单位的数据包大小，RTT是以秒为单位的会话往返时间，p是数据包丢失率，c是0.9…1.5范围内的常数（建议值为1.22[6]）。使用此关系，可以确定如果使用TCP连接，将导致特定会话的给定吞吐量的数据包丢失率。
Whilst this relation between packet loss rate and throughput is specific to the TCP congestion control algorithm, it also provides an estimate of the acceptable loss rate for a streaming media application using the same network path, which wishes to coexist fairly with TCP traffic. Clearly this is not sufficient for fair sharing of a link with TCP traffic, since it does not capture the dynamic behavior of the connection, merely the average behavior, but it does provide one definition of "reasonable" behavior in the absence of real congestion control.
虽然丢包率和吞吐量之间的这种关系特定于TCP拥塞控制算法，但它也为使用相同网络路径的流媒体应用程序提供了可接受的丢包率估计值，流媒体应用程序希望与TCP流量公平共存。显然，这对于与TCP流量公平共享链路是不够的，因为它不能捕获连接的动态行为，而仅仅是平均行为，但它确实提供了在缺乏真正拥塞控制的情况下“合理”行为的定义。
For example, an RTP audio session with DVI encoding and 40ms data packets will have 40 bytes RTP/UDP/IP header, 4 bytes codec state and 160 bytes of media data, giving a packet size, s, of 204 bytes. It will send 25 packets per second, giving T = 4800. It is possible to estimate the round-trip time from RTCP reception report statistics (say 200 milliseconds for the purpose of example). Substituting these values into the above equation, we estimate a "reasonable" packet loss rate, p, of 6.7%. This would represent an upper bound on the packet loss rate which this application should be designed to tolerate.
例如，具有DVI编码和40ms数据包的RTP音频会话将具有40字节的RTP/UDP/IP报头、4字节的编解码器状态和160字节的媒体数据，从而给出204字节的数据包大小s。它将每秒发送25个数据包，即T=4800。可以根据RTCP接收报告统计数据（例如，为了示例的目的，200毫秒）估计往返时间。将这些值代入上述等式，我们估计“合理”的分组丢失率p为6.7%。这将代表此应用程序应能容忍的丢包率上限。
It should be noted that a round trip time estimate based on RTCP reception report statistics is, at best, approximate; and that a round trip time for a multicast group can only be an `average' measure. This implies that the TCP equivalent throughput/loss rate determined by this relation will be an approximation of the upper bound to the rate a TCP connection would actually achieve.
应注意，基于RTCP接收报告统计数据的往返时间估计充其量是近似值；多播组的往返时间只能是一个“平均”指标。这意味着由该关系确定的TCP等效吞吐量/丢失率将是TCP连接实际达到的速率上限的近似值。
6 Security Considerations
6安全考虑
Some of the repair techniques discussed in this document result in the transmission of additional traffic to correct for the effects of packet loss. Application designers should be aware that the transmission of large amounts of repair traffic will increase network congestion, and hence packet loss, leading to a worsening of the problem which the use of error correction was intended to solve. At its worst, this can lead to excessive network congestion and may constitute a denial of service attack. Section 5 discusses this in
本文档中讨论的一些修复技术会导致传输额外的流量，以纠正数据包丢失的影响。应用程序设计者应该意识到，大量修复通信量的传输将增加网络拥塞，从而导致数据包丢失，从而导致使用纠错旨在解决的问题恶化。在最坏的情况下，这可能会导致过度的网络拥塞，并可能构成拒绝服务攻击。第5节讨论了这一点
more detail, and provides guidelines for prevention of this problem.
更多详细信息，并提供预防此问题的指南。
7 Summary
7摘要
Streaming media applications using the Internet will be subject to packet loss due to the unreliable nature of UDP packet delivery. This document has summarized the typical loss patterns seen on the public Mbone at the time of writing, and a range of techniques for recovery from such losses. We have further discussed the need for congestion control, and provided some guidelines as to reasonable behavior for streaming applications in the interim until congestion control can be deployed.
由于UDP数据包传输的不可靠性，使用互联网的流媒体应用程序将面临数据包丢失。本文件总结了在撰写本文时在公开Mbone上看到的典型损失模式，以及从此类损失中恢复的一系列技术。我们进一步讨论了拥塞控制的必要性，并提供了一些指导方针，说明在部署拥塞控制之前，流媒体应用程序的合理行为。
8 Acknowledgments
8致谢
The authors wish to thank Phil Karn and Lorenzo Vicisano for their helpful comments.
作者希望感谢Phil Karn和Lorenzo Vicisano的有益评论。
9 Authors' Addresses
9作者地址
Colin Perkins Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom
科林·珀金斯英国伦敦高尔街大学学院计算机科学系伦敦WC1E 6BT
EMail: c.perkins@cs.ucl.ac.uk
EMail: c.perkins@cs.ucl.ac.uk
Orion Hodson Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom
Orion Hodson计算机科学系大学学院伦敦高尔街伦敦WC1E 6BT英国
EMail: o.hodson@cs.ucl.ac.uk
EMail: o.hodson@cs.ucl.ac.uk
References
工具书类
[1] R.E. Blahut. Theory and Practice ofError Control Codes. Addison Wesley, 1983.
[1] R.E.布拉赫特。错误控制代码的理论和实践。艾迪生·韦斯利，1983年。
[2] J.-C. Bolot and A. Vega-Garcia. The case for FEC based error control for packet audio in the Internet. To appear in ACM Multimedia Systems.
[2] J-C.博洛和A.维加加西亚。因特网中基于FEC的分组音频差错控制案例。出现在ACM多媒体系统中。
[3] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload format for the 1998 version of ITU-T reccomendation H.263 video (H.263+). Work in Progress.
[3] C.鲍曼、L.克莱恩、G.戴谢尔、T.加多斯、C.马西奥科、D.纽厄尔、J.奥特、S.温格和C.朱。1998版ITU-T reccomendation H.263视频（H.263+）的RTP有效负载格式。正在进行的工作。
[4] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long. Media-independent error correction using RTP, Work in Progress.
[4] D.Budge、R.McKenzie、W.Mills、W.Diss和P.Long。使用RTP的媒体独立错误更正，正在进行中。
[5] G. Carle and E. W. Biersack. Survey of error recovery techniques for IP-based audio-visual multicast applications. IEEE Network, 11(6):24--36, November/December 1997.
[5] G.Carle和E.W.Biersack。基于IP的视听多播应用的错误恢复技术综述。IEEE网络，11（6）：24-361997年11月/12月。
[6] S. Floyd and K. Fall. Promoting the use of end-to-end congestion control in the internet. Submitted to IEEE/ACM Transactions on Networking, February 1998.
[6] 弗洛伊德和法尔。促进互联网端到端拥塞控制的使用。提交给IEEE/ACM网络交易，1998年2月。
[7] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang. A reliable multicast framework for light-weight sessions and applications level framing. IEEE/ACM Transactions on Networking, 1995.
[7] S.弗洛伊德、V.雅各布森、S.麦卡尼、C-G.刘和L.张。用于轻量级会话和应用程序级帧的可靠多播框架。IEEE/ACM网络事务，1995年。
[8] M. Handley. An examination of Mbone performance. USC/ISI Research Report: ISI/RR-97-450, April 1997.
[8] 汉德利先生。对Mbone性能的检查。USC/ISI研究报告：ISI/RR-97-4501997年4月。
[9] M. Handley and J. Crowcroft. Network text editor (NTE): A scalable shared text editor for the Mbone. In Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[9] 汉德利先生和克劳克罗夫特先生。网络文本编辑器（NTE）：Mbone的可扩展共享文本编辑器。1997年9月，法国戛纳，ACM SIGCOMM'97会议记录。
[10] V. Hardman, M. A. Sasse, M. Handley, and A. Watson. Reliable audio for use over the Internet. In Proceedings of INET'95, 1995.
[10] V.哈德曼、M.A.萨斯、M.汉德利和A.沃森。通过互联网使用的可靠音频。1995年国际内特会议记录。
[11] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft. Redundancy control in real-time Internet audio conferencing. In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.
[11] I.库韦拉斯、O.霍德森、V.哈德曼和J.克劳克罗夫特。实时互联网音频会议中的冗余控制。1997年9月在苏格兰阿伯丁的AVSPN'97诉讼中。
[12] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven layered multicast. In Proceedings ACM SIGCOMM'96, Stanford, CA., August 1996.
[12] S.McCanne、V.Jacobson和M.Vetterli。接收器驱动的分层多播。1996年8月在加利福尼亚州斯坦福市ACM SIGCOMM'96会议记录中。
[13] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based loss recovery for reliable multicast transmission. In Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[13] 诺南马赫、比塞克和托斯利。基于奇偶校验的可靠多播传输丢失恢复。1997年9月，法国戛纳，ACM SIGCOMM'97会议记录。
[14] P. Parnes. RTP extension for scalable reliable multicast, Work in Progress.
[14] 帕恩斯。可扩展可靠多播的RTP扩展，正在进行中。
[15] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J-C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[15] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J-C.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[16] J.L. Ramsey. Realization of optimum interleavers. IEEE Transactions on Information Theory, IT-16:338--345, May 1970.
[16] J.L.拉姆齐。最佳交织器的实现。IEEE信息论学报，IT-16:338--345，1970年5月。
[17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for generic forward error correction in RTP. Work in Progress.
[17] 罗森博格和舒尔兹林内。RTP中用于一般前向纠错的A/V配置文件扩展。正在进行的工作。
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport protocol for real-time applications", RFC 1889, January 1996.
[18] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[19] L. Vicisano, L. Rizzo, and Crowcroft J. TCP-like congestion control for layered multicast data transfer. In Proceedings IEEE INFOCOM'98, 1998.
[19] L.Vicisano，L.Rizzo和Crowcroft J.分层多播数据传输的类TCP拥塞控制。在IEEE INFOCOM'981998年的会议记录中。
[20] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar. Resilient multicast support for continuous media applications. In Proceedingsof the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV'97), Washington University in St. Louis, Missouri, May 1997.
[20] 徐若曦、迈尔斯、张浩和雅瓦卡。对连续媒体应用程序的弹性多播支持。1997年5月，密苏里州圣路易斯华盛顿大学第七届数字音频和视频网络和操作系统支持国际研讨会（NOSSDAV'97）的筹备工作。
[21] M. Yajnik, J. Kurose, and D. Towsley. Packet loss correlation in the Mbone multicast network. In Proceedings IEEE Global Internet Conference, November 1996.
[21] M.Yajnik、J.Kurose和D.Towsley。Mbone多播网络中的丢包相关性。《IEEE全球互联网会议记录》，1996年11月。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。