Network Working Group B. Adamson
Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Network Working Group B. Adamson
Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
面向否定确认（NACK）的可靠多播（NORM）构建块
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.
本文讨论面向否定确认（NACK）的可靠多播（NORM）协议的创建。提出了规范目标和假设的基本原理。确定了面向NACK（在某些情况下是通用的）可靠多播协议操作的技术挑战。这些目标和挑战被分解为一组功能“构建块”，用于解决规范协议操作的不同方面。预计这些构建块将有助于生成可靠多播协议的不同实例。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
Reliable multicast transport is a desirable technology for the efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users [3]. This document addresses the creation of negative-acknowledgment (NACK)- oriented reliable multicast (NORM) protocols. While different protocol instantiations may be required to meet specific application and network architecture demands [4], there are a number of fundamental components that may be common to these different instantiations. This document describes the framework and common "building block" components relevant to multicast protocols based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NORM protocol design, it specifically addresses in detail the following building blocks which are not addressed in other IETF documents:
可靠的多播传输是一种理想的技术，可以在Internet上高效、可靠地向组分发数据。组通信模式的复杂性需要不同的协议类型和实例化，以满足不同潜在可靠多播应用程序和用户的性能和可伸缩性要求[3]。本文档介绍面向否定确认（NACK）的可靠多播（NORM）协议的创建。虽然可能需要不同的协议实例化来满足特定的应用程序和网络架构需求[4]，但这些不同的实例化可能有许多共同的基本组件。本文档描述了与多播协议相关的框架和通用“构建块”组件，这些协议主要基于可靠传输的NACK操作。虽然本文件讨论了大量可靠的多播组件和与NORM协议设计相关的问题，但它具体阐述了其他IETF文件中未涉及的以下构建块：
1) NORM sender transmission strategies,
1) 规范发送方传输策略，
2) NACK-oriented repair process with timer-based feedback suppression, and
2) 具有基于定时器的反馈抑制的面向NACK的修复过程，以及
3) Round-trip timing for adapting NORM timers.
3) 用于调整标准计时器的往返计时。
The potential relationships to other reliable multicast transport building blocks (Forward Error Correction (FEC), congestion control) and general issues with NORM protocols are also discussed. This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [5]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
还讨论了与其他可靠多播传输构建块（前向纠错（FEC）、拥塞控制）的潜在关系以及与NORM协议的一般问题。本文件是IETF RMT工作组的产品，遵循RFC 3269[5]中提供的指南。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC 2357完全指定可靠多播传输协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
在等待此类方案可用或现有方案被证明足够时，可靠多播传输工作组（RMT）在“实验性”类别中发布此评论请求。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT的目的是，一旦满足上述条件，立即将本规范作为IETF建议的标准重新提交。
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
使用此处（以及其他适用的构建块文档）提供的构建块进行的每个潜在协议实例化将具有可能影响单个协议设计的特定标准。为了支持适用构建块的开发，确定和总结驱动通用协议设计目标和假设非常有用。这些是每个协议实例化都需要详细解决的领域。本文件中的每个构建块描述将包括对这些设计标准影响的讨论。此处考虑的设计标准类别包括：
1) Delivery Service Model, 2) Group Membership Dynamics, 3) Sender/receiver relationships, 4) Group Size Scalability, 5) Data Delivery Performance, 6) Network Environments, and 7) Router/Intermediate System Interactions.
1) 交付服务模型，2）组成员动态，3）发送方/接收方关系，4）组大小可伸缩性，5）数据交付性能，6）网络环境，以及7）路由器/中间系统交互。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents such as [9] have been created to address areas outside of the scope of this document. NORM protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NORM but may be used in concert with the other building block areas. In some cases, a building block may be able address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment.
至少对所有这些领域进行了简要讨论。此外，还创建了其他可靠的多播传输构建块文档，如[9]，以解决本文档范围之外的问题。NORM协议实例化可能依赖于这些其他构建块以及此处提供的构建块。本文件重点关注规范独有的区域，但可与其他构建块区域配合使用。在某些情况下，构建块可能能够处理范围广泛的假设，而在其他情况下，需要权衡以满足不同的应用程序需求或操作环境。如有必要，构建块特征设计为参数化，以满足不同的要求。当然，一个基本目标是最小化设计复杂性，并至少为任何此类参数推荐默认值，以满足典型互联网环境中的通用“批量数据传输”要求。
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. A most basic service model for reliable multicast transport is that of "bulk transfer" which is a primary focus of this and other related
可靠多播传输协议的隐含目标是在使用IP多播数据报服务进行通信的一组成员之间可靠地传递数据。但是，应用程序试图提供的特定服务可能会影响设计决策。可靠多播传输最基本的服务模型是“批量传输”，这是本领域和其他相关领域的主要关注点
RMT working group documents. However, the same principles in protocol design may also be applied to other services models, e.g., more interactive exchanges of small messages such as with white-boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
RMT工作组文件。然而，协议设计中的相同原则也可应用于其他服务模型，例如，更具互动性的小消息交换，如白板或文本聊天。在这些不同的模型中，存在一些问题，例如发送方缓存传输数据（或引用数据的状态）以便重新传输或修复的能力。根据数据内容，对组中成员之间的传输和接收序列中的顺序和/或因果关系的需求可能不同。组通信范式与点对点模型的显著不同之处在于，根据数据内容类型，一些接收器可以完成部分数据内容的接收，并且能够在其他成员接收到内容之前对其采取行动。这对于某些应用可能是可接受的（甚至是可取的），但对于其他应用则不是。这些不同的需求推动了对许多不同协议实例化设计的需求。开发普遍有用的构建块机制的一个重大挑战是在不定义特定的应用程序级细节的情况下，甚至可以容纳有限范围的这些功能。
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
组通信与点对点通信的不同之处在于，即使组的组成发生变化，通信的“线程”仍然存在。这与点对点通信模型形成对比，在点对点通信模型中，如果双方中的任何一方离开，则通信过程（数据交换）终止（或至少暂停）。根据应用程序目标，参与可靠多播传输“会话”的发送方和接收方可能能够延迟加入、离开和/或潜在地重新加入，而正在进行的组通信“线程”仍然保持功能和有用。还要注意，这可能会影响协议消息内容。如果支持“延迟加入者”，则可以在消息头中放置一些附加信息以适应此功能。或者，如果认为对典型消息传输的开销的影响太大，则可以在其自己的消息中发送信息（按需或间歇）。组动态还可能影响其他协议机制，如NACK定时、拥塞控制操作等。
The relationship of senders and receivers among group members requires consideration. In some applications, there may be a single sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender _and_ receiver of data may exist.
需要考虑组成员之间发送者和接收者的关系。在某些应用中，可能存在单个发送方对一组接收方的多播。在其他情况下，可能有多个发送者，或者组中的每个人都有可能成为数据的发送者和接收者。
Native IP multicast [2] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-oriented protocol can apply without NACK implosion problems. Research suggests that NORM group sizes on the order of tens of thousands of receivers may operate with modest feedback to the sender using probabilistic, timer-based suppression techniques [7]. However, the potential for router assistance and/or other NACK suppression heuristics may enable these protocols to scale to very large group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
本机IP多播[2]可以扩展到非常大的组大小。一些应用程序可能需要随着多播基础设施的扩展能力进行扩展。在其最简单的形式中，面向NACK的协议可以应用的组大小存在限制，而不会出现NACK内爆问题。研究表明，使用基于定时器的概率抑制技术，数万个接收机数量级的标准组可能会向发送方提供适度反馈[7]。然而，路由器协助和/或其他NACK抑制启发式的潜力可能使这些协议能够扩展到非常大的组大小。在大规模情况下，可能禁止成员对集团中的所有其他成员（特别是其他接收者）保持状态。在开发适用的构建块时，需要考虑群体规模的影响。
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer-based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and for the sender of data to identify appropriate content for efficient repair transmission. For example, backoff timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at a cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
在设计面向NACK的协议时，需要在可伸缩性和数据交付延迟之间进行权衡。如果要使用基于计时器的概率NACK抑制，NACK过程中会有一些延迟，以允许发生抑制，并让数据发送者识别适当的内容以进行有效的修复传输。例如，退避超时可用于确保有效的NACK抑制和修复传输，但这是以增加发送延迟和增加发送方和接收方的缓冲要求为代价的。构建块应允许应用程序为数据交付性能建立界限。请注意，应用程序设计人员必须了解在应用此类边界时所做的可伸缩性权衡。
The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively operating across a wide range of the networks to which general purpose IP service applies. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite and other wireless communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fan-out" to which IP multicast service is highly applicable. Additionally, policy and/or technical issues may result in topologies where multicast
Internet协议历来承担着跨异构网络拓扑提供服务的角色。期望可靠的多播协议能够在应用通用IP服务的广泛网络上有效地操作。今天，单个组成员之间链路上的可用带宽可能在无线链路的低kbit/s和高速LAN连接的多Gbit/s之间变化，来自其他流的争用程度不同。最近，包括56K/ADSL调制解调器、有线电视互联网服务、卫星和其他无线通信服务在内的许多非对称网络服务开始激增。其中许多是固有的广播媒体，具有潜在的大“扇出”，IP多播服务非常适用于这些媒体。此外，策略和/或技术问题可能导致多播
connectivity is limited to a single source multicast (SSM) model from a specific source [8]. Receivers in the group may be restricted to unicast feedback for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks.
连接仅限于来自特定源的单源多播（SSM）模型[8]。组中的接收机可被限制为针对nack和其他消息的单播反馈。在构建块开发和协议设计中，必须考虑底层网络的性质。
While intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to leverage the performance and scalability of reliable multicast protocols, there will continue to be a number of instances where this is not available or practical. Any building block components for NACK-oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
虽然可以使用直接了解底层网络拓扑的设备/系统提供的中间协助来利用可靠多播协议的性能和可伸缩性，但仍有许多实例不可用或不实用。面向NACK的可靠多播的任何构建块组件应能够在没有此类协助的情况下运行。然而，建议这样的协议也考虑在可用时利用这些特征。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NORM building block identification/design. This section describes different building block areas applicable to NORM protocols. Some of these areas are specific to NACK-oriented protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those other general building block areas from the standpoint of NACK-oriented reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NORM protocols.
上一节介绍了协议构建块的作用以及可能影响规范构建块识别/设计的一些标准。本节描述了适用于NORM协议的不同构建块区域。其中一些领域特定于面向NACK的协议。提供了这些区域的详细说明。在其他情况下，这些区域（例如，节点标识符、前向纠错（FEC）等）可适用于其他形式的可靠多播。在这些情况下，下面的讨论从面向NACK的可靠多播的角度描述了对这些其他通用构建块区域的要求。在适用的情况下，参考其他构建块文件，以对规范协议做出可能的贡献。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NORM building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
对于每个构建块，提供了概念上的“接口描述”，以说明一个构建块组件对另一个构建块组件或其他协议参数的依赖关系。构建块组件可能需要来自另一个构建块组件或其他源的某种形式的“输入”来执行其功能。构建块组件所需的任何“输入”和/或提供的任何结果“输出”将在每个构建块组件的接口描述中定义和描述。请注意，这里提供的构建块集不能完全满足彼此的“输入”和“输出”需求。在某些情况下，此处构建块的“输入”必须来自本文档外部的其他构建块（例如，拥塞控制或FEC）。在其他情况下，特定协议实例化或实现（例如，应用程序数据和控制）必须满足标准构建块“输入”。
The following building block components relevant to NORM are identified:
确定了与NORM相关的以下构建块组件：
(NORM-Specific) 1) NORM Sender Transmission 2) NORM Repair Process 3) NORM Receiver Join Policies (General Purpose) 4) Node (member) Identification 5) Data Content Identification 6) Forward Error Correction (FEC) 7) Round-trip Timing Collection 8) Group Size Determination/Estimation 9) Congestion Control Operation 10) Router/Intermediate System Assistance 11) Ancillary Protocol Mechanisms
（特定于规范）1）规范发送方传输2）规范修复过程3）规范接收方加入策略（通用）4）节点（成员）标识5）数据内容标识6）前向纠错（FEC）7）往返时间收集8）组大小确定/估计9）拥塞控制操作10）路由器/中间系统协助11）辅助协议机制
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
图1提供了这些构建块区域及其一些关系的图形概述。例如，发送方最初发送的数据消息的内容取决于“节点标识”、“数据内容标识”和“FEC”组件，而消息传输速率通常取决于“拥塞控制”组件。随后，接收器对这些传输的响应（例如，为维修而呼叫）将取决于数据消息内容和来自其他构建块组件的输入。最后，发送方对接收方响应的处理将反馈到其传输策略中。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------' _.-' `-----------------------' |
.---------------------. _.-' .' | .--------------. |
| Data Identification |--' .'' | | Join Policy | |
`---------------------' .' ' v `--------------' |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK | |
| `---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| `---------------------'` `._ | `------------------' | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------' .`- ` | `------------------' | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------'`. ` ` | `------------------' | |
.---------------------. ` ` ` `------------------------' |
| Other | ` ` ` | .-----------------. |
`---------------------' ` ` ` | |Router Assistance| |
`. ` ` v `-----------------' |
`.`' .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------'
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------' _.-' `-----------------------' |
.---------------------. _.-' .' | .--------------. |
| Data Identification |--' .'' | | Join Policy | |
`---------------------' .' ' v `--------------' |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK | |
| `---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| `---------------------'` `._ | `------------------' | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------' .`- ` | `------------------' | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------'`. ` ` | `------------------' | |
.---------------------. ` ` ` `------------------------' |
| Other | ` ` ` | .-----------------. |
`---------------------' ` ` ` | |Router Assistance| |
`. ` ` v `-----------------' |
`.`' .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Fig. 1 - NORM Building Block Framework
图1-标准构建块框架
The components on the left side of this figure are areas that may be applicable beyond NORM. The most significant of these components are discussed in other building block documents such as [9]. A brief description of these areas and their role in the NORM protocol is given below. The components on the right are seen as specific to NORM protocols, most notably the NACK repair process. These areas are discussed in detail below. Some other components (e.g., "Security") impact many aspects of the protocol, and others such as "Router Assistance" may be more transparent to the core protocol processing. The sections below describe the "NORM Sender
本图左侧的部件是可能超出标准适用范围的区域。这些组件中最重要的部分将在其他构建块文档（如[9]）中讨论。下文简要介绍了这些领域及其在NORM协议中的作用。右侧的组件被视为特定于NORM协议，最显著的是NACK修复过程。下面将详细讨论这些领域。一些其他组件（如“安全”）影响协议的许多方面，而其他组件（如“路由器协助”）可能对核心协议处理更加透明。以下各节介绍了“标准发送器”
Transmission", "NORM Repair Process", and "RTT Collection" building blocks in detail. The relationships to and among the other building block areas are also discussed, focusing on issues applicable to NORM protocol design. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NORM transport for the Internet.
“变速器”、“标准维修流程”和“RTT采集”“积木的细节。还讨论了与其他构建块区域之间的关系，重点讨论了适用于规范协议设计的问题。在适用的情况下，对适当满足互联网标准传输目标的机制提出了具体的技术建议。
NORM senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of [9]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), NORM transmission SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from NORM senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
标准发送方将向多播会话传输数据内容。数据内容将取决于应用程序。发送方将以应用程序和/或网络架构要求确定的速率和消息大小传输数据内容。发送方传输的任何FEC编码应符合[9]的指南。当需要拥塞控制机制时（一般互联网操作需要），规范传输应由拥塞控制机制控制。在任何情况下，建议来自标准发送方的所有数据传输都受到应用程序或拥塞控制算法确定的速率限制的约束。发送方的传输应充分利用可用容量（可能受到应用程序和/或拥塞控制的限制）。因此，预计新数据内容传输将与修复内容重叠和复用。与应用程序操作相关的其他因素可能决定发送方传输格式和方法。例如，当发送方没有数据传输时，需要考虑发送方在间歇空闲期间的行为。
In addition to data content, other sender messages or commands may be employed as part of protocol operation. These messages may occur outside of the scope of application data transfer. In NORM protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require following the rules of the NORM NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK-oriented responses from the receivers to this command.
除了数据内容之外，还可以使用其他发送方消息或命令作为协议操作的一部分。这些消息可能发生在应用程序数据传输范围之外。在NORM协议中，当由于组大小可伸缩性的考虑而禁止肯定确认时，可以通过冗余传输来尝试这种协议消息的可靠性。请注意，协议设计应提供处理组未收到此类消息的情况的机制。例如，命令消息可能由发送方冗余传输，以指示其暂时（或永久）停止传输。此时，接收者可能适合按照NACK标准程序的规则，对其要求的任何未完成维修作出NACK响应。为了提高效率，发送方应在冗余传输之间留出足够的时间，以便从接收方接收任何面向NACK的对此命令的响应。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NORM protocol timeouts should be dependent upon the group greatest round trip timing (GRTT) estimate
通常，当存在任何结果NACK或其他反馈操作时，发送方发出的控制消息的冗余传输时间和其他NORM协议超时应取决于组最大往返时间（GRTT）估计
and any expected resultant NACK or other feedback operation. The NORM GRTT is an estimate of the worst-case round-trip timing from a sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to given sender. NORM instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
以及任何预期的结果NACK或其他反馈操作。范数GRTT是对从发送方到组中任何接收方的最坏情况下往返时间的估计。假定GRTT间隔是网络拓扑中多播组相对于给定发送方的最大跨度（相对于延迟）的保守估计。规范实例化应该能够动态地适应广泛的多播网络拓扑。
Sender Transmission Interface Description
发送方传输接口说明
Inputs:
投入：
1) Application data and control 2) Sender node identifier 3) Data identifiers 4) Segmentation and FEC parameters 5) Transmission rate 6) Application controls 7) Receiver feedback messages (e.g., NACKs)
1) 应用程序数据和控制2）发送方节点标识符3）数据标识符4）分段和FEC参数5）传输速率6）应用程序控制7）接收方反馈消息（例如，NACK）
Outputs:
产出：
1) Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the NORM session. 2) Commands indicating sender's status or other transport control actions to be taken.
1) 消息的受控传输，消息头唯一标识NORM会话上下文中的数据或修复内容。2） 指示发送方状态或要采取的其他传输控制操作的命令。
A critical component of NORM protocols is the NACK repair process. This includes the receiver's role in detecting and requesting repair needs, and the sender's response to such requests. There are four primary elements of the NORM repair process:
NORM协议的一个关键组件是NACK修复过程。这包括接收方在检测和请求维修需求方面的作用，以及发送方对此类请求的响应。NORM维修流程有四个主要要素：
1) Receiver NACK process initiation,
1) 接收器NACK进程启动，
3) NACK suppression,
3) NACK抑制，
2) NACK message content,
2) NACK消息内容，
4) Sender NACK processing and response.
4) 发送方NACK处理和响应。
The NORM NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should
NORM NACK过程（周期）将由检测到需要修复来自特定发送方的传输以实现可靠接收的接收器启动。当应用FEC时，接收器应
initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the NORM data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
仅当已知NACK过程的修复要求超过给定数据内容编码块的未决FEC传输量时，才启动NACK过程。这可以在当前传输块结束时（如果指示）或在开始接收后续编码块或传输对象时确定。这意味着对范数数据内容进行标记以识别其FEC块号，并按照传输顺序保留顺序关系。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK processor earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events such as at the end-of-transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
或者，如果发送方的传输播发它已经计划为块发送的修复分组的数量，则接收机可能能够更早地启动NACK处理器。允许接收机在检测到其维修需求已超过待维修传输的任何时候启动NACK周期，可能会导致维修周期稍微加快。然而，将NACK过程发起限制为特定事件，例如在FEC编码块的传输结束时或在检测到后续编码块时，可能是有用的。这可以允许接收机将NACK内容聚合成更小数量的NACK消息，并在接收机集合之间提供一些隐式的松散同步，以帮助促进对NACK反馈的有效概率抑制。接收方必须保存从发送方收到的数据内容的历史记录，以确定其当前的修复需求。当采用FEC时，预期历史将对应于挂起或部分接收的编码块的记录。
For probabilistic, timer-base suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the current position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
对于基于定时器的概率反馈抑制，NACK周期应从接收机观察退避超时开始。在启动该退避超时的同时，接收机必须记录发送方传输序列中的当前位置，在该位置，接收机启动NACK循环。当抑制退避超时结束时，接收机在做出发送或抑制NACK的决定时，应该只考虑到其所需的传输位置直到所记录的传输位置。在没有该限制的情况下，当NACK消息通过网络传播到发送方和其他接收方期间从发送方接收到额外内容时，抑制被大大降低。
Receiver NACK Process Initiation Interface Description
接收机NACK进程启动接口说明
Inputs:
投入：
1) Sender data content with sequencing identifiers from sender transmissions. 2) History of content received from sender.
1) 发送方数据内容，带有来自发送方传输的序列标识符。2） 从发件人接收的内容的历史记录。
Outputs:
产出：
1) NACK process initiation decision 2) Recorded sender transmission sequence position.
1) NACK进程启动决定2）记录发送方传输序列位置。
An effective NORM feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [10]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or provide some other indicator of the repair information it will be subsequently transmitting.
一种有效的范数反馈抑制机制是在需要维修的接收机进行NACK传输之前使用随机退避超时[10]。退避超时到期后，接收方将请求修复，除非其待修复需求已被从其他接收方（当接收方正在多播NACK时）或从发送方的某个指示符听到的NACK消息完全取代。当接收机单播NACK消息时，发送方可以通过将其接收到的NACK内容的表示转发给整个组来促进NACK抑制，或者提供其随后将要发送的修复信息的一些其他指示符。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [6]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of sender<->group GRTT and a group size estimate that is determined by other mechanisms within the protocol or preset by the multicast application.
为了有效且可扩展的抑制性能，接收机使用的退避超时时间应由具有截断指数分布的接收机独立随机选取[6]。这导致在假设较小数量的“早期nacker”将取代组中其余部分的修复需求的情况下，大多数接收机组延迟NACK消息的传输。应将分布的平均值确定为发送方<->组GRTT的当前估计值和由协议内的其他机制确定或由多播应用程序预设的组大小估计值的函数。
A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g., NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T_maxBackoff) can be set to control reliable delivery latency versus volume of feedback traffic. A larger value of T_maxBackoff will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T_maxBackoff results in shorter latency which also reduces the buffering requirements of senders and receivers for reliable transport.
可以构造一个简单的算法来生成具有适当分布的随机退避超时。此外，该算法可被设计为在给定可能产生反馈的接收机（R）的数目的情况下优化退避分布。这种“优化”使所有接收机生成NACK的最坏情况下的反馈消息（例如，NACK）的数量最小化。可以设置最大退避超时（T_maxBackoff），以控制可靠的传递延迟与反馈流量的关系。T_maxBackoff的较大值将导致给定维修周期的反馈流量密度较低。T_maxBackoff的值越小，延迟越短，这也降低了发送方和接收方对可靠传输的缓冲要求。
Given the receiver group size (R), and maximum allowed backoff timeout (T_maxBackoff), random backoff timeouts (t') with a truncated exponential distribution can be picked with the following algorithm:
给定接收器组大小（R）和最大允许退避超时（T_maxBackoff），可以使用以下算法选择具有截断指数分布的随机退避超时（T’）：
1) Establish an optimal mean (L) for the exponential backoff based on the group size:
1) 根据组大小确定指数退避的最佳平均值（L）：
L = ln(R) + 1
L = ln(R) + 1
2) Pick a random number (x) from a uniform distribution over a range of:
2) 从以下范围内的均匀分布中选择一个随机数（x）：
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
3) Transform this random variate to generate the desired random backoff time (t') with the following equation:
3) 使用以下等式转换此随机变量以生成所需的随机退避时间（t’）：
t' = T_maxBackoff/L * ln(x * (exp(L) - 1) * (T_maxBackoff/L))
t' = T_maxBackoff/L * ln(x * (exp(L) - 1) * (T_maxBackoff/L))
This C language function can be used to generate an appropriate random backoff time interval:
此C语言函数可用于生成适当的随机退避时间间隔：
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following C code can be used:
其中UniformRand（double max）返回均匀分布范围为0..max的随机数。例如，基于POSIX“rand（）”函数，可以使用以下C代码：
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
The number of expected NACK messages generated (N) within the first round trip time for a single feedback event is approximately:
对于单个反馈事件，在第一次往返时间内生成的预期NACK消息数量（N）约为：
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
Thus the maximum backoff time can be adjusted to tradeoff worst-case NACK feedback volume versus latency. This is derived from [6] and assumes T_maxBackoff >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above.
因此，可以调整最大退避时间，以权衡最坏情况下的NACK反馈量与延迟。这是从[6]中推导出来的，假设T_maxBackoff>=GRTT，L是针对给定组大小优化的分布平均值，如上面的算法所示。
Note that other mechanisms within the protocol may work to reduce redundant NACK generation further. It is suggested that T_maxBackoff be selected as an integer multiple of the sender's current advertised GRTT estimate such that:
注意，协议内的其他机制可用于进一步减少冗余NACK生成。建议选择T_maxBackoff作为发送方当前公布的GRTT估计值的整数倍，以便：
T_maxBackoff = K * GRTT ;where K >= 1
T_maxBackoff = K * GRTT ;where K >= 1
For general Internet operation, a default value of K=4 is RECOMMENDED for operation with multicast (to the group at large) NACK delivery and a value of K=6 for unicast NACK delivery. Alternate values may be used to for buffer utilization, reliable delivery latency and group size scalability tradeoffs.
对于一般的Internet操作，对于多播（对整个组）NACK交付的操作，建议使用默认值K=4，对于单播NACK交付，建议使用默认值K=6。备选值可用于缓冲区利用率、可靠的传递延迟和组大小可伸缩性权衡。
Given that (K*GRTT) is the maximum backoff time used by the receivers to initiate NACK transmission, other timeout periods related to the NACK repair process can be scaled accordingly. One of those timeouts is the amount of time a receiver should wait after generating a NACK message before allowing itself to initiate another NACK backoff/transmission cycle (T_rcvrHoldoff). This delay should be sufficient for the sender to respond to the received NACK with repair messages. An appropriate value depends upon the amount of time for the NACK to reach the sender and the sender to provide a repair response. This MUST include any amount of sender NACK aggregation period during which possible multiple NACKs are accumulated to determine an efficient repair response. These timeouts are further discussed in the section below on "Sender NACK Processing and Repair Response".
假设（K*GRTT）是接收机用于发起NACK传输的最大退避时间，则与NACK修复过程相关的其他超时时间可以相应地缩放。其中一个超时是在生成NACK消息之后，接收机在允许自己启动另一个NACK退避/传输周期（T_rcvrHoldoff）之前应等待的时间量。此延迟应足以使发送方通过修复消息响应接收到的NACK。适当的值取决于NACK到达发送方和发送方提供修复响应的时间量。这必须包括任何数量的发送方NACK聚合期，在此期间可能会累积多个NACK以确定有效的修复响应。这些超时将在下文“发送方NACK处理和修复响应”一节中进一步讨论。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
还有一些辅助措施可用于改善反馈抑制的性能。例如，发送方的数据内容传输可以遵循顺序传输序列。当对数据内容进行修复时，接收机可以通过观察数据对象、FEC块号和FEC符号标识符来注意到发送方已经“重绕”了其数据内容传输位置。接收方应将NACK的传输限制为仅当发送方的当前传输位置超过接收方接收不完全的点时。这减少了发送方可能计划为响应其他接收方请求而提供的数据修复过早请求。当来自其他接收器（或来自发送方的指示符）的nack的传输丢失时，该机制对于高丢失条件下的协议收敛非常有效。另一种机制（当使用FEC时特别适用）用于发送方在当前发送的分组中嵌入即将进行的修复传输的指示。例如，该指示可以简单到为当前适用编码块发送的FEC分组的数量的广告。
Finally, some consideration might be given to using the NACKing history of receivers to weight their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires there is correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not be present in multicast networks. This adjustment of backoff timeout selection may require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process that may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network.
最后，可以考虑使用接收机的NACK历史来加权其NACK退避超时间隔的选择。例如，如果一个接收器在历史上经历了最大程度的损失，那么它可能会比其他接收器更快地将自己提升到统计上的NACK。注：这要求接收机所经历的损失在连续的时间间隔内存在相关性。这种相关性在多播网络中可能不存在。退避超时选择的调整可能需要为这些历史nacker创建“早期NACK”插槽。NACK退避窗口中的这一额外插槽将导致更长的维修周期，这对于某些应用来说可能是不可取的。这些权衡的解决方案可能取决于协议的目标应用程序集或网络。
After the random backoff timeout has expired, the receiver will make a decision on whether to generate a NACK repair request or not (i.e., it has been suppressed). The NACK will be suppressed when any of the following conditions has occurred:
在随机退避超时过期之后，接收器将决定是否生成NACK修复请求（即，它已被抑制）。当出现以下任一情况时，NACK将被抑制：
1) The accumulated state of NACKs heard from other receivers (or forwarding of this state by the sender) is equal to or supersedes the repair needs of the local receiver. Note that the local receiver should consider its repair needs only up to the sender transmission position recorded at the NACK cycle initiation (when the backoff timer was activated).
1) 从其他接收者听到的nack的累积状态（或发送者转发此状态）等于或取代本地接收者的修复需求。注意，本地接收器应该只考虑到在NACK周期启动时记录的发送器发送位置（当激活退避定时器时）。
2) The sender's data content transmission position "rewinds" to a point ordinally less than that of the lowest sequence position of the local receiver's repair needs. (This detection of sender "rewind" indicates the sender has already responded to other receiver repair needs of which the local receiver may not have been aware). This "rewind" event can occur any time between 1) when the NACK cycle was initiated with the backoff timeout activation and 2) the current moment when the backoff timeout has expired to suppress the NACK. Another NACK cycle must be initiated by the receiver when the sender's transmission sequence position exceeds the receiver's lowest ordinal repair point. Note it is possible that the local receiver may have had its repair needs satisfied as a result of the sender's response to the repair needs of other receivers and no further NACKing is required.
2) 发送方的数据内容传输位置“倒回”到一个点，该点顺序小于本地接收方修复需求的最低序列位置。（检测到发送方“倒带”表明发送方已经响应了本地接收方可能不知道的其他接收方维修需求）。该“倒带”事件可以在1）通过退避超时激活启动NACK循环和2）退避超时过期以抑制NACK的当前时刻之间的任何时间发生。当发送方的传输序列位置超过接收方的最低顺序修复点时，接收方必须启动另一个NACK循环。注：由于发送方对其他接收方的维修需求作出响应，本地接收方可能已经满足了其维修需求，因此不需要进一步的NACK。
If these conditions have not occurred and the receiver still has pending repair needs, a NACK message is generated and transmitted. The NACK should consist of an accumulation of repair needs from the receiver's lowest ordinal repair point up to the current sender transmission sequence position. A single NACK message should be generated and the NACK message content should be truncated if it exceeds the payload size of single protocol message. When such NACK
如果这些情况尚未发生，且接收器仍有待修复需求，则生成并发送NACK消息。NACK应包括从接收器最低顺序维修点到当前发送器传输序列位置的维修需求累积。应生成单个NACK消息，如果NACK消息内容超过单个协议消息的有效负载大小，则应截断NACK消息内容。当这样的NACK
payload limits occur, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender.
当出现有效负载限制时，NACK内容应包含对发送方所需的通常最低修复内容的请求。
NACK Suppression Interface Description
NACK抑制接口描述
Inputs:
投入：
1) NACK process initiation decision. 2) Recorded sender transmission sequence position. 3) Sender GRTT. 4) Sender group size estimate. 5) Application-defined bound on backoff timeout period. 6) NACKs from other receivers. 7) Pending repair indication from sender (may be forwarded NACKs). 8) Current sender transmission sequence position.
1) NACK进程启动决策。2） 记录发送器传输顺序位置。3） 发送方：GRTT。4） 发送方组大小估计。5） 应用程序定义的回退超时绑定。6） 来自其他接收器的nack。7） 发送方的待修复指示（可转发至NACKs）。8） 当前发送器传输顺序位置。
Outputs:
产出：
1) Yes/no decision to generate NACK message upon backoff timer expiration.
1) 是/否决定在退避计时器到期时生成NACK消息。
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NORM can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
可靠多播接收器生成的NACK消息的内容将包括详细说明其当前修复需求的信息。具体信息取决于正常维修过程中FEC的使用和类型。维修需求的识别取决于数据内容识别（见下文第3.5节）。在最高级别，NACK内容将标识NACK所寻址的发送方以及发送方传输中需要修复的数据传输对象（或流）。对于所指示的传输实体，NACK内容随后将识别重构完整传输数据所需的特定FEC编码块和/或符号。该内容可以包括FEC块擦除计数和/或数据和FEC内容的丢失块或符号（段）的明确指示。还应该注意的是，可以使用这里讨论的技术有效地实例化NORM，而不需要可靠的NACK交付。
Where FEC-based repair is used, the NACK message content will minimally need to identify the coding block(s) for which repair is needed and a count of erasures (missing packets) for the coding block. An exact count of erasures implies the FEC algorithm is capable of repairing _any_ loss combination within the coding block.
在使用基于FEC的修复的情况下，NACK消息内容将最低限度地需要识别需要修复的编码块以及编码块的擦除计数（丢失的分组）。擦除的精确计数意味着FEC算法能够修复编码块内的任何丢失组合。
This count may need to be adjusted for some FEC algorithms. Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually affect repair. For a most efficient repair strategy, the NACK content will need to also _explicitly_ identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small to medium size block FEC codes (e.g., Reed Solomon) that are capable of provided a limited number of parity symbols per FEC coding block.
对于某些FEC算法，可能需要调整此计数。考虑到成功完成修复可能需要多轮修复，擦除计数还意味着服务器可传输的唯一FEC奇偶校验数据包的数量基本上是无限的（即，服务器将始终能够提供新的、唯一的、以前未发送的奇偶校验包，以响应对同一编码块的任何后续修复请求）。或者，发送方可以“循环”通过给定编码块的可用FEC符号集进行传输，并最终影响修复。为了实现最有效的修复策略，NACK内容还需要明确标识哪些符号（信息和/或奇偶校验）接收机需要成功地重构编码块的内容。对于能够为每个FEC编码块提供有限数量奇偶校验符号的中小型块FEC码（例如，Reed Solomon码），尤其如此。
When FEC is not used as part of the repair process, or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the delay*bandwidth*loss characteristics of the network topology), the NACK content will need to contain _explicit_ coding block and/or segment loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set.
当FEC未作为修复过程的一部分使用时，或者即使发送方已传输了给定编码块的所有可用奇偶校验，也需要协议实例化来提供可靠性时（或者发送方缓冲传输历史的能力被网络拓扑的延迟*带宽*损耗特性所超出），NACK内容将需要包含u显式u编码块和/或段丢失信息，以便发送方能够提供适当的修复包和/或数据重传。NACK内容中的明确丢失信息也可能用于其他目的。例如，它可以用于解相关一组接收机之间的损耗特性，以帮助区分接收机集合之间的候选拥塞控制瓶颈。
When FEC is used and NACK content is designed to contain explicit repair requests, there is a strategy where the receivers can NACK for specific content that will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity symbols to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block (e.g., Reed Solomon) is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of data content to the group.
当使用FEC并且NACK内容被设计为包含明确的修复请求时，存在一种策略，其中接收机可以针对特定内容进行NACK，这将有助于促进NACK抑制和修复效率。该策略的假设是，发送方可能会耗尽其对给定编码块可用的新的、唯一的奇偶校验包的供应，并且需要显式地重新传输一些数据或奇偶校验符号以完成可靠的传输。另一个假设是使用FEC算法，其中任何奇偶校验分组可以填充编码块内的任何擦除（例如，Reed-Solomon）。此策略的目标是最大限度地利用可用奇偶校验，并在向集团可靠传输数据内容的过程中提供最少的数据量并修复传输。
When systematic FEC codes are used, the sender transmits the data content of the coding block (and optionally some quantity of parity packets) in its initial transmission. Note that a systematic FEC coding block is considered to be logically made up of the contiguous set of data vectors plus parity vectors for the given FEC algorithm
当使用系统FEC码时，发送方在其初始传输中传输编码块的数据内容（以及可选的一些奇偶校验分组）。注意，系统FEC编码块被认为在逻辑上由给定FEC算法的连续数据向量集加奇偶校验向量组成
used. For example, a coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
习惯于例如，为每个编码块提供64个数据符号和32个奇偶校验符号的编码方案将包含0到95范围内的FEC符号标识符。
Receivers then can construct NACK messages requesting sufficient content to satisfy their repair needs. For example, if the receiver has three erasures in a given received coding block, it will request transmission of the three lowest ordinal parity vectors in the coding block. In our example coding scheme from the previous paragraph, the receiver would explicitly request parity symbols 64 to 66 to fill its three erasures for the coding block. Note that if the receiver's loss for the coding block exceeds the available parity quantity (i.e., greater than 32 missing symbols in our example), the receiver will be required to construct a NACK requesting all (32) of the available parity symbols plus some additional portions of its missing data symbols in order to reconstruct the block. If this is done consistently across the receiver group, the resulting NACKs will comprise a minimal set of sender transmissions to satisfy their repair needs.
然后，接收器可以构造NACK消息，请求足够的内容以满足其修复需求。例如，如果接收机在给定的接收编码块中有三次擦除，它将请求传输编码块中的三个最低顺序奇偶校验向量。在上一段中的示例编码方案中，接收机将明确请求奇偶校验符号64到66以填充编码块的三次擦除。注意，如果接收机对编码块的丢失超过可用奇偶校验数量（即，在我们的示例中大于32个缺失符号），则接收机将被要求构造NACK，请求所有（32）可用奇偶校验符号加上其缺失数据符号的一些附加部分，以便重构块。如果在整个接收机组中一致地执行此操作，则产生的nack将包括最小的发送方传输集，以满足其修复需求。
In summary, the rule is to request the lower ordinal portion of the parity content for the FEC coding block to satisfy the erasure repair needs on the first NACK cycle. If the available number of parity symbols is insufficient, the receiver will also request the subset of ordinally highest missing data symbols to cover what the parity symbols will not fill. Note this strategy assumes FEC codes such as Reed-Solomon for which a single parity symbol can repair any erased symbol. This strategy would need minor modification to take into account the possibly limited repair capability of other FEC types. On subsequent NACK repair cycles where the receiver may have received some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender or intermediate systems assisting NACK operation.
总之，规则是请求FEC编码块的奇偶校验内容的较低顺序部分以满足第一NACK周期上的擦除修复需要。如果奇偶校验符号的可用数量不足，则接收器还将请求顺序最高的缺失数据符号的子集，以覆盖奇偶校验符号不会填充的内容。注：该策略假设FEC代码（如Reed Solomon）的单个奇偶校验符号可以修复任何已擦除符号。该策略需要稍作修改，以考虑到其他FEC类型的维修能力可能有限。在接收机可能已经接收到其先前请求的修复内容的某些部分的后续NACK修复周期上，接收机将使用相同的策略，但仅对其尚未接收到的奇偶校验和/或数据符号集使用NACK。可选地，接收机还可以提供擦除计数，以方便发送方或辅助NACK操作的中间系统。
After receipt and accumulation of NACK messages during the aggregation period, the sender can begin transmission of fresh (previously untransmitted) parity symbols for the coding block based on the highest receiver erasure count _if_ it has a sufficient quantity of parity symbols that were _not_ previously transmitted. Otherwise, the sender MUST resort to transmitting the explicit set of repair vectors requested. With this approach, the sender needs to maintain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use the same consistent algorithm to express their explicit repair needs, NACK suppression among receivers is simplified over the course of multiple repair cycles. The receivers
在聚合期间接收和累积NACK消息之后，发送方可以基于最高的接收方擦除计数开始为编码块传输新的（先前未传输的）奇偶校验符号，前提是其具有足够数量的先前未传输的奇偶校验符号。否则，发送方必须发送请求的修复向量的显式集合。使用这种方法，发送方需要在从组收到的请求上保持很少的状态，而不需要同步来自组的修复请求。由于所有接收机使用相同的一致性算法来表达其明确的修复需求，因此在多个修复周期的过程中简化了接收机之间的NACK抑制。接受者
can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages.
可以简单地将从其他接收器听到的NACK与它们自己计算的修复需求进行比较，以确定它们是否应该发送或抑制其挂起的NACK消息。
The format of NACK content will depend on the protocol's data service model and the format of data content identification the protocol uses. This NACK format also depends upon the type of FEC encoding (if any) used. Figure 2 illustrates a logical, hierarchical transmission content identification scheme, denoting that the notion of objects (or streams) and/or FEC blocking is optional at the protocol instantiation's discretion. Note that the identification of objects is with respect to a given sender. It is recommended that transport data content identification is done within the context of a sender in a given session. Since the notion of session "streams" and "blocks" is optional, the framework degenerates to that of typical transport data segmentation and reassembly in its simplest form.
NACK内容的格式将取决于协议的数据服务模型和协议使用的数据内容标识格式。此NACK格式还取决于所使用的FEC编码类型（如果有）。图2说明了一个逻辑、分层传输内容标识方案，表示对象（或流）和/或FEC阻塞的概念是由协议实例化决定的可选概念。请注意，对象的标识与给定的发送者有关。建议在给定会话中的发送方上下文中进行传输数据内容标识。由于会话“流”和“块”的概念是可选的，因此该框架退化为典型的传输数据分割和重组的最简单形式。
Session_ \_ Sender_ \_ [Object/Stream(s)]_ \_ [FEC Blocks]_ \_ Symbols
会话\发送方\对象/流\ FEC块\符号
Fig. 2: NORM Data Content Identification Hierarchy
图2：规范数据内容标识层次结构
The format of NACK messages should meet the following goals:
NACK消息的格式应满足以下目标：
1) Able to identify transport data unit transmissions required to repair a portion of the received content, whether it is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1) 能够识别修复所接收内容的一部分所需的传输数据单元传输，无论它是整个缺失对象/流（或范围）、整个FEC编码块或符号集，
2) Be simple to process for NACK aggregation and suppression,
2) NACK聚集和抑制过程简单，
3) Be capable of including NACKs for multiple objects, FEC coding blocks and/or symbols in a single message, and
3) 能够在单个消息中包括多个对象的nack、FEC编码块和/或符号，以及
4) Have a reasonably compact format.
4) 有一个合理紧凑的格式。
If the NORM transport object/stream is identified with an <objectId>
and the FEC symbol being transmitted is identified with an
<fecPayloadId>, the concatenation of <objectId::fecPayloadId>
If the NORM transport object/stream is identified with an <objectId>
and the FEC symbol being transmitted is identified with an
<fecPayloadId>, the concatenation of <objectId::fecPayloadId>
comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receivers repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
包括用于来自给定源的符号的基本传输协议数据单元（TPDU）标识符。NACK内容可以由这些TPDU标识符的列表和/或范围组成，以建立NACK消息来描述接收机的修复需求。如果没有使用分层对象描绘或FEC块，则TPDU是发送方发送的数据符号的简单线性表示。当TPDU表示用于对象/流描绘和/或FEC阻塞的层次时，NACK内容单元可能需要标志来指示TPDU的哪个部分是适用的。例如，如果接收到的数据中缺少整个“对象”（或对象范围），则接收器不一定知道要请求修复的<sourceBlockNumbers>或<encodingsymbols>的适当范围，因此需要某种机制来请求修复（或重传）由<objectId>表示的整个单元。如果由一个或一系列<sourceBlockNumbers>表示的整个FEC编码块丢失，情况也是如此。
NACK Content Interface Description
NACK内容接口描述
Inputs:
投入：
1) Sender identification. 2) Sender data identification. 3) Sender FEC Object Transmission Information. 4) Recorded sender transmission sequence position. 5) Current sender transmission sequence position. History of repair needs for this sender.
1) 发送者标识。2） 发送方数据标识。3） 发送方FEC对象传输信息。4） 记录发送器传输顺序位置。5） 当前发送器传输顺序位置。此发件人的维修需求历史记录。
Outputs:
产出：
1) NACK message with repair requests.
1) 带有修复请求的NACK消息。
Upon reception of a repair request from a receiver in the group, the sender will initiate a repair response procedure. The sender may wish to delay transmission of repair content until it has had sufficient time to accumulate potentially multiple NACKs from the receiver set. This allows the sender to determine the most efficient repair strategy for a given transport stream/object or FEC coding block. Depending upon the approach used, some protocols may find it beneficial for the sender to provide an indicator of pending repair transmissions as part of its current transmitted message content. This can aid some NACK suppression mechanisms. The amount of time to perform this NACK aggregation should be sufficient to allow for the maximum receiver NACK backoff window ("T_maxBackoff" from Section 3.2.2) and propagation of NACK messages from the receivers to the sender. Note the maximum transmission delay of a message from a
在接收到来自组中接收者的维修请求后，发送者将启动维修响应程序。发送方可能希望延迟修复内容的传输，直到其有足够的时间从接收方集合累积潜在的多个nack为止。这允许发送方确定给定传输流/对象或FEC编码块的最有效修复策略。根据所使用的方法，一些协议可能会发现，发送方提供未决修复传输的指示符作为其当前传输的消息内容的一部分是有益的。这有助于某些NACK抑制机制。执行此NACK聚合的时间量应足以允许最大的接收器NACK退避窗口（“第3.2.2节中的T_maxBackoff”）以及NACK消息从接收器传播到发送者。请注意来自服务器的消息的最大传输延迟
receiver to the sender may be approximately (1*GRTT) in the case of very asymmetric network topology with respect to transmission delay. Thus, if the maximum receiver NACK backoff time is T_maxBackoff = K*GRTT, the sender NACK aggregation period should be equal to at least:
在关于传输延迟的非常不对称的网络拓扑的情况下，发送方的接收机可以是大约（1×GRTT）。因此，如果最大接收方NACK退避时间为T_maxBackoff＝K×GRTT，则发送方NACK聚合周期应至少等于：
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
Immediately after the sender NACK aggregation period, the sender will begin transmitting repair content determined from the aggregate NACK state and continue with any new transmission. Also, at this time, the sender should observe a "holdoff" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "holdoff" time should be:
在发送方NACK聚合周期之后，发送方将立即开始传输根据聚合NACK状态确定的修复内容，并继续任何新的传输。此外，此时，发送方应观察到一个“延迟”期，其中它限制自己启动新的NACK聚合期，以允许由于对接收器组的修复响应而传播新的传输序列位置。为了考虑最坏情况下的不对称性，该“延迟”时间应为：
T_sndrHoldoff = 1*GRTT
T_sndrHoldoff = 1*GRTT
Recall that the receivers will also employ a "holdoff" timeout after generating a NACK message to allow time for the sender's response. Given a sender <T_sndrAggregate> plus <T_sndrHoldoff> time of (K+1)*GRTT, the receivers should use holdoff timeouts of:
回想一下，在生成NACK消息之后，接收方还将采用“延迟”超时，以允许发送方有时间作出响应。给定发送方<T_sndrAggregate>加上<T_sndrHoldoff>时间（K+1）*GRTT，接收方应使用以下延迟时间：
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
This allows for a worst-case propagation time of the receiver's NACK to the sender, the sender's aggregation time and propagation of the sender's response back to the receiver. Additionally, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) a representation of its aggregated NACK content to the group to allow for NACK suppression when there is not multicast connectivity among the receiver set.
这允许接收机的NACK向发送方的最坏情况传播时间、发送方的聚合时间以及发送方的响应向接收机的传播。另外，在来自接收器集的单播反馈的情况下，发送方将其聚集的NACK内容的表示转发（经由多播）到组以允许在接收器集之间不存在多播连接时抑制NACK是有用的。
At the expiration of the <T_sndrAggregate> timeout, the sender will begin transmitting repair messages according to the accumulated content of NACKs received. There are some guidelines with regards to FEC-based repair and the ordering of the repair response from the sender that can improve reliable multicast efficiency:
在<T_sndrAggregate>超时过期时，发送方将根据接收到的nack的累积内容开始发送修复消息。关于基于FEC的修复以及发送方修复响应的排序，有一些准则可以提高可靠的多播效率：
1) When FEC is used, it is beneficial that the sender transmit previously untransmitted parity content as repair messages whenever possible. This maximizes the receiving nodes' ability to reconstruct the entire transmitted content from their individual subsets of received messages.
1) 当使用FEC时，发送方尽可能将先前未传输的奇偶校验内容作为修复消息传输是有益的。这最大限度地提高了接收节点从其接收消息的单个子集重构整个传输内容的能力。
2) The transmitted object and/or stream data and repair content should be indexed with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content (e.g., ordinally lowest FEC blocks) first, the receivers can use a strategy of withholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help work to keep repair cycles relatively synchronized without dependence upon strict time synchronization among the sender and receivers. This also helps minimize the buffering requirements of receivers and senders and reduces redundant transmission of data to the group at large.
2) 传输的对象和/或流数据和修复内容应以单调递增的序列号（在相当大的顺序空间内）进行索引。如果发送方首先遵守发送对最早内容（例如，顺序最低的FEC块）的修复的规程，则接收方可以使用一种策略，在发送方再次返回到对象/流传输序列中的该点之前，扣留对随后内容的修复请求。这可以提高组中的整体消息效率，并有助于保持修复周期相对同步，而不依赖发送方和接收方之间的严格时间同步。这也有助于最小化接收器和发送器的缓冲要求，并减少向整个组的冗余数据传输。
Sender Repair Response Interface Description
发送方修复响应接口描述
Inputs:
投入：
1) Receiver NACK messages 2) Group timing information
1) 接收机NACK消息2）组定时信息
Outputs
输出
1) Repair messages (FEC and/or Data content retransmission) 2) Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
1) 修复消息（FEC和/或数据内容重传）2）当检测到单播接收器反馈时，当前未决修复传输的通告。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies limiting the opportunities when receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance, in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
应考虑新接收器加入一个组（可能在可靠传输已经进行的情况下）并开始请求修复的政策和程序。如果接收器连接不受限制，组成员身份的动态可能会妨碍应用程序实现其数据传输向前推进目标的能力。当接收者开始参与NACK过程时限制机会的策略可用于实现期望的行为。例如，接收机仅在对象或流的逻辑部分的第一FEC块中的数据的非修复传输时才尝试从新听到的发送方可靠接收可能是有益的。发送方还可以实现限制其将从中接受NACK请求的接收方的策略，但在某些情况下，由于可伸缩性的原因，这可能是禁止的。或者，在某些类型的批量传输应用程序（或潜在的交互式可靠多播应用程序）中，可能希望具有更宽松的传输同步策略并依赖会话管理机制来限制可能导致性能差的组动态。
Group Join Policy Interface Description
组加入策略接口描述
Inputs:
投入：
1) Current object/stream data/repair content and sequencing identifiers from sender transmissions.
1) 来自发送方传输的当前对象/流数据/修复内容和序列标识符。
Outputs:
产出：
1) Receiver yes/no decision to begin receiving and NACKing for reliable reception of data
1) 接收器是/否决定开始接收和呼叫以可靠接收数据
In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field should be present in packets transmitted by reliable multicast session members.
在可能存在多个数据源的NORM协议（或其他多播协议）中，有必要提供某种机制来唯一地标识组内的源（在某些情况下可能是一些或所有接收器）。基于到达的数据包源地址的标识不充分，原因有几个。这些原因包括具有多个接口的主机的路由更改，这些更改会随着时间的推移导致给定主机的不同数据包源地址，网络地址转换（NAT）或防火墙设备，或其他传输/网络桥接方法。因此，可靠多播会话成员传输的数据包中应该存在某种类型的唯一源标识符<sourceId>字段。
The data and repair content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/reassembly, caching, integrated forward error correction coding, etc.) rather than being
NORM发送方传输的数据和修复内容需要在协议头字段中进行某种形式的标识。这种识别是为了促进可靠的NACK导向维修过程。这些标识符也将用于生成的NACK消息中。此构建块文档假定两种非常通用的数据类型，它们可能包含批量传输会话内容。一种是有限大小的静态离散对象，另一种是连续的非有限流。给定的应用程序可能希望使用这些范例中的一种或两种来可靠地多播数据内容。虽然某些应用程序可能进一步推广此模型，并提供将静态对象封装为嵌入流中的内容的机制，但在许多应用程序中，在可靠多播会话的上下文中为静态批量对象和消息提供独特的支持具有优势。这些应用程序可能包括内容缓存服务器、文件传输或具有批量内容的协作工具。对这些静态对象类型有需求的应用程序可以利用传输层机制（即分段/重组、缓存、集成前向纠错编码等），而不是
required to provide their own mechanisms for these functions at the application layer.
需要在应用层为这些功能提供自己的机制。
As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-real-time message broadcasts (e.g., stock ticker) or some content types that are part of collaborative tools or other applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g., files) into one or more streams within a multicast session.
如所注意到的，一些应用可替换地希望以一个或多个非有限大小的流的形式传输批量内容。示例流包括连续的准实时消息广播（例如股票行情）或作为协作工具或其他应用程序一部分的某些内容类型。并且，如上所述，一些应用程序可能希望将其他批量内容（例如，文件）封装到多播会话内的一个或多个流中。
The components described within this building block document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast session. To support this requirement, the normal data content identification should include a field to uniquely identify the object or stream <objectId> within some reasonable temporal or ordinal interval. Note that it is _not_ expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
本构建块文档中描述的组件预计将适用于这两种模型，并可能在单个多播会话中混合使用这两种类型。为支持此要求，正常数据内容标识应包括一个字段，以在某个合理的时间或顺序间隔内唯一标识对象或流<objectId>。请注意，不期望此数据内容标识是全局唯一的。预期在可靠多播会话内以及在发送方支持该对象或流的特定传输实例期间，对象/流标识符相对于给定发送方将是唯一的。
Since the "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier that has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Building Block document [9] provides a standard message format for identifying FEC transmission content. NORM protocol instantiations using FEC SHOULD follow that document's guidelines.
由于“批量”对象/流内容通常需要分段，因此还必须提供某种形式的分段标识。该段标识符将与已提供的任何对象或流标识符相关。因此，在某些情况下，NORM协议实例化可以并行地接收多个流和一组或多组静态对象的传输并请求修复。对于使用FEC的协议实例化，数据内容标识符的段标识部分可以包括编码块标识符<sourceBlockNumber>和用于特定数据或码块的奇偶校验符号<encodingsymbol>的标识符的逻辑级联。FEC构建块文档[9]提供了用于识别FEC传输内容的标准消息格式。使用FEC的NORM协议实例化应遵循该文档的指导原则。
Additionally, flags to determine the usage of the content identifier fields (e.g., stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations.
此外，用于确定内容标识符字段（例如，流与对象）的使用的标志可能适用。标志还可以用于数据内容标识中的其他目的。预计定义的任何标志都将取决于各个协议实例。
In summary, the following data content identification fields may be required for NORM protocol data content messages:
总之，NORM协议数据内容消息可能需要以下数据内容标识字段：
1) Source node identifier (<sourceId>)
1) 源节点标识符（<sourceId>）
2) Object/Stream identifier (<objectId>), if applicable.
2) 对象/流标识符（<objectId>），如果适用。
3) FEC Block identifier (<sourceBlockNumber>), if applicable.
3) FEC块标识符（<sourceBlockNumber>），如果适用。
4) FEC Symbol identifier (<encodingSymbolId>)
4) FEC符号标识符（<encodingSymbolId>）
5) Flags to differentiate interpretation of identifier fields or identifier structure that implicitly indicates usage.
5) 用于区分隐式指示用法的标识符字段或标识符结构的解释的标志。
6) Additional FEC transmission content fields per FEC Building Block
6) 每个FEC构建块的附加FEC传输内容字段
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NORM protocols that use these data content fields should also be compatible with support for intermediate system assistance to reliable multicast transport operation when available.
这些字段已被标识，因为任何生成的NACK消息都将在请求修复或重新传输数据时使用这些标识符。使用这些数据内容字段的NORM协议还应与支持可靠多播传输操作的中间系统协助（如果可用）兼容。
Multiple forward error correction (FEC) approaches have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [11], [12], [13]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NORM, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [14]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large delay*bandwidth product with some nominal level of expected packet loss. While the application of FEC is not unique to NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
已经确定了多种前向纠错（FEC）方法，它们可以为面向NACK和其他可靠多播协议的修复过程提供极大的性能增强[11]、[12]、[13]。NORM协议可以获得额外的好处，因为基于FEC的修复通常不需要在其编码块大小（以符号为单位）的范围内明确了解修复内容。在NORM中，生成的奇偶校验修复包通常仅在响应来自接收节点的NACK修复请求时发送。然而，在一些网络环境中，传输与常规数据符号传输复用的一些预定数量的FEC修复分组是有益的[14]。当组大小非常大或网络连接具有较大的延迟*带宽积且具有某种标称水平的预期分组丢失时，这可以减少产生的NACK通信量，而开销成本相对较小。虽然FEC的应用不是NORM独有的，但这些类型的需求可能决定了适用的算法和协议方法的类型。
A specific issue related to the use of FEC with NORM is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId::sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [9] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
与使用具有NORM的FEC相关的一个特定问题是用于识别特定FEC分组适用的传输数据内容的部分的机制。预计FEC算法将基于为相应的传输数据分组块生成一组奇偶校验修复分组。由于数据内容包在传输过程中通过连接<sourceId:：objectId:：sourceBlockNumber:：EncodingSymbolicId>进行唯一标识，因此预计FEC包将以类似的方式进行标识。FEC构建块文档[9]提供了有关FEC应用和相关可靠多播协议消息标准格式的详细建议。
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for increased efficiency [15]. And in some cases, there might be absolute time synchronization among hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various timeouts used by receivers.
需要测量组成员之间的分组传播往返时间（RTT），以支持基于计时器的NACK抑制算法、发送方命令的定时或某些修复功能以及拥塞控制操作。收集的往返信息的性质取决于小组成员之间的互动类型。在仅需要“一对多”传输的情况下，可能只有发送方需要接收机组中最大RTT（GRTT）的RTT知识和/或仅组的一部分的RTT知识。在这里，GRTT信息可以以合理可伸缩的方式收集。对于拥塞控制操作，组中的每个接收机可能需要RTT信息。在这种情况下，可以使用替代RTT收集方案，其中接收机收集关于发送方的单个RTT测量，并将它们通告给组或发送方。如果可靠的多播数据很可能在组之间以“多对多”的方式进行交换，则可以采用其他测量技术来提高效率[15]。在某些情况下，主机之间可能存在绝对时间同步，从而简化RTT测量。在指定RTT（或GRTT）测量的通用建议之前，需要进一步考虑多播拥塞控制设计中的权衡。无论如何收集有关拥塞控制或其他要求的RTT信息（更具体地说是GRTT），发送方都需要向集团公布其当前GRTT估计值，以供接收方使用各种超时。
The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
这种形式的RTT测量的目的是让发送方在积极参与规范操作的接收方中学习GRTT。参与该过程的接收器集可以是整个组或从协议实例化内的另一机制确定的组的某个子集。以下是收集GRTT信息的方法。
The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a <sendTime> timestamp relative to an internal clock at the sender. Upon reception of this message, the receivers will record this <sendTime> timestamp and the time (referenced to their own clocks) at which it was received <recvTime>. When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantiation specification), it will construct a "response" using the formula:
发送方周期性地使用包含相对于发送方内部时钟的<sendTime>时间戳的消息（与其他传输独立或“背负”）轮询组。收到此消息后，接收者将记录此<sendTime>时间戳和接收该消息的时间（参考他们自己的时钟）。当接收方向发送方提供反馈时（明确地或作为其他反馈消息的一部分，具体取决于协议实例化规范），它将使用以下公式构造“响应”：
grttResponse = sendTime + (currentTime - recvTime)
grttResponse = sendTime + (currentTime - recvTime)
where the <sendTime> is the timestamp from the last probe message received from the source and the (<currentTime> - <recvTime>) is the amount of time differential since that request was received until the receiver generated the response.
其中，<sendTime>是从源接收到的最后一条探测消息的时间戳，（<currentTime>-<recvTime>）是自接收到该请求到接收器生成响应的时间差量。
The sender processes each receiver response by calculating a current RTT measurement for the receiver from whom the response was received using the following formula:
发送方通过使用以下公式计算接收到响应的接收方的当前RTT测量值来处理每个接收方响应：
RTT_rcvr = currentTime - grttResponse
RTT_rcvr = currentTime - grttResponse
During the each periodic GRTT probing interval, the source keeps the peak round trip timing measurement (RTT_peak) from the set of responses it has received. A conservative estimate of GRTT is kept to maximize the efficiency of redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules:
在每个周期性GRTT探测间隔期间，震源根据其接收到的响应集保持峰值往返时间测量（RTT_peak）。保留GRTT的保守估计，以最大限度地提高冗余NACK抑制和修复聚合的效率。根据以下规则更新来源对GRTT的持续估计：
1) If a receiver's response round trip time (RTT_rcvr) is greater than the current GRTT estimate, the GRTT is immediately updated to this new peak value:
1) 如果接收器的响应往返时间（RTT_rcvr）大于当前GRTT估计值，则GRTT立即更新为该新峰值：
GRTT = RTT_rcvr
GRTT = RTT_rcvr
2) At the end of the response collection period (i.e., the GRTT probe interval), if the recorded "peak" response RTT_peak) is less than the current GRTT estimate, the GRTT is updated to:
2) 在响应收集期结束时（即GRTT探测间隔），如果记录的“峰值”响应RTT_峰值）小于当前GRTT估计值，则GRTT更新为：
GRTT = MAX(0.9*GRTT, RTT_peak)
GRTT = MAX(0.9*GRTT, RTT_peak)
3) If no feedback is received, the sender GRTT estimate remains unchanged.
3) 如果没有收到反馈，发送方GRTT估计值保持不变。
4) At the end of the response collection period, the peak tracking value (RTT_peak) is reset to ZERO for subsequent peak detection.
4) 在响应收集周期结束时，峰值跟踪值（RTT_peak）重置为零，以进行后续峰值检测。
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation
GRTT收集周期（即探测传输周期）可以固定在组成员资格和/或网络拓扑动态预期值的顺序上。为了稳健性，在协议启动时，在稳定到较不频繁的稳态间隔之前，可以使用更快速的探测。可选地，可以开发算法来响应于当前GRTT估计（或其变化）和分组丢失估计动态地调整GRTT收集周期。当GRTT估计值稳定且不变时，探测消息的开销可以减少，但可以调整以在变化期间更动态地跟踪
with correspondingly shorter GRTT collection periods. GRTT collection may also be coupled with collection of other information for congestion control purposes.
相对较短的GRTT收集期。出于拥塞控制目的，GRTT收集还可以与其他信息的收集相结合。
In summary, although NORM repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not _strictly_ depend on highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
总之，尽管规范修复周期超时基于GRTT，但应注意，协议的收敛操作并不严格依赖于高精度GRTT估计。目前的机制已在仿真和迄今为止部署了类似范数协议的环境中证明是足够的。该算法提供的估计值跟踪实际GRTT的峰值包络（包括操作系统影响以及网络延迟），即使在相对较高的连接损失情况下也是如此。稳态探测/更新间隔可能会有所不同，以适应不同环境中不同级别的预期网络动态。
In this approach, receivers send messages with timestamps to the sender. To control the volume of these receiver-generated messages, a suppression mechanism similar to that described for NACK suppression my be used. The "age" of receivers' RTT measurement should be kept by receivers and used as a metric in competing for feedback opportunities in the suppression scheme. For example, receiver who have not made any RTT measurement or whose RTT measurement has aged most should have precedence over other receivers. In turn the sender may have limited capacity to provide an "echo" of the receiver timestamps back to the group, and it could use this RTT "age" metric to determine which receivers get precedence. The sender can determine the GRTT as described in 3.7.1 if it provides sender timestamps to the group. Alternatively, receivers who note their RTT is greater than the sender GRTT can compete in the feedback opportunity/suppression scheme to provide the sender and group with this information.
在这种方法中，接收者向发送者发送带有时间戳的消息。为了控制这些接收器生成的消息的数量，可以使用与NACK抑制类似的抑制机制。接收机RTT测量的“年龄”应由接收机保持，并用作在抑制方案中竞争反馈机会的度量。例如，未进行任何RTT测量或RTT测量老化最严重的接收器应优先于其他接收器。反过来，发送方可能有有限的能力向组提供接收方时间戳的“回声”，并且它可以使用此RTT“年龄”度量来确定哪些接收方获得优先权。如果发送方向组提供发送方时间戳，则发送方可以按照3.7.1中所述确定GRTT。或者，注意到其RTT大于发送方GRTT的接收方可以在反馈机会/抑制方案中竞争，以向发送方和组提供此信息。
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and sender's "b" and "c", it is likely that:
对于涉及多个发送方的可靠多播会话，在真正的“多对多”基础上进行RTT测量可能有用，而不是让每个发送方独立跟踪RTT。当接收者可以基于他们在另一个发送者上拥有的RTT信息以及该另一个发送者关于感兴趣的新发送者的RTT推断出他们相对于发送者的RTT的近似值时，可以获得一些协议效率。例如，对于接收方“a”和发送方的“b”和“c”，很可能：
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT to a small subset of other group members and RTT information among those other group members it learns during protocol operation.
如果节点可获得关于其自身对其他组成员的一小部分的RTT的RTT信息以及其在协议操作期间学习到的那些其他组成员中的RTT信息，则可对该估计进行进一步细化。
To facilitate deterministic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate to a single byte of information. The following C-language functions allows this to be done over a wide range (RTT_MIN through RTT_MAX) of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for RTT_MIN and RTT_MAX respectively. NORM applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
为了促进确定性范数协议的操作，发送方应该向接收方集合可靠地公布其当前的GRTT估计。对于发送方当前运行的GRTT估计值，集团内部的共同、可靠的知识将使协议以最有效的方式进行。发送方的GRTT估计值可以通过简单地将估计值嵌入发送方发送的所有相关消息中而可靠地通告给组。通过将GRTT估计量化（压缩）为一个字节的信息，可以使其开销非常小。以下C语言函数允许在较宽的GRTT值范围内（RTT_MIN到RTT_MAX）执行此操作，同时保持较小GRTT值的较大精度范围和较大值的较小精度范围。RTT_最小值和RTT_最大值建议分别为1.0e-06秒和1000秒。NORM应用程序可能希望对发送方公布的GRTT设置一个附加的、较小的上限，以满足应用程序数据交付延迟的限制，但在某些网络环境中会以更大的反馈量为代价。
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
请注意，此功能可用于量化1微秒至1000秒范围内的GRTT时间。当然，出于实际原因，NORM协议实现可能希望进一步限制公布的GRTT估计（例如，限制最大值）。
When NORM protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of a group size determination mechanism a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NORM usage.
当NORM协议操作包括激发来自整个组的反馈的机制（例如，拥塞控制）时，可以基于接收到的关于所使用的概率抑制机制的分布的反馈消息的数量粗略估计组大小。注意：本文档中描述的基于计时器的抑制机制不需要非常准确的组大小估计来充分执行。因此，一个粗略的估计，特别是如果保守的管理，可能就足够了。组大小也可以通过管理来确定。在没有组大小确定机制的情况下，建议使用默认的组大小值10000，以便根据预期规范使用的可伸缩性合理管理反馈。
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [16] or Pragmatic General Multicast Congestion Control (PGMCC) techniques [17] may be applied to NORM operation to meet this requirement.
一般的Internet操作需要拥塞控制，它与其他可靠的多播和TCP实例公平地共享可用的网络容量。TCP友好多播拥塞控制（TFMCC）[16]或实用通用多播拥塞控制（PGMCC）技术[17]可应用于规范操作以满足此要求。
NACK-oriented protocols may benefit from general purpose router assistance. In particular, additional NACK suppression where routers or intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NORM protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Both of these types of assist functions would require router interpretation of transport data unit content identifiers and flags.
面向NACK的协议可能受益于通用路由器协助。具体地说，额外的NACK抑制（路由器或中间系统可以在NACK内容中继到发送方时聚合来自接收器的NACK内容（或过滤重复的NACK内容）可以增强标准组大小的可伸缩性。对于使用FEC的NORM协议，中间系统可能能够过滤FEC修复消息，以根据从先前接收器nack学习到的修复需求，向多播拓扑的不同分支提供修复内容的智能“子类别”。这两种类型的辅助功能都需要路由器解释传输数据单元内容标识符和标志。
The NORM building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed negative-acknowledgement (NACK)-oriented reliable multicast
规范构建块适用于希望使用否定确认来实现可靠数据传输的协议。面向正确设计的否定确认（NACK）可靠组播
(NORM) protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the scalability property of NACK-oriented protocols [18], [19] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NORM protocols can make use of reciprocal (among senders and receivers) multicast communication under the Any-Source Multicast (ASM) model defined in RFC 1112 [2], and are capable of scalable operation in asymmetric topologies such as Single-Source Multicast (SSM) [8] where there may only be unicast routing service from the receivers to the sender(s).
（NORM）协议为应用和/或网络拓扑提供了可扩展性优势，其中，由于各种原因，禁止在基本第3层IP多播服务（例如，单播或混合单播/多播数据分发树）之上构建更高阶的交付基础设施。此外，面向NACK的协议[18]、[19]的可伸缩性属性适用于单个网络跳（例如，有线电视数据传输、卫星或其他广播通信服务）的广泛“扇出”。此外，基于“扁平”组范围多播分布的协议的简单性可为广泛的分布式服务或动态网络和应用提供优势。NORM协议可以利用RFC 1112[2]中定义的任意源多播（ASM）模型下的互惠（发送方和接收方之间）多播通信，并且能够在非对称拓扑中进行可伸缩操作，例如单源多播（SSM）[8]，其中可能只有从接收方到发送方的单播路由服务（s） 。
NORM operation is compatible with transport layer forward error correction coding techniques as described in [13] and congestion control mechanisms such as those described in [16] and [17]. A principal limitation of NORM operation involves group size scalability when network capacity for receiver feedback is very limited. NORM operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
NORM操作与[13]中描述的传输层前向纠错编码技术以及[16]和[17]中描述的拥塞控制机制兼容。NORM操作的一个主要限制是当接收反馈的网络容量非常有限时，组大小的可伸缩性。NORM操作也由实现缓冲约束控制。建议使用大于典型点到点可靠传输（如TCP）所需的缓冲，以允许接收器组连接中存在差异，并允许实现组大小可伸缩性所需的反馈延迟。
NORM protocols are expected to be subject to the same sort of security vulnerabilities as other IP and IP multicast protocols. NORM is compatible with IP security (IPsec) authentication mechanisms [20] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK based protocols is that of NACK replay attacks that would prevent a NORM sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. Additionally, NORM protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. The IETF Multicast Security (msec) Working Group is also developing solutions which may be applicable to NORM in the future.
NORM协议与其他IP和IP多播协议一样，预计会受到相同类型的安全漏洞的影响。NORM与IP安全（IPsec）身份验证机制[20]兼容，该机制建议用于防止会话入侵和拒绝服务攻击。基于NACK的协议的一个特殊威胁是NACK重播攻击，该攻击会阻止NORM发送方在传输过程中向前推进。建议使用任何可针对此类重播攻击提供保护的标准IPsec机制。另外，当网络层机制不可用时，规范协议实例化应该考虑为自己的NACK重放攻击保护提供支持。IETF多播安全（msec）工作组也在开发未来可能适用于NORM的解决方案。
The authors would like to thank Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
作者要感谢Rick Jones和Joerg Widmer对本文件的宝贵意见。作者还要感谢RMT工作组主席Roger Kermode和Lorenzo Vicisano对本规范开发的支持，以及Sally Floyd对本文件的早期投入。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[3] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[3] Mankin，A.，Romanow，A.，Bradner，S.，和V.Paxson，“评估可靠多播传输和应用协议的IETF标准”，RFC 2357，1998年6月。
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages 201--208, September 1990.
[4] Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”。在过程中。ACM SIGCOMM，第201-208页，1990年9月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[5] Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[6] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback," in IEEE Infocom, San Francisco, California, p. 964, March/April 1998.
[6] NIENMACHER，J和E. Biersack，“最佳多播反馈”，在IEEE iFocom，旧金山，加利福尼亚，P.1998年3月/4月，第964页。
[7] Macker, J. and R. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002.
[7] Macker，J.和R.Adamson，“面向Nack的可靠多播（NORM）反馈的定量预测”，Proc。IEEE MILCOM 2002，2002年10月。
[8] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[8] 霍尔布鲁克，H.，“多播的信道模型”，博士。斯坦福大学计算机科学系博士论文，斯坦福，加利福尼亚，2001年8月。
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[9] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[10] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang. "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[10] Floyd，S.，Jacobson，V.，McCanne，S.，Liu，C.，和L.Zhang。“用于轻量级会话和应用程序级帧的可靠多播框架”，Proc。ACM SIGCOMM，1995年8月。
[11] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications, Vol. Com-32, No.6, June 1984.
[11] 梅茨纳，J.，“一种改进的广播重传协议”，IEEE通信事务，卷Com-32，第6期，1984年6月。
[12] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97, October 1997.
[12] Macker，J.，“基于前向纠错的可靠多播传输和集成擦除”，Proc。IEEE MILCOM 97，1997年10月。
[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[13] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[14] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOM 98'.
[14] Gossink，D.和J.Macker，“具有信道估计的可靠多播和集成奇偶重传”，IEEE GLOBECOM 98。
[15] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[15] Ozdemir，V.，Muthukrishnan，S.，和I.Rhee，“可扩展的低开销网络延迟估计”，NCSU/AT&T白皮书，1999年2月。
[16] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, August 2001.
[16] Widmer，J.和M.Handley，“将基于方程的拥塞控制扩展到多播应用”，Proc ACM SIGCOMM 2001，圣地亚哥，2001年8月。
[17] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[17] Rizzo，L.，“pgmcc：一种TCP友好的单速率多播拥塞控制方案”，Proc ACM SIGCOMM 2000，斯德哥尔摩，2000年8月。
[18] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[18] Pingali，S.，Towsley，D.，和J.Kurose，“发送方发起和接收方发起的可靠多播协议的比较”。在过程中。信息通信公司，旧金山，CA，1993年10月。
[19] B.N. Levine, J.J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct 29--Nov 1, 1996.
[19] B.N.Levine，J.J.Garcia Luna Aceves，“可靠多播协议已知类别的比较”，Proc。网络协议国际会议（ICNP-96），俄亥俄州哥伦布，1996年10月29日至11月1日。
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Brian Adamson Naval Research Laboratory Washington, DC 20375
布莱恩·亚当森海军研究实验室华盛顿特区20375
EMail: adamson@itd.nrl.navy.mil
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
EMail: cabo@tzi.org
EMail: cabo@tzi.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
马克·汉德利英国伦敦高尔街大学学院计算机科学系伦敦WC1E 6BT
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
乔·麦克尔海军研究实验室华盛顿特区20375
EMail: macker@itd.nrl.navy.mil
EMail: macker@itd.nrl.navy.mil
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。