[要約] RFC 5401は、マルチキャストネガティブアクノリッジメント（NACK）のビルディングブロックに関するものであり、マルチキャスト通信におけるエラー検出とフィードバックのためのプロトコルを提供することを目的としています。
Network Working Group B. Adamson
Request for Comments: 5401 Naval Research Laboratory
Obsoletes: 3941 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2008
Multicast Negative-Acknowledgment (NACK) Building Blocks
マルチキャストネガティブ継続型（NACK）ビルディングブロック
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (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 reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941.
このドキュメントでは、ネガティブ継承（NACK）フィードバックを利用する信頼性の高いマルチキャストプロトコルの作成について説明します。プロトコル設計の目標と仮定の理論的根拠が提示されています。NACKベースの（および場合によっては一般的な）信頼できるマルチキャストプロトコル操作の技術的課題が特定されています。これらの目標と課題は、信頼できるマルチキャストプロトコル操作のさまざまな側面に対処する一連の機能的な「ビルディングブロック」に解決されます。これらのビルディングブロックは、信頼性の高いマルチキャストプロトコルのさまざまなインスタンス化を生成するのに役立つと予想されます。このドキュメントは、RFC 3941を廃止します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Rationale .......................................................4
2.1. Delivery Service Model .....................................5
2.2. Group Membership Dynamics ..................................6
2.3. Sender/Receiver Relationships ..............................6
2.4. Group Size Scalability .....................................6
2.5. Data Delivery Performance ..................................7
2.6. Network Environments .......................................7
2.7. Intermediate System Assistance .............................8
3. Functionality ...................................................8
3.1. Multicast Sender Transmission .............................11
3.2. NACK Repair Process .......................................13
3.3. Multicast Receiver Join Policies and Procedures ...........26
3.4. Node (Member) Identification ..............................26
3.5. Data Content Identification ...............................27
3.6. Forward Error Correction (FEC) ............................28
3.7. Round-Trip Timing Collection ..............................29
3.8. Group Size Determination/Estimation .......................33
3.9. Congestion Control Operation ..............................34
3.10. Intermediate System Assistance ...........................34
4. NACK-Based Reliable Multicast Applicability ....................35
5. Security Considerations ........................................36
6. Changes from RFC 3941 ..........................................38
7. Acknowledgements ...............................................38
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
Reliable multicast transport is a desirable technology for 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 (see [RFC2357]). This document addresses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. NACK-based protocols generally entail less frequent feedback messaging than reliability protocols based on positive acknowledgment (ACK). The less frequent feedback messaging helps simplify the problem of feedback implosion as group size grows larger. While different protocol instantiations may be required to meet specific application and network architecture demands [ArchConsiderations], there are a number of fundamental components that may be common to these different instantiations.
信頼性の高いマルチキャストトランスポートは、インターネット上のグループにデータを効率的かつ信頼できる配布のための望ましい技術です。グループ通信パラダイムの複雑さは、さまざまな潜在的な信頼性の高いマルチキャストアプリケーションとユーザーのパフォーマンスとスケーラビリティの要件を満たすために、さまざまなプロトコルタイプとインスタンス化を必要とします（[RFC2357]を参照）。このドキュメントでは、ネガティブ継承（NACK）フィードバックを利用する信頼性の高いマルチキャストプロトコルの作成に対処します。NACKベースのプロトコルは、一般に、肯定的な確認（ACK）に基づいて信頼性プロトコルよりも頻度の低いフィードバックメッセージングを伴います。頻度の低いフィードバックメッセージングは、グループサイズが大きくなるにつれて、フィードバックの破壊の問題を簡素化するのに役立ちます。特定のアプリケーションおよびネットワークアーキテクチャの要求を満たすためには、さまざまなプロトコルインスタンス化が必要になる場合がありますが、これらの異なるインスタンスに共通する可能性のある基本的なコンポーネントがいくつかあります。
This document describes the framework and common "building block" components relevant to multicast protocols that are based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NACK-based reliable multicast protocol design, it specifically addresses in detail the following building blocks, which are not addressed in other IETF documents:
このドキュメントでは、主に信頼できる輸送のためのNACK操作に基づいたマルチキャストプロトコルに関連するフレームワークと一般的な「ビルディングブロック」コンポーネントについて説明します。このドキュメントでは、信頼できるマルチキャストコンポーネントの大規模なセットと、NACKベースの信頼できるマルチキャストプロトコル設計に関連する問題について説明しますが、他のIETFドキュメントでは対処されていない次のビルディングブロックに特に対処します。
1. NACK-based multicast sender transmission strategies,
1. NACKベースのマルチキャスト送信者伝送戦略、
2. NACK repair process with timer-based feedback suppression, and
2. タイマーベースのフィードバック抑制によるNACK修復プロセス、および
3. Round-trip timing for adapting NACK and other timers.
3. NACKやその他のタイマーを適応させるための往復タイミング。
NACK-based reliable multicast implementations SHOULD make use of Forward Error Correction (FEC) erasure coding techniques, as described in the FEC Building Block [RFC5052] document. Packet-level erasure coding allows missing packets from a given FEC block to be recovered using the parity packets instead of classical, individualized retransmission of original source data content. For this reason, this document refers to the protocol mechanisms for reliability as a "repair process." Note that NACK-based protocols can reactively provide the parity packets in response to receiver requests for repair rather than just proactively sending added FEC parity content as part of the original transmission. Hybrid proactive/reactive use of FEC content is also possible with the mechanisms described in this document. Some classes of FEC coding, such as Maximal Separable Distance (MDS) codes, allow senders to dynamically implement deterministic, highly efficient receiver group repair strategies as part of a NACK-based, selective automated repeat-request (ARQ) scheme.
NACKベースの信頼性の高いマルチキャスト実装は、FECビルディングブロック[RFC5052]ドキュメントで説明されているように、フォワードエラー補正（FEC）消去コーディング手法を使用する必要があります。パケットレベルの消去コーディングにより、特定のFECブロックから欠落しているパケットは、元のソースデータコンテンツの古典的で個別化された再送信の代わりに、パリティパケットを使用して回復できます。このため、このドキュメントは、信頼性のプロトコルメカニズムを「修理プロセス」として指します。NACKベースのプロトコルは、元の送信の一部として追加されたFECパリティコンテンツを積極的に送信するのではなく、修復の受信者要求に応じてパリティパケットを反応的に提供できることに注意してください。このドキュメントで説明されているメカニズムでは、FECコンテンツのハイブリッドプロアクティブ/反応的使用も可能です。最大分離距離（MDS）コードなどのFECコーディングの一部のクラスにより、送信者は、NACKベースの選択的自動化されたリピートリケスト（ARQ）スキームの一部として、決定論的で効率的なレシーバーグループ修復戦略を動的に実装できるようにします。
The potential relationships to other reliable multicast transport building blocks (e.g., FEC, congestion control) and general issues with NACK-based reliable multicast protocols are also discussed. This document follows the guidelines provided in [RFC3269].
他の信頼できるマルチキャスト輸送ビルディングブロック（FEC、輻輳制御など）とNACKベースの信頼できるマルチキャストプロトコルに関する一般的な問題との潜在的な関係についても説明します。このドキュメントは、[RFC3269]で提供されるガイドラインに従います。
Statement of Intent
主旨書
This memo contains descriptions of building blocks that can be applied in the design of reliable multicast protocols utilizing negative-acknowledgement (NACK) feedback. [RFC3941] contains a previous description of this specification. RFC 3941 was published in the "Experimental" category. It was the stated intent of the Reliable Multicast Transport (RMT) working group at that time to resubmit this specification as an IETF Proposed Standard in due course.
このメモには、ネガティブな概要（NACK）フィードバックを利用して信頼できるマルチキャストプロトコルの設計に適用できるビルディングブロックの説明が含まれています。[RFC3941]には、この仕様の以前の説明が含まれています。RFC 3941は「実験的」カテゴリに掲載されました。当時の信頼性の高いマルチキャスト輸送（RMT）ワーキンググループの指示された意図であり、この仕様をIETF提案された基準としてやりがいに再提出しました。
This Proposed Standard specification is thus based on [RFC3941] and has been updated according to accumulated experience and growing protocol maturity since the publication of RFC 3941. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
したがって、この提案された標準仕様は[RFC3941]に基づいており、RFC3941の出版以来、累積経験とプロトコルの成熟度の増加に応じて更新されています。。
The differences between [RFC3941] and this document are listed in Section 6.
[RFC3941]とこのドキュメントの違いは、セクション6にリストされています。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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,
1. 配達サービスモデル、
2. Group Membership Dynamics,
2. グループメンバーシップダイナミクス、
3. Sender/Receiver Relationships,
3. 送信者/レシーバーの関係、
4. Group Size Scalability,
4. グループサイズのスケーラビリティ、
5. Data Delivery Performance, and
5. データ配信パフォーマンス、および
6. Network Environments.
6. ネットワーク環境。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents, such as [RFC5052], have been created to address areas outside of the scope of this document. NACK-based reliable multicast 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 NACK-based reliable multicast but may be used in concert with the other building block areas. In some cases, a building block may be able to 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. The forms of "bulk data transfer" covered here include reliable transport of bulky, fixed-length, a priori static content and also transmission of non-predetermined, perhaps streamed, content of indefinite length. Section 3.5 discusses these different forms of bulk data content in further detail.
これらの領域はすべて、少なくとも簡単に説明します。さらに、[RFC5052]などのその他の信頼できるマルチキャストトランスポートビルディングブロックドキュメントが、このドキュメントの範囲外の領域に対処するために作成されています。NACKベースの信頼性の高いマルチキャストプロトコルインスタンス化は、これらの他のビルディングブロックと、ここに示されているものに依存する可能性があります。このドキュメントは、NACKベースの信頼できるマルチキャストに固有のエリアに焦点を当てていますが、他のビルディングブロックエリアと協力して使用できます。場合によっては、ビルディングブロックが幅広い仮定に対処できる場合がありますが、他のケースでは、さまざまなアプリケーションのニーズやオペレーティング環境を満たすために必要なトレードオフがあります。必要に応じて、ビルディングブロック機能は、さまざまな要件を満たすためにパラメトリックになるように設計されています。もちろん、根本的な目標は、設計の複雑さを最小限に抑え、典型的なインターネット環境で汎用「バルクデータ転送」要件を満たすパラメーターに少なくともデフォルト値を推奨することです。ここでカバーされている「バルクデータ転送」の形式には、かさばる、固定長、先験的な静的コンテンツの信頼できる輸送、および非提案された、おそらくストリーミングされた、無期限のコンテンツの送信が含まれます。セクション3.5では、これらのさまざまな形式のバルクデータコンテンツについてさらに詳しく説明します。
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. The most basic service model for reliable multicast transport is that of "bulk transfer", which is a primary focus of this and other related RMT working group documents. However, the same principles in protocol design may also be applied to other service 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.
信頼性の高いマルチキャストトランスポートプロトコルの暗黙の目標は、IPマルチキャストデータグラムサービスを使用して通信するメンバーのグループ間のデータの信頼できる配信です。ただし、アプリケーションが提供しようとしている特定のサービスは、設計上の決定に影響を与える可能性があります。信頼性の高いマルチキャストトランスポートの最も基本的なサービスモデルは、「バルク転送」のモデルであり、これはこの関連RMTワーキンググループドキュメントの主要な焦点です。ただし、プロトコル設計の同じ原則は、他のサービスモデルにも適用される場合があります。たとえば、ホワイトボードやテキストチャットなどの小さなメッセージのよりインタラクティブな交換。これらの異なるモデルには、送信または修理のために送信されたデータ（またはそれを参照する状態）をキャッシュする送信者の能力などの問題があります。グループ内のメンバー間のトランスミッションとレセプションのシーケンスにおける順序および/または因果関係のニーズは、データコンテンツによって異なる場合があります。グループ通信のパラダイムは、データコンテンツタイプに応じて、データコンテンツの一部の受信を完了し、他のメンバーがコンテンツを受け取る前にそれに基づいて行動できるようになる可能性があるという点で、ポイントツーポイントモデルとは大きく異なります。これは、一部のアプリケーションでは受け入れられる（または望ましい）場合もありますが、他のアプリケーションでは許容されません。これらのさまざまな要件は、さまざまなプロトコルインスタンスデザインの必要性を促進します。一般的に有用なビルディングブロックメカニズムの開発における重要な課題は、特定のアプリケーションレベルの詳細を定義せずに、これらの機能の限られた範囲でさえ対応することです。
Another factor impacting the delivery service model is the potential for different receivers in the multicast group to have significantly differing quality of network connectivity. This may involve receivers with very limited goodput due to connection rate or substantial packet loss. NACK-based protocol implementations may wish to provide policies by which extremely poor-performing receivers are excluded from the main group or migrated to a separate delivery group. Note that some application models may require that the entire group be constrained to the performance of the "weakest member" to satisfy operational requirements. In either case, protocol designs should consider this aspect of the reliable multicast delivery service model.
配信サービスモデルに影響を与えるもう1つの要因は、マルチキャストグループのさまざまなレシーバーがネットワーク接続の品質が大幅に異なる可能性です。これには、接続率または大幅なパケット損失のために、非常に限られたグッドプットのレシーバーが含まれる場合があります。NACKベースのプロトコルの実装は、非常にパフォーマンスの低い受信機がメイングループから除外されるか、別の配信グループに移行されるポリシーを提供したい場合があります。一部のアプリケーションモデルでは、運用要件を満たすためにグループ全体を「最も弱いメンバー」のパフォーマンスに制約する必要がある場合があることに注意してください。どちらの場合でも、プロトコル設計では、信頼できるマルチキャスト配信サービスモデルのこの側面を考慮する必要があります。
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.
グループ通信がポイントツーポイント通信と異なる領域の1つは、グループの構成が変化したとしても、通信の「スレッド」が存在する可能性があることです。これは、2つの当事者のいずれかが去る場合、通信プロセス（データの交換）が終了する（または少なくとも一時停止）されるポイントツーポイント通信モデルとは対照的です。アプリケーションの目標に応じて、信頼できるマルチキャストトランスポート「セッション」に参加する送信者と受信者は、進行中のグループ通信「スレッド」が依然として機能的かつ有用なままである間に、遅く、去る、および/または潜在的に再加入することができる場合があります。また、これはプロトコルメッセージコンテンツに影響を与える可能性があることに注意してください。「後期ジョイナー」がサポートされている場合、この機能に対応するために、いくつかの量の追加情報をメッセージヘッダーに配置することができます。あるいは、典型的なメッセージ送信のオーバーヘッドへの影響が大きすぎると見なされている場合、情報は、独自のメッセージ（オンデマンドまたは断続的に）で送信される場合があります。グループダイナミクスは、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 [RFC1112] 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-based protocol can be applied without the potential for the volume of NACK feedback messages to overwhelm network capacity. This is often referred to as "feedback implosion". Research suggests that NACK-based reliable multicast group sizes on the order of tens of thousands of receivers may operate with acceptable levels of feedback to the sender using probabilistic, timer-based suppression techniques [NormFeedback]. Instead of receivers immediately transmitting feedback messages when loss is detected, these techniques specify use of purposefully-scaled, random back-off timeouts such that some potential NACKing receivers can self-suppress their feedback upon hearing messages from other receivers that have selected shorter random timeout intervals. However, there may be additional NACK suppression heuristics that can be applied to enable these protocols to scale to even larger 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マルチキャスト[RFC1112]は、非常に大きなグループサイズにスケーリングする場合があります。一部のアプリケーションは、マルチキャストインフラストラクチャのスケーリング能力とともにスケーリングすることが望ましい場合があります。最も単純な形式では、NACKベースのプロトコルを適用できるグループサイズには、NACKフィードバックメッセージのボリュームがネットワーク容量を圧倒する可能性がなくても制限があります。これはしばしば「フィードバック爆発」と呼ばれます。調査によると、確率的でタイマーベースの抑制技術[NormFeedback]を使用して、何万人もの受信機の順序での信頼性の高いマルチキャストグループサイズが、送信者への受け入れ可能なレベルのフィードバックで動作する可能性があることが示唆されています。損失が検出されたときにすぐにフィードバックメッセージを送信する代わりに、これらの手法では、意図的にスケーリングされたランダムバックオフタイムアウトの使用を指定して、一部の潜在的なナッキングレシーバーが、より短いランダムタイムアウトを選択した他のレシーバーからの聴覚メッセージでフィードバックを自己抑制できるようにします。間隔。ただし、これらのプロトコルがさらに大きなグループサイズにスケーリングできるようにするために適用できる追加のNACK抑制ヒューリスティックがある場合があります。大規模な場合、メンバーがグループ内の他のすべてのメンバー（特に他の受信者）の状態を維持することは法外な場合があります。グループサイズの影響は、該当するビルディングブロックの開発において考慮する必要があります。
Group size scalability may also be aided by intermediate system assistance; see section 2.7 below.
グループサイズのスケーラビリティは、中間システムの支援によっても支援される場合があります。以下のセクション2.7を参照してください。
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 to allow the sender of data to identify appropriate content for efficient repair transmission. For example, back-off timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at the 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 connectivity is limited to a source-specific multicast (SSM) model from a specific source [RFC4607]. 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.
インターネットプロトコルは、歴史的に、異種ネットワークトポロジ全体でサービスを提供する役割を引き受けてきました。信頼できるマルチキャストプロトコルが、汎用IPサービスが適用される幅広いネットワークで効果的に動作できることが望ましいです。今日の単一グループのメンバー間のリンクで利用可能な帯域幅は、ワイヤレスリンクのKBIT/sの数が少ないことと、高速LAN接続の複数のGBIT/sによって異なり、他のフローからの程度の程度が異なります。最近、56K/ADSLモデム、CATVインターネットサービス、衛星、その他のワイヤレス通信サービスを含む多くの非対称ネットワークサービスが増殖し始めています。これらの多くは、IPマルチキャストサービスが非常に適用可能である潜在的に大きな「ファンアウト」を備えた本質的に放送メディアです。さらに、ポリシーおよび/または技術的な問題により、マルチキャスト接続が特定のソース[RFC4607]のソース固有のマルチキャスト（SSM）モデルに限定されるトポロジが生じる場合があります。グループ内の受信機は、NACKやその他のメッセージのユニキャストフィードバックに制限される場合があります。基礎となるネットワークの性質については、構成要素の開発とプロトコルの設計に考慮しなければなりません。
Intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to increase the performance and scalability of NACK-based reliable multicast protocols. Feedback aggregation and filtering of sender repair data may be possible with NACK-based protocols using FEC-based repair strategies as described in the present and other reliable multicast transport building block documents. However, there will continue to be a number of instances where intermediate system assistance 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ベースの信頼できるマルチキャストプロトコルのパフォーマンスとスケーラビリティを向上させることができます。現在およびその他の信頼性の高いマルチキャストトランスポートビルディングブロックドキュメントで説明されているように、FECベースの修復戦略を使用したNACKベースのプロトコルを使用すると、送信者修理データのフィードバックの集約とフィルタリングが可能になる場合があります。ただし、中間システムの支援が利用できない、または実用的でない場合、引き続き多くのインスタンスがあります。NACK指向の信頼できるマルチキャストのビルディングブロックコンポーネントは、そのような支援なしで運用することができます。ただし、このようなプロトコルは、利用可能な場合にこれらの機能を利用することも検討することをお勧めします。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NACK-based reliable multicast building block identification/design. This section describes different building block areas applicable to NACK-based reliable multicast protocols. Some of these areas are specific to NACK-based 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 general building block areas from the standpoint of NACK-based reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NACK-based reliable multicast protocols.
前のセクションでは、プロトコルビルディングブロックの役割と、NACKベースの信頼できるマルチキャストビルディングブロックの識別/設計に影響を与える可能性のある基準の一部を示しています。このセクションでは、NACKベースの信頼できるマルチキャストプロトコルに適用可能なさまざまなビルディングブロック領域について説明します。これらの領域の一部は、NACKベースのプロトコルに固有です。そのような領域の詳細な説明が提供されます。それ以外の場合、領域（ノード識別子、前方エラー補正（FEC）など）は、信頼できるマルチキャストの他の形式に適用できる場合があります。そのような場合、以下の議論では、NACKベースの信頼できるマルチキャストの観点からこれらの一般的なビルディングブロック領域に置かれた要件について説明しています。該当する場合、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 NACK- based reliable multicast building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
各ビルディングブロックについて、概念的な「インターフェイス説明」が提供され、1つのビルディングブロックコンポーネントの依存関係が別のものまたは他のプロトコルパラメーターに依存します。ビルディングブロックコンポーネントは、その機能を実行するために、別のビルディングブロックコンポーネントまたは他のソースからの何らかの形の「入力」を必要とする場合があります。提供されるビルディングブロックコンポーネントおよび/または結果の「出力」に必要な「入力」は、各ビルディングブロックコンポーネントのインターフェイスの説明で定義および説明されます。ここに示されているビルディングブロックのセットは、互いの「入力」と「出力」のニーズを完全に満たしていないことに注意してください。場合によっては、ここのビルディングブロックの「入力」は、このドキュメントの外部の他のビルディングブロック（渋滞制御またはFECなど）から来る必要があります。他のケースでは、NACKベースの信頼性の高いマルチキャストビルディングブロック「入力」は、特定のプロトコルのインスタンス化または実装（アプリケーションデータとコントロールなど）によって満たされる必要があります。
The following building block components relevant to NACK-based reliable multicast are identified:
NACKベースの信頼できるマルチキャストに関連する次のビルディングブロックコンポーネントが特定されています。
NORM (NACK-Oriented Reliable Multicast)-Specific
Norm（NACK指向の信頼性の高いマルチキャスト）特異的
1. Multicast Sender Transmission
1. マルチキャスト送信者伝送
2. NACK Repair Process
2. NACK修理プロセス
3. Multicast Receiver Join Policies and Procedures
3. マルチキャストレシーバーはポリシーと手順に参加します
General Purpose
一般的用途
1. Node (Member) Identification
1. ノード（メンバー）識別
2. Data Content Identification
2. データコンテンツ識別
3. Forward Error Correction (FEC)
3. フォワードエラー補正（FEC）
4. Round-Trip Timing Collection
4. 往復タイミングコレクション
5. Group Size Determination/Estimation
5. グループサイズの決定/推定
6. Congestion Control Operation
6. 混雑制御操作
7. Intermediate System Assistance
7. 中間システム支援
8. Ancillary Protocol Mechanisms
8. 補助プロトコルメカニズム
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」コンポーネントに依存しますが、メッセージ送信のレートは一般に「混雑制御」コンポーネントに依存します。。その後、これらの送信に対する受信機の応答（たとえば、修理のためのナック）は、他のビルディングブロックコンポーネントからのデータメッセージコンテンツと入力に依存します。最後に、送信者の受信者応答の処理は、送信戦略にフィードバックされます。
The components on the left side of this figure are areas that may be applicable beyond NACK-based reliable multicast. The more significant of these components are discussed in other building block documents, such as the FEC Building Block [RFC5052]. Brief descriptions of these areas and their roles in NACK-based reliable multicast protocols are given below, and "RTT Collection" is discussed in detail in Section 3.7 of this document.
この図の左側のコンポーネントは、NACKベースの信頼性の高いマルチキャストを超えて適用できる領域です。これらのコンポーネントのうち、FECビルディングブロック[RFC5052]など、他のビルディングブロックドキュメントで説明されています。これらの領域の簡単な説明とNACKベースの信頼できるマルチキャストプロトコルにおけるその役割を以下に示し、「RTTコレクション」については、このドキュメントのセクション3.7で詳しく説明します。
The components on the right are seen as specific to NACK-based reliable multicast protocols, most notably the NACK repair process. These areas are discussed in detail below (most notably, "Multicast Sender Transmission" and "NACK Repair Process" in Sections 3.1 and 3.2). Some other components (e.g., "Security") impact many aspects of the protocol, and others may be more transparent to the core protocol processing. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NACK-based reliable multicast transport for the Internet.
右側のコンポーネントは、NACKベースの信頼性の高いマルチキャストプロトコル、特にNACK修復プロセスに固有のものと見なされます。これらの領域については、以下で詳しく説明します（特に、セクション3.1および3.2の「マルチキャスト送信者伝送」および「NACK修復プロセス」）。他のコンポーネント（「セキュリティ」など）は、プロトコルの多くの側面に影響を与え、他のコンポーネントはコアプロトコル処理に対してより透明性が高い場合があります。該当する場合、インターネット用のNACKベースの信頼性の高いマルチキャストトランスポートの目標を適切に満たすメカニズムに対して、特定の技術的推奨事項が作成されます。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |-------+-->| Sender Transmission |<---.
`---------------------' | `-----------------------' |
.---------------------. | | .------------------. |
| Data Identification |-------+ | | Rcvr Join Policy | |
`---------------------' | V `------------------' |
.---------------------. | .----------------------. |
.->| Congestion Control |-------+ | Receiver NACK | |
| `---------------------' | | Repair Process | |
| .---------------------. | | .------------------. | |
| | |-------' | | NACK Initiation | | |
| | FEC |-----. | `------------------' | |
| | |--. | | .------------------. | |
| `---------------------' | | | | NACK Content | | |
| .---------------------. | | | `------------------' | |
`--| RTT Collection |--|--+---->| .------------------. | |
| |--+ | | | NACK Suppression | | |
`---------------------' | | | `------------------' | |
.---------------------. | | `----------------------' |
| Group Size Est. |--|--' | .-----------------. |
| |--+ | | Intermediate | |
`---------------------' | | | System Assist | |
.---------------------. | v `-----------------' |
| Other | | .-------------------------. |
`---------------------' `------->| Sender NACK Processing |--'
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Figure 1: NACK-Based Reliable Multicast Building Block Framework
図1：NACKベースの信頼性の高いマルチキャストビルディングブロックフレームワーク
Reliable multicast 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 the FEC Building Block [RFC5052]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), the sender transmission rate SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from multicast 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エンコーディングは、FECビルディングブロックのガイドラインに準拠する必要があります[RFC5052]。輻輳制御メカニズムが必要な場合（一般的なインターネット操作に必要）、送信者伝送レートは混雑制御メカニズムによって制御されます。いずれにせよ、マルチキャスト送信者からのすべてのデータ送信は、アプリケーションまたは輻輳制御アルゴリズムによって決定されるレート制限の対象となることをお勧めします。送信者の送信は、利用可能な容量を適切に利用する必要があります（これは、アプリケーションおよび/または混雑制御によって制限される場合があります）。その結果、修理コンテンツを使用した新しいデータコンテンツ伝送が重複し、多重化が行われると予想されます。アプリケーション操作に関連する他の要因は、送信者の伝送形式と方法を決定する場合があります。たとえば、送信するデータがない断続的なアイドル期間中に、送信者の動作を考慮する必要があります。
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 NACK-based reliable multicast 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 NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK responses from the receivers to this command.
データコンテンツに加えて、他の送信者メッセージまたはコマンドがプロトコル操作の一部として採用される場合があります。これらのメッセージは、アプリケーションデータ転送の範囲外で発生する場合があります。NACKベースの信頼性の高いマルチキャストプロトコルでは、グループサイズのスケーラビリティの懸念のために肯定的な認識が法外な場合、そのようなプロトコルメッセージの信頼性は冗長送信によって試みられます。プロトコル設計は、そのようなメッセージがグループによって受信されない場合に対処するためのメカニズムを提供する必要があることに注意してください。例として、コマンドメッセージは、送信者が一時的に（または永続的に）停止していることを示すために、送信者によって冗長に送信される場合があります。現時点では、NACK手順のルールに従って、必要な未解決の修理について、受信者がNACKSで応答することが適切かもしれません。効率のために、送信者は、冗長な送信の間の十分な時間を確保して、受信機からこのコマンドへの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 NACK-based reliable multicast protocol timeouts should be dependent upon the group greatest round-trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The sender GRTT is an estimate of the worst-case round-trip timing from a given 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 a given sender. NACK-based reliable multicast instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
一般に、結果のNACKまたはその他のフィードバック操作がある場合、送信者およびその他のNACKベースの信頼できるマルチキャストプロトコルタイムアウトによって発行されたコントロールメッセージの冗長送信のタイミングは、グループ最大の往復タイミング（GRTT）の推定に依存する必要がありますそして、予想される結果としてのNACKまたはその他のフィードバック操作。送信者GRTTは、特定の送信者からグループ内の任意のレシーバーへの最悪の往復タイミングの推定値です。GRTT間隔は、特定の送信者に関するネットワークトポロジ全体のマルチキャストグループの最大スパン（遅延に関して）の保守的な推定であると想定されています。NACKベースの信頼性の高いマルチキャストインスタンス化は、幅広いマルチキャストネットワークトポロジに動的に適応できるはずです。
Inputs:
入力：
1. Application data and control.
1. アプリケーションデータと制御。
2. Sender node identifier.
2. 送信者ノード識別子。
3. Data identifiers.
3. データ識別子。
4. Segmentation and FEC parameters.
4. セグメンテーションおよびFECパラメーター。
5. Transmission rate.
5. 伝送速度。
6. Application controls.
6. アプリケーションコントロール。
7. Receiver feedback messages (e.g., NACKs).
7. レシーバーフィードバックメッセージ（NACKSなど）。
Outputs:
出力：
1. Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the reliable multicast session.
1. 信頼できるマルチキャストセッションのコンテキスト内で、データまたはコンテンツを一意に識別するヘッダーを使用したメッセージの制御送信。
2. Commands indicating sender's status or other transport control actions to be taken.
2. 送信者のステータスまたはその他の輸送制御アクションを示すコマンド。
A critical component of NACK-based reliable multicast protocols is the NACK repair process. This includes both 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 NACK repair process:
NACKベースの信頼できるマルチキャストプロトコルの重要なコンポーネントは、NACK修復プロセスです。これには、修理ニーズの検出と要求における受信者の役割と、そのようなリクエストに対する送信者の応答の両方が含まれます。NACK修理プロセスには4つの主要な要素があります。
1. Receiver NACK process initiation,
1. 受信機NACKプロセス開始、
2. NACK suppression,
2. ナック抑制、
3. NACK message content,
3. Nackメッセージコンテンツ、
4. Sender NACK processing and repair response.
4. 送信者NACK処理と修復応答。
The 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 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 sender data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
NACKプロセス（サイクル）は、信頼できる受信を達成するために特定の送信者からの修理送信の必要性を検出する受信機によって開始されます。FECが適用されると、受信者は、データコンテンツの特定のコーディングブロックの保留中の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 process 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サイクルを開始できるようにすることで、修理が保留されている場合は、修理サイクルがわずかに速くなる可能性があります。ただし、FECコーディングブロックの移動の終了時や後続のコーディングブロックの検出時など、NACKプロセスの開始を特定のイベントに制限することが役立つ場合があります。これにより、受信機はNACKコンテンツを少量のNACKメッセージに集約し、受信機セット間で暗黙の緩い同期を提供して、NACKフィードバックの効果的な確率的抑制を促進するのに役立ちます。受信者は、現在の修理ニーズを決定するために、送信者から受け取ったデータコンテンツの履歴を維持する必要があります。FECが採用されると、履歴は保留中または部分的に推定されたコーディングブロックの記録に対応することが予想されます。
For probabilistic, timer-based 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 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メッセージがネットワークを越えて送信者や他のレシーバーに伝播する間に、送信者から追加のコンテンツが受信されるため、抑制は大幅に減少します。
Inputs:
入力：
1. Sender data content with sequencing identifiers from sender transmissions.
1. 送信者データコンテンツは、送信者送信からのシーケンス識別子を備えています。
2. History of content received from sender.
2. 送信者から受け取ったコンテンツの履歴。
Outputs:
出力：
1. NACK process initiation decision.
1. NACKプロセス開始決定。
2. Recorded sender transmission sequence position.
2. 記録された送信者伝送シーケンス位置。
An effective feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [SrmFramework]. 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 by providing some other indicator of the repair information it will be subsequently transmitting.
効果的なフィードバック抑制メカニズムは、修理を必要とする受信機によるNACK送信の前に、ランダムバックオフタイムアウトを使用することです[SRMFramework]。バックオフタイムアウトの有効期限が切れると、受信者は、保留中の修理ニーズが他のレシーバー（受信機がマルチリキャスト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 [McastFeedback]. 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 the sender's GRTT assessment and a group size estimate that is either determined by other mechanisms within the protocol or is preset by the multicast application.
効果的でスケーラブルな抑制パフォーマンスのために、受信機が使用するバックオフタイムアウト期間は、切り捨てられた指数分布を持つレシーバーがランダムに選択する必要があります[mcastFeedback]。これにより、レシーバーセットの大部分は、少数の「初期ナッカー」がグループの残りの修理ニーズに取って代わるという仮定の下で、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」の値が少ないと、遅延が短くなり、信頼できる輸送のために送信者と受信機のバッファリング要件も削減されます。
In the functions below, the "log()" function specified refers to the "natural logarithm" and the "exp()" function is similarly based upon the mathematical constant 'e' (a.k.a. Euler's number) where "exp(x)" corresponds to '"e"' raised to the power of '"x"'. Given the receiver group size ("groupSize") and maximum allowed backoff timeout ("T_maxBackoff"), random backoff timeouts ("t'") with a truncated exponential distribution can be picked with the following algorithm:
以下の関数では、指定された「log（）」関数は「自然対数」を指し、「exp（）」関数は同様に数学的定数「e」（a.k.a. eulerの数）に基づいています。'"x"'の力に引き上げられた '"e"'に対応します。受信機グループサイズ（「グループ化」）と最大許容バックオフタイムアウト（ "T_Maxbackoff"）を考えると、次のアルゴリズムで切り捨てられた指数分布を備えたランダムバックオフタイムアウト（ "T '"）を選択できます。
1. Establish an optimal mean ("L") for the exponential backoff based on the "groupSize":
1. 「グループ化」に基づいて、指数バックオフに最適な平均（ "L"）を確立します。
L = log(groupSize) + 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
3. Transform this random variate to generate the desired random backoff time ("t'") with the following equation:
3. このランダムバリエートを変換して、次の方程式で目的のランダムバックオフ時間（ "t '"）を生成します。
t' = T_maxBackoff/L * log(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 T_maxBackoff, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/T_maxBackoff) +
lambda / (T_maxBackoff*(exp(lambda)-1));
return ((T_maxBackoff/lambda) *
log(x*(exp(lambda)-1)*(T_maxBackoff/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:
ここで、「Uniferland（Double Max）」は、「0..max」の範囲から均一な分布で乱数を返します。たとえば、POSIX「rand（）」関数に基づいて、次の「C」コードを使用できます。
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))
Thus, the maximum backoff time can be adjusted to trade off worst-case NACK feedback volume versus latency. This is derived from the equations given in [McastFeedback] 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. 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: T_maxBackoff = K * GRTT; where K >= 1
したがって、最大のバックオフ時間を調整して、最悪のNACKフィードバックボリュームとレイテンシをトレードオフすることができます。これは[mcastfeedback]に与えられた方程式から導出され、「t_maxbackoff> = grtt」を想定し、「l」は上記のアルゴリズムに示すように、与えられたグループサイズに最適化された分布の平均です。プロトコル内の他のメカニズムは、冗長なNACK生成をさらに減らすために機能する可能性があることに注意してください。「T_Maxbackoff」は、次のような送信者の現在の宣伝されているGRTT推定の整数倍として選択することをお勧めします。ここで、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; a value of "K=6" is the RECOMMENDED default for unicast NACK delivery. Alternate values may be used to achieve desired buffer utilization, reliable delivery latency, and group size scalability trade-offs.
一般的なインターネット操作の場合、「k = 4」のデフォルト値が、マルチキャスト（グループ全体に）NACK配信を使用した操作に推奨されます。「k = 6」の値は、ユニキャストNACK配信の推奨デフォルトです。代替値を使用して、望ましいバッファー利用率、信頼できる配信遅延、およびグループサイズのスケーラビリティトレードオフを実現できます。
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 Section 3.2.4.
（ "k*grtt"）は、NACK送信を開始するためにレシーバーが使用する最大バックオフ時間であることを考えると、それに応じてNACK修復プロセスに関連する他のタイムアウト期間をスケーリングできます。それらのタイムアウトの1つは、別のNACKバックオフ/送信サイクル（「T_RCVRHOLDOFF」）を開始できるようにする前に、NACKメッセージを生成した後にレシーバーが待つ時間です。この遅延は、送信者が修理メッセージを使用して受信したNACKに応答するのに十分でなければなりません。適切な値は、NACKが送信者と送信者に到達して修理応答を提供する時間に依存します。これには、効率的な修復応答を決定するために可能な複数のNACKが蓄積される送信者NACK集約期間の量を含める必要があります。これらのタイムアウトについては、セクション3.2.4でさらに説明します。
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 bias 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 correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not always 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バックオフウィンドウにあるこの追加スロットは、一部のアプリケーションでは望ましくない可能性のある修復サイクルプロセスが長くなります。これらのトレードオフの解決は、プロトコルのターゲットアプリケーションセットまたはネットワークに依存する場合があります。
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サイクルを受信機によって開始する必要があります。注意してください。地元の受信機は、他の受信機の修理ニーズに対する送信者の応答の結果として修理ニーズを満たしていた可能性があり、それ以上のナッキングは必要ありません。
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 payload limits occur, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender.
これらの条件が発生しておらず、受信者がまだ修理のニーズが保留されている場合、NACKメッセージが生成され、送信されます。NACKは、現在の送信者伝送シーケンス位置までの受信者の最低順序修復ポイントから修理ニーズの蓄積で構成されている必要があります。単一のNACKメッセージを生成する必要があり、単一のプロトコルメッセージのペイロードサイズを超える場合は、NACKメッセージコンテンツを切り捨てる必要があります。このようなNACKペイロード制限が発生した場合、NACKコンテンツには、送信者から必要な通常の最低修理コンテンツのリクエストを含める必要があります。
Inputs:
入力：
1. NACK process initiation decision.
1. NACKプロセス開始決定。
2. Recorded sender transmission sequence position.
2. 記録された送信者伝送シーケンス位置。
3. Sender GRTT.
3. 送信者GRTT。
4. Sender group size estimate.
4. 送信者グループサイズの推定。
5. Application-defined bound on backoff timeout period.
5. バックオフタイムアウト期間にバインドされたアプリケーション定義バウンド。
6. NACKs from other receivers.
6. 他のレシーバーからのナック。
7. Pending repair indication from sender (may be forwarded NACKs).
7. 送信者からの保留中の修理兆候（nacksが転送される場合があります）。
8. Current sender transmission sequence position.
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 NACK 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 NACK-based reliable multicast can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼できるマルチキャストレシーバーによって生成されたNACKメッセージの内容には、現在の修理ニーズを詳述する情報が含まれます。特定の情報は、NACK修復プロセスのFECの使用とタイプに依存します。修理ニーズの識別は、データコンテンツの識別に依存します（以下のセクション3.5を参照）。最高レベルでは、NACKコンテンツは、NACKに対処される送信者と、修理が必要な送信者の送信内のデータ輸送オブジェクト（またはストリーム）を識別します。指定された輸送エンティティの場合、NACKコンテンツは、完全な送信データを再構築するために必要な特定のFECコーディングブロックおよび/またはシンボルを識別します。このコンテンツは、FECブロックの消去カウントおよび/またはデータおよびFECコンテンツの欠落ブロックまたはシンボル（セグメント）の明示的な指標で構成されている場合があります。また、NACKベースの信頼できるマルチキャストは、ここで説明する技術を使用して信頼できる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. This count may need to be adjusted for some FEC algorithms.
FECベースの修理が使用される場合、NACKメッセージコンテンツは、修復が必要なコーディングブロックと、コーディングブロックの消去カウント（欠落パケット）を最小限に識別する必要があります。消去の正確なカウントは、FECアルゴリズムがコーディングブロック内の損失の組み合わせを修復できることを意味します。このカウントは、一部のFECアルゴリズムに対して調整する必要がある場合があります。
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 effect repair. For the 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 [FecSchemes]) that are capable of providing a limited number of parity symbols per FEC coding block.
修理を正常に完了するために複数の修理ラウンドが必要になる可能性があることを考慮すると、消去カウントは、サーバーが利用できる一意のFECパリティパケットの量が本質的に無制限であることを意味します（つまり、サーバーは常に新しい、ユニークな、新しい、新しいものを提供できます。以前は、同じコーディングブロックの後続の修理要求に応じて、以前は無関係のパリティパケット）。あるいは、送信者は、特定のコーディングブロックで使用可能なFECシンボルを介して「ラウンドロビン」を送信し、最終的には修復に影響を与えることがあります。最も効率的な修理戦略のために、NACKコンテンツは、レシーバーがコーディングブロックのコンテンツを正常に再構築するために必要なシンボル（情報および/またはパリティ）を明示的に識別する必要があります。これは、FECコーディングブロックごとに限られた数のパリティシンボルを提供できる小規模から中サイズのブロックFECコード（例：Reed Solomon [Fecschemes]）に特に当てはまります。
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コンテンツは、適切な修理パケットおよび/またはデータ再送信を提供できるように、明示的なコーディングブロックおよび/またはセグメント損失情報を含める必要があります。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 the 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できる戦略があります。この戦略の仮定は、送信者が特定のコーディングブロックで利用可能な新しいユニークなパリティパケットの供給を潜在的に排出し、信頼できる転送を完了するためにいくつかのデータまたはパリティシンボルを明示的に再送信する必要があるということです。もう1つの仮定は、パリティパケットがコーディングブロック内の消去（Reed Solomonなど）を埋めることができるFECアルゴリズムが使用されることです。この戦略の目標は、利用可能なパリティを最大限に活用し、グループへの信頼できるデータコンテンツの伝達中に最小限のデータと修理送信を提供することです。
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 source data vectors plus parity vectors for the given FEC algorithm used. For example, a systematic 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.
系統的FECコードを使用すると、送信者は、最初の送信でコーディングブロックのデータコンテンツ（およびオプションであるパリティパケット）を送信します。系統的FECコーディングブロックは、使用された特定のFECアルゴリズムのソースデータベクトルとパリティベクトルの連続的なセットで論理的に構成されていると見なされていることに注意してください。たとえば、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メッセージを作成できます。たとえば、受信者に特定の受信コーディングブロックに3つの消去がある場合、コーディングブロック内の3つの最低順序パリティベクターの送信が要求されます。前の段落からのコードスキームの例では、受信者はパリティシンボル64〜66を明示的に要求して、コーディングブロックの3つの消去を埋めます。コーディングブロックの受信機の損失が利用可能なパリティ数量を超えている場合（つまり、例では32を超えるシンボルを超える）、受信者は利用可能なパリティシンボルのすべて（32）と追加の追加を要求するNACKを作成する必要があることに注意してください。ブロックを再構築するための欠落データ記号の一部。これがレシーバーグループ全体で一貫して行われた場合、結果の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 receive 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.
要約すると、ルールは、FECコーディングブロックのパリティコンテンツの下位部分を要求して、最初のNACKサイクルの消去修復ニーズを満たすことです。利用可能なパリティ記号の数が不十分な場合、受信者は、パリティ記号が埋められないものをカバーするために、通常最も高い欠落データ記号のサブセットを要求します。注この戦略は、単一のパリティシンボルが消去されたシンボルを修復できるReed-SolomonなどのFECコードを想定しています。この戦略では、他のFECタイプの制限された修理能力を考慮に入れるために、マイナーな変更が必要です。レシーバーが以前に要求した修理コンテンツの一部を受け取ることができる後続のNACK修理サイクルでは、受信機は同じ戦略を使用しますが、まだ受け取っていないパリティおよび/またはデータ記号のセットについてはNACKのみを使用します。オプションで、受信者は、送信者にとって利便性として消去のカウントを提供することもできます。
Other types of FEC schemes may require alteration to the NACK and repair strategy described here. For example, some of the large block or expandable FEC codes described in [RFC3453] may be less deterministic with respect to defining optimal repair requests by receivers or repair transmission strategies by senders. For these types of codes, it may be sufficient for receivers to NACK with an estimate of the quantity of additional FEC symbols required to complete reliable reception and for the sender to respond accordingly. This apparent disadvantage, as compared to codes such as Reed Solomon, may be offset by the reduced computational requirements and/or ability to support large coding blocks for increased repair efficiency that these codes can offer.
他のタイプのFECスキームでは、ここで説明するNACKおよび修復戦略の変更が必要になる場合があります。たとえば、[RFC3453]で説明されている大きなブロックまたは拡張可能なFECコードの一部は、受信者による最適な修理要求または送信者による修理伝送戦略を定義することに関して、それほど決定的ではない場合があります。これらのタイプのコードでは、信頼できる受信を完了するために必要な追加のFECシンボルの推定値と、それに応じて送信者が応答するために必要な追加のFECシンボルの推定値で、受信機がNACKを使用するだけで十分かもしれません。Reed Solomonなどのコードと比較して、この明らかな欠点は、これらのコードが提供できる修復効率を向上させるために、計算要件の減少および/または大きなコーディングブロックをサポートする能力によって相殺される可能性があります。
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 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抑制は複数の修理サイクルの過程で簡素化されます。受信機は、他のレシーバーから聞いた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
session_ \ _ sender_ \ _ [object/stream（s）] _ \ _ [fec blocks] _ \ _シンボル
Figure 2: Reliable Multicast Data Content Identification Hierarchy
図2：信頼性の高いマルチキャストデータコンテンツ識別階層
The format of NACK messages should enable the following:
NACKメッセージの形式は、次のことを有効にする必要があります。
1. Identification of transport data units required to repair the received content, whether this is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1. これが欠落しているオブジェクト/ストリーム（または範囲）、FECコーディングブロック全体、またはシンボルのセットであるかどうか、受信したコンテンツを修復するために必要なトランスポートデータユニットの識別、
2. Simple processing for NACK aggregation and suppression,
2. NACKの集約と抑制のための簡単な処理、
3. Inclusion of NACKs for multiple objects, FEC coding blocks, and/or symbols in a single message, and
3. 単一のメッセージに複数のオブジェクト、FECコーディングブロック、および/またはシンボルにNACKを含める、および
4. A reasonably compact format.
4. 合理的にコンパクトな形式。
If the reliable multicast 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 receiver's 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.
信頼性の高いマルチキャストトランスポートオブジェクト/ストリームが<ObjectId>で識別され、送信されるFECシンボルが<fecpayloadid>で識別される場合、<objectid :: fecpayloadid>の連結は、基本的なトランスポートプロトコルデータユニット（TPDU）識別子で構成されています。特定のソースからのシンボル。NACKコンテンツは、これらのTPDU識別子のリストおよび/または範囲で構成して、受信者の修理ニーズを説明するためにNACKメッセージを構築することができます。階層オブジェクトの描写またはFECブロッキングが使用されていない場合、TPDUは送信者によって送信されるデータ記号の単純な線形表現です。TPDUがオブジェクト/ストリームの描写および/またはFECブロッキングの目的で階層を表す場合、NACKコンテンツユニットは、TPDUのどの部分が適用可能かを示すためにフラグを要求する場合があります。たとえば、受信したデータに「オブジェクト」全体（またはオブジェクトの範囲）が欠落している場合、受信者は必ずしも修理を要求する<sourceBlockNumbers>または<EncodingSymbolidsの適切な範囲を知っているわけではありません。<ObjectId>で表されるユニット全体の修理（または再送信）を要求します。<sourceblocknumbers>の範囲または範囲の範囲で表されるFECコーディングブロック全体が失われている場合、同じことが言えます。
Inputs:
入力：
1. Sender identification.
1. 送信者識別。
2. Sender data identification.
2. 送信者データ識別。
3. Sender FEC object transmission information.
3. 送信者FECオブジェクト伝送情報。
4. Recorded sender transmission sequence position.
4. 記録された送信者伝送シーケンス位置。
5. Current sender transmission sequence position. History of repair needs for this sender.
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 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:
グループ内の受信機からの修理要求が受信されると、送信者は修理応答手順を開始します。送信者は、受信機セットから潜在的に複数のNACKを蓄積するのに十分な時間があるまで、修理コンテンツの送信を遅らせることを望む場合があります。これにより、送信者は特定の輸送ストリーム/オブジェクトまたはFECコーディングブロックの最も効率的な修復戦略を決定できます。使用されるアプローチに応じて、一部のプロトコルは、現在の送信されたメッセージコンテンツの一部として、保留中の修理送信の指標を送信者が提供することが有益である場合があります。これにより、いくつかのNACK抑制メカニズムが役立ちます。このNACK集約を実行する時間の量は、最大の受信機NACKバックオフウィンドウ（セクション3.2.2からの「T_Maxbackoff」」と受信者から送信者へのNACKメッセージの伝播を可能にするのに十分でなければなりません。メモ送信遅延に関する非常に非対称ネットワークトポロジの場合、受信者から送信者へのメッセージの最大送信遅延は、非常に非対称ネットワークトポロジの場合にほぼ「（1*grtt）」になる可能性があります。したがって、最大受信機のバックオフ時間が「T_Maxbackoff = k*grtt」の場合、送信者NACK集約期間は少なくとも次のことに等しくなければなりません。
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 "hold-off" 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 "hold-off" time should be:
送信者NACK集約期間の直後、送信者は、総計状態から決定された修理コンテンツの送信を開始し、新しい送信を続けます。また、現時点では、送信者は、受信機グループへの修復応答のために新しい伝送シーケンス位置の伝播を可能にする新しいNACK集約期間を開始することを制約する「ホールドオフ」期間を観察する必要があります。最悪の場合の非対称性を可能にするために、この「ホールドオフ」時間は次のとおりです。
T_sndrHoldoff = 1*GRTT
Recall that the receivers will also employ a "hold-off" 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 hold-off timeouts of:
NACKメッセージを生成して、送信者の応答の時間を確保した後、レシーバーは「ホールドオフ」タイムアウトも採用することを思い出してください。送信者「<t_sndraggregate>」と「 "<t_sndrholdoff>" time of "（k 1）*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抑制を可能にすることが役立つ場合があります。設定。
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ベースの修理と、信頼できるマルチキャスト効率を改善できる送信者からの修理応答の順序に関するガイドラインがいくつかあります。
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.
FECを使用すると、送信者が以前に移植されていないパリティコンテンツを可能な限り修理メッセージとして送信することが有益です。これにより、受信したノードの送信コンテンツ全体を個々のメッセージのサブセットから再構築する機能が最大化されます。
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 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.
送信されたオブジェクトおよび/またはストリームデータおよび修復コンテンツは、単調に増加するシーケンス番号（合理的に大きな順序空間内）でインデックス付けする必要があります。送信者が最初に最も早いコンテンツ（例えば、通常最も低いFECブロックなど）の送信修理の規律を観察する場合、受信者は、送信者が再びオブジェクト/ストリームのそのポイントに戻るまで、後のコンテンツの修理要求を差し控える戦略を使用できます伝送シーケンス。これにより、グループ間の全体的なメッセージ効率が向上し、送信者とレシーバー間の厳密な時間同期に依存せずに修復サイクルを比較的同期し続けることができます。これにより、受信者と送信者のバッファリング要件を最小限に抑え、データの冗長な伝送をグループ全体に削減するのにも役立ちます。
Inputs:
入力：
1. Receiver NACK messages.
1. レシーバーNACKメッセージ。
2. Group timing information.
2. グループタイミング情報。
Outputs:
出力：
1. Repair messages (FEC and/or Data content retransmission).
1. メッセージメッセージ（FECおよび/またはデータコンテンツの再送信）。
2. Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
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 that limit the opportunities for receivers to 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要求を受け入れるレシーバーを制限するポリシーを実装することもできますが、これは状況によってはスケーラビリティの理由で禁止される場合があります。あるいは、緩い輸送同期ポリシーを持ち、セッション管理メカニズムに依存して、ある種のバルク転送アプリケーション（または潜在的なインタラクティブな信頼性の高いマルチキャストアプリケーション）でパフォーマンスが低下する可能性のあるグループダイナミクスを制限することが望ましい場合があります。
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 NACK-based reliable multicast 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) within the group. Receivers that send NACK messages to the group will need to identify the sender to which the NACK is intended. 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.
複数のデータソースがある可能性があるNACKベースの信頼性の高いマルチキャストプロトコル（またはその他のマルチキャストプロトコル）では、グループ内のソース（およびおそらく一部またはすべてのレシーバー）を一意に識別するためのメカニズムを提供する必要があります。NACKメッセージをグループに送信する受信者は、NACKが意図している送信者を特定する必要があります。パケットソースアドレスの到着に基づくIDは、いくつかの理由で不十分です。これらの理由には、時間の経過とともに特定のホストの異なるパケットソースアドレスをもたらす複数のインターフェイスを持つホストのルーティング変更、ネットワークアドレスの翻訳（NAT）またはファイアウォールデバイス、またはその他のトランスポート/ネットワークブリッジングアプローチが含まれます。その結果、信頼できるマルチキャストセッションメンバーが送信したパケットには、あるタイプの一意のソース識別子<sourceId>フィールドが存在する必要があります。
The data and repair content transmitted by a NACK-based reliable multicast 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 required to provide their own mechanisms for these functions at the application layer.
NACKベースの信頼性の高いマルチキャスト送信者によって送信されるデータおよび修復コンテンツには、プロトコルヘッダーフィールドで何らかの形の識別が必要です。この識別は、信頼できるNACK指向の修復プロセスを促進するために必要です。これらの識別子は、生成されたNACKメッセージでも使用されます。このビルディングブロックドキュメントでは、バルク転送セッションコンテンツを含む2つの非常に一般的なタイプのデータを想定しています。1つのタイプは、静的で離散的なサイズのオブジェクトであり、もう1つのタイプは連続的な非フィニットストリームです。特定のアプリケーションは、これらのパラダイムのいずれかまたは両方を使用して、確実にマルチキャストデータコンテンツを希望する場合があります。一部のアプリケーションがこのモデルをさらに一般化し、ストリーム内に埋め込まれたコンテンツとして静的オブジェクトをカプセル化するメカニズムを提供することが可能かもしれませんが、多くのアプリケーションでは、信頼できるマルチキャストのコンテキストで静的バルクオブジェクトとメッセージを明確にサポートすることは利点があります。セッション。これらのアプリケーションには、コンテンツキャッシュサーバー、ファイル転送、またはバルクコンテンツを含むコラボレーションツールが含まれます。これらの静的オブジェクトタイプの要件を備えたアプリケーションは、アプリケーションレイヤーでこれらの関数の独自のメカニズムを提供するために必要ではなく、輸送層のメカニズム（つまり、セグメンテーション/再組み立て、キャッシュ、統合されたフォワードエラー補正コードなど）を活用できます。。
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.
前述のように、一部のアプリケーションは、非フィニットサイズの1つ以上のストリームの形でバルクコンテンツを送信したい場合があります。例のストリームには、継続的な準リアルタイムメッセージブロードキャスト（ストックティッカーなど）または共同ツールやその他のアプリケーションの一部であるコンテンツタイプが含まれます。また、上記のように、一部のアプリケーションは、マルチキャストセッション内の他のバルクコンテンツ（ファイルなど）を1つ以上のストリームにカプセル化することを望む場合があります。
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 (e.g., <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 "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, NACK-based reliable multicast 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 Basic Schemes building block [FECSchemes] and descriptions of additional FEC schemes that may be documented later provide a standard message format for identifying FEC transmission content. NACK-based reliable multicast protocol instantiations using FEC SHOULD follow such guidelines.
「バルク」オブジェクト/ストリームコンテンツには通常、セグメンテーションが必要なため、何らかの形のセグメント識別も提供する必要があります。このセグメント識別子は、提供されたオブジェクトまたはストリーム識別子に対して関連します。したがって、場合によっては、NACKベースの信頼性の高いマルチキャストプロトコルインスタンス化が送信を受信し、複数のストリームと1つ以上の静的オブジェクトの修理を並列にリクエストできる場合があります。FECを使用したプロトコルインスタンス化の場合、データコンテンツ識別子のセグメント識別部分は、コードブロックの特定のデータまたはパリティシンボル<EncodingSymbolid>のコーディングブロック識別子<sourceBlockNumber>の論理的連結で構成されている場合があります。FEC Basic Schemes Building Block [Fecschemes]と、後で文書化される可能性のある追加のFECスキームの説明は、FEC伝送コンテンツを識別するための標準メッセージ形式を提供します。FECを使用したNACKベースの信頼性の高いマルチキャストプロトコルインスタンス化は、このようなガイドラインに従う必要があります。
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 NACK-based reliable multicast protocol data content messages:
要約すると、NACKベースの信頼性の高いマルチキャストプロトコルデータコンテンツメッセージには、次のデータコンテンツ識別フィールドが必要になる場合があります。
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シンボル識別子（<EncodingSimbolid>）。
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.
これらのフィールドは、生成されたNACKメッセージがデータの修理または再送信を要求する際にこれらの識別子を使用するため、特定されています。
Multiple forward error correction (FEC) approaches using erasure coding techniques have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [FecBroadcast], [RmFec],
消去コード化技術を使用した複数の前方エラー補正（FEC）アプローチが特定されており、NACK指向およびその他の信頼できるマルチキャストプロトコル[FECBROADCAST]、[RMFEC]の修復プロセスに優れたパフォーマンス向上を提供できます。
[RFC3453]. NACK-based reliable multicast 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 NACK-based reliable multicast, 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 [FecHybrid]. 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 NACK-based reliable multicast, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
[RFC3453]。NACKベースの信頼性の高いマルチキャストプロトコルは、FECベースの修復には一般に、コーディングブロックサイズ（シンボル内）の境界内で修復コンテンツの明示的な知識を必要としないため、追加の利点を享受できます。NACKベースの信頼性の高いマルチキャストでは、生成されたパリティ修理パケットは通常、受信ノードからのNACK修理要求に応じてのみ送信されます。ただし、通常のデータシンボル送信[Fechybrid]で多重化されたFEC修復パケットのいくつかの所定量を送信するためのネットワーク環境によっては利点があります。これにより、グループサイズが非常に大きい場合、またはネットワーク接続が公称レベルの予想パケット損失を備えた大きな「遅延*帯域幅」製品がある場合、比較的少ないオーバーヘッドコストで生成されるNACKトラフィックの量を減らすことができます。FECの適用はNACKベースの信頼性の高いマルチキャストに固有のものではありませんが、これらの種類の要件は、適用可能なアルゴリズムとプロトコルアプローチの種類を決定する可能性があります。
A specific issue related to the use of FEC with NACK-based reliable multicast 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 [RFC5052] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
NACKベースの信頼できるマルチキャストでのFECの使用に関連する特定の問題は、特定のFECパケットが適用される送信されたデータコンテンツの部分を識別するために使用されるメカニズムです。FECアルゴリズムは、送信されるデータパケットの対応するブロックのパリティ修理パケットのセットを生成することに基づいていることが予想されます。データコンテンツパケットは、<sourceId :: objectId :: sourceBlockNumber :: encodingsymbolid>の連結によって一意に識別されるため、FECパケットは同様の方法で識別されると予想されます。FECビルディングブロックドキュメント[RFC5052]は、関連する信頼できるマルチキャストプロトコルメッセージの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 of "one-to-many" transmission, it may be that only the sender requires RTT knowledge of the GRTT 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 each receiver in the group may need knowledge of its individual RTT. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender(s) and advertise them to the group or sender(s). 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 [DelayEstimation]. In some cases, there might be absolute time synchronization available among the participating 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 NACK timeouts used by receivers.
グループメンバー間のパケット伝播の往復時間（RTT）の測定は、タイマーベースのNACK抑制アルゴリズム、送信者コマンドまたは特定の修理機能のタイミング、および輻輳制御操作をサポートするために必要です。収集された往復情報の性質は、グループのメンバー間の相互作用の種類に依存します。「1対Many」トランスミッションの場合、GRTTおよび/またはRTTのグループの一部のみのRTT知識を必要とするのは、送信者のみが必要です。ここでは、GRTT情報が合理的にスケーラブルな方法で収集される場合があります。輻輳制御操作の場合、グループ内の各受信機が個々のRTTの知識を必要とする可能性があります。この場合、受信者が送信者に対して個々のRTT測定値を収集し、それらをグループまたは送信者に宣伝する代替RTTコレクションスキームを利用することができます。信頼性の高いマルチキャストデータの交換が「多目的」ベースでグループ間で発生する可能性が高い場合、効率を向上させるために使用される可能性のある代替測定技術があります[遅延]。場合によっては、RTT測定を簡素化する可能性のある参加ホストの間で、絶対的な時間同期が利用可能である可能性があります。RTT（またはGRTT）測定に関する普遍的な推奨事項を指定する前に、さらに考慮する必要があるマルチキャスト輻輳制御設計にはトレードオフがあります。輻輳制御またはその他の要件に関してRTT情報（およびより具体的にはGRTT）をどのように収集するかに関係なく、送信者はレシーバーが使用するさまざまなNACKタイムアウトについて、現在のGRTT見積もりをグループに宣伝する必要があります。
The goal of this form of RTT measurement is for the sender to estimate the GRTT among the receivers who are actively participating in NACK-based reliable multicast 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測定の目標は、送信者がNACKベースの信頼できるマルチキャスト操作に積極的に参加しているレシーバーの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>」タイムスタンプと、「<cocvtime>」を受け取った時間（自分の時計を参照）を記録します。受信者が送信者にフィードバックを提供すると（プロトコルインスタンス化仕様に応じて、明示的または他のフィードバックメッセージの一部として）、式を使用して「応答」を構築します。
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
During 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
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_PEAK」）が現在のGRTT推定よりも少ない場合、GRTTは次のように更新されます。
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 estimate of GRTT (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 with correspondingly shorter GRTT collection periods. GRTT collection MAY also be coupled with collection of other information for congestion control purposes.
GRTT収集期間（つまり、プローブ伝送の期間）は、グループメンバーシップおよび/またはネットワークトポロジーのダイナミクスに対して予想される順序の値に固定できます。堅牢性のために、プロトコルスタートアップでより迅速な調査を使用してから、頻繁ではない定常状態の間隔に落ち着きます。オプションでは、GRTTの現在の推定（またはそのバリエーション）およびパケット損失の推定に応じて、GRTT収集期間を動的に調整するためのアルゴリズムを開発することができます。GRTTの推定値が安定して不変である場合、プローブメッセージのオーバーヘッドは、その後、GRTT収集期間が短くなったバリエーションの期間中により動的に追跡するように調整されます。GRTTコレクションは、輻輳制御目的で他の情報のコレクションと結合することもできます。
In summary, although NACK repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not depend upon highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NACK-based reliable multicast protocols have been deployed to date. The estimate provided by the given 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.
要約すると、NACK修復サイクルのタイムアウトはGRTTに基づいていますが、プロトコルの収束動作は非常に正確なGRTT推定に依存しないことに注意する必要があります。現在のメカニズムは、シミュレーションと、NACKベースの信頼性の高いマルチキャストプロトコルがこれまで展開されている環境で十分であることが証明されています。指定されたアルゴリズムによって提供される推定値は、比較的高い損失接続であっても、実際の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 senders "b" and "c", it is likely that:
複数の送信者を含む信頼性の高いマルチキャストセッションの場合、各送信者が独立してRTTを追跡するのではなく、真の「多目的」ベースでRTT測定を発生させることが有用かもしれません。レシーバーが、別の送信者に持っているRTT情報と、関心のある新しい送信者に関して他の送信者のRTTに基づいて、送信者に関するRTTの近似を推測できる場合、一部のプロトコル効率を得ることができます。たとえば、レシーバー「A」と送信者の「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 with respect to a small subset of other group members and if information concerning RTT among those other group members is learned by the node during protocol operation.
他のグループメンバーの小さなサブセットに関して、独自のRTTに関してRTT情報が独自のRTTに関するノードで利用可能である場合、および他のグループメンバーの間のRTTに関する情報がプロトコル操作中にノードによって学習される場合、この推定のさらなる改良を実施できます。
To facilitate deterministic 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 allow 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 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. NACK-based reliable multicast 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_MIN」）で実行することができます。それぞれ「RTT_MIN」と「RTT_MAX」には、1.0E-06秒と1000秒の値が推奨されます。NACKベースの信頼性の高いマルチキャストアプリケーションは、一部のネットワーク環境でより大きなフィードバックボリュームを犠牲にしてアプリケーションデータ配信の遅延制約を満たすために、送信者が宣伝する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)));
}
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NACK-based reliable multicast protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
この関数は、1マイクロ秒から1000秒の範囲のGRTT時間を量子化するのに役立つことに注意してください。もちろん、NACKベースの信頼性の高いマルチキャストプロトコルの実装は、実際的な理由から、広告されたGRTTの推定値（最大値を制限するなど）をさらに制約することを望む場合があります。
When NACK-based reliable multicast 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 any group size determination mechanism, a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. This conservative estimate (over-estimate) of group size in the algorithms described above will result in some added latency to the NACK repair process if the actual group size is smaller but with a guarantee of feedback implosion protection. The study of the timer-based feedback suppression mechanism described in [McastFeedback] and [NormFeedback] showed that the group size estimate need only be with an order-of-magnitude to provide effective suppression performance.
NACKベースの信頼性の高いマルチキャストプロトコル操作には、グループ全体からのフィードバックを励起するメカニズム（混雑制御など）が含まれている場合、受信したフィードバックメッセージの数に基づいてグループサイズを大まかに推定することができる場合があります。使用される確率的抑制メカニズム。このドキュメントで説明されているタイマーベースの抑制メカニズムは、適切に実行するためにグループサイズの非常に正確な推定値を必要としません。したがって、特に保守的に管理されている場合、大まかな推定で十分です。グループサイズも管理上決定できます。グループサイズの決定メカニズムがない場合、予想されるNACKベースの信頼性の高いマルチキャスト使用のスケーラビリティを考慮して、フィードバックの合理的な管理には、デフォルトのグループサイズ値10,000を推奨します。上記のアルゴリズムのグループサイズのこの保守的な推定（過大評価）は、実際のグループサイズが小さいがフィードバック爆発保護が保証されている場合、NACK修復プロセスにいくらか追加されるレイテンシをもたらします。[mcastFeedback]および[normfeedback]で説明されているタイマーベースのフィードバック抑制メカニズムの研究は、グループサイズの推定値が効果的な抑制性能を提供するために順序があるだけである必要があることを示しました。
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) [TfmccPaper] or Pragmatic General Multicast Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to NACK-based reliable multicast operation to meet this requirement. The former technique has been further documented in [RFC4654] and has been successfully applied in the NACK-Oriented Reliable Multicast Protocol (NORM) [RFC3940].
一般的なインターネット操作には、他の信頼できるマルチキャストおよびTCPインスタンス化と利用可能なネットワーク容量をかなり共有する混雑制御が必要です。TCPに優しいマルチキャスト輻輳制御（TFMCC）[TFMCCPAPE]または実用的な一般的なマルチキャスト輻輳制御（PGMCC）[PGMCCPAPE]手法は、この要件を満たすためにNACKベースの信頼できるマルチキャスト操作に適用できます。前者の手法は[RFC4654]でさらに文書化されており、NACK指向の信頼できるマルチキャストプロトコル（NORM）[RFC3940]に正常に適用されています。
NACK-based multicast protocols may benefit from general purpose intermediate system assistance. In particular, additional NACK suppression where 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 NACK-based reliable multicast 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. Similarly, intermediate systems could monitor receiver NACKs and provide repair transmissions on-demand in response if sufficient state on the content being transmitted was being maintained. This can reduce the latency and volume of repair transmissions when the intermediate system is associated with a network link that is particularly problematic with respect to packet loss. These types of assist functions would require intermediate system interpretation of transport data unit content identifiers and flags. NACK-based protocol designs should consider the potential for intermediate system assistance in the specification of protocol messages and operations. It is likely that intermediate systems assistance will be more pragmatic if message parsing requirements are modest and if the amount of state an intermediate system is required to maintain is relatively small.
NACKベースのマルチキャストプロトコルは、汎用の中間システム支援の恩恵を受ける可能性があります。特に、中間システムがNACKコンテンツを集約できる追加のNACK抑制（または、受信機からコンテンツ（または重複したNACKコンテンツ）を集約すると、送信者にリレーされているため、NORMグループサイズのスケーラビリティが向上する可能性があります。FECを使用したNACKベースの信頼性の高いマルチキャストプロトコルの場合、中間システムがFEC修復メッセージをフィルタリングして、以前のレシーバーから学んだ修理ニーズに応じて、マルチキャストトポロジの異なる脚に修理コンテンツのインテリジェントな「サブキャスト」を提供できる可能性があります。ナック。同様に、中間システムは、受信機のNACKを監視し、送信されているコンテンツの十分な状態が維持されている場合に応答して、オンデマンドで修復送信を提供できます。これにより、中間システムがパケットの損失に関して特に問題があるネットワークリンクに関連付けられている場合、修復送信の潜時と量を減らすことができます。これらのタイプのアシスト機能には、トランスポートデータユニットのコンテンツ識別子とフラグの中間システム解釈が必要です。NACKベースのプロトコル設計では、プロトコルメッセージと操作の仕様における中間システム支援の可能性を考慮する必要があります。メッセージの解析要件が控えめであり、維持するために中間システムが必要な場合、メッセージの解析要件が控えめな場合、中間システムの支援はより実用的になる可能性があります。
The Multicast NACK building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed NACK-based reliable multicast 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 multicast scalability property of NACK-based protocols [RmComparison], [RmClasses] 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. NACK-based reliable multicast protocols can make use of reciprocal (among senders and receivers) multicast communication under the any-source multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable of scalable operation in asymmetric topologies, such as source-specific multicast (SSM) [RFC4607], where there may only be unicast routing service from the receivers to the sender(s).
マルチキャストNACKビルディングブロックは、信頼できるデータ転送を達成するために否定的な承認を採用したいプロトコルに適用されます。適切に設計されたNACKベースの信頼性の高いマルチキャストプロトコルは、さまざまな理由で、基本レイヤー3 IPマルチキャストサービス（例えば、ユニキャストまたはハイブリッドユニキャスト/マルチキャストデータ分布ツリー）。さらに、NACKベースのプロトコル[RMComparison]、[rmclasses]のマルチキャストスケーラビリティプロパティは、単一のネットワークホップに広範な「ファンアウト」が予想される場合に適用可能です（ケーブルTVデータ配信、衛星、またはその他のブロードキャスト通信サービス）。さらに、「フラット」なグループ全体のマルチキャスト分布に基づくプロトコルの単純さは、広範囲の分散サービスまたは動的ネットワークとアプリケーションの利点を提供する可能性があります。NACKベースの信頼性の高いマルチキャストプロトコルは、RFC 1112 [RFC1112]で定義されている任意のソースマルチキャスト（ASM）モデルの下で、相互（送信者と受信機の）マルチキャスト通信を利用でき、ソースなどの非対称トポロジーでスケーラブルな動作が可能です。 - 特異的マルチキャスト（SSM）[RFC4607]。レシーバーから送信者へのユニキャストルーティングサービスのみがある可能性があります。
NACK-based reliable multicast protocol operation is compatible with transport layer forward error correction coding techniques as described in [RFC3453] and congestion control mechanisms such as those described in [TfmccPaper] and [PgmccPaper]. A principal limitation of NACK-based reliable multicast operation involves group size scalability when network capacity for receiver feedback is very limited. It is possible that, with proper protocol design, the intermediate system assistance techniques mentioned in Section 2.4 and described further in Section 3.10 can allow NACK-based approaches to scale to larger group sizes. NACK-based reliable multicast 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.
NACKベースの信頼性の高いマルチキャストプロトコル操作は、[RFC3453]に記載されているように、[TFMCCPAPE]や[PGMCCPAPE]に記載されているものなどの輻輳制御メカニズムと輸送層の前方エラー補正コード技術と互換性があります。NACKベースの信頼性の高いマルチキャスト操作の主な制限には、受信機フィードバックのネットワーク容量が非常に限られている場合のグループサイズのスケーラビリティが含まれます。適切なプロトコル設計により、セクション2.4で述べ、セクション3.10でさらに説明した中間システム支援技術により、NACKベースのアプローチがより大きなグループサイズにスケーリングできるようにする可能性があります。NACKベースの信頼性の高いマルチキャスト操作は、実装バッファリングの制約によっても支配されています。典型的なポイントツーポイント信頼できる輸送（TCPなど）に必要なバッファリングは、受信機グループの接続の格差を可能にし、グループサイズのスケーラビリティを達成するために必要なフィードバックの遅延を可能にするために推奨されます。
Prior experimental work included various protocol instantiations that implemented some of the concepts described in this building block document. This includes the Pragmatic General Multicast (PGM) protocol described in [RFC3208] as well as others that were documented or deployed outside of IETF activities. While the PGM protocol specification and some other approaches encompassed many of the goals of bulk data delivery as described here, this NACK-based building block provides a more generalized framework so that different application needs can be met by different protocol instantiation variants. The NACK-based building block approach described here includes compatibility with the other protocol mechanisms including FEC and congestion control that are described in other IETF reliable multicast building block documents. The NACK repair process described in this document can provide performance advantages compared to PGM when both are deployed on a pure end-to-end basis without intermediate system assistance. The round-trip timing estimation described here and its use in the NACK repair process allow protocol operation to more automatically adapt to different network environments or operate within environments where connectivity is dynamic. Use of the FEC payload identification techniques described in the FEC building block [RFC5052] and specific FEC instantiations allow protocol instantiations more flexibility as FEC techniques evolve than the specific sequence number data identification scheme described in the PGM specification. Similar flexibility is expected if protocol instantiations are designed to modularly invoke (at design time, if not run-time) the appropriate congestion control building block for different application or deployment purposes.
以前の実験作業には、このビルディングブロックドキュメントで説明されている概念の一部を実装するさまざまなプロトコルインスタンス化が含まれていました。これには、[RFC3208]に記載されている実用的な一般的なマルチキャスト（PGM）プロトコルと、IETFアクティビティの外部で文書化または展開された他のプロトコルが含まれます。PGMプロトコルの仕様と他のいくつかのアプローチには、ここで説明されているようにバルクデータ配信の多くの目標が含まれていましたが、このNACKベースのビルディングブロックは、異なるプロトコルインスタンス化バリアントによって異なるアプリケーションのニーズを満たすことができるように、より一般化されたフレームワークを提供します。ここで説明するNACKベースのビルディングブロックアプローチには、他のIETF信頼できるマルチキャストビルディングブロックドキュメントに記載されているFECや輻輳制御など、他のプロトコルメカニズムとの互換性が含まれます。このドキュメントで説明されているNACK修復プロセスは、両方が中間システム支援なしで純粋なエンドツーエンドベースで展開されている場合、PGMと比較してパフォーマンスの利点を提供できます。ここで説明する往復タイミングの推定とNACK修復プロセスでのその使用により、プロトコル操作は異なるネットワーク環境により自動的に適応するか、接続性が動的である環境内で動作することができます。FECビルディングブロック[RFC5052]および特定のFECインスタンス化に記載されているFECペイロード識別手法の使用により、PGM仕様で説明されている特定のシーケンス番号データ識別スキームよりもFEC技術が進化するため、プロトコルインスタンス化により柔軟性が高まります。プロトコルのインスタンス化が、さまざまなアプリケーションまたは展開の目的で適切な輻輳制御ビルディングブロックをモジュール式に呼び出すように設計されている場合、同様の柔軟性が予想されます。
NACK-based reliable multicast protocols are expected to be subject to the same security vulnerabilities as other IP and IP multicast protocols. However, unlike point-to-point (unicast) transport protocols, it is possible that one badly behaving participant can impact the transport service experience of others in the group. For example, a malicious receiver node could intentionally transmit NACK messages to cause the sender(s) to unnecessarily transmit repairs instead of making forward progress with reliable transfer. Also, group-wise messaging to support congestion control or other aspects of protocol operation may be subject to similar vulnerabilities. Thus, it is highly RECOMMENDED that security techniques such as authentication and data integrity checks be applied for NACK-based reliable multicast deployments. Protocol instantiations using this building block MUST identify approaches to security that can be used to address these and other security considerations.
NACKベースの信頼性の高いマルチキャストプロトコルは、他のIPおよびIPマルチキャストプロトコルと同じセキュリティの脆弱性の対象となると予想されます。ただし、ポイントツーポイント（ユニキャスト）輸送プロトコルとは異なり、1人の悪い振る舞いの参加者がグループ内の他の人の輸送サービスエクスペリエンスに影響を与える可能性があります。たとえば、悪意のあるレシーバーノードは、信頼できる転送で前進するのではなく、送信者が不必要に修理を送信するために、意図的にNACKメッセージを送信することができます。また、輻輳制御またはプロトコル操作の他の側面をサポートするためのグループごとのメッセージは、同様の脆弱性の対象となる場合があります。したがって、NACKベースの信頼性の高いマルチキャスト展開には、認証やデータの整合性チェックなどのセキュリティ手法を適用することを強くお勧めします。このビルディングブロックを使用したプロトコルインスタンス化は、これらおよびその他のセキュリティに関する考慮事項に対処するために使用できるセキュリティへのアプローチを特定する必要があります。
NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] 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, which could prevent a multicast sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. The IETF Multicast Security (MSEC) Working Group has developed a set of recommendations in its "Multicast Extensions to the Security Architecture for the Internet Protocol" [IpsecExtensions] that can be applied to appropriately extend IPsec mechanisms to multicast operation. An appendix of this document specifically addresses the NACK-Oriented Reliable Multicast protocol service model. As complete support for IPsec multicast operation may potentially follow reliable multicast deployment, NACK-based reliable multicast protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. This MAY be necessary when IPsec implementations are used that do not provide multicast replay attack protection when multiple sources are present.
NACKベースの信頼性の高いマルチキャストは、セッションの侵入とサービス攻撃に対する保護に推奨されるIPセキュリティ（IPSEC）認証メカニズム[RFC4301]と互換性があります。NACKベースのプロトコルに対する特定の脅威は、NACKリプレイ攻撃の脅威であり、マルチキャスト送信者が送信を前進させることを妨げる可能性があります。このようなリプレイ攻撃に対する保護を提供できる標準のIPSECメカニズムは、使用に推奨されます。IETFマルチキャストセキュリティ（MSEC）ワーキンググループは、「インターネットプロトコルのセキュリティアーキテクチャへのマルチキャスト拡張機能」[IPSExextensions]に、IPSECメカニズムをマルチキャスト操作に適切に拡張するために適用できる一連の推奨事項を開発しました。このドキュメントの付録は、NACK指向の信頼性の高いマルチキャストプロトコルサービスモデルを具体的に扱っています。IPSECマルチキャスト操作の完全なサポートは、信頼できるマルチキャスト展開に続く可能性があるため、NACKベースの信頼できるマルチキャストプロトコルインスタンスは、ネットワークレイヤーメカニズムが利用できない場合に独自のNACKリプレイ攻撃保護のサポートを提供することを検討する必要があります。これは、複数のソースが存在するときにマルチキャストリプレイ攻撃保護を提供しないIPSEC実装を使用する場合に必要になる場合があります。
For NACK-based multicast deployments with large receiver groups using IPsec, approaches might be developed that use shared, common keys for receiver-originated protocol messages to maintain a practical number of IPsec Security Associations (SAs). However, such group-based authentication may not be sufficient unless the receiver population can be completely trusted. Additionally, this can make identification of badly behaving (although authenticated) receiver nodes problematic as such nodes could potentially masquerade as other receivers in the group. In deployments such as this, one SHOULD consider use of source-specific multicast (SSM) instead of any-source multicast (ASM) models of multicast operation. SSM operation can simplify security challenges in a couple of ways:
IPSECを使用して大規模な受信機グループを使用したNACKベースのマルチキャスト展開の場合、実用的な数のIPSECセキュリティ協会（SA）を維持するために、レシーバーによって発生するプロトコルメッセージに共有された共通キーを使用するアプローチが開発される可能性があります。ただし、受信者集団が完全に信頼できない限り、このようなグループベースの認証は十分ではない場合があります。さらに、これにより、このようなノードがグループ内の他の受信機を潜在的に仮定する可能性があるため、問題のある（認証されていますが）レシーバーノードの識別が可能になります。このような展開では、マルチキャスト操作のあらゆるソースマルチキャスト（ASM）モデルの代わりに、ソース固有のマルチキャスト（SSM）の使用を検討する必要があります。SSM操作は、いくつかの方法でセキュリティの課題を簡素化できます。
1. A NACK-based protocol supporting SSM operation can eliminate direct receiver-to-receiver signaling. This dramatically reduces the number of security associations that need to be established.
1. SSM操作をサポートするNACKベースのプロトコルは、直接受信者から受信者へのシグナリングを排除できます。これにより、確立する必要があるセキュリティ協会の数が劇的に減少します。
2. The SSM sender(s) can provide a centralized management point for secure group operation for its respective data flow as the sender alone is required to conduct individual host authentication for each receiver when group-based authentication does not suffice or is not pragmatic to deploy.
2. SSM送信者は、グループベースの認証が十分ではない場合、または展開するのに実用的でない場合に、各受信者に対して個々のホスト認証を実施するために送信者だけが必要であるため、それぞれのデータフローの安全なグループ操作の集中管理ポイントを提供できます。
When individual host authentication is required, then it is possible receivers could use a digital signature on the IPsec Encapsulating Security Protocol (ESP) payload as described in [RFC4359]. Either an identity-based signature system or a group-specific public key infrastructure could avoid per-receiver state at the sender(s). Additionally, implementations MUST also support policies to limit the impact of extremely or exceptionally poor-performing (due to bad behavior or otherwise) receivers upon overall group operation if this is acceptable for the relevant application.
個々のホスト認証が必要な場合、[RFC4359]で説明されているように、受信機がIPSECカプセル化セキュリティプロトコル（ESP）ペイロードでデジタル署名を使用できる可能性があります。アイデンティティベースの署名システムまたはグループ固有の公開キーインフラストラクチャのいずれかが、送信者のレシーバーごとの状態を回避できます。さらに、実装は、関連するアプリケーションに受け入れられる場合、グループ全体の操作時に、極端にまたは非常に不十分な動作の影響を制限するためのポリシーもサポートする必要があります（動作が悪いため）レシーバーが全体的に操作されます。
As described in Section 3.4, deployment of NACK-based reliable multicast in some network environments may require identification of group members beyond that of IP addressing. If protocol-specific security mechanisms are developed, then it is RECOMMENDED that protocol group member identifiers are used as selectors (as defined in [RFC4301]) for the applicable security associations. When IPsec is used, it is RECOMMENDED that the protocol implementation verify that the source IP addresses of received packets are valid for the given protocol source identifier in addition to usual IPsec authentication. This would prevent a badly behaving (although authorized) member from spoofing messages from other legitimate members, provided that individual host authentication is supported.
セクション3.4で説明されているように、一部のネットワーク環境でのNACKベースの信頼できるマルチキャストの展開では、IPアドレスを超えてグループメンバーの識別が必要になる場合があります。プロトコル固有のセキュリティメカニズムが開発されている場合、プロトコルグループメンバー識別子は、該当するセキュリティ関連のために（[RFC4301]で定義されている）セレクターとして使用することをお勧めします。IPSECを使用する場合、プロトコルの実装では、受信したパケットのソースIPアドレスが、通常のIPSEC認証に加えて、指定されたプロトコルソース識別子に対して有効であることを確認することをお勧めします。これにより、個々のホスト認証がサポートされていれば、これにより、（認定された）メンバーが他の正当なメンバーからのメッセージをスプーフィングすることができなくなります。
The MSEC Working Group has also developed automated group keying solutions that are applicable to NACK-based reliable multicast security. For example, to support IPsec or other security mechanisms, the Group Secure Association Key Management Protocol [RFC4535] MAY be used for automated group key management. The technique it identifies for "Group Establishment for Receive-Only Members" may be application NACK-based reliable multicast SSM operation.
MSECワーキンググループは、NACKベースの信頼できるマルチキャストセキュリティに適用できる自動化グループキーイングソリューションも開発しました。たとえば、IPSECまたはその他のセキュリティメカニズムをサポートするために、Group Secure Association Key Management Protocol [RFC4535]を自動化されたグループキー管理に使用できます。「受信専用メンバーのグループ設立」で特定する手法は、アプリケーションNACKベースの信頼性の高いマルチキャストSSM操作である場合があります。
This section lists the changes between the Experimental version of this specification, [RFC3941], and this version:
このセクションには、この仕様の実験バージョン[RFC3941]とこのバージョンの間の変更を示します。
1. Change of title to avoid confusion with NORM Protocol specification,
1. ノルムプロトコル仕様との混乱を避けるためのタイトルの変更、
2. Updated references to related, updated RMT Building Block documents, and
2. 関連する、更新されたRMTビルディングブロックドキュメントへの更新された参照、および
3. More detailed security considerations.
3. より詳細なセキュリティ上の考慮事項。
(and these are not Negative)
（そして、これらは否定的ではありません）
The authors would like to thank George Gross, 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.
著者は、この文書に関する貴重なコメントについて、ジョージ・グロス、リック・ジョーンズ、ジョーグ・ウィドマーに感謝したいと思います。著者はまた、RMTワーキンググループの椅子、ロジャー・カーモードとロレンツォ・ヴィジサノに、この仕様の開発を支援してくれたこと、そしてこの文書への初期の入力についてサリー・フロイドに感謝したいと思います。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[ArchConsiderations] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proc. ACM SIGCOMM, pp. 201-208, September 1990.
[ArchConsiderations] Clark、D。およびD. Tennenhouse、「新世代のプロトコルに対する建築上の考慮事項」、Proc。ACM Sigcomm、pp。201-208、1990年9月。
[DelayEstimation] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[遅延判断] Ozdemir、V.、Muthukrishnan、S。、およびI. Rhee、「スケーラブル、低オーバーヘッドネットワーク遅延推定」、NCSU/AT＆Tホワイトペーパー、1999年2月。
[FECSchemes] Watson, M., "Basic Forward Error Correction (FEC) Schemes", Work in Progress, July 2008.
[Fecschemes] Watson、M。、「Basic Forward Error Correction（FEC）Schemes」、2008年7月に進行中の作業。
[FecBroadcast] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications Vol. Com-32, No. 6, June 1984.
[Fecbroadcast] Metzner、J。、「改善された放送再送信プロトコル」、IEEE Transactions on Communications Vol。com-32、No。6、1984年6月。
[FecHybrid] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE Globecomm 1998, 1998.
[Fechybrid] Gossink、D。およびJ. Macker、「信頼性の高いマルチキャストと統合されたパリティの再送信によるチャネル推定」、IEEE Globecomm 1998、1998。
[FecSchemes] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", Work in Progress, November 2007.
[Fecschemes] Lacan、J.、Roca、V.、Peltotalo、J。、およびS. Peltotalo、「Reed-Solomon Forward Error Correction（FEC）Schemes」、2007年11月、Work in Progress。
[IpsecExtensions] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", Work in Progress, June 2008.
[Ipsecextensions] Weis、B.、Gross、G。、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャへのマルチキャスト拡張」、2008年6月、進行中の作業。
[McastFeedback] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", IEEE Infocom p. 964, March/April 1998.
[mcastFeedback] Nonnenmacher、J。およびE. Biersack、「最適なマルチキャストフィードバック」、IEEE Infocom p。964、1998年3月/4月。
[NormFeedback] Adamson, B. and J. Macker, "Quantitative Prediction of NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE MILCOM 2002, October 2002.
[NormFeedback] Adamson、B。およびJ. Macker、「NACK指向の信頼できるマルチキャスト（NORM）フィードバックの定量的予測」、IEEE Milcom 2002、2002年10月。
[PgmccPaper] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", ACM SIGCOMM 2000, August 2000.
[PGMCCPAPE] Rizzo、L。、「PGMCC：TCPに優しいシングルレートマルチキャスト輻輳制御スキーム」、ACM Sigcomm 2000、2000年8月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanov、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208] Speakman、T.、Crowcroft、J.、Gemmell、J.、Farinacci、D.、Lin、S.、Leshchiner、D.、Luby、M.、Montgomery、T.、Rizzo、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R。、およびL. Vicisano、「PGM信頼できる輸送プロトコル仕様」、RFC 3208、2001年12月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R。およびL. Vicisano、「信頼できるマルチキャスト輸送（RMT）ビルディングブロックおよびプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[RFC3453] 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.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「ネガティブ承認型（NACK） - 信頼できるマルチキャスト（NORM）プロトコル」、RFC 3940、2004年11月。
[RFC3941] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[RFC3941] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「ネガティブ編集（NACK） - 信頼できるマルチキャスト（NORM）ビルディングブロック」、RFC 3941、2004年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年1月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年6月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654] Widmer、J。およびM. Handley、「TCPフレンドリーマルチキャスト輻輳制御（TFMCC）：プロトコル仕様」、RFC 4654、2006年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 5052、2007年8月。
[RmClasses] Levine, B. and J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96) Columbus, OH, October 1996.
[rmclasses] Levine、B。and J. Garcia-Luna-aceves、「信頼できるマルチキャストプロトコルの既知のクラスの比較」、Proc。1996年10月、オハイオ州コロンバスのネットワークプロトコルに関する国際会議（ICNP-96）コロンバス。
[RmComparison] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", Proc. INFOCOMM San Francisco, CA, October 1993.
[Rmcomparison] Pingali、S.、Towsley、D。、およびJ. Kurose、「送信者が開始した信頼できるマルチキャストプロトコルの比較」、Proc。Infocomm San Francisco、CA、1993年10月。
[RmFec] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", IEEE MILCOM 1997, October 1997.
[RMFEC] Macker、J。、「信頼性の高いマルチキャスト輸送および統合された消去ベースの前方エラー補正」、IEEE Milcom 1997、1997年10月。
[SrmFramework] 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.
[SRMFRAMEWORK] Floyd、S.、Jacobson、V.、McCanne、S.、Liu、C。、およびL. Zhang、「軽量セッションとアプリケーションレベルのフレーミングのための信頼できるマルチキャストフレームワーク」、Proc。ACM Sigcomm、1995年8月。
[TfmccPaper] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", ACM SIGCOMM 2001, August 2001.
[TFMCCPAPE] Widmer、J。およびM. Handley、「式ベースの輻輳制御をマルチキャストアプリケーションに拡張」、ACM Sigcomm 2001、2001年8月。
Authors' Addresses
著者のアドレス
Brian Adamson Naval Research Laboratory Washington, DC 20375
ブライアンアダムソン海軍研究所ワシントン、DC 20375
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 D-28334ブレーメン、ドイツ
EMail: cabo@tzi.org
Mark Handley University College London Gower Street London, WC1E 6BT UK
マークハンドリー大学ロンドンガワーストリートロンドン、WC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
ジョーマッカー海軍研究所ワシントン、DC 20375
EMail: macker@itd.nrl.navy.mil