Network Working Group A. Mankin
Request for Comments: 2357 USC/ISI
Category: Informational A. Romanow
MCI
S. Bradner
Harvard University
V. Paxson
LBL
With the TSV
Area Directorate
June 1998
Network Working Group A. Mankin
Request for Comments: 2357 USC/ISI
Category: Informational A. Romanow
MCI
S. Bradner
Harvard University
V. Paxson
LBL
With the TSV
Area Directorate
June 1998
IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols
IETF评估可靠多播传输和应用协议的标准
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes 1997].
本备忘录描述了审查IETF传输区（TSV）内可靠多播协议的程序和标准。在当今的互联网中，可靠的多播服务有着重要的应用。推动可靠多播技术的一些例子是协作工作区（如白板）、数据和软件分发，以及（更具推测性的）web缓存协议。由于技术问题的性质，一个单一的普遍接受的技术解决方案来解决可靠多播的所有需求可能是不可行的[RMMinutes 1997]。
A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications. [Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet?
许多可靠的多播协议已经被开发出来，用于解决各种类型应用的各种问题。[Floyd97]描述了一个广泛部署的示例。IETF应如何处理这些协议，IETF应如何引导可靠多播朝着有利于普通互联网的方向发展？
The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols.
TSV区域总监及其董事会概述了一套审查程序，以解决这些问题，并为可靠多播传输协议的互联网草案作为RFC发布设定标准和流程。
In the IETF, work in an area is directed and managed by the Area Directors (ADs), who have authority over the chartering of working groups (WGs).
在IETF中，区域内的工作由区域主管（ADs）指导和管理，他们有权组建工作组（WG）。
In addition, ADs review individually submitted (not by WGs) Internet-Drafts about work that is relevant to their areas prior to publication as RFCs (Experimental, Informational or, in rare cases, Standards Track). The review is done according to the guidelines set out in the Internet Standards Process, RFC 2026 [InetStdProc96].
此外，ADs审查单独提交（不是由WGs）的互联网草案，这些草案涉及在作为RFC出版之前与其领域相关的工作（实验性的、信息性的，或在极少数情况下，标准跟踪）。审查是根据互联网标准流程RFC 2026[InetStdProc96]中规定的指南进行的。
The purpose of this document is to present the criteria that will be used by the TSV ADs in reviewing reliable multicast Internet-Drafts for any form of RFC publication.
本文件旨在介绍TSV ADs在审查任何形式的RFC出版物的可靠多播互联网草案时所使用的标准。
For I-Ds submitted for Standards Track publication, these criteria must be met or else the ADs will decline to support publication of the document, which suffices to prevent publication. For I-Ds submitted as Experimental or Informational, these criteria must be met or else, at a minimum, the Ads will recommend publishing the I-D with an IESG note prepended stating that the protocol fails to comply with these criteria.
对于提交用于标准跟踪发布的I-D，必须满足这些标准，否则ADs将拒绝支持文档的发布，这足以阻止发布。对于作为实验性或信息性提交的I-D，必须满足这些标准，否则，Ads将建议至少发布I-D，并在之前附上IESG说明，说明协议不符合这些标准。
There is a strong application demand for reliable multicast. Widespread use of the Internet makes the economy of multicast transport attractive. The current Internet multicast model offers best-effort many-to-many delivery service and offers no guarantees. One-to-many and few-to-few services may become more important in the future. Reliable multicast transports add delivery guarantees, not necessarily like those of reliable unicast TCP, to the group-delivery model of multicast. A panel of some major users of the Internet, convened at the 38th IETF, articulated reliable bulk transfer multicast as one of their most critical requirements [DiffServBOF97]. Examples of applications that could use reliable bulk multicast transfer include collaborative tools, distributed virtual reality, and software upgrade services.
对可靠组播有着强烈的应用需求。互联网的广泛使用使得多播传输的经济性具有吸引力。当前的Internet多播模型提供尽力而为的多对多交付服务，并且不提供任何保证。一对多和少对少服务在未来可能变得更加重要。可靠的多播传输为多播的组传递模型添加了传递保证，而不一定像可靠的单播TCP那样。在第38届IETF会议上，由互联网的一些主要用户组成的一个小组明确提出了可靠的批量传输多播是他们最关键的要求之一[DiffServBOF97]。可以使用可靠批量多播传输的应用程序示例包括协作工具、分布式虚拟现实和软件升级服务。
To meet the growing demand for reliable multicast, there is a large number of protocol proposals. A few were published as RFCs before the impact of congestion from reliable multicast was fully
为了满足日益增长的可靠组播需求，出现了大量的协议方案。在可靠多播造成的拥塞影响完全消除之前，有一些已作为RFC发布
appreciated, and these should be deprecated [DeprRFCs]. Two surveys of other publications are [DiotCrow97], [Obraczka98].
感谢您的支持，这些建议应该被弃用[DeprRFCs]。其他出版物的两项调查分别为[DiotCrow97]、[Obraczka98]。
As we discuss in Section 3, the issues raised by reliable multicast are considerably more complex than those related to reliable unicast. In particular, in today's Internet, reliable multicast protocols could do great damage through causing congestion disasters if they are widely used and do not provide adequate congestion control.
正如我们在第3节中所讨论的，由可靠多播引起的问题比与可靠单播相关的问题要复杂得多。特别是，在当今的互联网上，如果可靠的多播协议被广泛使用，并且不能提供足够的拥塞控制，那么它们可能会通过造成拥塞灾难而造成巨大的破坏。
Because of the complexity of the technical issues, and the abundance of proposed solutions, we are putting in place review procedures that are more explicit than usual. We compare this action with an IESG action taken in 1991, RFC 1264 [Routing91], when community experience with standard Internet dynamic routing protocols was still limited, and extra review was deemed necessary to assure that the protocols introduced would be effective, correct and robust.
由于技术问题的复杂性和提出的解决方案的丰富性，我们正在制定比通常更明确的审查程序。我们将这一行动与1991年采取的IESG行动RFC 1264[Routing91]进行了比较，当时社区对标准互联网动态路由协议的经验仍然有限，并且认为有必要进行额外审查，以确保引入的协议有效、正确和稳健。
Section 3 describes in detail the nature of the particular challenges posed by reliable multicast. Section 4 describes the process for considering reliable multicast solutions. Section 5 details the additional requirements that need to be met by proposals to be published as Standards Track RFCs.
第3节详细描述了可靠多播带来的特殊挑战的性质。第4节描述了考虑可靠多播解决方案的过程。第5节详细说明了作为标准跟踪RFC发布的提案需要满足的附加要求。
Two aspects of reliable multicast make standardization particularly challenging. First, the meaning of reliability varies in the context of different applications. Secondly, if special care is not taken, reliable multicast protocols can cause a particular threat to the operation of today's global Internet. These issues are discussed in detail in this section.
可靠多播的两个方面使得标准化尤其具有挑战性。首先，可靠性的含义在不同的应用环境中有所不同。其次，如果不特别注意，可靠的多播协议可能会对当今全球互联网的运行造成特别的威胁。本节将详细讨论这些问题。
Unlike reliable unicast, where a single transport protocol (TCP) is currently used to meet the reliable delivery needs of a wide range of applications, reliable multicast does not necessarily lend itself to a single application interface or to a single underlying set of mechanisms. For unicast transport, the requirements for reliable, sequenced data delivery are fairly general. TCP, the primary transport protocol for reliable unicast, is a mature protocol with delivery semantics that suit a wide range of applications.
与可靠单播不同，可靠多播目前使用单一传输协议（TCP）来满足广泛应用程序的可靠传输需求，它不一定适用于单一应用程序接口或单一底层机制集。对于单播传输，可靠、有序数据传输的要求相当普遍。TCP是可靠单播的主要传输协议，是一种成熟的协议，具有适合广泛应用的传输语义。
In contrast, different multicast applications have widely different requirements for reliability. For example, some applications require that message delivery obey a total ordering while others do not. Some applications have many or all the members sending data while others have only one data source. Some applications have replicated
相比之下，不同的多播应用程序对可靠性的要求大不相同。例如，一些应用程序要求消息传递遵循总顺序，而其他应用程序则不这样做。某些应用程序有许多或所有成员发送数据，而其他应用程序只有一个数据源。一些应用程序已经复制
data, for example in an n-redundant file store, so that several members are capable of transmitting a data item, while for others all data originates at a single source. Some applications are restricted to small fixed-membership multicast groups, while other applications need to scale dynamically to thousands or tens of thousands of members (or possibly more). Some applications have stringent delay requirements, while others do not. Some applications such as file-transfer are high-bandwidth, while other applications such as interactive collaboration tools are more likely to be bursty but use low bandwidth overall. Some applications will sometimes trade off less than complete reliability for more timely delivery. These requirements each impact the design of reliable multicast protocols in a different way.
数据，例如n冗余文件存储中的数据，因此多个成员能够传输一个数据项，而对于其他成员，所有数据都来自单个源。一些应用程序仅限于小型固定成员多播组，而其他应用程序需要动态扩展到数千或上万个成员（或可能更多）。一些应用程序有严格的延迟要求，而其他应用程序则没有。一些应用程序（如文件传输）的带宽很高，而其他应用程序（如交互式协作工具）的带宽更高，但总体上使用的带宽较低。有些应用程序有时会为了更及时地交付而牺牲不完全的可靠性。这些需求都以不同的方式影响可靠多播协议的设计。
In addition, even for a specific application where the application's requirements for reliable multicast are well understood, there are many open questions about the underlying mechanisms for providing reliable multicast. A key question concerns the robustness of the underlying reliable multicast mechanisms as the number of senders or the membership of the multicast group grows.
此外，即使对于应用程序对可靠多播的要求已得到充分理解的特定应用程序，也存在许多关于提供可靠多播的底层机制的开放性问题。一个关键问题是，随着发送方数量或多播组成员数量的增加，底层可靠多播机制的健壮性。
One challenge to the IETF is to end up with the right match between applications' requirements and reliable multicast mechanisms. While there is general agreement that a single reliable multicast protocol or framework is not likely to meet the needs of all Internet applications, there is less understanding and agreement about the exact relationship between application-specific requirements and more generic underlying reliable mutlicast protocols or mechanisms. There are also open questions about the appropriate integration between an application and an underlying reliable multicast framework, and the potential generality of a single applications interface for that framework.
IETF面临的一个挑战是如何在应用程序的需求和可靠的多播机制之间实现正确的匹配。虽然人们普遍认为单一的可靠多播协议或框架不可能满足所有互联网应用程序的需求，但对于特定于应用程序的需求与更通用的底层可靠多播协议或机制之间的确切关系，人们的理解和一致性较少。关于应用程序和底层可靠多播框架之间的适当集成，以及该框架的单个应用程序接口的潜在通用性，还有一些开放性问题。
A particular concern for the IETF is the impact of reliable multicast traffic on other traffic in the Internet in times of congestion, in particular the effect of reliable multicast traffic on competing TCP traffic. The success of the Internet relies on the fact that best-effort traffic responds to congestion on a link (currently as indicated by packet drops) by reducing the load presented to the network. Congestion collapse in today's Internet is prevented only by the congestion control mechanisms in TCP, standardized by RFC 2001 [CongAvoid97, Jacobson88].
IETF特别关注的是在拥塞时可靠多播流量对Internet中其他流量的影响，特别是可靠多播流量对竞争TCP流量的影响。互联网的成功依赖于这样一个事实：尽力而为的流量通过减少网络负载来响应链路上的拥塞（目前由丢包表示）。当今互联网的拥塞崩溃只能通过TCP中的拥塞控制机制来防止，该机制由RFC 2001标准化[CongAvoid97，Jacobson88]。
There are a number of reasons to be particularly attentive to the congestion-related issues raised by reliable multicast proposals. Multicast applications in general have the potential to do more
有许多原因需要特别关注可靠多播方案提出的与拥塞相关的问题。一般来说，多播应用程序具有做更多事情的潜力
congestion-related damage to the Internet than do unicast applications. One factor is that a single multicast flow can be distributed along a large, global multicast tree reaching throughout the entire Internet.
与单播应用程序相比，拥塞对互联网造成的损害更大。一个因素是单个多播流可以分布在一个大型的全局多播树上，覆盖整个互联网。
Unreliable multicast applications such as audio and video are, at the moment, usually accompanied by a person at the receiving end, and people typically unsubscribe from a multicast group if congestion is so heavy that the audio or video stream is unintelligible. Reliable multicast applications such as group file transfer applications, on the other hand, are likely to be between computers, with no humans in attendance monitoring congestion levels.
目前，音频和视频等不可靠的多播应用程序通常由接收端的一个人陪同，如果拥塞严重，音频或视频流无法理解，人们通常会取消多播组的订阅。另一方面，可靠的多播应用程序（如组文件传输应用程序）可能位于计算机之间，没有人监控拥塞级别。
In addition, reliable multicast applications do not necessarily have the natural time limitations typical of current unreliable multicast applications. For a file transfer application, for example, the data transfer might continue until all of the data is transferred to all of the intended receivers, resulting in a potentially-unlimited duration for an individual flow. Reliable multicast applications also have to contend with a potential explosion of complex patterns of control traffic (e.g., ACKs, NACKs, status messages). The design of congestion control mechanisms for reliable multicast for large multicast groups is currently an area of active research.
此外，可靠多播应用不一定具有当前不可靠多播应用典型的自然时间限制。例如，对于文件传输应用程序，数据传输可能会继续，直到所有数据传输到所有预期接收器，从而导致单个流的潜在无限持续时间。可靠的多播应用程序还必须应对控制流量的复杂模式（例如，ACK、NACK、状态消息）的潜在爆炸。为大型组播组设计可靠组播的拥塞控制机制是当前一个活跃的研究领域。
The challenge to the IETF is to encourage research and implementations of reliable multicast, and to enable the needs of applications for reliable multicast to be met as expeditiously as possible, while at the same time protecting the Internet from the congestion disaster or collapse that could result from the widespread use of applications with inappropriate reliable multicast mechanisms. Because of the setbacks and costs that could result from the widespread deployment of reliable multicast with inadequate congestion control, the IETF must exercise care in the standardization of a reliable multicast protocol that might see widespread use.
IETF面临的挑战是鼓励研究和实施可靠多播，并使可靠多播应用程序的需求能够尽快得到满足，同时保护互联网免受拥塞灾难或崩溃的影响，这可能是由于广泛使用具有不适当可靠多播机制的应用程序造成的。由于在拥塞控制不足的情况下广泛部署可靠多播可能会带来挫折和成本，IETF必须谨慎地对可能广泛使用的可靠多播协议进行标准化。
The careful review and cautious acceptance procedures for proposals submitted as Internet-Drafts reflects our concern to meet the challenges described here.
对作为互联网草案提交的提案的仔细审查和谨慎接受程序反映了我们对应对此处所述挑战的关注。
4. IETF Process for Review and Publication of Reliable Multicast Protocol Specifications
4. IETF审查和发布可靠多播协议规范的过程
In the general case of individually submitted Internet-Drafts (proposals not produced by an IETF WG), the process of publication as some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96]. This specifies that if the submitted Internet-Draft is closely related to work being done or expected to be done in the IETF, the
对于单独提交的互联网草案（并非由IETF工作组编制的提案），RFC 2026（4.2.3）[InetStdProc96]中描述了作为某种类型RFC发布的过程。这规定，如果提交的互联网草案与IETF中正在完成或预期完成的工作密切相关，则
ADs may recommend that the document be brought within the IETF and progressed in the IETF context. Otherwise, the ADs may recommend that the Internet-Draft be published as an Experimental or Informational RFC, with or without an IESG annotation of its relationship to the IETF context.
ADs可能建议将该文件纳入IETF，并在IETF环境下进行。否则，ADs可能会建议将互联网草案作为实验性或信息性RFC发布，无论是否对其与IETF上下文的关系进行IESG注释。
The procedure for Reliable Multicast proposal publication will have as its default RFC status Experimental, when the technical criteria listed in Section 5 are deemed to be fulfilled. Both the criteria and the procedure reflect the AD's technical assessment of the current state of reliable multicast technology. It does not reflect the origins of the proposals, which we expect will be equally from commercial vendors with initial products and from researchers.
当第5节中列出的技术标准被视为已满足时，可靠多播方案发布程序的默认RFC状态为试验状态。标准和程序都反映了AD对可靠多播技术现状的技术评估。它没有反映出提案的起源，我们预计提案将同样来自具有初始产品的商业供应商和研究人员。
Work on the development and engineering of protocols that may eventually meet the review criteria could take place either in the IRTF Reliable Multicast Research Group (http://www.irtf.org) or a focused short IETF WG with an Experimental product.
最终可能满足审查标准的协议的开发和工程设计工作可以在IRTF可靠多播研究小组中进行(http://www.irtf.org)或者一个有实验性产品的专注的IETF短期工作组。
When the work in reliable multicast technology has matured enough to be considered for standardization within the IETF, the TSV Area may charter appropriate working groups to develop standards track documents. The criteria for evaluation of standards track technology will be at least as stringent as those described herein (next section).
当可靠多播技术的工作已经成熟到可以考虑在IETF内进行标准化时，TSV区域可以成立适当的工作组来制定标准跟踪文件。标准轨道技术的评估标准将至少与本文（下一节）所述标准一样严格。
The Internet-Draft must (in itself or a companion draft):
互联网草案必须（本身或配套草案）：
a. Analyze the behavior of the protocol. The vulnerabilities and performance problems must be shown through analysis. Especially the protocol behavior must be explained in detail with respect to scalability, congestion control, error recovery, and robustness.
a. 分析协议的行为。必须通过分析显示漏洞和性能问题。特别是，必须从可伸缩性、拥塞控制、错误恢复和健壮性方面详细解释协议行为。
For example the following questions should be answered:
例如，应回答以下问题：
How scalable is the protocol to the number of senders or receivers in a group, the number of groups, and wide dispersion of group members?
协议对组中发送方或接收方的数量、组的数量以及组成员的广泛分布的可伸缩性如何？
Identify the mechanisms which limit scalability and estimate those limits.
确定限制可伸缩性的机制并估计这些限制。
How does the protocol protect the Internet from congestion? How well does it perform? When does it fail?
协议如何保护互联网免受拥塞？它的表现如何？什么时候失败？
Under what circumstances will the protocol fail to perform the functions needed by the applications it serves? Is there a congestion control mechanism? How well does it perform? When does it fail? Note that congestion control mechanisms that operate on the network more aggressively than TCP will face a great burden of proof that they don't threaten network stability.
在什么情况下，协议将无法执行其服务的应用程序所需的功能？是否有拥塞控制机制？它的表现如何？什么时候失败？请注意，在网络上比TCP更积极地运行的拥塞控制机制将面临巨大的举证责任，证明它们不会威胁网络的稳定性。
b. Include a description of trials and/or simulations which support the development of the protocol and the answers to the above questions.
b. 包括对支持制定方案的试验和/或模拟的描述以及对上述问题的回答。
c. Include an analysis of whether the protocol has congestion avoidance mechanisms strong enough to cope with deployment in the Global Internet, and if not, clearly document the circumstances in which congestion harm can occur. How are these circumstances to be prevented?
c. 包括对协议是否具有足够强大的拥塞避免机制以应对在全球互联网上的部署的分析，如果没有，则明确记录可能发生拥塞损害的情况。如何防止这些情况？
d. Include a description of any mechanisms which contain the traffic within limited network environments. If the analysis in a or c shows that the protocol has potential to damage the Internet, then the analysis must include a discussion of ways to limit the scope or otherwise contain the protocol. We recognize that the confinement of Internet applications is an open research area.
d. 包括包含有限网络环境中流量的任何机制的描述。如果a或c中的分析表明协议有可能损坏互联网，那么分析必须包括对限制范围或以其他方式包含协议的方法的讨论。我们认识到，限制互联网应用是一个开放的研究领域。
e. Reliable multicast protocols must include an analysis of how they address a number of security and privacy concerns. If the protocol can be used in different modes of secure operation, then each mode must be analyzed.
e. 可靠的多播协议必须包括对它们如何解决许多安全和隐私问题的分析。如果协议可用于不同的安全操作模式，则必须分析每种模式。
The analysis must document which of the various parties -- senders, routers (more generally, data forwarders), receivers, retransmission sources -- must be trusted in order to ensure secure operation and privacy of the transmitted data, to what degree, and why. (One issue to address here are "man-in-the-middle" attacks.)
为了确保传输数据的安全操作和保密性，分析必须记录各方中的哪些方——发送方、路由器（更一般地说，数据转发器）、接收方、重传源——必须被信任，信任程度如何，以及为什么。（这里要解决的一个问题是“中间人”攻击。）
To what degree can data be manipulated so that at least a subset of the receivers receive different copies? Does the protocol allow a group of receivers to determine whether they all received the same data?
在多大程度上可以操纵数据，以便至少一部分接收器接收不同的副本？协议是否允许一组接收器确定它们是否都接收到相同的数据？
What limitations are placed on the retransmission mechanism to prevent it from being abused to flood network links with excessive traffic? Which parties must be trusted to ensure this, and to what degree, and why? The presumption will be that either a congestion control mechanism will inherently limit the volume of retransmission traffic, and that this limiting
对重传机制有哪些限制，以防止其被滥用，导致网络链路流量过大？必须信任哪些方面来确保这一点，信任程度如何，为什么？假设拥塞控制机制会固有地限制重传通信量，并且这种限制
influence is robust under concerted attack; or that retransmission requests will be signed in a cryptographically strong manner so that abuses of the mechanism can be traced back to their source. Protocols that do not provide either of these forms of protection face a great burden of proof that they don't threaten network stability.
在协同攻击下，影响是鲁棒的；或者，重新传输请求将以加密方式进行签名，这样滥用机制的行为可以追溯到其源头。不提供这两种保护形式的协议都面临着巨大的举证责任，证明它们不会威胁网络的稳定性。
What sort of key management does the protocol require, and provide for?
协议需要并提供什么样的密钥管理？
This memo specifies in Section 5.e. that reliable multicast Internet-Drafts reviewed by the Transport Area Directors must explicitly explore the security aspects of the proposed design.
本备忘录在第5.e节中规定。由运输区域主管审查的可靠多播互联网草案必须明确探讨拟议设计的安全方面。
Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike Reiter gave especially helpful comments on drafts of this document.
Sally Floyd、Steve McCanne、Mark Handley、Steve Bellovin和Mike Reiter对本文件的草稿提出了特别有用的意见。
[RMMinutes 1997] Minutes the Second Reliable Multicast Research
Group Meeting. September 1997. http://www.east.isi.edu/rm
[RMMinutes 1997] Minutes the Second Reliable Multicast Research
Group Meeting. September 1997. http://www.east.isi.edu/rm
[Floyd97] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking, December 1997 An online version of the paper is at http://ee.lbl.gov/floyd/srm-paper.html.
[Floyd97]Floyd，S.，Jacobson，V.，Liu，C.，McCanne，S.，和Zhang，L.，一个用于轻量级会话和应用程序级帧的可靠多播框架。IEEE/ACM网络交易，1997年12月该论文的在线版本在http://ee.lbl.gov/floyd/srm-paper.html.
[InetStdProc96] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[InetStdProc96]Bradner，S.，“互联网标准过程——第3版”，RFC 2026，1996年10月。
[DiffServBOF97] [6] http://www.ietf.org/proceedings/97apr - Transport Area - FDDIFS BOF, April 1997.
[DiffServBOF97][6]http://www.ietf.org/proceedings/97apr -运输区——FDDIFS BOF，1997年4月。
[DeprRFCs] Freier, A., "Multicast Transport Protocol", RFC 1301, February 1992. and Braudes, R., and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[DeprRFCs]Freier，A.，“多播传输协议”，RFC 13011992年2月。和Braudes，R.和S.Zabele，“多播协议的要求”，RFC 1458，1993年5月。
[DiotCrow97] Diot, C., Crowcroft, J., Multicast Transport Survey. Journal of Selected Areas in Communications, 1997.
[DiotCrow97]Diot，C.，Crowcroft，J.，多播传输调查。《通信选定领域杂志》，1997年。
[Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey and Taxonomy. To appear in IEEE Communications, 1998.
[Obraczka98]Obraczka，K.，多播传输机制：综述和分类。将出现在IEEE通讯，1998年。
[Routing91] Hinden, R., and Internet Engineering Task Force, "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[Routing91]Hinden，R.和互联网工程任务组，“互联网路由协议标准化标准”，RFC 12641991年10月。
[CongAvoid97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[CongAvoid97]Stevens，W.，“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
[Jacobson 1988] Jacobson, V., Congestion Avoidance and Control, Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An updated version of this paper is available at "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".
[Jacobson 1988]Jacobson，V.，拥塞避免和控制，SIGCOMM'88诉讼，1988年8月，第314-329页。本文件的最新版本可在以下网址获得：ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".
Allison Mankin - Past TSV Area Director USC/ISI East 4350 N. Fairfax Dr., Suite 620 Arlington VA 22203 USA
Allison Mankin-前TSV区域总监USC/ISI East 4350 N.Fairfax Dr.，美国弗吉尼亚州阿灵顿620室22203
Phone: 703 812 3706 EMail: mankin@east.isi.edu
电话：703 812 3706电子邮件：mankin@east.isi.edu
Allyn Romanow - Past TSV Area Director MCI Corporation 2560 North First Street San Jose, CA 9531 USA
Allyn Romanow-美国加利福尼亚州圣何塞北第一街2560号，前TSV区域总监MCI Corporation 9531
Phone: 408 922 7143 EMail: allyn@mci.net
电话：408 922 7143电子邮件：allyn@mci.net
Scott Bradner - TSV Co-Area Director Harvard University 1350 Mass. Ave., Rm. 876 Cambridge MA 02138 USA
斯科特·布拉德纳-TSV联合区域主任哈佛大学1350马萨诸塞州。埃弗顿大街，Rm。876剑桥马萨诸塞州02138美国
Phone: 617 495 3864 EMail: sob@harvard.edu
电话：6174953864电子邮件：sob@harvard.edu
Vern Paxson - TSV Co-Area Director MS 50B/2239 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
韦恩帕克森- TSV CO区主任MS 50B / 2239劳伦斯伯克利国家实验室加利福尼亚大学伯克利，CA 94720美国
Phone: 510-486-7504 EMail: vern@ee.lbl.gov
电话：510-486-7504电子邮件：vern@ee.lbl.gov
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。