[要約] RFC 3941は、NACK指向の信頼性のあるマルチキャスト（NORM）の構築要素に関するものであり、NACKを使用して信頼性を確保するためのプロトコルを提供します。このRFCの目的は、高い信頼性と効率的なマルチキャスト通信を実現するための基本的な要素を定義することです。
Network Working Group B. Adamson
Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
否定応答 (NACK) 指向の信頼できるマルチキャスト (NORM) ビルディング ブロック
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネット コミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準も指定しません。改善のための議論と提案が求められます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.
この文書では、否定応答 (NACK) 指向の信頼できるマルチキャスト (NORM) プロトコルの作成について説明します。NORM の目標と前提の理論的根拠が示されています。NACK 指向の (場合によっては一般的な) 信頼性の高いマルチキャスト プロトコル動作に対する技術的課題が特定されています。これらの目標と課題は、NORM プロトコル動作のさまざまな側面に対処する一連の機能的な「構成要素」として解決されます。これらの構成要素は、信頼性の高いマルチキャスト プロトコルのさまざまなインスタンスを生成する際に役立つことが期待されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
Reliable multicast transport is a desirable technology for the efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users [3]. This document addresses the creation of negative-acknowledgment (NACK)- oriented reliable multicast (NORM) protocols. While different protocol instantiations may be required to meet specific application and network architecture demands [4], there are a number of fundamental components that may be common to these different instantiations. This document describes the framework and common "building block" components relevant to multicast protocols based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NORM protocol design, it specifically addresses in detail the following building blocks which are not addressed in other IETF documents:
信頼性の高いマルチキャスト トランスポートは、インターネット上のグループにデータを効率的かつ信頼性高く配信するために望ましいテクノロジです。グループ通信パラダイムの複雑さにより、さまざまな潜在的な信頼性の高いマルチキャスト アプリケーションとユーザーのパフォーマンスとスケーラビリティ要件の範囲を満たすために、さまざまなプロトコル タイプとインスタンス化が必要になります [3]。この文書では、否定応答 (NACK) 指向の信頼できるマルチキャスト (NORM) プロトコルの作成について説明します。特定のアプリケーションやネットワーク アーキテクチャの要求を満たすには、さまざまなプロトコルのインスタンス化が必要になる場合があります [4] が、これらのさまざまなインスタンス化に共通する基本コンポーネントが多数あります。この文書では、主に信頼性の高い転送のための NACK 動作に基づいたマルチキャスト プロトコルに関連するフレームワークと共通の「ビルディング ブロック」コンポーネントについて説明します。このドキュメントでは、信頼性の高いマルチキャスト コンポーネントの大規模なセットと NORM プロトコル設計に関連する問題について説明しますが、特に、他の IETF ドキュメントでは取り上げられていない次の構成要素について詳しく取り上げます。
1) NORM sender transmission strategies,
1) NORM 送信側送信戦略、
2) NACK-oriented repair process with timer-based feedback suppression, and
2) タイマーベースのフィードバック抑制を備えた NACK 指向の修復プロセス、および
3) Round-trip timing for adapting NORM timers.
3) NORM タイマーを適応させるためのラウンドトリップ タイミング。
The potential relationships to other reliable multicast transport building blocks (Forward Error Correction (FEC), congestion control) and general issues with NORM protocols are also discussed. This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [5]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
他の信頼性の高いマルチキャスト トランスポートの構成要素 (前方誤り訂正 (FEC)、輻輳制御) との潜在的な関係や、NORM プロトコルの一般的な問題についても説明します。この文書は IETF RMT WG の成果物であり、RFC 3269 [5] で提供されるガイドラインに従っています。この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [1] に記載されているように解釈されます。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモには、RFC 2357 に従って信頼性の高いマルチキャスト トランスポート プロトコルを完全に指定するために必要な定義の一部が含まれています。RFC 2357 に従って、インターネットで信頼性の高いマルチキャスト プロトコルを使用するには、適切な輻輳制御スキームが必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームが利用可能になるか、既存のスキームが適切であることが証明されるのを待つ間、高信頼性マルチキャスト トランスポート ワーキング グループ (RMT) は、このコメント募集を「実験」カテゴリで公開します。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT の目的は、上記の条件が満たされ次第、この仕様を IETF 提案標準として再提出することです。
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
ここ (および他の該当するビルディング ブロックのドキュメント) で示されているビルディング ブロックを使用した潜在的なプロトコルのインスタンス化には、個々のプロトコルの設計に影響を与える可能性のある特定の基準があります。適用可能なビルディング ブロックの開発をサポートするには、推進する一般的なプロトコル設計の目標と前提を特定し、要約することが役立ちます。これらは、各プロトコルのインスタンス化で詳細に対処する必要がある領域です。このドキュメントの各ビルディング ブロックの説明には、これらの設計基準の影響についての説明が含まれます。ここで考慮される設計基準のカテゴリには次のものがあります。
1) Delivery Service Model, 2) Group Membership Dynamics, 3) Sender/receiver relationships, 4) Group Size Scalability, 5) Data Delivery Performance, 6) Network Environments, and 7) Router/Intermediate System Interactions.
1) 配信サービス モデル、2) グループ メンバーシップのダイナミクス、3) 送信者/受信者の関係、4) グループ サイズの拡張性、5) データ配信パフォーマンス、6) ネットワーク環境、7) ルーター/中間システムの相互作用。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents such as [9] have been created to address areas outside of the scope of this document. NORM protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NORM but may be used in concert with the other building block areas. In some cases, a building block may be able address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment.
これらすべての領域について、少なくとも簡単に説明します。さらに、この文書の範囲外の領域に対処するために、[9] などの他の信頼できるマルチキャスト トランスポート ビルディング ブロック文書が作成されています。NORM プロトコルのインスタンス化は、ここで示したものだけでなく、これらの他の構成要素にも依存する場合があります。このドキュメントでは、NORM に固有の領域に焦点を当てていますが、他の構成要素領域と組み合わせて使用することもできます。場合によっては、ビルディング ブロックが幅広い想定に対応できる場合もありますが、別の場合には、さまざまなアプリケーションのニーズや動作環境を満たすためにトレードオフが必要になる場合もあります。必要に応じて、ビルディング ブロックの機能は、さまざまな要件を満たすためにパラメトリックになるように設計されています。もちろん、基本的な目標は、設計の複雑さを最小限に抑え、一般的なインターネット環境における汎用の「バルク データ転送」要件を満たすようなパラメータのデフォルト値を少なくとも推奨することです。
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. A most basic service model for reliable multicast transport is that of "bulk transfer" which is a primary focus of this and other related RMT working group documents. However, the same principles in protocol design may also be applied to other services models, e.g., more interactive exchanges of small messages such as with white-boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
信頼性の高いマルチキャスト トランスポート プロトコルの暗黙の目標は、IP マルチキャスト データグラム サービスを使用して通信するメンバーのグループ間でデータを確実に配信することです。ただし、アプリケーションが提供しようとしている特定のサービスは、設計上の決定に影響を与える可能性があります。信頼性の高いマルチキャスト転送のための最も基本的なサービス モデルは、「バルク転送」です。これは、この文書およびその他の関連する RMT ワーキング グループ文書の主な焦点です。ただし、プロトコル設計における同じ原則は、他のサービス モデル、たとえば、ホワイトボードやテキスト チャットなどの小さなメッセージのよりインタラクティブな交換にも適用できます。これらのさまざまなモデルには、送信側が再送信または修復のために送信データ (またはそれを参照する状態) をキャッシュする能力などの問題があります。グループ内のメンバー間の送受信のシーケンスにおける順序付けおよび/または因果関係の必要性は、データの内容に応じて異なる場合があります。グループ通信パラダイムは、データ コンテンツ タイプに応じて、一部の受信者がデータ コンテンツの一部の受信を完了し、他のメンバーがコンテンツを受信する前にそのコンテンツに基づいて動作できる場合があるという点で、ポイントツーポイント モデルとは大きく異なります。これは、一部のアプリケーションでは許容できる (または望ましい) 場合もありますが、他のアプリケーションでは許容できない場合があります。これらのさまざまな要件により、さまざまなプロトコルのインスタンス化設計の必要性が高まります。一般に有用なビルディング ブロック メカニズムを開発する際の重要な課題は、特定のアプリケーション レベルの詳細を定義せずに、これらの機能の限られた範囲にも対応することです。
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
グループ コミュニケーションがポイントツーポイント コミュニケーションと異なる点の 1 つは、グループの構成が変わった場合でも、コミュニケーションの「スレッド」が依然として存在できることです。これは、二者のいずれかが離れると通信プロセス (データ交換) が終了 (または少なくとも一時停止) されるポイントツーポイント通信モデルとは対照的です。アプリケーションの目標に応じて、信頼性の高いマルチキャスト トランスポート「セッション」に参加している送信者と受信者は、進行中のグループ通信「スレッド」がまだ機能し有用なままである間に、遅れて参加したり、退席したり、潜在的に再参加したりすることができる場合があります。これはプロトコル メッセージの内容に影響を与える可能性があることにも注意してください。「遅延参加者」がサポートされている場合、この機能に対応するために、ある程度の追加情報がメッセージ ヘッダーに配置される場合があります。あるいは、一般的なメッセージ送信のオーバーヘッドへの影響が大きすぎると思われる場合は、情報を独自のメッセージで (オンデマンドまたは断続的に) 送信することもできます。グループのダイナミクスは、NACK タイミング、輻輳制御動作などの他のプロトコル メカニズムにも影響を与える可能性があります。
The relationship of senders and receivers among group members requires consideration. In some applications, there may be a single sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender _and_ receiver of data may exist.
グループメンバー間の送信者と受信者の関係には考慮が必要です。アプリケーションによっては、単一の送信者が受信者のグループにマルチキャストする場合があります。他の場合には、送信者が複数存在するか、グループ内の全員がデータの送信者および受信者になる可能性があります。
Native IP multicast [2] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-oriented protocol can apply without NACK implosion problems. Research suggests that NORM group sizes on the order of tens of thousands of receivers may operate with modest feedback to the sender using probabilistic, timer-based suppression techniques [7]. However, the potential for router assistance and/or other NACK suppression heuristics may enable these protocols to scale to very large group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
ネイティブ IP マルチキャスト [2] は、非常に大きなグループ サイズに拡張することができます。一部のアプリケーションでは、マルチキャスト インフラストラクチャの拡張機能に合わせて拡張することが望ましい場合があります。最も単純な形式では、NACK の爆縮問題なしに NACK 指向のプロトコルを適用できるグループ サイズには制限があります。研究によると、数万人規模の受信側 NORM グループは、確率的なタイマーベースの抑制技術を使用して、送信側への控えめなフィードバックで動作する可能性があることが示唆されています [7]。ただし、ルーター支援やその他の NACK 抑制ヒューリスティックの可能性により、これらのプロトコルを非常に大きなグループ サイズに拡張できる可能性があります。大規模な場合、メンバーがグループ内の他のすべてのメンバー (特に他の受信者) の状態を維持することは法外な場合があります。適用可能な構成要素を開発する際には、グループのサイズの影響を考慮する必要があります。
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer-based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and for the sender of data to identify appropriate content for efficient repair transmission. For example, backoff timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at a cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
NACK 指向のプロトコルを設計する場合、スケーラビリティとデータ配信遅延の間にはトレードオフがあります。確率的なタイマーベースの NACK 抑制が使用される場合、抑制が発生し、データの送信者が効率的な修復送信に適したコンテンツを識別できるようにするために、NACK プロセスにある程度の遅延が組み込まれます。たとえば、バックオフ タイムアウトを使用すると、NACK の抑制と送信の修復を効率的に行うことができますが、これには配信遅延の増加と、送信側と受信側の両方のバッファリング要件の増加という代償が伴います。ビルディング ブロックにより、アプリケーションはデータ配信パフォーマンスの限界を確立できるようにすべきです (SHOULD)。アプリケーション設計者は、そのような制限が適用されるときに生じるスケーラビリティのトレードオフを認識する必要があることに注意してください。
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 single source multicast (SSM) model from a specific source [8]. Receivers in the group may be restricted to unicast feedback for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks.
インターネット プロトコルは歴史的に、異種ネットワーク トポロジ全体にサービスを提供する役割を担ってきました。信頼性の高いマルチキャスト プロトコルが、汎用 IP サービスが適用される広範囲のネットワークにわたって効果的に動作できることが望ましい。現在、単一グループのメンバー間のリンクで利用可能な帯域幅は、他のフローとの競合の程度に応じて、ワイヤレス リンクの低い kbit/s から高速 LAN 接続の数 Gbit/s まで変化する可能性があります。最近、56K/ADSL モデム、CATV インターネット サービス、衛星およびその他の無線通信サービスを含む多くの非対称ネットワーク サービスが普及し始めています。これらの多くは本質的に大きな「ファンアウト」を伴うブロードキャスト メディアであり、IP マルチキャスト サービスが非常に適用可能です。さらに、ポリシーや技術的な問題により、マルチキャスト接続が特定のソースからの単一ソース マルチキャスト (SSM) モデルに限定されるトポロジが発生する可能性があります [8]。グループ内の受信者は、NACK およびその他のメッセージのユニキャスト フィードバックに制限される場合があります。ビルディング ブロックの開発とプロトコルの設計では、基礎となるネットワークの性質を考慮する必要があります。
While intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to leverage the performance and scalability of reliable multicast protocols, there will continue to be a number of instances where this is not available or practical. Any building block components for NACK-oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
信頼できるマルチキャスト プロトコルのパフォーマンスとスケーラビリティを活用するには、基盤となるネットワーク トポロジを直接知っているデバイス/システムからの中間支援を使用できますが、これが利用できない、または実用的でない場合は今後も数多く存在します。NACK 指向の信頼性のあるマルチキャストのビルディング ブロック コンポーネントは、そのような支援なしで動作できるものとします (SHALL)。ただし、利用可能な場合には、そのようなプロトコルでもこれらの機能の利用を考慮することが推奨されます。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NORM building block identification/design. This section describes different building block areas applicable to NORM protocols. Some of these areas are specific to NACK-oriented protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those other general building block areas from the standpoint of NACK-oriented reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NORM protocols.
前のセクションでは、プロトコル ビルディング ブロックの役割と、NORM ビルディング ブロックの識別/設計に影響を与える可能性のある基準のいくつかを示しました。このセクションでは、NORM プロトコルに適用できるさまざまな構成要素の領域について説明します。これらの領域の一部は、NACK 指向のプロトコルに固有です。このような領域の詳細な説明が提供されます。他の場合には、その領域（例えば、ノード識別子、前方誤り訂正（ＦＥＣ）など）は、他の形式の信頼できるマルチキャストに適用できる場合がある。このような場合、以下の説明では、NACK 指向の信頼性のあるマルチキャストの観点から、他の一般的な構成要素領域に課せられる要件について説明します。該当する場合、NORM プロトコルへの貢献の可能性について、他の構成要素の文書が参照されます。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NORM building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
ビルディング ブロックごとに、あるビルディング ブロック コンポーネントの別のコンポーネントまたは他のプロトコル パラメーターに対する依存関係を示す概念的な「インターフェイス記述」が提供されます。ビルディング ブロック コンポーネントは、その機能を実行するために、別のビルディング ブロック コンポーネントまたは他のソースからの何らかの形式の「入力」を必要とする場合があります。ビルディング ブロック コンポーネントに必要な「入力」および/またはその結果として提供される「出力」は、各ビルディング ブロック コンポーネントのインターフェイス記述で定義および説明されます。ここで紹介されている一連の構成要素は、互いの「入力」と「出力」のニーズを完全には満たしていないことに注意してください。場合によっては、ここでのビルディング ブロックの「入力」は、このドキュメントの外部にある他のビルディング ブロック (輻輳制御や FEC など) から取得する必要があります。他の場合には、NORM ビルディング ブロックの「入力」は、特定のプロトコルのインスタンス化または実装 (アプリケーション データや制御など) によって満たされる必要があります。
The following building block components relevant to NORM are identified:
NORM に関連する次の構成要素コンポーネントが特定されています。
(NORM-Specific) 1) NORM Sender Transmission 2) NORM Repair Process 3) NORM Receiver Join Policies (General Purpose) 4) Node (member) Identification 5) Data Content Identification 6) Forward Error Correction (FEC) 7) Round-trip Timing Collection 8) Group Size Determination/Estimation 9) Congestion Control Operation 10) Router/Intermediate System Assistance 11) Ancillary Protocol Mechanisms
(NORM 固有) 1) NORM 送信側送信 2) NORM 修復プロセス 3) NORM 受信側参加ポリシー (汎用) 4) ノード (メンバー) 識別 5) データコンテンツ識別 6) 前方誤り訂正 (FEC) 7) ラウンドトリップタイミング収集 8) グループ サイズの決定/推定 9) 輻輳制御操作 10) ルーター/中間システム支援 11) 補助プロトコル メカニズム
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
図 1 は、これらの構成要素領域とそれらの関係の一部の概要を図で示しています。たとえば、送信者が最初に送信するデータ メッセージの内容は、「ノード識別」、「データ コンテンツ識別」、および「FEC」コンポーネントに依存しますが、メッセージ送信速度は一般に「輻輳制御」コンポーネントに依存します。その後、これらの送信に対する受信者の応答 (修復のための NACK など) は、データ メッセージの内容と他のビルディング ブロック コンポーネントからの入力に依存します。最後に、送信者による受信者の応答の処理は、その送信戦略にフィードバックされます。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------' _.-' `-----------------------' |
.---------------------. _.-' .' | .--------------. |
| Data Identification |--' .'' | | Join Policy | |
`---------------------' .' ' v `--------------' |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK | |
| `---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| `---------------------'` `._ | `------------------' | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------' .`- ` | `------------------' | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------'`. ` ` | `------------------' | |
.---------------------. ` ` ` `------------------------' |
| Other | ` ` ` | .-----------------. |
`---------------------' ` ` ` | |Router Assistance| |
`. ` ` v `-----------------' |
`.`' .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Fig. 1 - NORM Building Block Framework
図 1 - NORM ビルディング ブロック フレームワーク
The components on the left side of this figure are areas that may be applicable beyond NORM. The most significant of these components are discussed in other building block documents such as [9]. A brief description of these areas and their role in the NORM protocol is given below. The components on the right are seen as specific to NORM protocols, most notably the NACK repair process. These areas are discussed in detail below. Some other components (e.g., "Security") impact many aspects of the protocol, and others such as "Router Assistance" may be more transparent to the core protocol processing. The sections below describe the "NORM Sender Transmission", "NORM Repair Process", and "RTT Collection" building blocks in detail. The relationships to and among the other building block areas are also discussed, focusing on issues applicable to NORM protocol design. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NORM transport for the Internet.
この図の左側のコンポーネントは、NORM を超えて適用できる可能性のある領域です。これらのコンポーネントのうち最も重要なものは、[9] などの他の構成要素の文書で説明されています。これらの領域と NORM プロトコルにおけるそれらの役割の簡単な説明を以下に示します。右側のコンポーネントは NORM プロトコルに固有のものであり、最も注目に値するのは NACK 修復プロセスです。これらの領域については、以下で詳しく説明します。他の一部のコンポーネント (「セキュリティ」など) はプロトコルの多くの側面に影響を与えますが、「ルーター支援」などの他のコンポーネントは、コアのプロトコル処理に対してより透過的である可能性があります。以下のセクションでは、「NORM 送信者送信」、「NORM 修復プロセス」、および「RTT コレクション」の構成要素について詳しく説明します。NORM プロトコル設計に適用できる問題に焦点を当てて、他の構成要素領域との関係および他の構成要素領域間の関係についても説明します。該当する場合、インターネットの NORM トランスポートの目標を適切に満たすメカニズムについて、特定の技術的推奨事項が作成されます。
NORM senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of [9]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), NORM transmission SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from NORM senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
NORM 送信者はデータ コンテンツをマルチキャスト セッションに送信します。データの内容はアプリケーションによって異なります。送信者は、アプリケーションやネットワーク アーキテクチャの要件によって決定されるレートとメッセージ サイズでデータ コンテンツを送信します。送信側送信の FEC エンコーディングは、[9] のガイドラインに準拠する必要があります (SHOULD)。輻輳制御メカニズムが必要な場合（一般的なインターネット運用には必須）、NORM 送信は輻輳制御メカニズムによって制御されるものとします（SHALL）。いずれの場合も、NORM 送信者からのすべてのデータ送信は、アプリケーションまたは輻輳制御アルゴリズムによって決定されるレート制限の対象となることが推奨されます。送信者の送信は、利用可能な容量 (アプリケーションや輻輳制御によって制限される可能性がある) を有効に利用する必要があります (SHOULD)。その結果、新しいデータコンテンツの送信と修復コンテンツの重複および多重化が発生することが予想されます。アプリケーションの動作に関連するその他の要因によって、送信者の送信形式と方法が決定される場合があります。たとえば、送信するデータがない断続的なアイドル期間中の送信者の動作については、ある程度の考慮が必要です。
In addition to data content, other sender messages or commands may be employed as part of protocol operation. These messages may occur outside of the scope of application data transfer. In NORM protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require following the rules of the NORM NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK-oriented responses from the receivers to this command.
データコンテンツに加えて、他の送信メッセージまたはコマンドがプロトコル操作の一部として使用される場合があります。これらのメッセージは、アプリケーション データ転送の範囲外で発生する可能性があります。NORM プロトコルでは、グループ サイズのスケーラビリティの問題により肯定応答が不可能な場合、そのようなプロトコル メッセージの信頼性を冗長送信によって試みることがあります。プロトコル設計は、そのようなメッセージがグループによって受信されない場合に対処するためのメカニズムを提供すべきである(SHOULD)ことに注意してください。一例として、一時的 (または永久的) に送信を停止していることを示すために、送信者によってコマンド メッセージが冗長に送信される場合があります。現時点では、受信機が NORM NACK 手順の規則に従って必要な未処理の修復に対して NACK で応答することが適切な場合があります。効率を高めるために、送信者は、このコマンドに対する受信者からの NACK 指向の応答を受信するために、冗長送信の間に十分な時間を与える必要があります。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NORM protocol timeouts should be dependent upon the group greatest round trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The NORM GRTT is an estimate of the worst-case round-trip timing from a sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to given sender. NORM instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
一般に、結果として NACK またはその他のフィードバック操作が発生した場合、送信者によって発行された制御メッセージの冗長送信およびその他の NORM プロトコル タイムアウトのタイミングは、グループ最大ラウンド トリップ タイミング (GRTT) の推定値と、予想される結果として生じる NACK に依存する必要があります。または他のフィードバック操作。NORM GRTT は、送信者からグループ内の任意の受信者への最悪の場合の往復タイミングの推定値です。GRTT 間隔は、特定の送信者に関するネットワーク トポロジ全体のマルチキャスト グループの (遅延に関する) 最大スパンの控えめな推定値であると想定されます。NORM インスタンス化は、広範囲のマルチキャスト ネットワーク トポロジに動的に適応できる必要があります (SHOULD)。
Sender Transmission Interface Description
送信側送信インターフェースの説明
Inputs:
入力:
1) Application data and control 2) Sender node identifier 3) Data identifiers 4) Segmentation and FEC parameters 5) Transmission rate 6) Application controls 7) Receiver feedback messages (e.g., NACKs)
1) アプリケーションデータと制御 2) 送信側ノード識別子 3) データ識別子 4) セグメンテーションおよび FEC パラメータ 5) 伝送速度 6) アプリケーション制御 7) 受信側フィードバックメッセージ (NACK など)
Outputs:
出力:
1) Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the NORM session. 2) Commands indicating sender's status or other transport control actions to be taken.
1) NORM セッションのコンテキスト内でデータまたは修復コンテンツを一意に識別するヘッダーを持つメッセージの制御された送信。2) 送信者のステータスまたは実行される他のトランスポート制御アクションを示すコマンド。
A critical component of NORM protocols is the NACK repair process. This includes the receiver's role in detecting and requesting repair needs, and the sender's response to such requests. There are four primary elements of the NORM repair process:
NORM プロトコルの重要なコンポーネントは、NACK 修復プロセスです。これには、修理の必要性を検出して要求する受信者の役割と、そのような要求に対する送信者の応答が含まれます。NORM 修復プロセスには 4 つの主要な要素があります。
1) Receiver NACK process initiation,
1) 受信側の NACK プロセスの開始、
3) NACK suppression,
3) NACK抑制、
2) NACK message content,
2) NACKメッセージの内容、
4) Sender NACK processing and response.
4) 送信者の NACK 処理と応答。
The NORM NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the NORM data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
NORM NACK プロセス (サイクル) は、信頼性の高い受信を実現するために、特定の送信者からの修復送信の必要性を検出した受信者によって開始されます。FEC が適用される場合、受信機は、修復要件がデータ コンテンツの特定のコーディング ブロックに対する保留中の FEC 送信の量を超えることがわかっている場合にのみ、NACK プロセスを開始する必要があります。これは、現在の送信ブロックの終了時（指定されている場合）、または後続のコーディングブロックまたは送信オブジェクトの受信の開始時に決定できます。これは、NORM データ コンテンツがその FEC ブロック番号を識別するためにマークされていること、および順序関係が送信順序で保存されていることを意味します。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK processor earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events such as at the end-of-transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
あるいは、送信側の送信がブロックに対して送信する予定の修復パケットの量をアドバタイズする場合、受信側は NACK プロセッサをより早く開始できる可能性があります。受信機が修復の必要性が保留中の修復送信を超えたことを検出したときにいつでも NACK サイクルを開始できるようにすると、修復サイクルがわずかに速くなる可能性があります。ただし、NACK プロセスの開始を、FEC コーディング ブロックの送信終了時や後続のコーディング ブロックの検出時などの特定のイベントに制限すると便利な場合があります。これにより、受信機は NACK コンテンツを少数の NACK メッセージに集約し、受信機セット間で暗黙的な緩やかな同期を提供して、NACK フィードバックの効果的な確率的抑制を促進することができます。受信者は、現在の修復の必要性を判断するために、送信者から受信したデータ内容の履歴を維持しなければなりません(MUST)。FEC が使用される場合、履歴は保留中または部分的に受信されたコーディング ブロックの記録に対応することが期待されます。
For probabilistic, timer-base suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the current position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
フィードバックを確率的にタイマーベースで抑制するには、受信機がバックオフ タイムアウトを監視することから NACK サイクルを開始する必要があります。このバックオフ タイムアウトの開始と併せて、受信側が NACK サイクルを開始する送信側の送信シーケンス内の現在位置を記録することが重要です。抑制バックオフ タイムアウトが経過すると、受信機は、NACK を送信するか抑制するかを決定する際に、この記録された送信位置までの修復の必要性のみを考慮する必要があります。この制限がないと、NACK メッセージがネットワークを介して送信者および他の受信者に伝播する間に送信者から追加のコンテンツが受信されるため、抑制が大幅に軽減されます。
Receiver NACK Process Initiation Interface Description
受信側 NACK プロセス開始インターフェイスの説明
Inputs:
入力:
1) Sender data content with sequencing identifiers from sender transmissions. 2) History of content received from sender.
1) 送信者の送信からのシーケンス識別子を含む送信者のデータ コンテンツ。2) 送信者から受信したコンテンツの履歴。
Outputs:
出力:
1) NACK process initiation decision 2) Recorded sender transmission sequence position.
1) NACK プロセス開始の決定 2) 記録された送信側送信シーケンス位置。
An effective NORM feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [10]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or provide some other indicator of the repair information it will be subsequently transmitting.
効果的な NORM フィードバック抑制メカニズムは、修復を必要とする受信機による NACK 送信の前にランダム バックオフ タイムアウトを使用することです [10]。バックオフ タイムアウトが経過すると、受信者は、保留中の修復の必要性が、他の受信者から受信した NACK メッセージ (受信者が NACK をマルチキャストしている場合)、または送信者からの何らかのインジケーターによって完全に置き換えられない限り、修復を要求します。受信者が NACK メッセージをユニキャストしている場合、送信者は、受信した NACK コンテンツの表現をグループ全体に転送するか、その後送信する修復情報のその他のインジケーターを提供することによって、NACK 抑制を容易にすることができます。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [6]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of sender<->group GRTT and a group size estimate that is determined by other mechanisms within the protocol or preset by the multicast application.
効果的かつスケーラブルな抑制パフォーマンスを得るには、受信機が使用するバックオフ タイムアウト期間は、切り捨てられた指数分布を使用して受信機によって独立してランダムに選択される必要があります [6]。この結果、少数の「初期 NACKer」がグループの残りの修復ニーズに取って代わるという想定の下、受信機セットの大部分が NACK メッセージの送信を保留することになります。分布の平均は、送信者<->グループ GRTT の現在の推定値と、プロトコル内の他のメカニズムによって決定されるか、マルチキャスト アプリケーションによって事前に設定されるグループ サイズ推定値の関数として決定される必要があります。
A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g., NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T_maxBackoff) can be set to control reliable delivery latency versus volume of feedback traffic. A larger value of T_maxBackoff will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T_maxBackoff results in shorter latency which also reduces the buffering requirements of senders and receivers for reliable transport.
単純なアルゴリズムを構築して、適切な分布でランダムなバックオフ タイムアウトを生成できます。さらに、フィードバックを生成する可能性がある受信機 (R) の数を考慮して、バックオフ分布を最適化するようにアルゴリズムを設計することもできます。この「最適化」により、すべての受信機が NACK を生成する最悪の状況でのフィードバック メッセージ (NACK など) の数が最小限に抑えられます。最大バックオフ タイムアウト (T_maxBackoff) を設定して、信頼性の高い配信遅延とフィードバック トラフィックの量を制御できます。T_maxBackoff の値が大きいほど、特定の修復サイクルにおけるフィードバック トラフィックの密度が低くなります。T_maxBackoff の値が小さいほど遅延が短くなり、信頼性の高いトランスポートを実現するための送信側と受信側のバッファリング要件も軽減されます。
Given the receiver group size (R), and maximum allowed backoff timeout (T_maxBackoff), random backoff timeouts (t') with a truncated exponential distribution can be picked with the following algorithm: 1) Establish an optimal mean (L) for the exponential backoff based on the group size:
受信グループ サイズ (R) と最大許容バックオフ タイムアウト (T_maxBackoff) を考慮すると、切り捨てられた指数分布を持つランダム バックオフ タイムアウト (t') を次のアルゴリズムで選択できます。 1) 指数分布の最適平均 (L) を確立します。グループサイズに基づくバックオフ:
L = ln(R) + 1
2) Pick a random number (x) from a uniform distribution over a range of:
2) 次の範囲にわたる一様分布から乱数 (x) を選択します。
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
3) Transform this random variate to generate the desired random backoff time (t') with the following equation:
3) 次の方程式を使用して、このランダム変数を変換して、目的のランダム バックオフ時間 (t') を生成します。
t' = T_maxBackoff/L * ln(x * (exp(L) - 1) * (T_maxBackoff/L))
This C language function can be used to generate an appropriate random backoff time interval:
この C 言語関数を使用すると、適切なランダム バックオフ時間間隔を生成できます。
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following C code can be used:
ここで、UniformRand(double max) は、0..max の範囲から一様分布を持つ乱数を返します。たとえば、POSIX の「rand()」関数に基づいて、次の C コードを使用できます。
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
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 tradeoff worst-case NACK feedback volume versus latency. This is derived from [6] and assumes T_maxBackoff >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above.
したがって、最大バックオフ時間は、最悪の場合の NACK フィードバック量と待ち時間のトレードオフに調整できます。これは [6] から導出され、T_maxBackoff >= GRTT を仮定し、L は上記のアルゴリズムで示されているように、特定のグループ サイズに対して最適化された分布の平均です。
Note that other mechanisms within the protocol may work to reduce redundant NACK generation further. It is suggested that T_maxBackoff be selected as an integer multiple of the sender's current advertised GRTT estimate such that:
プロトコル内の他のメカニズムは、冗長な NACK 生成をさらに減らすために機能する可能性があることに注意してください。T_maxBackoff は、送信者が現在アドバタイズしている GRTT 推定値の整数倍として、次のように選択することをお勧めします。
T_maxBackoff = K * GRTT ;where K >= 1
For general Internet operation, a default value of K=4 is RECOMMENDED for operation with multicast (to the group at large) NACK delivery and a value of K=6 for unicast NACK delivery. Alternate values may be used to for buffer utilization, reliable delivery latency and group size scalability tradeoffs.
一般的なインターネット操作では、マルチキャスト (グループ全体へ) NACK 配信の操作にはデフォルト値 K=4 が推奨され、ユニキャスト NACK 配信には K=6 の値が推奨されます。代替値は、バッファ使用率、信頼性の高い配信遅延、およびグループ サイズのスケーラビリティのトレードオフに使用できます。
Given that (K*GRTT) is the maximum backoff time used by the receivers to initiate NACK transmission, other timeout periods related to the NACK repair process can be scaled accordingly. One of those timeouts is the amount of time a receiver should wait after generating a NACK message before allowing itself to initiate another NACK backoff/transmission cycle (T_rcvrHoldoff). This delay should be sufficient for the sender to respond to the received NACK with repair messages. An appropriate value depends upon the amount of time for the NACK to reach the sender and the sender to provide a repair response. This MUST include any amount of sender NACK aggregation period during which possible multiple NACKs are accumulated to determine an efficient repair response. These timeouts are further discussed in the section below on "Sender NACK Processing and Repair Response".
(K*GRTT) が NACK 送信を開始するために受信機によって使用される最大バックオフ時間であるとすると、NACK 修復プロセスに関連する他のタイムアウト期間は、それに応じて調整できます。これらのタイムアウトの 1 つは、受信機が NACK メッセージを生成した後、別の NACK バックオフ/送信サイクル (T_rcvrHoldoff) を開始できるようになるまで待機する必要がある時間です。この遅延は、送信者が受信した NACK に修復メッセージで応答するのに十分なはずです。適切な値は、NACK が送信者に到達するまでの時間、および送信者が修復応答を提供するまでの時間によって異なります。これには、効率的な修復応答を決定するために可能な複数の NACK が蓄積される送信側 NACK 集約期間の任意の量が含まれなければなりません (MUST)。これらのタイムアウトについては、以下の「送信側 NACK 処理と修復応答」のセクションで詳しく説明します。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
フィードバック抑制のパフォーマンスを向上させるために適用できる二次的な対策もあります。たとえば、送信者のデータ コンテンツの送信は、通常の送信シーケンスに従うことができます。データ コンテンツの修復が発生すると、受信者は、データ オブジェクト、FEC ブロック番号、および FEC シンボル識別子を観察することで、送信者がデータ コンテンツの送信位置を「巻き戻し」たことに気づくことができます。受信者は、送信者の現在の送信位置が受信者の受信が不完全な地点を超えた場合にのみ、NACK の送信を制限すべきである(SHOULD)。これにより、送信者が他の受信者の要求に応じて提供する予定のデータ修復の時期尚早な要求が減少します。このメカニズムは、他の受信者 (または送信者からのインジケーター) からの NACK の送信が失われたときの高損失状態でのプロトコルの収束に非常に効果的です。もう 1 つのメカニズム (特に FEC が使用される場合に適用可能) は、送信者が現在送信されているパケットに差し迫った修復送信の表示を埋め込むことです。例えば、この指示は、現在適用可能なコーディングブロックに対して送信されるＦＥＣパケットの数を通知するという単純なものであってもよい。
Finally, some consideration might be given to using the NACKing history of receivers to weight their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires there is correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not be present in multicast networks. This adjustment of backoff timeout selection may require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process that may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network.
最後に、受信機の NACK 履歴を使用して NACK バックオフ タイムアウト間隔の選択に重みを付けることを考慮することも考えられます。たとえば、受信機が過去に最も大きな損失を経験している場合、統計的に他の受信機よりも早く NACK を行う可能性があります。これには、受信機が経験する損失に連続する時間間隔にわたって相関関係があることが必要であることに注意してください。このような相関関係は、マルチキャスト ネットワークには存在しなくてもよい(MAY)。バックオフ タイムアウト選択のこの調整には、これらの履歴 NACKer 用の「初期 NACK」スロットの作成が必要になる場合があります。NACK バックオフ ウィンドウ内のこの追加スロットにより、修復サイクル プロセスが長くなり、一部のアプリケーションにとっては望ましくない可能性があります。これらのトレードオフの解決は、プロトコルのターゲット アプリケーション セットまたはネットワークに依存する場合があります。
After the random backoff timeout has expired, the receiver will make a decision on whether to generate a NACK repair request or not (i.e., it has been suppressed). The NACK will be suppressed when any of the following conditions has occurred:
ランダム バックオフ タイムアウトが経過すると、受信側は NACK 修復要求を生成するかどうか (つまり、NACK 修復要求が抑制されたかどうか) を決定します。次のいずれかの状況が発生した場合、NACK は抑制されます。
1) The accumulated state of NACKs heard from other receivers (or forwarding of this state by the sender) is equal to or supersedes the repair needs of the local receiver. Note that the local receiver should consider its repair needs only up to the sender transmission position recorded at the NACK cycle initiation (when the backoff timer was activated).
1) 他の受信者から受信した NACK の蓄積状態 (または送信者によるこの状態の転送) は、ローカル受信者の修復ニーズと同等か、またはそれに優先します。ローカル受信機は、NACK サイクルの開始時 (バックオフ タイマーがアクティブ化されたとき) に記録された送信側送信位置までのみ、修復の必要性を考慮する必要があることに注意してください。
2) The sender's data content transmission position "rewinds" to a point ordinally less than that of the lowest sequence position of the local receiver's repair needs. (This detection of sender "rewind" indicates the sender has already responded to other receiver repair needs of which the local receiver may not have been aware). This "rewind" event can occur any time between 1) when the NACK cycle was initiated with the backoff timeout activation and 2) the current moment when the backoff timeout has expired to suppress the NACK. Another NACK cycle must be initiated by the receiver when the sender's transmission sequence position exceeds the receiver's lowest ordinal repair point. Note it is possible that the local receiver may have had its repair needs satisfied as a result of the sender's response to the repair needs of other receivers and no further NACKing is required.
2) 送信側のデータコンテンツの送信位置は、通常、ローカル受信側の修復が必要な最下位シーケンス位置よりも小さい位置まで「巻き戻し」ます。(この送信者の「巻き戻し」の検出は、ローカル受信者が認識していない可能性のある他の受信者の修復ニーズに送信者がすでに応答していることを示します)。この「巻き戻し」イベントは、1) バックオフ タイムアウトのアクティブ化によって NACK サイクルが開始されたときと、2) NACK を抑制するためにバックオフ タイムアウトが期限切れになった現在の瞬間との間の任意の時点で発生する可能性があります。送信者の送信シーケンス位置が受信者の最低順序修復ポイントを超えた場合、受信者は別の NACK サイクルを開始する必要があります。他の受信者の修復ニーズに対する送信者の応答の結果として、ローカル受信者がその修復ニーズを満たしている可能性があり、それ以上の NACK は必要ないことに注意してください。
If these conditions have not occurred and the receiver still has pending repair needs, a NACK message is generated and transmitted. The NACK should consist of an accumulation of repair needs from the receiver's lowest ordinal repair point up to the current sender transmission sequence position. A single NACK message should be generated and the NACK message content should be truncated if it exceeds the payload size of single protocol message. When such NACK 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 コンテンツには、送信者から必要とされる通常最も低い修復コンテンツのリクエストが含まれるべきである(SHOULD)。
NACK Suppression Interface Description
NACK 抑制インターフェイスの説明
Inputs:
入力:
1) NACK process initiation decision. 2) Recorded sender transmission sequence position. 3) Sender GRTT. 4) Sender group size estimate. 5) Application-defined bound on backoff timeout period. 6) NACKs from other receivers. 7) Pending repair indication from sender (may be forwarded NACKs). 8) Current sender transmission sequence position.
1) NACK プロセスの開始決定。2) 記録された送信側送信シーケンス位置。3) 送信者 GRTT。4) 送信者グループのサイズの推定。5) バックオフ タイムアウト期間のアプリケーション定義の制限。6) 他の受信者からの NACK。7) 送信者からの保留中の修復指示 (NACK が転送される可能性があります)。8) 現在の送信側送信シーケンス位置。
Outputs:
出力:
1) Yes/no decision to generate NACK message upon backoff timer expiration.
1) バックオフ タイマーの期限切れ時に NACK メッセージを生成するかどうかの決定。
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NORM can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼できるマルチキャスト受信者によって生成された NACK メッセージの内容には、現在の修復ニーズを詳細に示す情報が含まれます。特定の情報は、NORM 修復プロセスでの FEC の使用とタイプによって異なります。修理の必要性の特定は、データ内容の特定に依存します (下記のセクション 3.5 を参照)。最も高いレベルでは、NACK コンテンツは、NACK がアドレス指定されている送信者と、送信者の送信内の修復が必要なデータ トランスポート オブジェクト (またはストリーム) を識別します。示されたトランスポート エンティティについて、NACK コンテンツは、完全な送信データを再構築するために必要な特定の FEC コーディング ブロックおよび/またはシンボルを識別します。このコンテンツは、FEC ブロック消去カウント、および/またはデータと FEC コンテンツの欠落しているブロックまたはシンボル (セグメント) の明示的な表示で構成されている場合があります。ここで説明する技術を使用すると、信頼性の高い NACK 配信を必要とせずに NORM を効果的にインスタンス化できることにも注意してください。
Where FEC-based repair is used, the NACK message content will minimally need to identify the coding block(s) for which repair is needed and a count of erasures (missing packets) for the coding block. An exact count of erasures implies the FEC algorithm is capable of repairing _any_ loss combination within the coding block.
FEC ベースの修復が使用される場合、NACK メッセージの内容は、修復が必要なコーディング ブロックとコーディング ブロックの消去 (欠落パケット) のカウントを識別する必要が最小限になります。正確な消去数は、FEC アルゴリズムがコーディング ブロック内のあらゆる損失の組み合わせを修復できることを意味します。
This count may need to be adjusted for some FEC algorithms. Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually affect repair. For a most efficient repair strategy, the NACK content will need to also _explicitly_ identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small to medium size block FEC codes (e.g., Reed Solomon) that are capable of provided a limited number of parity symbols per FEC coding block.
一部の FEC アルゴリズムでは、このカウントを調整する必要がある場合があります。修復を正常に完了するには複数の修復ラウンドが必要になる可能性があることを考慮すると、消去カウントは、サーバーが送信できる一意の FEC パリティ パケットの量が基本的に無制限であることも意味します (つまり、サーバーは常に新しい一意の FEC パリティ パケットを提供できます)。同じコーディング ブロックに対する後続の修復要求に応じて、以前に送信されていないパリティ パケット）。あるいは、送信者は、特定のコーディング ブロックに対して利用可能な FEC シンボルのセットを通じて「ラウンドロビン」送信を行い、最終的に修復に影響を与える可能性があります。最も効率的な修復戦略を実現するには、NACK コンテンツは、受信機がコーディング ブロックのコンテンツを正常に再構築するためにどのシンボル (情報および/またはパリティ) を必要とするかを_明示的に_識別する必要もあります。これは、FEC コーディング ブロックごとに限られた数のパリティ シンボルを提供できる小規模から中規模のブロック FEC コード (リード ソロモンなど) に特に当てはまります。
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 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 つの仮定は、任意のパリティ パケットがコーディング ブロック内の任意の消去を埋めることができる 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 data vectors plus parity vectors for the given FEC algorithm used. For example, a coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
体系的な 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 つの順序パリティ ベクトルの送信を要求します。前の段落のコーディング スキームの例では、受信機はコーディング ブロックの 3 つの消去を埋めるためにパリティ シンボル 64 ～ 66 を明示的に要求します。符号化ブロックの受信機の損失が利用可能なパリティ量を超える場合（つまり、この例では欠落シンボルが 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 have received some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender or intermediate systems assisting NACK operation.
要約すると、ルールは、最初の NACK サイクルでの消失修復のニーズを満たすために、FEC コーディング ブロックのパリティ コンテンツの下位順序部分を要求することです。利用可能なパリティ シンボルの数が不十分な場合、受信機は、パリティ シンボルでは満たせない部分をカバーするために、通常最大の欠落データ シンボルのサブセットも要求します。この戦略は、単一のパリティ シンボルで消去されたシンボルを修復できるリードソロモンなどの FEC コードを前提としていることに注意してください。この戦略は、他の FEC タイプの修復能力が制限されている可能性を考慮して、若干の変更を行う必要があります。受信機が以前に要求した修復コンテンツの一部を受信している可能性がある後続の NACK 修復サイクルでは、受信機は同じ戦略を使用しますが、まだ受信していないパリティおよび/またはデータ シンボルのセットに対しては NACK のみを使用します。オプションで、受信側は、NACK 操作を支援する送信側または中間システムの便宜として、消去のカウントを提供することもできます。
After receipt and accumulation of NACK messages during the aggregation period, the sender can begin transmission of fresh (previously untransmitted) parity symbols for the coding block based on the highest receiver erasure count _if_ it has a sufficient quantity of parity symbols that were _not_ previously transmitted. Otherwise, the sender MUST resort to transmitting the explicit set of repair vectors requested. With this approach, the sender needs to maintain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use the same consistent algorithm to express their explicit repair needs, NACK suppression among receivers is simplified over the course of multiple repair cycles. The receivers 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 メッセージを受信して蓄積した後、送信側は、以前に送信されていない十分な量のパリティ シンボルがある場合、最大の受信側消去カウントに基づいて、コーディング ブロックの新しい (以前に送信されていない) パリティ シンボルの送信を開始できます。。それ以外の場合、送信者は要求された明示的な修復ベクトルのセットを送信することに頼らなければなりません (MUST)。このアプローチでは、送信者は、グループからの修復リクエストを同期する必要がなく、グループから受信したリクエストの状態をほとんど維持する必要がありません。すべての受信機は同じ一貫したアルゴリズムを使用して明示的な修復ニーズを表現するため、複数の修復サイクルにわたって受信機間の 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
セッション_ \_ 送信者_ \_ [オブジェクト/ストリーム]_ \_ [FEC ブロック]_ \_ シンボル
Fig. 2: NORM Data Content Identification Hierarchy
図 2: NORM データコンテンツ識別階層
The format of NACK messages should meet the following goals:
NACK メッセージの形式は、次の目標を満たす必要があります。
1) Able to identify transport data unit transmissions required to repair a portion of the received content, whether it is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1) 欠落しているオブジェクト/ストリーム (または範囲) 全体、FEC コーディング ブロック全体、シンボルのセットなど、受信したコンテンツの一部を修復するために必要なトランスポート データ ユニット送信を識別できます。
2) Be simple to process for NACK aggregation and suppression,
2) NACK の集約と抑制の処理が簡単であること、
3) Be capable of including NACKs for multiple objects, FEC coding blocks and/or symbols in a single message, and
3) 単一のメッセージに複数のオブジェクト、FEC コーディング ブロック、シンボルの NACK を含めることができること。
4) Have a reasonably compact format.
4) 適度にコンパクトなフォーマットにする。
If the NORM transport object/stream is identified with an <objectId> and the FEC symbol being transmitted is identified with an <fecPayloadId>, the concatenation of <objectId::fecPayloadId> comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receivers repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
NORM トランスポート オブジェクト/ストリームが <objectId> で識別され、送信される FEC シンボルが <fecPayloadId> で識別される場合、<objectId::fecPayloadId> の連結はシンボルの基本トランスポート プロトコル データ ユニット (TPDU) 識別子を構成します。特定の情報源から。NACK コンテンツは、受信者の修復ニーズを記述する NACK メッセージを構築するために、これらの TPDU 識別子のリストおよび/または範囲で構成できます。階層オブジェクトの描写や FEC ブロッキングが使用されない場合、TPDU は送信者によって送信されるデータ シンボルの単純な線形表現です。TPDU がオブジェクト/ストリームの描写および/または FEC ブロックの目的で階層を表す場合、NACK コンテンツ ユニットは、TPDU のどの部分が適用可能であるかを示すフラグを必要とする場合があります。たとえば、受信したデータで「オブジェクト」全体 (またはオブジェクトの範囲) が欠落している場合、受信側は修復を要求するための <sourceBlockNumbers> または <encodingSymbolIds> の適切な範囲を必ずしも知っているわけではないため、何らかのメカニズムが必要になります。<objectId> で表されるユニット全体の修復 (または再送信) を要求します。1 つまたは <sourceBlockNumbers> の範囲によって表される FEC コーディング ブロック全体が失われた場合も同様です。
NACK Content Interface Description
NACK コンテンツ インターフェイスの説明
Inputs:
入力:
1) Sender identification. 2) Sender data identification. 3) Sender FEC Object Transmission Information. 4) Recorded sender transmission sequence position. 5) Current sender transmission sequence position. History of repair needs for this sender.
1) 送信者の識別。2) 送信者データの識別。3) 送信側 FEC オブジェクト送信情報。4) 記録された送信側送信シーケンス位置。5) 現在の送信側送信シーケンス位置。この送信者の修理ニーズの履歴。
Outputs:
出力:
1) NACK message with repair requests.
1) 修復要求を含む NACK メッセージ。
Upon reception of a repair request from a receiver in the group, the sender will initiate a repair response procedure. The sender may wish to delay transmission of repair content until it has had sufficient time to accumulate potentially multiple NACKs from the receiver set. This allows the sender to determine the most efficient repair strategy for a given transport stream/object or FEC coding block. Depending upon the approach used, some protocols may find it beneficial for the sender to provide an indicator of pending repair transmissions as part of its current transmitted message content. This can aid some NACK suppression mechanisms. The amount of time to perform this NACK aggregation should be sufficient to allow for the maximum receiver NACK backoff window ("T_maxBackoff" from Section 3.2.2) and propagation of NACK messages from the receivers to the sender. Note the maximum transmission delay of a message from a 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) になる可能性があることに注意してください。したがって、最大受信側 NACK バックオフ時間が 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 "holdoff" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "holdoff" time should be:
送信側 NACK 集約期間の直後に、送信側は集約 NACK 状態から決定された修復コンテンツの送信を開始し、新しい送信を続行します。また、この時点で、送信側は、受信側グループへの修復応答による新しい送信シーケンス位置の伝播を許可するために、新しい NACK アグリゲーション期間の開始を制限する「ホールドオフ」期間を観察する必要があります。最悪の場合の非対称性を考慮して、この「ホールドオフ」時間は次のようにする必要があります。
T_sndrHoldoff = 1*GRTT
Recall that the receivers will also employ a "holdoff" timeout after generating a NACK message to allow time for the sender's response. Given a sender <T_sndrAggregate> plus <T_sndrHoldoff> time of (K+1)*GRTT, the receivers should use holdoff timeouts of:
受信者は、NACK メッセージを生成した後、送信者の応答のための時間を確保するために「ホールドオフ」タイムアウトも採用することを思い出してください。送信者の <T_sndrAggregate> と <T_sndrHoldoff> の時間 (K 1)*GRTT を加算すると、受信者は次のホールドオフ タイムアウトを使用する必要があります。
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
This allows for a worst-case propagation time of the receiver's NACK to the sender, the sender's aggregation time and propagation of the sender's response back to the receiver. Additionally, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) a representation of its aggregated NACK content to the group to allow for NACK suppression when there is not multicast connectivity among the receiver set.
これにより、受信者の NACK の送信者への最悪の伝播時間、送信者の集約時間、および受信者への送信者の応答の伝播が考慮されます。さらに、受信セットからのユニキャスト フィードバックの場合、受信セット間にマルチキャスト接続がない場合に NACK の抑制を可能にするために、送信側が集約された NACK コンテンツの表現を (マルチキャスト経由で) グループに転送することが役立つ場合があります。セット。
At the expiration of the <T_sndrAggregate> timeout, the sender will begin transmitting repair messages according to the accumulated content of NACKs received. There are some guidelines with regards to FEC-based repair and the ordering of the repair response from the sender that can improve reliable multicast efficiency:
<T_sndrAggregate> タイムアウトが経過すると、送信者は受信した NACK の蓄積された内容に従って修復メッセージの送信を開始します。FEC ベースの修復と、信頼性の高いマルチキャスト効率を向上させる送信者からの修復応答の順序に関して、いくつかのガイドラインがあります。
1) When FEC is used, it is beneficial that the sender transmit previously untransmitted parity content as repair messages whenever possible. This maximizes the receiving nodes' ability to reconstruct the entire transmitted content from their individual subsets of received messages.
1) FEC が使用される場合、送信者は可能な限り、以前に送信されていないパリティ コンテンツを修復メッセージとして送信することが有益です。これにより、受信ノードが受信メッセージの個々のサブセットから送信コンテンツ全体を再構築する能力が最大化されます。
2) The transmitted object and/or stream data and repair content should be indexed with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content (e.g., ordinally lowest FEC blocks) first, the receivers can use a strategy of withholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help work to keep repair cycles relatively synchronized without dependence upon strict time synchronization among the sender and receivers. This also helps minimize the buffering requirements of receivers and senders and reduces redundant transmission of data to the group at large.
2) 送信されたオブジェクトおよび/またはストリーム データと修復コンテンツには、(適度に大きな順序空間内で) 単調増加するシーケンス番号でインデックスを付ける必要があります。送信者が、最初のコンテンツ (通常、最も低い FEC ブロックなど) の修復を送信する規律を最初に遵守する場合、受信者は、送信者がオブジェクト/ストリーム内のその時点に再び戻るまで、後のコンテンツの修復要求を保留する戦略を使用できます。送信シーケンス。これにより、グループ内の全体的なメッセージ効率が向上し、送信者と受信者間の厳密な時刻同期に依存せずに、修復サイクルを比較的同期した状態に保つ作業が容易になります。これは、受信者と送信者のバッファリング要件を最小限に抑え、グループ全体への冗長なデータ送信を減らすのにも役立ちます。
Sender Repair Response Interface Description
送信者の修復応答インターフェイスの説明
Inputs:
入力:
1) Receiver NACK messages 2) Group timing information
1) 受信側 NACK メッセージ 2) グループ タイミング情報
Outputs
出力
1) Repair messages (FEC and/or Data content retransmission) 2) Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
1) 修復メッセージ (FEC および/またはデータ コンテンツの再送信) 2) ユニキャスト受信機フィードバックが検出された場合の、現在保留中の修復送信の通知。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies limiting the opportunities when receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance, in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
新しい受信機が (おそらく、信頼性の高い送信がすでに進行中の) グループに参加し、修理の要求を開始するためのポリシーと手順を考慮する必要があります。受信者の結合が制約されていない場合、グループ メンバーシップのダイナミクスにより、アプリケーションがデータ送信を前進させるという目標を達成する能力が妨げられる可能性があります。受信機が NACK プロセスに参加し始める機会を制限するポリシーを使用して、望ましい動作を実現できます。たとえば、オブジェクトまたはストリームの論理部分の最初の FEC ブロック内のデータの非修復送信の場合にのみ、受信者が新しく聞いた送信者からの信頼できる受信を試みることは有益である可能性があります。送信者は、NACK リクエストを受け入れる受信者を制限するポリシーを実装することもできますが、状況によってはスケーラビリティ上の理由からこれが不可能になる場合があります。あるいは、一部の種類の一括転送アプリケーション (または潜在的な対話型で信頼性の高いマルチキャスト アプリケーション) では、より緩やかなトランスポート同期ポリシーを使用し、セッション管理メカニズムに依存して、パフォーマンス低下の原因となる可能性のあるグループ ダイナミクスを制限することが望ましい場合があります。
Group Join Policy Interface Description
グループ参加ポリシーのインターフェイスの説明
Inputs:
入力:
1) Current object/stream data/repair content and sequencing identifiers from sender transmissions.
1) 現在のオブジェクト/ストリーム データ/修復コンテンツおよび送信側送信からのシーケンス識別子。
Outputs:
出力:
1) Receiver yes/no decision to begin receiving and NACKing for reliable reception of data
1) データの信頼性の高い受信のために受信と NACK を開始するための受信側のはい/いいえの決定
In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field should be present in packets transmitted by reliable multicast session members.
複数のデータソースが存在する可能性がある NORM プロトコル (または他のマルチキャストプロトコル) では、グループ内のソース (場合によっては一部またはすべての受信者) を一意に識別する何らかのメカニズムを提供する必要があります。到着パケットの送信元アドレスに基づく ID では、いくつかの理由から不十分です。これらの理由としては、複数のインターフェイスを持つホストのルーティングの変更により、時間の経過とともに特定のホストのパケット送信元アドレスが異なること、ネットワーク アドレス変換 (NAT) またはファイアウォール デバイス、またはその他のトランスポート/ネットワーク ブリッジングのアプローチが含まれます。その結果、信頼できるマルチキャスト セッション メンバーによって送信されるパケットには、ある種の一意のソース識別子 <sourceId> フィールドが存在する必要があります。
The data and repair content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/reassembly, caching, integrated forward error correction coding, etc.) rather than being required to provide their own mechanisms for these functions at the application layer.
NORM 送信者によって送信されるデータと修復コンテンツには、プロトコル ヘッダー フィールドに何らかの形式の識別が必要です。この識別は、信頼性の高い 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 <objectId> within some reasonable temporal or ordinal interval. Note that it is _not_ expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
このビルディング ブロックのドキュメント内で説明されているコンポーネントは、これらのモデルの両方に適用できることが想定されており、単一のマルチキャスト セッション内で両方のタイプが混在する可能性があります。この要件をサポートするには、通常のデータ コンテンツ識別に、合理的な時間間隔または順序間隔内でオブジェクトまたはストリーム <objectId> を一意に識別するフィールドを含める必要があります。このデータコンテンツ識別がグローバルに一意であることは「期待されていない」ことに注意してください。オブジェクト/ストリーム識別子は、信頼できるマルチキャスト セッション内および送信者がそのオブジェクトまたはストリームの特定のトランスポート インスタンスをサポートしている間、特定の送信者に関して一意であることが期待されます。
Since the "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier that has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Building Block document [9] provides a standard message format for identifying FEC transmission content. NORM protocol instantiations using FEC SHOULD follow that document's guidelines.
「バルク」オブジェクト/ストリーム コンテンツは通常、セグメント化を必要とするため、何らかの形式のセグメント識別も提供する必要があります。このセグメント識別子は、提供されたオブジェクトまたはストリーム識別子に相対的なものになります。したがって、場合によっては、NORM プロトコルのインスタンス化は、送信を受信し、複数のストリームと 1 つ以上の静的オブジェクトのセットの修復を並行して要求できる場合があります。FEC を使用するプロトコルのインスタンス化の場合、データ コンテンツ識別子のセグメント識別部分は、コーディング ブロック識別子 <sourceBlockNumber> と、コード ブロックの特定のデータまたはパリティ シンボルの識別子 <encodingSymbolId> の論理連結で構成されます。FEC Building Block 文書 [9] は、FEC 送信コンテンツを識別するための標準メッセージ形式を提供します。FEC を使用した NORM プロトコルのインスタンス化は、その文書のガイドラインに従う必要があります (SHOULD)。
Additionally, flags to determine the usage of the content identifier fields (e.g., stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations.
さらに、コンテンツ識別子フィールドの使用法 (ストリームとオブジェクトなど) を決定するためのフラグを適用できる場合があります。フラグは、データ コンテンツの識別において他の目的にも役立つ場合があります。定義されたフラグは、個々のプロトコルのインスタンス化に依存することが予想されます。
In summary, the following data content identification fields may be required for NORM protocol data content messages:
要約すると、NORM プロトコル データ コンテンツ メッセージには次のデータ コンテンツ識別フィールドが必要になる場合があります。
1) Source node identifier (<sourceId>) 2) Object/Stream identifier (<objectId>), if applicable.
1) ソース ノード識別子 (<sourceId>) 2) オブジェクト/ストリーム識別子 (<objectId>) (該当する場合)。
3) FEC Block identifier (<sourceBlockNumber>), if applicable.
3) FEC ブロック識別子 (<sourceBlockNumber>) (該当する場合)。
4) FEC Symbol identifier (<encodingSymbolId>)
4) FEC シンボル識別子 (<encodingSymbolId>)
5) Flags to differentiate interpretation of identifier fields or identifier structure that implicitly indicates usage.
5) 暗黙的に使用法を示す識別子フィールドまたは識別子構造の解釈を区別するためのフラグ。
6) Additional FEC transmission content fields per FEC Building Block
6) FEC ビルディング ブロックごとの追加の FEC 送信コンテンツ フィールド
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NORM protocols that use these data content fields should also be compatible with support for intermediate system assistance to reliable multicast transport operation when available.
これらのフィールドは、生成された NACK メッセージがデータの修復または再送信を要求する際にこれらの識別子を使用するため、識別されています。これらのデータ コンテンツ フィールドを使用する NORM プロトコルは、利用可能な場合には、信頼性の高いマルチキャスト トランスポート操作に対する中間システム支援のサポートと互換性がある必要があります。
Multiple forward error correction (FEC) approaches have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [11], [12], [13]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NORM, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [14]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large delay*bandwidth product with some nominal level of expected packet loss. While the application of FEC is not unique to NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
NACK 指向および他の信頼性の高いマルチキャスト プロトコルの修復プロセスに大幅なパフォーマンス向上を提供できる、複数の前方誤り訂正 (FEC) アプローチが特定されています [11]、[12]、[13]。NORM プロトコルは、FEC ベースの修復では、コーディング ブロック サイズ (シンボル単位) の範囲内で修復内容の明示的な知識を「一般に」必要としないため、さらなる利点を得ることができます。NORM では、生成されたパリティ修復パケットは通常、受信ノードからの NACK 修復要求に応答してのみ送信されます。ただし、一部のネットワーク環境では、通常のデータ シンボル送信と多重化された所定量の FEC 修復パケットを送信する利点があります [14]。これにより、グループ サイズが非常に大きい場合、またはネットワーク接続の遅延 * 帯域幅積が大きく、名目レベルのパケット損失が予想される場合に、比較的少ないオーバーヘッド コストで生成される NACK トラフィックの量を削減できます。FEC のアプリケーションは NORM に固有のものではありませんが、この種の要件によって、適用できるアルゴリズムとプロトコルのアプローチの種類が決まる場合があります。
A specific issue related to the use of FEC with NORM is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId::sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [9] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
NORM での FEC の使用に関連する特定の問題は、特定の FEC パケットが適用される送信データ コンテンツの部分を識別するために使用されるメカニズムです。FEC アルゴリズムは、送信されたデータ パケットの対応するブロックに対するパリティ修復パケットのセットの生成に基づくことが予想されます。データ コンテンツ パケットは、転送中に <sourceId::objectId::sourceBlockNumber::encodingSymbolId> の連結によって一意に識別されるため、FEC パケットも同様の方法で識別されることが期待されます。FEC Building Block 文書 [9] では、FEC の適用に関する詳細な推奨事項と、関連する信頼性の高いマルチキャスト プロトコル メッセージの標準フォーマットが提供されています。
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for increased efficiency [15]. And in some cases, there might be absolute time synchronization among hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various timeouts used by receivers.
グループのメンバー間のパケット伝播ラウンドトリップ時間 (RTT) の測定は、タイマーベースの NACK 抑制アルゴリズム、送信側コマンドまたは特定の修復機能のタイミング、および輻輳制御動作をサポートするために必要です。収集される往復情報の性質は、グループのメンバー間の対話の種類によって異なります。「１対多」の送信だけが必要な場合、送信者だけが受信機セットの中で最大のＲＴＴ（ＧＲＴＴ）のＲＴＴ知識、および／またはグループの一部のみのＲＴＴ知識を必要とする可能性がある。ここで、GRTT 情報は合理的にスケーラブルな方法で収集される可能性があります。輻輳制御動作のために、グループ内の各受信機が RTT 情報を必要とする可能性があります。この場合、受信者が送信者に関する個々の RTT 測定値を収集し、それらをグループまたは送信者にアドバタイズする、代替の RTT 収集スキームを利用することができます。グループ内で信頼性の高いマルチキャスト データの交換が「多対多」ベースで行われる可能性がある場合、効率を高めるために使用できる代替の測定手法があります [15]。また、場合によっては、ホスト間で絶対時刻同期が行われ、RTT 測定が簡素化される可能性があります。マルチキャスト輻輳制御設計にはトレードオフがあり、RTT (または GRTT) 測定に関する普遍的な推奨事項を指定する前にさらなる検討が必要です。輻輳制御やその他の要件に関して RTT 情報 (より具体的には GRTT) がどのように収集されるかに関係なく、送信者は、受信者が使用するさまざまなタイムアウトについて、現在の GRTT 推定値をグループにアドバタイズする必要があります。
The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
この形式の RTT 測定の目的は、送信者が NORM 操作に積極的に参加している受信者の間で 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> タイムスタンプと、メッセージを受信した時刻 (独自のクロックを参照) <recvTime> を記録します。受信者が送信者にフィードバックを提供すると (明示的に、またはプロトコルのインスタンス化仕様に応じて他のフィードバック メッセージの一部として)、次の式を使用して「応答」を構築します。
grttResponse = sendTime + (currentTime - recvTime)
where the <sendTime> is the timestamp from the last probe message received from the source and the (<currentTime> - <recvTime>) is the amount of time differential since that request was received until the receiver generated the response.
ここで、<sendTime> は送信元から受信した最後のプローブ メッセージのタイムスタンプで、(<currentTime> - <recvTime>) はその要求を受信してから受信者が応答を生成するまでの時間差です。
The sender processes each receiver response by calculating a current RTT measurement for the receiver from whom the response was received using the following formula:
送信者は、次の式を使用して、応答を受信した受信者の現在の RTT 測定値を計算することにより、各受信者の応答を処理します。
RTT_rcvr = currentTime - grttResponse
During the each periodic GRTT probing interval, the source keeps the peak round trip timing measurement (RTT_peak) from the set of responses it has received. A conservative estimate of GRTT is kept to maximize the efficiency of redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules:
各周期的な GRTT プローブ間隔中に、ソースは受信した一連の応答からのピーク往復タイミング測定値 (RTT_peak) を保持します。冗長 NACK の抑制と修復集約の効率を最大化するために、GRTT の保守的な推定値が維持されます。ソースによる 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 GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation 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 NORM repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not _strictly_ depend on highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
要約すると、NORM 修復サイクルのタイムアウトは GRTT に基づいていますが、プロトコルの収束動作は、高精度の GRTT 推定に「厳密には」依存しないことに注意する必要があります。現在のメカニズムは、シミュレーションおよびこれまでに NORM のようなプロトコルが導入されている環境で十分であることが証明されています。アルゴリズムによって提供される推定値は、接続損失が比較的高い場合でも、実際の GRTT (オペレーティング システムの影響やネットワーク遅延を含む) のピーク エンベロープを追跡します。定常状態のプローブ/更新間隔は、さまざまな環境で予想されるさまざまなレベルのネットワーク ダイナミクスに対応するために変更される可能性があります。
In this approach, receivers send messages with timestamps to the sender. To control the volume of these receiver-generated messages, a suppression mechanism similar to that described for NACK suppression my be used. The "age" of receivers' RTT measurement should be kept by receivers and used as a metric in competing for feedback opportunities in the suppression scheme. For example, receiver who have not made any RTT measurement or whose RTT measurement has aged most should have precedence over other receivers. In turn the sender may have limited capacity to provide an "echo" of the receiver timestamps back to the group, and it could use this RTT "age" metric to determine which receivers get precedence. The sender can determine the GRTT as described in 3.7.1 if it provides sender timestamps to the group. Alternatively, receivers who note their RTT is greater than the sender GRTT can compete in the feedback opportunity/suppression scheme to provide the sender and group with this information.
このアプローチでは、受信者はタイムスタンプ付きのメッセージを送信者に送信します。これらの受信者が生成するメッセージの量を制御するには、NACK 抑制について説明したものと同様の抑制メカニズムを使用できます。受信機の RTT 測定の「年齢」は、受信機によって保持され、抑制スキームにおけるフィードバック機会を競合する際の指標として使用される必要があります。たとえば、RTT 測定をまったく行っていない受信機、または RTT 測定が最も古くなっている受信機は、他の受信機よりも優先される必要があります。次に、送信者は、受信者のタイムスタンプの「エコー」をグループに提供する能力が限られている可能性があり、この RTT の「経過時間」メトリクスを使用して、どの受信者が優先されるかを決定することができます。送信者は、グループに送信者のタイムスタンプを提供する場合、3.7.1 で説明されているように GRTT を決定できます。あるいは、自分の RTT が送信者の GRTT よりも大きいことに気付いた受信者は、フィードバックの機会/抑制スキームで競合して、送信者とグループにこの情報を提供できます。
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and sender's "b" and "c", it is likely that:
複数の送信者が関与する信頼性の高いマルチキャスト セッションの場合、各送信者が個別に RTT を追跡するのではなく、真の「多対多」ベースで RTT 測定を実行する方が便利な場合があります。受信者が別の送信者に関する RTT 情報と、対象の新しい送信者に関する他の送信者の RTT 情報に基づいて、送信者に関する RTT の近似値を推測できる場合、プロトコルの効率がある程度得られます。たとえば、受信者「a」、送信者「b」および「c」の場合、次の可能性があります。
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT to a small subset of other group members and RTT information among those other group members it learns during protocol operation.
他のグループメンバーの小サブセットに対する自身の RTT と、プロトコル動作中に学習した他のグループメンバー間の RTT 情報に関する RTT 情報がノードで利用可能であれば、この推定値をさらに改良することができます。
To facilitate deterministic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate to a single byte of information. The following C-language functions allows this to be done over a wide range (RTT_MIN through RTT_MAX) of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for RTT_MIN and RTT_MAX respectively. NORM applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
決定論的な NORM プロトコルの動作を容易にするために、送信側は GRTT の現在の推定値を受信側セットに確実にアドバタイズする必要があります。送信者の現在動作中の GRTT 推定値に関するグループ間での共通かつ堅牢な知識により、プロトコルを最も効率的な方法で進めることが可能になります。送信者の GRTT 推定値は、送信者によって送信されるすべての関連メッセージに推定値を埋め込むだけで、グループに確実に通知できます。GRTT 推定値を 1 バイトの情報に量子化 (圧縮) することで、このオーバーヘッドをかなり小さくすることができます。次の C 言語関数を使用すると、小さい GRTT 値ではより広い範囲の精度を維持し、大きい値ではより低い精度を維持しながら、広い範囲 (RTT_MIN から RTT_MAX) の GRTT 値に対してこれを実行できます。RTT_MIN と RTT_MAX には、それぞれ 1.0e-06 秒と 1000 秒の値が推奨されます。NORM アプリケーションは、一部のネットワーク環境ではより大きなフィードバック量を犠牲にして、アプリケーション データ配信の遅延制約を満たすために、送信者によってアドバタイズされる GRTT に追加のより小さい上限を設定することを望む場合があります。
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
この関数は、GRTT 時間を 1 マイクロ秒から 1000 秒の範囲で量子化するのに便利であることに注意してください。もちろん、NORM プロトコルの実装では、実際的な理由から、宣伝される GRTT 推定値をさらに制限する (たとえば、最大値を制限する) ことを望む場合があります。
When NORM protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of a group size determination mechanism a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NORM usage.
NORM プロトコルの動作に、グループ全体からのフィードバックを促すメカニズム (輻輳制御など) が含まれる場合、使用される確率的抑制メカニズムの分布に関して受信したフィードバック メッセージの数に基づいて、グループ サイズを大まかに推定できる可能性があります。。このドキュメントで説明されているタイマーベースの抑制メカニズムは、適切に実行するためにグループ サイズの非常に正確な推定を必要としないことに注意してください。したがって、特に保守的に管理されている場合には、大まかな推定で十分な場合があります。グループのサイズは管理上決定される場合もあります。グループ サイズ決定メカニズムがない場合、予想される NORM 使用量のスケーラビリティを考慮したフィードバックの合理的な管理のために、デフォルトのグループ サイズ値 10,000 が推奨されます。
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [16] or Pragmatic General Multicast Congestion Control (PGMCC) techniques [17] may be applied to NORM operation to meet this requirement.
一般的なインターネット運用には、利用可能なネットワーク容量を他の信頼できるマルチキャストおよび TCP インスタンスと公平に共有する輻輳制御が必要です。この要件を満たすために、TCP-Friendly Multicast Congestion Control (TFMCC) [16] または Pragmatic General Multicast Congestion Control (PGMCC) 技術 [17] を NORM 動作に適用することができます。
NACK-oriented protocols may benefit from general purpose router assistance. In particular, additional NACK suppression where routers or intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NORM protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Both of these types of assist functions would require router interpretation of transport data unit content identifiers and flags.
NACK 指向のプロトコルは、汎用ルーターの支援から恩恵を受ける可能性があります。特に、ルーターまたは中間システムが送信者に向けて中継される際に、受信者からの NACK コンテンツを集約 (または重複した NACK コンテンツのフィルター) できる追加の NACK 抑制により、NORM グループ サイズのスケーラビリティが向上する可能性があります。FEC を使用する NORM プロトコルの場合、中間システムが FEC 修復メッセージをフィルタリングして、以前の受信側 NACK から学習した修復ニーズに応じて、マルチキャスト トポロジのさまざまなレッグに修復コンテンツのインテリジェントな「サブキャスト」を提供できる可能性があります。これらのタイプのアシスト機能はどちらも、ルーターによるトランスポート データ ユニットのコンテンツ識別子とフラグの解釈を必要とします。
The NORM building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed negative-acknowledgement (NACK)-oriented reliable multicast (NORM) protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the scalability property of NACK-oriented protocols [18], [19] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NORM protocols can make use of reciprocal (among senders and receivers) multicast communication under the Any-Source Multicast (ASM) model defined in RFC 1112 [2], and are capable of scalable operation in asymmetric topologies such as Single-Source Multicast (SSM) [8] where there may only be unicast routing service from the receivers to the sender(s).
NORM ビルディング ブロックは、信頼性の高いデータ転送を実現するために否定応答を使用するプロトコルに適用されます。適切に設計された否定応答 (NACK) 指向の信頼できるマルチキャスト (NORM) プロトコルは、さまざまな理由により、基本的なレイヤー 3 IP マルチキャスト サービスの上に高次の配信インフラストラクチャを構築することが不可能なアプリケーションやネットワーク トポロジにスケーラビリティの利点をもたらします。(例: ユニキャストまたはハイブリッド ユニキャスト/マルチキャスト データ配信ツリー)。さらに、NACK 指向プロトコルのスケーラビリティ特性 [18]、[19] は、単一のネットワーク ホップ (ケーブル TV データ配信、衛星、またはその他の放送通信サービスなど) に対して広範な「ファンアウト」が予想される場合に適用できます。。さらに、「フラットな」グループ全体のマルチキャスト配信に基づくプロトコルの単純さは、広範囲の分散サービスや動的ネットワークおよびアプリケーションに利点を提供する可能性があります。NORM プロトコルは、RFC 1112 [2] で定義されている Any-Source Multicast (ASM) モデルの下で相互 (送信者と受信者の間で) マルチキャスト通信を利用でき、Single-Source Multicast (SSM) などの非対称トポロジーでスケーラブルな動作が可能です。) [8] ここでは、受信者から送信者へのユニキャスト ルーティング サービスのみが存在する可能性があります。
NORM operation is compatible with transport layer forward error correction coding techniques as described in [13] and congestion control mechanisms such as those described in [16] and [17]. A principal limitation of NORM operation involves group size scalability when network capacity for receiver feedback is very limited. NORM operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
NORM 動作は、[13] で説明されているトランスポート層の前方誤り訂正符号化技術や、[16] および [17] で説明されているような輻輳制御メカニズムと互換性があります。NORM 動作の主な制限には、受信機フィードバックのネットワーク容量が非常に限られている場合のグループ サイズのスケーラビリティが関係します。NORM 操作は、実装のバッファリング制約によっても制御されます。受信グループの接続性の不均衡を考慮し、グループ サイズのスケーラビリティを達成するために必要なフィードバック遅延を考慮して、一般的なポイントツーポイントの信頼できるトランスポート (TCP など) に必要なバッファリングよりも大きなバッファリングを推奨します。
NORM protocols are expected to be subject to the same sort of security vulnerabilities as other IP and IP multicast protocols. NORM is compatible with IP security (IPsec) authentication mechanisms [20] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK based protocols is that of NACK replay attacks that would prevent a NORM sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. Additionally, NORM protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. The IETF Multicast Security (msec) Working Group is also developing solutions which may be applicable to NORM in the future.
NORM プロトコルは、他の IP および IP マルチキャスト プロトコルと同様のセキュリティ脆弱性の影響を受けることが予想されます。NORM は、セッション侵入やサービス拒否攻撃に対する保護のために推奨される IP セキュリティ (IPsec) 認証メカニズム [20] と互換性があります。NACK ベースのプロトコルに対する特別な脅威は、NORM 送信者の送信の進行を妨げる NACK リプレイ攻撃です。このようなリプレイ攻撃に対する保護を提供できる標準の IPsec メカニズムを使用することが推奨されます。さらに、NORM プロトコルのインスタンス化は、ネットワーク層メカニズムが利用できない場合に、独自の NACK リプレイ攻撃保護のサポートを提供することを検討すべきです(SHOULD)。IETF マルチキャスト セキュリティ (ミリ秒) ワーキング グループも、将来 NORM に適用できる可能性のあるソリューションを開発しています。
The authors would like to thank Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
著者らは、この文書に関する貴重なコメントをくださった Rick Jones 氏と Joerg Widmer 氏に感謝の意を表します。著者らはまた、この仕様の開発を支援してくれた RMT ワーキング グループの議長である Roger Kermode と Lorenzo Vicisano、およびこの文書への初期のインプットに対する Sally Floyd に感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2] Deering, S.、「IP マルチキャスト用のホスト拡張」、STD 5、RFC 1112、1989 年 8 月。
[3] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[3] Mankin, A.、Romanow, A.、Bradner, S.、および V. Paxson、「信頼性の高いマルチキャスト トランスポートおよびアプリケーション プロトコルを評価するための IETF 基準」、RFC 2357、1998 年 6 月。
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages 201--208, September 1990.
[4] Clark, D. および D. Tennenhouse、「新世代のプロトコルのアーキテクチャに関する考慮事項」。プロセスで。ACM SIGCOMM、201 ～ 208 ページ、1990 年 9 月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[5] Kermode, R. および L. Vicisano、「高信頼性マルチキャスト トランスポート (RMT) ビルディング ブロックおよびプロトコルのインスタンス化ドキュメントの作成者ガイドライン」、RFC 3269、2002 年 4 月。
[6] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback," in IEEE Infocom, San Francisco, California, p. 964, March/April 1998.
[6] Nonnenmacher、J. および E. Biersack、「Optimal Multicast Feedback」、IEEE Infocom、カリフォルニア州サンフランシスコ、p.964、1998 年 3 月または 4 月。
[7] Macker, J. and R. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002.
[7] Macker, J. および R. Adamson、「Nack Oriented Reliable Multicast (NORM) フィードバックの定量的予測」、Proc.IEEE MILCOM 2002、2002 年 10 月。
[8] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[8] Holbrook, H.、「マルチキャストのチャネル モデル」、Ph.D.学位論文、スタンフォード大学コンピュータ サイエンス学部、カリフォルニア州スタンフォード、2001 年 8 月。
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[9] Luby, M.、Vicisano, L.、Gemmell, J.、Rizzo, L.、Handley, M.、および J. Crowcroft、「前方誤り訂正 (FEC) ビルディング ブロック」、RFC 3452、2002 年 12 月。
[10] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang. "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[10] フロイド、S.、ジェイコブソン、V.、マッキャン、S.、リュー、C.、L. チャン。「軽量セッションおよびアプリケーション レベルのフレーミングのための信頼できるマルチキャスト フレームワーク」、Proc.ACM SIGCOMM、1995 年 8 月。
[11] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications, Vol. Com-32, No.6, June 1984.
[11] Metzner, J.、「改善されたブロードキャスト再送信プロトコル」、IEEE Transactions on Communications、Vol.Com-32、No.6、1984 年 6 月。
[12] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97, October 1997.
[12] Macker, J.、「信頼性の高いマルチキャスト トランスポートと統合消去ベースの前方誤り訂正」、Proc.IEEE MILCOM 97、1997 年 10 月。
[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[13] Luby, M.、Vicisano, L.、Gemmell, J.、Rizzo, L.、Handley, M.、および J. Crowcroft、「信頼性の高いマルチキャストにおける前方誤り訂正 (FEC) の使用」、RFC 3453、2002 年 12 月。
[14] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOM 98'.
[14] Gossink, D. および J. Macker、「チャネル推定による信頼性の高いマルチキャストおよび統合パリティ再送信」、IEEE GLOBECOM 98'。
[15] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[15] Ozdemir, V.、Muthukrishnan, S.、および I. Rhee、「スケーラブルで低オーバーヘッドのネットワーク遅延推定」、NCSU/AT&T ホワイト ペーパー、1999 年 2 月。
[16] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, August 2001.
[16] Widmer, J. および M. Handley、「Extending Equation-Based Congestion Control to Multicast Applications」、Proc ACM SIGCOMM 2001、サンディエゴ、2001 年 8 月。
[17] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[17] Rizzo, L.、「pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme」、Proc ACM SIGCOMM 2000、ストックホルム、2000 年 8 月。
[18] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[18] Pingali, S.、Towsley, D.、および J. Kurase、「送信者開始型と受信者開始型の信頼できるマルチキャスト プロトコルの比較」。プロセスで。INFOCOM、カリフォルニア州サンフランシスコ、1993 年 10 月。
[19] B.N. Levine, J.J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct 29--Nov 1, 1996.
[19] B.N.レヴィン、J.J.Garcia-Luna-Aceves、「信頼できるマルチキャスト プロトコルの既知のクラスの比較」、Proc.ネットワーク プロトコルに関する国際会議 (ICNP-96)、オハイオ州コロンバス、1996 年 10 月 29 日～11 月 1 日。
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
Brian Adamson Naval Research Laboratory Washington, DC 20375
ブライアン・アダムソン海軍研究所 ワシントン 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 Department of Computer Science University College London Gower Street London WC1E 6BT UK
Mark Handley コンピューター サイエンス学科 ユニバーシティ カレッジ ロンドン Gower Street London 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
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。