Network Working Group M. Handley
Request for Comments: 2887 S. Floyd
Category: Informational ACIRI
B. Whetten
Talarian
R. Kermode
Motorola
L. Vicisano
Cisco
M. Luby
Digital Fountain, Inc.
August 2000
Network Working Group M. Handley
Request for Comments: 2887 S. Floyd
Category: Informational ACIRI
B. Whetten
Talarian
R. Kermode
Motorola
L. Vicisano
Cisco
M. Luby
Digital Fountain, Inc.
August 2000
The Reliable Multicast Design Space for Bulk Data Transfer
大容量数据传输的可靠组播设计空间
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions.
可靠多播的设计空间非常丰富，已经设计出许多可能的解决方案。然而，应用程序需求将此设计空间限制在相对较小的解决方案空间内。本文档概述了设计空间以及应用程序约束影响可能解决方案的方式。
The term "general purpose reliable multicast protocol" is something of an oxymoron. Different applications have different requirements of a reliable multicast protocol, and these requirements constrain the design space in ways that two applications with differing requirements often cannot share a single solution. There are however many successful reliable multicast protocol designs that serve more special purpose requirements well.
术语“通用可靠多播协议”是一种矛盾的说法。不同的应用程序对可靠的多播协议有不同的要求，这些要求限制了设计空间，使得具有不同要求的两个应用程序通常无法共享一个解决方案。然而，有许多成功的可靠多播协议设计能够很好地满足更多的特殊用途需求。
In this document we attempt to review the design space for reliable multicast protocols intended for bulk data transfer. The term bulk data transfer should be taken as having broad meaning - the main limitations are that the data stream is continuous and long lived -
在本文中，我们试图回顾用于批量数据传输的可靠多播协议的设计空间。术语“批量数据传输”应被视为具有广泛的含义-主要限制是数据流连续且寿命长-
constraints necessary for the forms of congestion control we currently understand. The purpose of this review is to gather together an overview of the field and to make explicit the constraints imposed by particular mechanisms. The aim is to provide guidance to the standardization process for protocols and protocol building blocks. In doing this, we cluster potential solutions into a number of loose categories - real protocols may be composed of mechanisms from more than one of these clusters.
我们目前所理解的拥塞控制形式的必要约束。本次审查的目的是收集该领域的概况，并明确特定机制施加的限制。目的是为协议和协议构建块的标准化过程提供指导。在这样做的过程中，我们将潜在的解决方案分为若干松散的类别——实际的协议可能由多个集群的机制组成。
The main constraint on solutions is imposed by the need to scale to large receiver sets. For small receiver sets the design space is much less restricted.
解决方案的主要限制是需要扩展到大型接收器集。对于小型接收机组，设计空间的限制要小得多。
Application requirements for reliable multicast (RM) are as broad and varied as the applications themselves. However, there are a set of requirements that significantly affect the design of an RM protocol. A brief list includes:
可靠多播（RM）的应用程序需求与应用程序本身一样广泛和多样。但是，有一组需求会显著影响RM协议的设计。简要清单包括：
o Does the application need to know that everyone received the data?
o 应用程序是否需要知道每个人都收到了数据？
o Does the application need to constrain differences between receivers?
o 应用程序是否需要限制接收器之间的差异？
o Does the application need to scale to large numbers of receivers?
o 应用程序是否需要扩展到大量接收器？
o Does the application need to be totally reliable?
o 应用程序是否需要完全可靠？
o Does the application need ordered data?
o 应用程序是否需要有序数据？
o Does the application need to provide low-delay delivery?
o 应用程序是否需要提供低延迟交付？
o Does the application need to provide time-bounded delivery?
o 应用程序是否需要提供有时间限制的交付？
o Does the application need many interacting senders?
o 应用程序是否需要许多交互发件人？
o Is the application data flow intermittent?
o 应用程序数据流是否间歇性？
o Does the application need to work in the public Internet?
o 应用程序是否需要在公共互联网上工作？
o Does the application need to work without a return path (e.g. satellite)?
o 应用程序是否需要在没有返回路径（如卫星）的情况下工作？
o Does the application need to provide secure delivery?
o 应用程序是否需要提供安全交付？
In the context of standardizing bulk data transfer protocols, we can rule out applications with multiple interacting senders and intermittent data flows. It is not that these applications are unimportant, but that we do not yet have effective congestion control for such applications.
在标准化批量数据传输协议的背景下，我们可以排除具有多个交互发送方和间歇性数据流的应用程序。这并不是说这些应用程序不重要，而是我们还没有对这些应用程序进行有效的拥塞控制。
In many applications a logically defined unit or units of data is to be delivered to multiple clients, e.g., a file or a set of files, a software package, a stock quote or package of stock quotes, an event notification, a set of slides, a frame or block from a video. An application data unit (ADU) is defined to be a logically separable unit of data that is useful to the application. In some cases, an application data unit may be short enough to fit into a single packet (e.g., an event notification or a stock quote), whereas in other cases an application data unit may be much longer than a packet (e.g., a software package).
在许多应用程序中，逻辑定义的一个或多个数据单元将被传送到多个客户端，例如，一个文件或一组文件、软件包、股票报价或股票报价包、事件通知、一组幻灯片、视频中的帧或块。应用程序数据单元（ADU）被定义为对应用程序有用的逻辑上可分离的数据单元。在某些情况下，应用数据单元可能短到足以容纳单个数据包（例如，事件通知或股票报价），而在其他情况下，应用数据单元可能比数据包（例如，软件包）长得多。
A protocol may optionally provide delivery confirmation to ensure reliable delivery, i.e., a mechanism for receivers to inform the sender when data has been delivered. There are two types of confirmation, at the application data unit level and at the packet level. Application data unit confirmation is useful at the application level, e.g., to inform the application about receiver progress and to decide when to stop sending packets about a particular application data unit. Packet confirmation is useful at the transport level, e.g., to inform the transport level when it can release buffer space being used for storing packets for which delivery has been confirmed.
协议可以可选地提供交付确认以确保可靠交付，即，接收方在数据交付时通知发送方的机制。有两种类型的确认，应用程序数据单元级别和数据包级别。应用程序数据单元确认在应用程序级别是有用的，例如，通知应用程序关于接收器的进度，并决定何时停止发送关于特定应用程序数据单元的分组。数据包确认在传输级别是有用的，例如，当传输级别可以释放用于存储已确认发送的数据包的缓冲空间时，通知传输级别。
Some applications have a strong requirement for confirmation that all the receivers got an ADU, or if not, to be informed of which specific receivers failed to receive the entire ADU. Examples include applications where receivers pay for data, and reliable file-system replication. Other applications do not have such a requirement. An example is the distribution of free software.
一些应用强烈要求确认所有接收者都获得了ADU，或者如果没有，则通知哪些特定接收者没有收到整个ADU。示例包括接收方为数据付费的应用程序，以及可靠的文件系统复制。其他应用程序没有这样的要求。自由软件的发行就是一个例子。
If the application does need to know that every receiver got the ADU, then a positive acknowledgment must be received from every receiver, although it may be possible to aggregate these acknowledgments. If the application needs to know precisely which receivers failed to get the ADU, additional constraints are placed on acknowledgment aggregation.
如果应用程序确实需要知道每个接收器都获得了ADU，那么必须从每个接收器接收到肯定的确认，尽管可以聚合这些确认。如果应用程序需要准确地知道哪些接收器未能获得ADU，则会对确认聚合施加额外的约束。
It should be noted that different mechanisms can be used for ADU-level confirmation and packet-level confirmation in the same application. For example, an ADU-level confirmation mechanism using
应该注意的是，在同一应用程序中，不同的机制可用于ADU级确认和数据包级确认。例如，ADU级别的确认机制使用
positive acknowledgments may sit on top of a packet-level NACK or FEC-based transport. Typically this only makes sense when ADUs are significantly larger than a single packet.
肯定确认可以位于基于分组级别NACK或FEC的传输之上。通常，这仅在ADU明显大于单个数据包时才有意义。
Some applications need to constrain differences between receivers so that the data reception characteristics for all receivers falls within some range. An example is a stock price feed, where it is unacceptable for a receiver to suffer delivery that is delayed significantly more than any other receiver.
一些应用需要限制接收机之间的差异，以便所有接收机的数据接收特性都在一定范围内。一个例子是股票价格馈送，在这种情况下，接收者比任何其他接收者遭受的交付延迟都要大得多是不可接受的。
This requirement is difficult to satisfy without harming performance. Typically solutions involve not sending more than a limited amount of new data until positive acknowledgments have been received from all the receivers. Such a solution does not cope with network and end-system failures well.
在不影响性能的情况下，很难满足此要求。通常，解决方案包括在从所有接收器接收到肯定的确认之前，不发送超过有限数量的新数据。这种解决方案不能很好地处理网络和终端系统故障。
There are many applications for RM that do not need to scale to large numbers of receivers. For such applications, a range of solutions may be available that are not available for applications where scaling to large receiver sets is a requirement.
RM有许多应用程序不需要扩展到大量接收器。对于此类应用，可能提供一系列解决方案，但这些解决方案不适用于需要扩展到大型接收器集的应用。
A protocol must achieve good throughput of application data units to receivers. This means that most data that is delivered to receivers is useful in recovering the application data unit that they are trying to receive. A protocol must also provide good congestion control to fairly share the available network resources between all applications. Receiver set scaling is one of the most important constraints in meeting these requirements, because it strictly limits the mechanisms that can be used to achieve these requirements to those that will efficiently scale to a large receiver population. Acknowledgement packets have been employed by many systems to achieve these goals, but it is important to understand the strength and limitations of different ways of using such packets.
协议必须实现应用程序数据单元到接收器的良好吞吐量。这意味着，交付给接收器的大多数数据在恢复他们试图接收的应用程序数据单元时非常有用。协议还必须提供良好的拥塞控制，以便在所有应用程序之间公平地共享可用的网络资源。接收器集缩放是满足这些要求的最重要约束之一，因为它严格限制了可用于实现这些要求的机制，使其能够有效地扩展到大量接收器群体。许多系统都使用确认数据包来实现这些目标，但了解使用这些数据包的不同方法的强度和局限性很重要。
In a very small system, it may be acceptable to have the receivers acknowledge every packet. This approach provides the sender with the maximum amount of information about reception conditions at all the receivers, information that can be used both to achieve good throughput and to achieve congestion control.
在一个非常小的系统中，让接收器确认每个数据包是可以接受的。该方法向发送方提供关于所有接收机的接收条件的最大数量的信息，这些信息可用于实现良好吞吐量和实现拥塞控制。
For larger systems, such "flat ACK" schemes cause acknowledge implosions at the sender. Attempts have been made to reduce this problem by sending aggregate ACKs infrequently [RMWT98, BC94], but it is very difficult to incorporate effective congestion control into such protocols because of the spareceness of feedback.
对于较大的系统，这种“平坦ACK”方案会导致发送方的确认内爆。已经尝试通过不经常发送聚合ack来减少此问题[RMWT98，BC94]，但是由于反馈的稀疏性，很难将有效的拥塞控制纳入此类协议中。
Using negative acknowledgments (NACKs) instead of ACKs reduces this problem to one of NACK implosion (only from the receivers missing the packets), and because the sender really only needs to know that at least one receiver is missing data in order to achieve good throughput, various NACK suppression mechanisms can be applied.
使用否定确认（NACK）代替确认将此问题减少为NACK内爆（仅来自丢失分组的接收器），并且由于发送方实际上只需要知道至少一个接收器丢失数据以实现良好吞吐量，因此可以应用各种NACK抑制机制。
An alternative to NACKs is ACK aggregation, which can be done by arranging the receivers into a logical tree, so that each leaf sends ACKs to its parent which aggregates them, and passes them on up the tree. Tree-based protocols scale well, but tree formation can be problematic.
nack的另一种替代方法是ACK聚合，它可以通过将接收器安排到一个逻辑树中来完成，这样每个叶向其父叶发送ACK，父叶聚合ACK，并向上传递ACK。基于树的协议可以很好地扩展，但树的形成可能会有问题。
Other ACK topologies such as rings are also possible, but are often more difficult to form and maintain than trees are. An alternative strategy is to add mechanisms to routers so that they can help out in achieving good throughput or in reducing the cost of achieving good throughput.
其他ACK拓扑（如环）也是可能的，但通常比树更难形成和维护。另一种策略是向路由器添加机制，以便它们能够帮助实现高吞吐量或降低实现高吞吐量的成本。
All these solutions improve receiver set scaling, but they all have limits of one form or another. One class of solutions scales to an infinite number of receivers by having no feedback channel whatsoever in order to achieve good throughput. These open-loop solutions take the initial data and encode it using an FEC-style mechanism. This encoded data is transmitted in a continuous stream. Receivers then join the session and receive packets until they have sufficient packets to decode the original data, at which point they leave the session.
所有这些解决方案都提高了接收器集的可伸缩性，但它们都有某种形式的限制。一类解决方案通过没有任何反馈通道来扩展到无限多个接收机，以实现良好的吞吐量。这些开环解决方案获取初始数据，并使用FEC风格的机制对其进行编码。该编码数据以连续流的形式传输。然后，接收者加入会话并接收数据包，直到他们有足够的数据包来解码原始数据，此时他们离开会话。
Thus, it is clear that the intended scale of the session constrains the possible solutions. All solutions will work for very small sessions, but as the intended receive set increases, the range of possible solutions that can be deployed safely decreases.
因此，会议的预期规模显然限制了可能的解决办法。所有解决方案都适用于非常小的会话，但随着预期接收集的增加，可以安全部署的可能解决方案的范围会减少。
It should also be noted that hybrids of these mechanisms are possible, and that using one mechanism at the packet-level and a different (typically higher overhead) solution at the ADU level may also scale reasonably if the ADUs are large compared to packets.
还应注意，这些机制的混合是可能的，并且如果ADU与分组相比较大，则在分组级别使用一种机制和在ADU级别使用不同的（通常更高的开销）解决方案也可以合理地扩展。
Many applications require delivery of application data units to be totally reliable; if any of the application data unit is missing, none of the received portion of the application data unit is useful. File transfer applications are a good example of applications requiring total reliability.
许多应用程序要求应用程序数据单元的交付完全可靠；如果缺少应用数据单元中的任何一个，则应用数据单元的接收部分中没有一个是有用的。文件传输应用程序是需要完全可靠性的应用程序的一个很好的例子。
However, some applications do not need total reliability. An example is audio broadcasting, where missing packets reduce the quality of the received audio but do not render it unusable. Such applications can sometimes get by without any additional reliability over native IP reliability, but often having a semi-reliable multicast protocol is desirable.
然而，有些应用不需要完全的可靠性。音频广播就是一个例子，丢失的数据包会降低所接收音频的质量，但不会使其无法使用。这样的应用程序有时可以在没有任何额外的本地IP可靠性的情况下运行，但通常需要一个半可靠的多播协议。
Many applications just require data to be delivered to the receivers as fast as possible. They have no absolute deadline for delivery.
许多应用程序只要求数据尽可能快地传送到接收器。他们没有绝对的交货期限。
However, some applications have hard delivery constraints - if the data does not arrive at the receiver by a certain time, there is no point in delivering it at all. Such time-boundedness may be as a result of real-time constraints such as with audio or video streaming, or as the result of new data superseding old data. In both cases, the requirement is for the application to have a greater degree of control over precisely what the application sends at which time than might be required with applications such as file transfer.
但是，有些应用程序有硬传输限制-如果数据在某个时间没有到达接收器，那么传输它就毫无意义。这种时间有界性可能是实时约束的结果，例如音频或视频流，或者是新数据取代旧数据的结果。在这两种情况下，要求应用程序比文件传输等应用程序更精确地控制应用程序在何时发送的内容。
Time-bounded delivery usually also implies a semi-reliable protocol, but the converse does not necessarily hold.
有时间限制的交付通常也意味着一个半可靠的协议，但反之不一定成立。
The properties of the network in which the application is being deployed may themselves constrain the reliable multicast design space.
部署应用程序的网络的属性本身可能会限制可靠的多播设计空间。
In principle the Internet and intranets are the same. In practice however, the fact that an intranet is under one administration might allow for solutions to be configured that can not easily be done in the public Internet. Thus, if the data is of very high value, it might be appropriate to enhance the routers to provide assistance to a reliable multicast transport protocol. In the public Internet, it is less likely that the additional expense required to support this state in the routers would be acceptable.
互联网和内部网原则上是相同的。然而，在实践中，内联网由一个管理机构管理这一事实可能允许配置解决方案，而这些解决方案在公共互联网上很难实现。因此，如果数据具有非常高的价值，则可能适合增强路由器以向可靠的多播传输协议提供帮助。在公共互联网中，路由器支持这种状态所需的额外费用不太可能被接受。
In principle, when feedback is required from receivers, this feedback can be multicast or unicast. Multicast feedback has advantages, especially in NACK-based protocols where it is valuable for NACK suppression. However, it is not clear at this time whether all ISPs will allow all members of a session to send to that session. If multicast feedback is not allowed, then unicast feedback can almost always be substituted, although often at the expense of additional messages and mechanisms.
原则上，当需要来自接收器的反馈时，该反馈可以是多播或单播。多播反馈具有优势，特别是在基于NACK的协议中，它对NACK抑制非常有用。但是，目前还不清楚是否所有ISP都允许某个会话的所有成员发送到该会话。如果不允许多播反馈，那么几乎总是可以替换单播反馈，尽管通常会以牺牲额外的消息和机制为代价。
Some networks may not allow any form of feedback however. The primary example of this occurs with satellite broadcasts where the back channel may be very narrow or even non-existent. For such networks the solution space is very constrained - only FEC-based encodings have any real chance of working. If the receivers are direct satellite receivers, then no congestion control is needed, but it is dangerous to make such assumptions because it is possible for a satellite hop to feed downstream networks. Thus, congestion control still needs to be considered with solutions that do not have a return path.
然而，有些网络可能不允许任何形式的反馈。这方面的主要例子发生在卫星广播中，其中后频道可能非常窄，甚至不存在。对于这样的网络，解决方案空间非常有限——只有基于FEC的编码才有真正的工作机会。如果接收机是直接卫星接收机，则不需要拥塞控制，但做出这种假设是危险的，因为卫星跳有可能向下游网络馈电。因此，拥塞控制仍然需要考虑没有返回路径的解决方案。
A reliable multicast protocol must involve mechanisms running in end hosts, and must involve routers forwarding multicast packets. However under some circumstances, it is possible to rely on some additional degree of assistance from network elements. Broadly speaking we can cluster RM protocols into four classes depending on the degree of support received from other network elements.
可靠的多播协议必须包含在终端主机中运行的机制，并且必须包含转发多播数据包的路由器。然而，在某些情况下，可以依赖网络要素提供的某种程度的额外协助。广义地说，我们可以根据从其他网络元素获得的支持程度将RM协议分为四类。
No Additional Support The routers merely forward packets, and only the sender and receivers have any reliable multicast protocol state.
没有额外的支持路由器只转发数据包，只有发送方和接收方具有可靠的多播协议状态。
Layered Approaches Data is split across multiple multicast groups. Receivers join appropriate groups to receive only the traffic they require. This may in some cases require fast join or leave functionality from the routers, and may require more forwarding state in the routers.
分层方法将数据分割到多个多播组中。接收者加入适当的组，只接收他们需要的流量。在某些情况下，这可能需要路由器的快速加入或离开功能，并且可能需要路由器中的更多转发状态。
Server-based Approaches Additional nodes are used to assist with data delivery or feedback aggregation. These additional nodes might not be normal senders or receivers, and may be present on the distribution or feedback tree only to provide assistance to the reliable multicast protocol. They would not otherwise receive the multicast traffic.
基于服务器的方法使用其他节点来协助数据交付或反馈聚合。这些附加节点可能不是正常的发送方或接收方，并且可能出现在分发树或反馈树上，只是为了向可靠的多播协议提供帮助。否则，它们将不会接收多播通信。
Router-based Approaches With router-based approaches, routers on the normal data distribution tree from the sender to the receivers assist in the delivery of data or feedback aggregation or suppression. As routers can directly influence multicast routing, they have more control over which traffic goes to which group members than server-based approaches. However routers do not normally have a large amount of spare memory or processing power, which restricts how much functionality can be placed in the routers. In addition, router code is normally more difficult to upgrade than application code, so router-based approaches need to be very general as they are more difficult to deploy and to change.
基于路由器的方法基于路由器的方法，正常数据分布树上从发送方到接收方的路由器有助于数据传递或反馈聚合或抑制。由于路由器可以直接影响多播路由，因此它们比基于服务器的方法更能控制哪些流量流向哪些组成员。然而，路由器通常没有大量的备用内存或处理能力，这限制了路由器中可以放置多少功能。此外，路由器代码通常比应用程序代码更难升级，因此基于路由器的方法需要非常通用，因为它们更难部署和更改。
Two main concerns that a RM protocol must address are congestion control and good throughput. Packet loss plays a major role with respect to both concerns. The primary symptom of congestion in many networks is packet loss. The primary obstacle that must be overcome to achieve good throughput is packet loss. Thus, measuring and reacting to packet loss is crucial to address both concerns. RM solutions that address these concerns can be roughly categorized as using one or more of the following techniques:
RM协议必须解决的两个主要问题是拥塞控制和良好的吞吐量。数据包丢失在这两方面都起着重要作用。在许多网络中，拥塞的主要症状是数据包丢失。要获得良好的吞吐量，必须克服的主要障碍是数据包丢失。因此，测量和应对数据包丢失对于解决这两个问题至关重要。解决这些问题的RM解决方案大致可分为使用以下一种或多种技术：
o Data packet acknowledgment.
o 数据包确认。
o Negative acknowledgment of missing data packets.
o 丢失数据包的否定确认。
o Redundancy allowing not all packets to be received.
o 冗余，不允许接收所有数据包。
These techniques themselves can be usefully subdivided, so that we can examine the parts of the requirement space in which each mechanism can be deployed. In this section, we focus on using these mechanisms for achieving good throughput, and in the next section we focus on using these mechanisms for congestion control.
这些技术本身可以有效地细分，这样我们就可以检查需求空间中可以部署每个机制的部分。在本节中，我们将重点介绍如何使用这些机制实现良好的吞吐量，在下一节中，我们将重点介绍如何使用这些机制实现拥塞控制。
The simplest ACK-based mechanism involves every receiver sending an ACK packet for every data packet it receives and resending packets that are lost by any receiver. Such mechanisms are limited to very small receiver groups by the implosion of ACKs received at the sender, and for this reason they are impractical for most applications.
最简单的基于ACK的机制涉及每个接收器为其接收的每个数据包发送ACK包，并重新发送任何接收器丢失的包。由于发送方接收到的ack的内爆，这种机制仅限于非常小的接收方组，因此对于大多数应用来说是不切实际的。
Putting multiple ACKs into a single data packet [RMWT98] reduces the implosion problem by a constant amount, allowing slightly larger receiver groups. However a limit is soon reached whereby feedback to the sender is too infrequent for sender-based congestion control mechanisms to work reliably.
将多个ack放入一个数据包[RMWT98]中可将内爆问题减少恒定量，从而允许稍微大一点的接收器组。然而，很快就会达到一个极限，即对发送方的反馈太少，基于发送方的拥塞控制机制无法可靠地工作。
Arranging the receivers into a ring [WKM94] whereby an "ACK-token" is passed around the ring prevents the implosion problem for data. However ring creation and maintenance may itself be problematic. Also if ring creation does not take into account network topology (something which is difficult to achieve in practice), then the number of ACK packets crossing the network backbone for each data packet sent may increase O(n) with the number of receivers.
将接收器安排在一个环中[WKM94]，从而在环周围传递“ACK令牌”，防止数据内爆问题。但是，环的创建和维护本身可能存在问题。此外，如果环的创建没有考虑网络拓扑（这在实践中很难实现），则对于每个发送的数据分组，穿过网络主干的ACK分组的数量可能会随着接收机的数量增加O（n）。
Arranging the receivers into a tree [MWB+98, KCW98] whereby receivers generate ACKs to a parent node, which aggregates those ACKs to its parent in turn, is both more robust and more easily configured than a ring. The ACK-tree is typically only used for ACK-aggregation - data packets are multicast from the sender to the receivers as normal. Trees are easier to construct than rings because more local information can be used in their construction. Also they can be more fault tolerant than rings because node failures only affect a subset of receivers, each of which can easily and locally decide to by-pass its parent and report directly to the node one level higher in the tree. With good ACK-tree formation, tree-based ACK mechanisms have the potential to be one of the most scalable RM solutions.
将接收机排列到树[MWB+98，KCW98]中，由此接收机生成到父节点的ack，父节点依次将这些ack聚合到其父节点，这比环更健壮且更容易配置。ACK树通常仅用于ACK聚合-数据包通常是从发送方到接收方的多播。树比环更容易构造，因为在构造树时可以使用更多的局部信息。此外，它们可以比环更具容错性，因为节点故障只影响接收器的子集，每个接收器可以轻松地本地决定绕过其父节点，并直接向树中更高级别的节点报告。通过良好的ACK树结构，基于树的ACK机制有可能成为最具可扩展性的RM解决方案之一。
To be simple to deploy, tree-based protocols must be self-organizing - the receivers must form the tree themselves using local information in a scalable manner. Such mechanisms are possible, but are not trivial. The main scaling limitations of tree-based protocols therefore come from the tree formation and maintenance mechanisms rather than from the use of ACKs. Without such a scalable and automatic tree-formation mechanism, tree-based protocols must rely on manual configuration, which significantly limits their applicability (often to intranets) and (due to the complexity of configuration) their scalability.
为了便于部署，基于树的协议必须是自组织的——接收方必须以可伸缩的方式使用本地信息自己形成树。这种机制是可能的，但并非微不足道。因此，基于树的协议的主要扩展限制来自树的形成和维护机制，而不是来自ACK的使用。如果没有这种可伸缩的自动树形成机制，基于树的协议必须依赖于手动配置，这大大限制了它们的适用性（通常是内部网）和可伸缩性（由于配置的复杂性）。
Orthogonal to the issue of tree formation is the issue of subtree retransmission. With appropriate router mechanisms, or the use of multiple multicast groups, it is possible to allow the intermediate tree nodes to retransmit missing data to the nodes below them in the tree rather than relying on the original sender to retransmit the data. This relies on there being a good correlation at the point of the intermediate node between the ACK tree and the actual data tree, as well as there being a mechanism to constrain the retransmission to
与树形成问题正交的是子树重传问题。通过适当的路由器机制，或者使用多个多播组，可以允许中间树节点将丢失的数据重新传输到树中它们下面的节点，而不是依赖原始发送方来重新传输数据。这依赖于在ACK树和实际数据树之间的中间节点的点处存在良好的相关性，并且存在将重传约束到数据树的机制
the subtree. A good automatic tree formation mechanism combined with the use of administrative scoped multicast groups might provide such a solution. Without such tree formation mechanisms, subtree retransmission is difficult to deploy in large groups in the public internet. This could also be solved by the use of transport-level router mechanisms to assist or perform retransmission, although existing router mechanisms [FLST98] support NACK-based rather than ACK-based protocols.
子树。一个好的自动树形成机制结合使用管理范围的多播组可能会提供这样的解决方案。如果没有这种树形成机制，子树重传很难在公共互联网上大规模部署。这也可以通过使用传输级路由器机制来帮助或执行重传来解决，尽管现有的路由器机制[FLST98]支持基于NACK而不是基于ACK的协议。
Another important issue is the nature of the aggregation performed at interior nodes on the ACK-tree. Such nodes could:
另一个重要问题是在ACK树的内部节点上执行的聚合的性质。这些节点可以：
1. aggregate ACKs by sending a single ACK when all their children have ACKed,
1. 当所有子代都已确认时，通过发送单个确认来聚合确认，
2. aggregate ACKs by listing all the children that have ACKed,
2. 通过列出所有已确认的子项来聚合确认，
3. send an aggregated ACK with a NACK-like exception list.
3. 发送带有NACK类异常列表的聚合ACK。
For data packets, 1. is clearly more scalable, and should be preferred. However if the sender needs to know exactly which receivers received the data, 2. and 3. provide this information. Fortunately, there is usually no need to do this on a per-packet basis, but rather on a per-ADU basis. Doing 1. on a per packet basis, and 3. on a per ADU basis is the most scalable solution for applications that need this information, and suffers virtually no disadvantage compared to the other solutions used on a per-packet basis.
对于数据包，1。显然更具可扩展性，应该是首选。但是，如果发送方需要确切地知道哪些接收方收到了数据，2。三,。请提供此信息。幸运的是，通常不需要在每个数据包的基础上这样做，而是在每个ADU的基础上这样做。做1。以每包为基础，以及3。对于需要此信息的应用程序，基于每个ADU的解决方案是最具可扩展性的解决方案，与基于每个数据包的其他解决方案相比，它几乎没有缺点。
Instead of sending an ACK for every data packet received, receivers can send a negative acknowledgment (NACK) for every data packet they discover they did not receive. This has a number of advantages over ACK-based mechanisms:
接收器可以为发现未接收到的每个数据包发送否定确认（NACK），而不是为接收到的每个数据包发送ACK。与基于ACK的机制相比，这有许多优点：
o The sender no longer needs to know exactly how many receivers there are. This removes the topology-building phase needed for ring- or tree-style ACK-based algorithms.
o 发送者不再需要确切知道有多少接收者。这消除了基于环形或树型ACK算法所需的拓扑构建阶段。
o Fault-tolerance is made somewhat simpler by making receivers responsible for reliability.
o 通过使接收器对可靠性负责，容错变得更加简单。
o Sender state can be significantly reduced because the sender does not need to keep track of the receivers state.
o 发送方状态可以显著减少，因为发送方不需要跟踪接收方状态。
o Only a single NACK is needed from any receiver to indicate a packet that is missing by any number of receivers. Thus NACK suppression is possible.
o 任何接收器只需要一个NACK来指示任何数量的接收器丢失的数据包。因此，NACK抑制是可能的。
The disadvantages are that it is more difficult for the sender to know that it can free transmission buffers, and that additional session level mechanisms are needed if the sender really needs to know if a particular receiver actually received all the data. However for many applications, neither of these is an issue.
缺点是，发送方更难知道它可以释放传输缓冲区，并且如果发送方确实需要知道特定接收方是否实际接收到所有数据，则需要额外的会话级机制。然而，对于许多应用程序来说，这两个都不是问题。
The key differences between NACK-based protocols is in how NACK-suppression is performed. The goal is for only one NACK to reach the sender (or a node that can resend the missing data) as soon as possible after the loss is first noticed, and for only one copy of the missing data to be received by those nodes needing retransmission.
基于NACK的协议之间的关键区别在于如何执行NACK抑制。目标是在第一次注意到丢失后，只有一个NACK尽快到达发送方（或可以重新发送丢失数据的节点），并且需要重新传输的节点只接收丢失数据的一个副本。
Different mechanisms come close to satisfying these goals in different ways.
不同的机制以不同的方式接近于实现这些目标。
o SRM [FJM95] uses random timers weighted by the round trip time between the sender and each node missing the data. This is effective, but requires computing the RTT to each receiver before suppression works properly.
o SRM[FJM95]使用随机计时器，该计时器由发送方和缺少数据的每个节点之间的往返时间加权。这是有效的，但需要在抑制正常工作之前计算每个接收机的RTT。
o NTE [HC97] uses a sender-triggered mechanism based on random keys and sliding masks. This does not require random timers, and works for very large sessions, but makes it difficult to provide the constant low-level stream of feedback needed to perform congestion control.
o NTE[HC97]使用基于随机键和滑动掩码的发送方触发机制。这不需要随机计时器，并且适用于非常大的会话，但很难提供执行拥塞控制所需的恒定低级别反馈流。
o AAP [Ha99] uses exponentially distributed random timers and is effective for large sessions without needing to compute the RTT to each receiver.
o AAP[Ha99]使用指数分布的随机计时器，对于大型会话有效，无需计算每个接收器的RTT。
o PGM [FLST98] and LMS [PPV98] use additional mechanisms in routers to suppress duplicate NACKs. In the case of PGM, router assistance suppliments SRM-stype random timers and localizes the suppression so that the whole group does not need suppressing.
o PGM[FLST98]和LMS[PPV98]在路由器中使用额外的机制来抑制重复的NACK。在PGM的情况下，路由器辅助支持SRM stype随机定时器，并将抑制本地化，以便整个组不需要抑制。
The most general of these mechanisms is probably exponentially weighted random timers. Although SRM style timers can reduce feedback delay, they are harder to use correctly in situations where all the RTTs are not known, or where the number of respondees is
这些机制中最普遍的可能是指数加权随机定时器。虽然SRM类型的计时器可以减少反馈延迟，但在所有RTT未知或响应者数量不确定的情况下，它们很难正确使用
unknown. In contrast, exponentially weighted random timers work well across a large range of session sizes with good worst case delay characteristics.
未知的相反，指数加权随机计时器在会话大小的大范围内工作良好，具有良好的最坏情况延迟特性。
Either form of random timer based mechanism can be supplemented by router-support where it is available. Sender triggered NACK mechanisms (e.g. [HC97]) are more difficult to integrate with router-based support mechanisms.
任何一种基于随机定时器的机制都可以在路由器支持的情况下得到补充。发送方触发的NACK机制（例如[HC97]）更难与基于路由器的支持机制集成。
Some RM protocols can be designed so as to not need explicit reliability mechanisms except in comparatively rare cases. An example is in a multicast game, where the position of a moving object is continuously multicast. This positional stream does not require additional reliability because a new position superseding the old one will be sent before any retransmission could take place. However, when the moving object interacts with other objects or stops moving, then an explicit reliability mechanism is required to reliably send the interaction information or last position.
一些RM协议可以设计为不需要显式的可靠性机制，除非在相对罕见的情况下。例如，在多播游戏中，移动对象的位置是连续多播的。此位置流不需要额外的可靠性，因为将在任何重传发生之前发送取代旧位置的新位置。然而，当移动对象与其他对象交互或停止移动时，则需要显式的可靠性机制来可靠地发送交互信息或最后位置。
It is not just games that can be built in this manner - the NTE shared text editor[HC97] uses just such a mechanism with changes to a line of text. For every change the whole line is sent, and so long as the user keeps typing no explicit reliability mechanism is needed. The major advantage of replication is that it is not susceptible to spatially uncorrelated packet loss. With a traditional ACK or NACK based protocol, the probability of any particular packet being received by all the receivers in a large group can be very low. This leads to high retransmission rates. In contrast, replicated streams do not suffer as the size of the receiver group increases - different receivers lose different packets, but this does not increase network traffic.
以这种方式构建的不仅仅是游戏，NTE共享文本编辑器[HC97]使用的就是这样一种机制，可以对一行文本进行更改。对于每一次更改，都会发送整行内容，只要用户继续键入，就不需要显式的可靠性机制。复制的主要优点是它不易受到空间上不相关的数据包丢失的影响。使用传统的基于ACK或NACK的协议，任何特定分组被大组中的所有接收机接收的概率可能非常低。这会导致高重传率。相反，复制流不会随着接收器组大小的增加而受到影响-不同的接收器丢失不同的数据包，但这不会增加网络流量。
Forward Error Correction (FEC) is a well known technique for protecting data against corruption. For reliable multicast it is most useful in the form of erasure codes.
前向纠错（FEC）是一种保护数据免受损坏的众所周知的技术。对于可靠的多播，它以擦除码的形式最为有用。
The simplest form of packet-level FEC is to take a group of packets that is to be sent, and to XOR the packets together to form a newpacket which is also sent. If there were three original packets plus the XOR packet sent, then if a receiver is missing any one of the original data packets, but receives the XOR packet, then it can reproduce the missing original packet.
数据包级FEC的最简单形式是获取一组要发送的数据包，并将这些数据包异或在一起以形成一个也要发送的新数据包。如果有三个原始数据包加上发送的XOR数据包，那么如果接收器丢失了原始数据包中的任何一个，但收到了XOR数据包，那么它可以复制丢失的原始数据包。
More general erasure codes exist [BKKKLZ95], [Ri97], [LMSSS97] that allow the generation of n encoding packets from k original data packets. In such cases, so long as at least k of the n encoding packets are received, then the k original data packets can be reproduced.
存在更通用的擦除码[BKKLZ95]、[Ri97]、[LMSSS97]，它们允许从k个原始数据包生成n个编码包。在这种情况下，只要接收到n个编码分组中的至少k个，则可以再现k个原始数据分组。
To apply FEC the sender groups data packets into rounds, and encoding packets are produced based on all the data packets in a round. A round may consist of all data packets in an entire application data unit in some cases, whereas in other cases it may consist of a group of data packets that make up only a small portion of an application data unit.
为了应用FEC，发送方将数据包分组成轮，并基于一轮中的所有数据包生成编码包。在某些情况下，一轮可能由整个应用程序数据单元中的所有数据包组成，而在其他情况下，它可能由仅构成应用程序数据单元一小部分的一组数据包组成。
Using erasure codes to repair packet loss is a significant improvement over simple retransmission because the dependency on which packets have been lost is removed. Thus, the amount of repair traffic required to repair spatially uncorrelated packet loss is considerably lessened.
使用擦除码修复数据包丢失是对简单重传的一个重大改进，因为数据包丢失的依赖性被消除。因此，修复空间上不相关的分组丢失所需的修复通信量大大减少。
We can divide packet-level FEC schemes into two categories: proactive FEC and reactive FEC. The difference between the two is that for proactive FEC the sender decides a priori how many encoding packets to send for each round of data packets, whereas for reactive FEC the sender initially transmits only the original data packets for each round. Then, the sender uses feedback from the receivers to compute how many packets were lost by the receiver that experienced the most loss in each round, and then only that number of additional encoding packets are sent for that round. These encoding packets will then also serve to repair loss at the other receivers that are missing fewer packets. The receivers report via ACKs or NACKs how many packets are missing from each round. With NACKs, only the receiver missing the most packets need send a NACK for this round, so this is used to weight the random timers in the NACK calculation.
我们可以将分组级FEC方案分为两类：主动FEC和反应FEC。两者之间的区别在于，对于主动FEC，发送方预先决定每一轮数据包要发送多少编码包，而对于反应FEC，发送方最初只发送每一轮的原始数据包。然后，发送方使用来自接收方的反馈来计算在每一轮中丢失最多的接收方丢失了多少数据包，然后仅为该轮发送该数量的额外编码数据包。然后，这些编码分组还将用于修复丢失较少分组的其他接收机的丢失。接收者通过ACK或NACK报告每轮丢失多少数据包。对于NACK，只有丢失最多数据包的接收器才需要为这一轮发送NACK，因此这用于在NACK计算中对随机计时器进行加权。
Proactive and reactive FEC can be combined, e.g., a certain amount of proactive FEC can be sent for each round and if there are receivers that experience more loss than can be overcome by this for some rounds then they can request and receive additional encoding packets for these rounds.
主动式和反应式FEC可以组合，例如，可以为每轮发送一定数量的主动式FEC，并且如果有接收机在某些轮中遭受的损失超过了可以克服的损失，则他们可以为这些轮请求和接收额外的编码包。
FEC is very effective at reducing the repair traffic for packet loss. However, it requires that the data to be sent to be grouped into rounds, which can add to end-to-end latency. For bulk-data applications this is typically not a problem, but this may be an issue for interactive applications where replication may be a better solution.
FEC在减少丢包修复流量方面非常有效。但是，它要求将要发送的数据分组为多轮，这会增加端到端延迟。对于大容量数据应用程序，这通常不是问题，但对于交互式应用程序来说，这可能是一个问题，因为复制可能是更好的解决方案。
An alternative use of packet level FEC is possible when data is spread across several multicast groups [RVC98], [BLMR98]. In such cases, the original k data packets are used to generate n encoding packets, where n is much larger than k. The n encoded packets are then striped across multiple multicast groups. When a receiver wishes to receive the original data it joins one or more of the multicast groups, and receives the encoding packets. Once it has received k different encoding packets, the receiver can then leave all the multicast groups and reconstruct the original data.
当数据分布在多个多播组[RVC98]、[BLMR98]时，分组级FEC的替代使用是可能的。在这种情况下，原始k个数据分组用于生成n个编码分组，其中n远大于k。然后，n个编码的数据包被分条到多个多播组。当接收器希望接收原始数据时，它加入一个或多个多播组，并接收编码分组。一旦接收到k个不同的编码数据包，接收器就可以离开所有多播组并重建原始数据。
The primary importance of such a layering is that it allows different receivers to be able to receive the traffic at different rates according to the available capacity. Such schemes do not require any form of feedback from the receivers to the sender to ensure good throughput, and therefore the need for good throughput does not constrain the size of the receiver set. However, to perform adequate network congestion control using receiver joins and leaves in this manner may require coordination between members that are behind the same congested link from the sender. As described in the next section, [RVC98] suggests such a layered congestion control scheme.
这种分层的主要重要性在于，它允许不同的接收器能够根据可用容量以不同的速率接收流量。这样的方案不需要从接收机到发送方的任何形式的反馈来确保良好的吞吐量，因此对良好吞吐量的需求并不限制接收机集的大小。然而，要以这种方式使用接收方加入和离开来执行充分的网络拥塞控制，可能需要在来自发送方的同一拥塞链路后面的成员之间进行协调。如下一节所述，[RVC98]建议采用这种分层拥塞控制方案。
The basic delivery model of the Internet is best-effort service. No guarantees are given as to throughput, delay or packet loss. End-systems are expected to be adaptive, and to reduce their transmission rate to a level appropriate for the congestion state of the network. Although increasingly the Internet will start to support reserved bandwidth and differentiated service classes for specialist applications, unless an end-system knows explicitly that it has reserved bandwidth, it must still perform congestion control.
互联网的基本交付模式是尽力而为的服务。不保证吞吐量、延迟或数据包丢失。终端系统应具有自适应性，并将其传输速率降低到适合网络拥塞状态的水平。尽管互联网将越来越多地开始支持专用应用的保留带宽和差异化服务类别，但除非终端系统明确知道它有保留带宽，否则它仍必须执行拥塞控制。
Broadly speaking, there are five classes of single-sender multicast congestion control solution:
概括地说，有五类单发送方多播拥塞控制解决方案：
o Sender-controlled, one group.
o 发送者控制，一组。
A single multicast group is used for data distribution. Feedback from the group members is used to control the rate of this group. The goal is to transmit at a rate dictated by the slowest receiver.
单个多播组用于数据分发。来自组成员的反馈用于控制此组的速率。目标是以最慢的接收器指定的速率进行传输。
o Sender-controlled, multiple groups.
o 发件人控制的多个组。
One initial multicast group is adaptively subdivided into multiple subgroups with subdivisions centered on congestion points in the network. Application-level relays buffer data from a group nearer the original sender, and retransmit it at a slower rate into a group further from the original sender. In this way, different receivers can receiver the data at different rates. Sender-based congestion control takes place between the members of a subgroup and their relay.
一个初始多播组自适应地细分为多个子组，子组以网络中的拥塞点为中心。应用程序级中继来自更靠近原始发送方的组的缓冲区数据，并以较慢的速率将其重新传输到距离原始发送方更远的组中。这样，不同的接收器可以以不同的速率接收数据。基于发送方的拥塞控制发生在子组成员及其中继之间。
o Receiver-controlled, one group.
o 受试者控制，一组。
A single multicast group is used for data distribution. The receivers determine if the sender is transmitting too rapidly for the current congestion state of the network, and they leave the group if this is the case.
单个多播组用于数据分发。接收方确定发送方在网络当前拥塞状态下的传输速度是否过快，如果是这种情况，则离开组。
o Receiver-controlled, layered organization.
o 接收器控制，分层组织。
A layered approach for how to combine this scheme with a congestion control protocol that requires no receiver feedback is described in [RVC98]. The sender stripes data across multiple multicast groups simultaneously. Receivers join and leave these layered groups depending on their measurements of the congestion state of the network, so that the amount of data being received is always appropriate. However, this scheme relies on receivers to join and leave the different multicast groups in a coordinated fashion behind a bottleneck link, and it has not yet been completely confirmed that this approach will scale in practice to the Internet. As a result, more work on this congestion control mechanism would be beneficial.
[RVC98]中描述了如何将该方案与无需接收器反馈的拥塞控制协议相结合的分层方法。发送方同时跨多播组对数据进行分条。接收器根据其对网络拥塞状态的测量加入和离开这些分层组，因此接收的数据量总是合适的。然而，该方案依赖于接收者在瓶颈链路后以协调的方式加入和离开不同的多播组，并且尚未完全证实该方法在实践中能够扩展到Internet。因此，对这种拥塞控制机制进行更多的研究将是有益的。
o Router-based congestion control.
o 基于路由器的拥塞控制。
It is possible to add additional mechanisms to multicast routers to assist in multicast congestion control. Such mechanisms could include:
可以向多播路由器添加额外的机制以协助多播拥塞控制。这些机制可包括：
o Conditional joins (a multicast join that specifies a loss rate above which it is acceptable for the router to reject the join).
o 条件连接（一种多播连接，指定丢失率，超过该丢失率路由器可以拒绝连接）。
o Router filtering of traffic that exceeds a reasonable rate. This may include mechanisms for filtering traffic at different points in the network at different rates depending on local congestion conditions [LVS99].
o 路由器过滤超过合理速率的流量。这可能包括用于根据本地拥塞情况以不同速率过滤网络中不同点处的流量的机制[LVS99]。
o Fair queuing schemes combined with end-to-end adaptation.
o 结合端到端自适应的公平排队方案。
Router-based schemes generally require more state in network routers than has traditionally been acceptable for backbone routers. Thus, in the near-term, such schemes are only likely to be applicable for intranet solutions.
基于路由器的方案通常需要更多的网络路由器状态，而不是传统上主干路由器所能接受的状态。因此，在短期内，此类方案可能只适用于内部网解决方案。
For reliable multicast protocols, it is important to consider congestion control at the same time as reliability is being considered. The same mechanisms that are used to provide reliability will sometimes be used to provide congestion control.
对于可靠的多播协议，重要的是考虑拥塞控制同时考虑到可靠性。用于提供可靠性的机制有时也用于提供拥塞控制。
In the case of receiver-based congestion control, open-loop delivery using FEC is the likely choice for achieving good throughput for bulk- data transfer. This is because open-loop delivery requires no feedback from receivers, and thus it is a perfect match with a receiver-based congestion-control mechanism that operates without feedback from receivers.
在基于接收器的拥塞控制的情况下，使用FEC的开环交付是实现大容量数据传输良好吞吐量的可能选择。这是因为开环交付不需要来自接收器的反馈，因此它与基于接收器的拥塞控制机制完美匹配，该机制在没有接收器反馈的情况下运行。
Generally speaking, security considerations have relatively little effect on constraining the design space for reliable multicast protocols. The primary issues constraining the design space are all related to receiver-set scaling. For authentication of the source and of data integrity, receiver-set scaling is not a significant issue. However, for data encryption, key distribution and particularly re-keying may be significantly affected by receiver-set scaling. Tree and graph based re-keying solutions[WHA98,WGL97] would appear to be appropriate solutions to these problems. It is not clear however that such re-keying solutions need to directly affect the design of the data distribution part of a reliable multicast protocol.
一般来说，安全考虑对限制可靠多播协议的设计空间的影响相对较小。限制设计空间的主要问题都与接收器集缩放有关。对于源和数据完整性的身份验证，接收器集缩放不是一个重要问题。然而，对于数据加密，密钥分配，特别是重设密钥，可能会受到接收器集缩放的显著影响。基于树和图的密钥更新解决方案[WHA98，WGL97]似乎是这些问题的合适解决方案。然而，目前尚不清楚这种密钥更新解决方案是否需要直接影响可靠多播协议的数据分发部分的设计。
The primary question to consider for the security of reliable multicast protocols is the role of third-parties. If nodes other than the original source of the data are allowed to send or resend data packets, then the security model for the protocol must take this into account. In particular, it must be clear whether such third parties are trusted or untrusted. A requirement for trusted third parties can make protocols difficult to deploy on the Internet.
可靠组播协议安全考虑的首要问题是第三方的作用。如果允许原始数据源以外的节点发送或重新发送数据包，则协议的安全模型必须考虑这一点。特别是，必须明确此类第三方是否可信。对可信第三方的要求可能会使协议难以在Internet上部署。
Untrusted third parties (such as receivers that retransmit the data) may be used so long as the data authentication mechanisms take this into account. Typically this means that the original sender digitally signs and timestamps the data, and that the third parties resend this signed timestamped payload unmodified.
只要数据认证机制考虑到这一点，就可以使用不受信任的第三方（例如重新传输数据的接收器）。通常这意味着原始发送方对数据进行数字签名和时间戳，并且第三方未经修改重新发送该签名的时间戳有效负载。
Unlike unicast protocols, denial-of-service attacks on multicast transport state are easy if the protocol design does not take such attacks into account. This is because any receiver can join the session, and can then produce feedback that influences the progress of a session involving many other receivers. Hence protection against denial-of-service attacks on reliable multicast protocols must be carefully considered. A receiver that requests retransmission of every packet, or that refuses to acknowledge packets in an ACK-based protocol can potentially bring a reliable multicast session to a standstill. Senders must have appropriate policy to deal with such conditions, and if necessary, evict the receiver from the group. A single receiver masquerading as a large number of receivers may still be an issue under such circumstances with protocols that support NACK-like functionality. Providing unique "keys" to each NACKer when they first NACK using a unicast response might potentially prevent such attacks.
与单播协议不同，如果协议设计不考虑此类攻击，则对多播传输状态的拒绝服务攻击很容易发生。这是因为任何接收者都可以加入会话，然后可以产生影响涉及许多其他接收者的会话进度的反馈。因此，必须仔细考虑针对可靠多播协议的拒绝服务攻击的保护。在基于ACK的协议中，请求重传每个数据包或拒绝确认数据包的接收器可能会使可靠的多播会话停止。发送方必须有适当的策略来处理此类情况，如有必要，将接收方逐出组。在这种情况下，使用支持NACK类功能的协议，伪装成大量接收器的单个接收器可能仍然是一个问题。当每个NACKer第一次使用单播响应进行NACK时，为其提供唯一的“密钥”可能会潜在地防止此类攻击。
Denial-of-service attacks caused by traffic flooding are however somewhat easier to protect against than with unicast. Unwanted senders can simply be pruned from the distribution tree using the mechanisms implemented in IGMP v3[CDT99].
但是，与单播相比，流量泛滥导致的拒绝服务攻击更容易防范。使用IGMP v3[CDT99]中实现的机制，可以简单地从分发树中删除不需要的发送者。
In this document we present an overview of the design space for reliable multicast within the context of one-to-many bulk-data transfer. Other flavors of multicast application are not considered in this document, and hence the overview given should not be considered inclusive of the design space for protocols that fall outside the context of one-to-many bulk-data transfer. During the course of this overview, we have reaffirmed the notion that the process of reliable multicast protocol design is affected by a number of factors that render the generation of a "one size fits all solution" moot. These factors are then described to show how an application's needs serve to constrain the set of available techniques that may be used to create a reliable multicast protocol. We examined a number of basic techniques and to show how well they can meet the needs of certain types of applications.
In this document we present an overview of the design space for reliable multicast within the context of one-to-many bulk-data transfer. Other flavors of multicast application are not considered in this document, and hence the overview given should not be considered inclusive of the design space for protocols that fall outside the context of one-to-many bulk-data transfer. During the course of this overview, we have reaffirmed the notion that the process of reliable multicast protocol design is affected by a number of factors that render the generation of a "one size fits all solution" moot. These factors are then described to show how an application's needs serve to constrain the set of available techniques that may be used to create a reliable multicast protocol. We examined a number of basic techniques and to show how well they can meet the needs of certain types of applications.translate error, please retry
This document is intended to provide guidance to the IETF community regarding the standardization of reliable multicast protocols for bulk-data transfer. Given the degree to which application requirements constrain reliable multicast solutions, and the diverse set of applications that need to be supported, it should be clear that any standardization work should take great pains to be future-proof. This would seem to imply not standardizing complete reliable multicast transport protocols in one pass, but rather examining the degree to which such protocols are separable into functional building
本文件旨在就批量数据传输的可靠多播协议的标准化向IETF社区提供指导。考虑到应用程序需求在多大程度上限制了可靠的多播解决方案，以及需要支持的应用程序的多样性，应该清楚的是，任何标准化工作都应该不遗余力地成为未来的证明。这似乎意味着不需要一次性标准化完整的可靠多播传输协议，而是要检查这些协议在功能构建中的可分离程度
blocks, and standardizing these blocks separately to the maximum degree that makes sense. Such an approach allows for protocol evolution, and allows applications with new constraints to be supported with maximal reuse of existing and tested mechanisms.
块，并将这些块分别标准化到有意义的最大程度。这种方法允许协议演化，并允许通过最大限度地重用现有和测试的机制来支持具有新约束的应用程序。
This document represents an overview of the reliable multicast design space. The ideas presented are not those of the authors, but are collected from the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions.
本文档概述了可靠多播设计空间。提出的想法不是作者的想法，而是从IRTF可靠多播研究小组的各种演示和讨论中收集的。虽然它们太多，无法在此列出，但我们感谢所有参与这些讨论的人所作的贡献。
Mark Handley ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
美国加利福尼亚州伯克利中心大街1947号600室国际计算机科学研究所ICSI互联网研究中心Mark Handley ATT，邮编：94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
美国加利福尼亚州伯克利中心街1947号600室国际计算机科学研究所ICSI互联网研究中心Sally Floyd ATT，邮编：94704
EMail: floyd@aciri.org
EMail: floyd@aciri.org
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
Brian Whetten Talarian公司，美国加利福尼亚州洛斯阿尔托斯市Distel Circle 333号，邮编94022
EMail: whetten@talarian.com
EMail: whetten@talarian.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
Roger Kermode摩托罗拉澳大利亚研究中心3楼，地址：澳大利亚新南威尔士州植物学街12号，邮编：2019
EMail: Roger.Kermode@motorola.com
EMail: Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems，170 West Tasman Dr.San Jose，CA 95134，美国
EMail: lorenzo@cisco.com
EMail: lorenzo@cisco.com
Michael Luby Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110
米迦勒鲁比数字喷泉公司，旧金山阿拉巴马街600号，CA，94110
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
[BC94] K. Birman, T. Clark. "Performance of the Isis Distributed Computing Toolkit." Technical Report TR-94-1432, Dept. of Computer Science, Cornell University.
[BC94]K.伯曼，T.克拉克。“Isis分布式计算工具包的性能”，技术报告TR-94-1432，康奈尔大学计算机科学系。
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. Zuckerman, "An XOR-based Erasure Resilient Coding Scheme", ICSI Technical Report No. TR-95-048, August 1995.
[BKKLZ95]J.Bloemer，M.Kalfine，M.Karpinski，R.Karp，M.Luby，D.Zuckerman，“基于XOR的擦除弹性编码方案”，ICSI技术报告TR-95-048号，1995年8月。
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data", Proc ACM SIGCOMM 98.
[BLMR98]J.Byers，M.Luby，M.Mitzenmacher，A.Rege，“批量数据可靠分发的数字喷泉方法”，Proc ACM SIGCOMM 98。
[CDT99] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Work in Progress.
[CDT99]Cain，B.，Deering，S.，和A.Thyagarajan，“互联网组管理协议，第3版”，正在进行中。
[FLST98] Farinacci, D., Lin, S., Speakman, T. and A. Tweedly, "PGM reliable transport protocol specification", Work in Progress.
[FLST98]Farinaci，D.，Lin，S.，Speakman，T.和A.Tweedly，“PGM可靠传输协议规范”，工作正在进行中。
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
[FJM95]S.Floyd，V.Jacobson，S.McCanne，“用于轻量级会话和应用程序级帧的可靠多播框架”，Proc ACM SIGCOMM 95，1995年8月，第342-356页。
[Ha99] Handley, M., "Multicast address allocation protocol (AAP)", Work in Progress.
[Ha99]Handley，M.，“多播地址分配协议（AAP）”，正在进行中。
[HC97] M. Handley and J. Crowcroft, "Network text editor (NTE) a scalable shared text editor for MBone," ACM Computer Communication Review, vol. 27, pp. 197-208, Oct. 1997. ACM SIGCOMM'97, Sept. 1997.
[HC97]M.Handley和J.Crowcroft，“网络文本编辑器（NTE）MBone的可扩展共享文本编辑器”，ACM计算机通信评论，第27卷，第197-208页，1997年10月。ACM SIGCOMM'971997年9月。
[KCW98] Kadansky, M., Chiu, D. and J. Wesley, "Tree-based reliable multicast (TRAM)", Work in Progress.
[KCW98]Kadansky，M.，Chiu，D.和J.Wesley，“基于树的可靠多播（TRAM）”，正在进行中。
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V. Stemann, "Practical Loss-Resilient Codes", Proc ACM Symposium on Theory of Computing, 1997.
[LMSSS97]M.Luby，M.Mitzenmacher，A.Shokrollahi，D.Spielman，V.Stemann，“实用的抗损失代码”，Proc ACM计算理论研讨会，1997年。
[MWB+98] Montgomery, T., Whetten, B., Basavaiah, M., Paul, S., Rastogi, N., Conlan, J. and T. Yeh, "THE RMTP-II PROTOCOL", Work in Progress.
[MWB+98]蒙哥马利，T.，惠顿，B.，巴萨瓦亚，M.，保罗，S.，拉斯托吉，N.，康兰，J.和T.叶，“RMTP-II协议”，正在进行中。
[PPV98] C. Papadopoulos, G. Parulkar, and G. Varghese, "An error control scheme for large-scale multicast applications," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1188, March/April 1998.
[PPV98]C.Papadopoulos，G.Parulkar和G.Varghese，“大规模多播应用的错误控制方案”，载于计算机通信会议记录（IEEE Infocom）（加利福尼亚州旧金山），第页。1998年3月/4月1188日。
[Ri97] L. Rizzo, "Effective erasure codes for reliable computer communication protocols," ACM Computer Communication Review, vol. 27, pp. 24-36, Apr. 1997.
[Ri97]L.Rizzo，“可靠计算机通信协议的有效擦除代码”，《ACM计算机通信评论》，第27卷，第24-36页，1997年4月。
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast data Distribution Protocol based on software FEC techniques", Proc. of The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25, 1997.
[RV97]L.Rizzo，L.Vicisano，“基于软件FEC技术的可靠多播数据分发协议”，Proc。第四届IEEE高性能通信系统体系结构和实施研讨会（HPCS'97），1997年6月23日至25日，希腊Chalkidiki萨尼海滩。
[RVC98] L. Rizzo, L. Vicisano, J. Crowcroft, "The RLC multicast congestion control algorithm", submitted to IEEE Network - special issue multicast.
[RVC98]L.Rizzo，L.Vicisano，J.Crowcroft，“RLC多播拥塞控制算法”，提交给IEEE网络-特刊多播。
[RMWT98] Robertson, K., Miller, K., White, M. and A. Tweedly, "StarBurst multicast file transfer protocol (MFTP) specification", Work in Progress.
[RMWT98]Robertson，K.，Miller，K.，White，M.和A.Tweedly，“星突发多播文件传输协议（MFTP）规范”，工作正在进行中。
[WHA98] Wallner, D., Hardler, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[WHA98]Wallner，D.，Hardler，E.和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1999年6月。
[WKM94] Brian Whetten, Simon Kaplan, and Todd Montgomery, "A high performance totally ordered multicast protocol," research memorandum, Aug. 1994.
[WKM94]Brian Whetten、Simon Kaplan和Todd Montgomery，“高性能全序多播协议”，研究备忘录，1994年8月。
[WGL97] C.K. Wong, M. Gouda, S. Lam, "Secure Group Communications Using Key Graphs," Technical Report TR 97-23, Department of Computer Sciences, The University of Texas at Austin, July 1997.
[WGL99] C.K.黄，M. Gouda，S. Lam，“使用关键图的安全组通信，”技术报告TR 9723，得克萨斯大学奥斯汀分校计算机科学系，1997年7月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。