RFC5401 日本語訳
5401 Multicast Negative-Acknowledgment (NACK) Building Blocks. B.Adamson, C. Bormann, M. Handley, J. Macker. November 2008. (Format: TXT=109312 bytes) (Obsoletes RFC3941) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Adamson
Request for Comments: 5401 Naval Research Laboratory
Obsoletes: 3941 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2008
コメントを求めるワーキンググループB.アダムソン要求をネットワークでつないでください: 5401年の海軍研究試験所は以下を時代遅れにします。 3941年のC.ボルマンカテゴリ: 研究所2008年11月の海軍の標準化過程のM.ハンドレーユニバーシティ・カレッジロンドンJ.UniversitaetブレーメンTZI Macker
Multicast Negative-Acknowledgment (NACK) Building Blocks
マルチキャスト否定応答(ナック)ブロック
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941.
このドキュメントは否定応答(ナック)フィードバックを利用する信頼できるマルチキャストプロトコルの作成について議論します。 プロトコルデザイン目標と仮定のための原理は提示されます。 ナックベースの、そして、(いくつかの場合一般的)の信頼できるマルチキャストプロトコル操作のための技術的難関は特定されます。 これらの目標と挑戦は信頼できるマルチキャストプロトコル操作の異なった局面を扱う1セットの機能的な「ブロック」に変えられます。 これらのブロックが信頼できるマルチキャストプロトコルの異なった具体化を生成する際に役に立つと予期されます。 このドキュメントはRFC3941を時代遅れにします。
Adamson, et al. Standards Track [Page 1] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Rationale .......................................................4
2.1. Delivery Service Model .....................................5
2.2. Group Membership Dynamics ..................................6
2.3. Sender/Receiver Relationships ..............................6
2.4. Group Size Scalability .....................................6
2.5. Data Delivery Performance ..................................7
2.6. Network Environments .......................................7
2.7. Intermediate System Assistance .............................8
3. Functionality ...................................................8
3.1. Multicast Sender Transmission .............................11
3.2. NACK Repair Process .......................................13
3.3. Multicast Receiver Join Policies and Procedures ...........26
3.4. Node (Member) Identification ..............................26
3.5. Data Content Identification ...............................27
3.6. Forward Error Correction (FEC) ............................28
3.7. Round-Trip Timing Collection ..............................29
3.8. Group Size Determination/Estimation .......................33
3.9. Congestion Control Operation ..............................34
3.10. Intermediate System Assistance ...........................34
4. NACK-Based Reliable Multicast Applicability ....................35
5. Security Considerations ........................................36
6. Changes from RFC 3941 ..........................................38
7. Acknowledgements ...............................................38
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
1. 序論…2 1.1. 要件言語…4 2. 原理…4 2.1. デリバリ・サービスモデル…5 2.2. 会員資格力学を分類してください…6 2.3. 送付者/受信機関係…6 2.4. サイズスケーラビリティを分類してください…6 2.5. データ配送パフォーマンス…7 2.6. 環境をネットワークでつないでください…7 2.7. 中間システム支援…8 3. 機能性…8 3.1. マルチキャスト送付者送信…11 3.2. ナック修理プロセス…13 3.3. マルチキャスト受信機は方針と手順を接合します…26 3.4. ノード(メンバー)識別…26 3.5. データ内容識別…27 3.6. エラー修正(FEC)を進めてください…28 3.7. 往復のタイミング収集…29 3.8. サイズ決断/見積りを分類してください…33 3.9. 輻輳制御操作…34 3.10. 中間システム支援…34 4. ナック-Basedの信頼できるマルチキャストの適用性…35 5. セキュリティ問題…36 6. RFC3941からの変化…38 7. 承認…38 8. 参照…39 8.1. 標準の参照…39 8.2. 有益な参照…39
1. Introduction
1. 序論
Reliable multicast transport is a desirable technology for efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users (see [RFC2357]). This document addresses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. NACK-based protocols generally entail less frequent feedback messaging than reliability protocols based on positive acknowledgment (ACK). The less frequent feedback messaging helps simplify the problem of feedback implosion as group size grows larger. While different protocol instantiations may be required to meet specific application and network architecture demands [ArchConsiderations], there are a number of fundamental components that may be common to these different instantiations.
信頼できるマルチキャスト輸送はインターネットに関するグループへの効率的で信頼できるデータの分配のための望ましい技術です。 グループコミュニケーションパラダイムの複雑さは異なったプロトコルタイプ、性能の範囲と異なった潜在的高信頼のマルチキャストアプリケーションに関するスケーラビリティ必要条件を満たす具体化、およびユーザを必要とします([RFC2357]を見てください)。 このドキュメントは否定応答(ナック)フィードバックを利用する信頼できるマルチキャストプロトコルの作成を扱います。 一般に、ナックベースのプロトコルは頻繁なフィードバックメッセージングより肯定応答(ACK)に基づく信頼性のプロトコルを伴います。 それほど頻繁でないフィードバックメッセージングは、グループサイズが大きくなるのに応じてフィードバック内部破裂の問題を簡素化するのを助けます。 異なったプロトコル具体化が特定のアプリケーションとネットワークアーキテクチャ需要[ArchConsiderations]にこたえるのに必要であるかもしれませんが、これらの異なった具体化に共通であるかもしれない多くの基本要素があります。
Adamson, et al. Standards Track [Page 2] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[2ページ]。
This document describes the framework and common "building block" components relevant to multicast protocols that are based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NACK-based reliable multicast protocol design, it specifically addresses in detail the following building blocks, which are not addressed in other IETF documents:
このドキュメントは信頼できる輸送のための主としてナックの操作に基づいているマルチキャストプロトコルに関連しているフレームワークと一般的な「ブロック」コンポーネントについて説明します。 このドキュメントは信頼できるマルチキャストコンポーネントとナックベースの信頼できるマルチキャストプロトコルデザインに関連している問題の大きいセットについて議論しますが、明確に、詳細に、以下のブロックに演説します:(ブロックは他のIETFドキュメントで演説されません)。
1. NACK-based multicast sender transmission strategies,
1. ナックベースのマルチキャスト送付者トランスミッション戦略
2. NACK repair process with timer-based feedback suppression, and
2. そしてタイマベースのフィードバック抑圧があるナック修理プロセス。
3. Round-trip timing for adapting NACK and other timers.
3. ナックと他のタイマを適合させる往復のタイミング。
NACK-based reliable multicast implementations SHOULD make use of Forward Error Correction (FEC) erasure coding techniques, as described in the FEC Building Block [RFC5052] document. Packet-level erasure coding allows missing packets from a given FEC block to be recovered using the parity packets instead of classical, individualized retransmission of original source data content. For this reason, this document refers to the protocol mechanisms for reliability as a "repair process." Note that NACK-based protocols can reactively provide the parity packets in response to receiver requests for repair rather than just proactively sending added FEC parity content as part of the original transmission. Hybrid proactive/reactive use of FEC content is also possible with the mechanisms described in this document. Some classes of FEC coding, such as Maximal Separable Distance (MDS) codes, allow senders to dynamically implement deterministic, highly efficient receiver group repair strategies as part of a NACK-based, selective automated repeat-request (ARQ) scheme.
ナックベースの信頼できるマルチキャスト実装SHOULDはForward Error Correction(FEC)消去コーディング技法を利用します、FECビルBlock[RFC5052]ドキュメントで説明されるように。 パケット・レベル消去コード化で、与えられたFECブロックからのなくなったパケットは、一次資料データ内容の古典的で、個性化された「再-トランスミッション」の代わりにパリティパケットを使用することで回復します。 この理由で、このドキュメントは信頼性について「修理プロセス」とプロトコルメカニズムを呼びます。 ナックベースのプロトコルがちょうど予測して発信するよりむしろ修理を求める受信機要求に対応してパリティパケットを反動的に提供できるというメモはオリジナルのトランスミッションの一部としてFECパリティ内容を加えました。 また、メカニズムが本書では説明されている状態で、FEC内容のハイブリッド先を見越すか反応している使用も可能です。 FECコード化のMaximal Separable Distance(MDS)コードなどの数人のクラスで、送付者は、ナックベースの、そして、選択している自動化された反復要求(ARQ)体系の一部として決定論的で、高能率的な受信機グループ修理が戦略であるとダイナミックに実装することができます。
The potential relationships to other reliable multicast transport building blocks (e.g., FEC, congestion control) and general issues with NACK-based reliable multicast protocols are also discussed. This document follows the guidelines provided in [RFC3269].
また、他の信頼できるマルチキャスト輸送ブロック(例えば、FEC、輻輳制御)との潜在的関係とナックベースの信頼できるマルチキャストプロトコルの一般答弁について議論します。 このドキュメントは[RFC3269]に提供されたガイドラインに従います。
Statement of Intent
主旨書
This memo contains descriptions of building blocks that can be applied in the design of reliable multicast protocols utilizing negative-acknowledgement (NACK) feedback. [RFC3941] contains a previous description of this specification. RFC 3941 was published in the "Experimental" category. It was the stated intent of the Reliable Multicast Transport (RMT) working group at that time to resubmit this specification as an IETF Proposed Standard in due course.
このメモは否定的承認(ナック)フィードバックを利用する信頼できるマルチキャストプロトコルのデザインで適用できるブロックの記述を含んでいます。 [RFC3941]はこの仕様の前の記述を含んでいます。 RFC3941は「実験的な」カテゴリで発行されました。 その時、IETF Proposed Standardとしてやがてこの仕様を再提出するのは、Reliable Multicast Transport(RMT)ワーキンググループの述べられた意図でした。
Adamson, et al. Standards Track [Page 3] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[3ページ]。
This Proposed Standard specification is thus based on [RFC3941] and has been updated according to accumulated experience and growing protocol maturity since the publication of RFC 3941. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
このProposed Standard仕様はこのようにして[RFC3941]に基づいています、そして、アップデートされて蓄積した経験に従って成長したのはRFC3941の公表以来の円熟について議定書の中で述べます。 前述の経験はこの仕様自体と、そして、この仕様の使用に関連するふくそう制御方式に適用されます。
The differences between [RFC3941] and this document are listed in Section 6.
[RFC3941]とこのドキュメントの違いはセクション6に記載されています。
1.1. Requirements Language
1.1. 要件言語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Rationale
2. 原理
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
ここ(そして他の適切なブロックドキュメントで)に提示されたブロックを使用するそれぞれの潜在的プロトコル具体化が個々のプロトコルデザインに影響を及ぼすかもしれない特定の評価基準を持つでしょう。 適切なブロックの発展をサポートするために、運転する一般的なプロトコルデザイン目標と仮定を特定して、まとめるのは役に立ちます。 これらはそれぞれのプロトコル具体化が詳細に扱う必要がある領域です。 それぞれのブロック記述は本書ではこれらの設計基準の影響の議論を含むでしょう。 ここで考えられた設計基準のカテゴリは:
1. Delivery Service Model,
1. デリバリ・サービスモデル
2. Group Membership Dynamics,
2. 会員資格力学を分類してください。
3. Sender/Receiver Relationships,
3. 送付者/受信機関係
4. Group Size Scalability,
4. サイズスケーラビリティを分類してください。
5. Data Delivery Performance, and
5. そしてデータ配送パフォーマンス。
6. Network Environments.
6. 環境をネットワークでつないでください。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents, such as [RFC5052], have been created to address areas outside of the scope of this document. NACK-based reliable multicast protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NACK-based reliable multicast but may be used in concert with the other building block areas. In some cases, a building block may be
簡潔にこれらの領域のすべてについて少なくとも議論します。 さらに、[RFC5052]などの他の信頼できるマルチキャスト輸送ブロックドキュメントは、このドキュメントの範囲の外で領域を扱うために作成されました。 ナックベースの信頼できるマルチキャストプロトコル具体化はここに提示されたものと同様にこれらの他のブロックに頼るかもしれません。 このドキュメントは、ナックベースの信頼できるマルチキャストにユニークな領域に焦点を合わせますが、他のブロック領域と協力して使用されるかもしれません。 いくつかの場合、ブロックはそうです。
Adamson, et al. Standards Track [Page 4] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[4ページ]。
able to address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment. The forms of "bulk data transfer" covered here include reliable transport of bulky, fixed-length, a priori static content and also transmission of non-predetermined, perhaps streamed, content of indefinite length. Section 3.5 discusses these different forms of bulk data content in further detail.
さまざまな仮定を扱うことができます、他の場合にはある間、異なったアプリケーションの必要性か操作環境を満たすのに必要であるトレードオフがあるでしょう。 必要であるところに、ブロックの特徴は、異なった必要条件を満たすパラメトリックになるように設計されています。 もちろん、基本的な目標は、デザインの複雑さを最小にして、典型的なインターネット環境における汎用の「バルク・データ転送」必要条件を満たすどんなそのようなパラメタのためにもデフォルト値を少なくとも推薦することでしょう。 ここにカバーされた「バルク・データ転送」のフォームはかさばって、固定長さで、先験的な静的な内容の信頼できる輸送と無期長さの非予定されて、恐らく流された内容の伝達も含んでいます。 セクション3.5は詳細のこれらの異なったフォームの大量のデータ中身について論じます。
2.1. Delivery Service Model
2.1. デリバリ・サービスモデル
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. The most basic service model for reliable multicast transport is that of "bulk transfer", which is a primary focus of this and other related RMT working group documents. However, the same principles in protocol design may also be applied to other service models, e.g., more interactive exchanges of small messages such as with white- boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
信頼できるマルチキャストトランスポート・プロトコルの暗黙の目標はIPマルチキャストデータグラムサービスを使用することで交信するメンバーのグループのデータの信頼できる配信です。 しかしながら、アプリケーションが提供するのを試みている特定のサービスはデザイン決定に影響を与えることができます。 信頼できるマルチキャスト輸送のための最も基本的なサービスモデルは「バルク転送」のものです(これと他の関連するRMTワーキンググループドキュメントの焦点です)。 しかしながら、また、プロトコルデザインにおける同じ原則は他のサービスモデル(例えば、小さいメッセージの白い板囲いやテキストチャットなどの、より対話的な交換)に適用されるかもしれません。 あるこれらの異なったモデルの中では、キャッシュする送付者の能力などの問題は「再-トランスミッション」か修理のためのデータ(または、それに参照をつける州)を送りました。 データ内容によって、注文する必要性、そして/または、トランスミッションの系列の因果関係とグループのメンバーの中のレセプションは異なっているかもしれません。 グループコミュニケーションパラダイムは二地点間モデルからデータcontent typeによって、いくつかの受信機がデータ内容の部分のレセプションを完成して、他のメンバーが内容を受け取る前にそれに作用できるかもしれないという点において有意差があります。 これは、許容できるのと(望ましいさえ。)であるかもしれません。他のものではなく、いくつかのアプリケーションのために。 これらの異なった要件は多くの異なったプロトコル具体化デザインの必要性を追い立てます。 特定のアプリケーションレベルの詳細を定義しないで、展開している一般に役に立つブロックメカニズムにおける重要な挑戦はこれらの能力の限られた範囲さえ収容しています。
Another factor impacting the delivery service model is the potential for different receivers in the multicast group to have significantly differing quality of network connectivity. This may involve receivers with very limited goodput due to connection rate or substantial packet loss. NACK-based protocol implementations may wish to provide policies by which extremely poor-performing receivers are excluded from the main group or migrated to a separate delivery
デリバリ・サービスモデルに影響を与える別の要素はマルチキャストグループにおける異なった受信機にはネットワークの接続性のかなり異なった品質がある可能性です。 これは接続率かかなりのパケット損失のため非常に限られたgoodputに受信機にかかわるかもしれません。 ナックベースのプロトコル実装は貧乏人を非常に実行する受信機が主なグループから除かれるか別送に移行する方針を提供したがっているかもしれません。
Adamson, et al. Standards Track [Page 5] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[5ページ]。
group. Note that some application models may require that the entire group be constrained to the performance of the "weakest member" to satisfy operational requirements. In either case, protocol designs should consider this aspect of the reliable multicast delivery service model.
分類してください。 何人かのアプリケーションモデルが、全体のグループが「最も弱いメンバー」が操作上の要件を満たす性能に抑制されるのを必要とするかもしれないことに注意してください。 どちらの場合ではも、プロトコルデザインは頼もしいマルチキャストデリバリ・サービスモデルのこの局面を考えるべきです。
2.2. Group Membership Dynamics
2.2. グループ会員資格力学
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
グループコミュニケーションが二地点間コミュニケーションと異なることができる1つの領域はグループの構成が変化しても、コミュニケーションの「スレッド」がまだ存在できるということです。 これはコミュニケーション・プロセス(データの交換)がパーティーが2つのもののどちらかならいなくなるか、終えられるのとまたは(少なくともポーズされています)である二地点間コミュニケーションモデルとひどく違います。 信頼できるマルチキャスト輸送「セッション」のときに参加するのが遅く接合できるかもしれないアプリケーション目標、送付者、および受信機に頼って、いなくなってください、そして、「スレッド」という進行中のグループコミュニケーションがまだ機能的であって、役に立ったままで残っている間、潜在的に再び加わってください。 また、これがプロトコルメッセージ内容に影響を与えることができることに注意してください。 「故joiners」がサポートされるなら、いくらかの量の追加情報が、この機能性に対応するためにメッセージヘッダーに置かれるかもしれません。 あるいはまた、すばらし過ぎると典型的なメッセージ送信のオーバーヘッドへの影響を考えるなら、それ自身のメッセージ(要求に応じてか断続的である)で情報を送るかもしれません。 また、グループ・ダイナミックスはナックタイミング、混雑制御機能などの他のプロトコルメカニズムに影響を与えることができます。
2.3. Sender/Receiver Relationships
2.3. 送付者/受信機関係
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.
グループのメンバーの中の送付者と受信機の関係は考慮を必要とします。 使用目的によっては、受信機のグループへのただ一つの送付者マルチキャスティングがあるかもしれません。 他の場合には、1人以上の送付者がいるかもしれませんか、またはデータの送付者と受信機であるグループの皆の可能性は存在するかもしれません。
2.4. Group Size Scalability
2.4. グループサイズスケーラビリティ
Native IP multicast [RFC1112] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-based protocol can be applied without the potential for the volume of NACK feedback messages to overwhelm network capacity. This is often referred to as "feedback implosion". Research suggests that NACK- based reliable multicast group sizes on the order of tens of thousands of receivers may operate with acceptable levels of feedback to the sender using probabilistic, timer-based suppression techniques [NormFeedback]. Instead of receivers immediately transmitting feedback messages when loss is detected, these techniques specify use
ネイティブのIPマルチキャスト[RFC1112]は非常に大きいグループサイズに比例するかもしれません。 いくつかのアプリケーションが比例するマルチキャストインフラストラクチャの能力と共に比例するのは、望ましいかもしれません。 最も簡単なフォームには、ネットワーク容量を圧倒するナックフィードバックメッセージのボリュームの可能性なしでナックベースのプロトコルを適用できるグループサイズへの限界があります。 これはしばしば「フィードバック内部破裂」と呼ばれます。 研究は、ナックが確率的で、タイマベースのサプレッション技術[NormFeedback]を使用することで何万台もの受信機の注文のサイズが合格水準のフィードバックで送付者に経営するかもしれない信頼できるマルチキャストグループを基礎づけたと示唆します。 損失がすぐに検出されるときフィードバックメッセージを送る受信機の代わりに、これらのテクニックは使用を指定します。
Adamson, et al. Standards Track [Page 6] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[6ページ]。
of purposefully-scaled, random back-off timeouts such that some potential NACKing receivers can self-suppress their feedback upon hearing messages from other receivers that have selected shorter random timeout intervals. However, there may be additional NACK suppression heuristics that can be applied to enable these protocols to scale to even larger group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
故意にスケーリングされて、無作為の下に後部タイムアウトでは、そうした他の受信機からメッセージを聞くとき、いくつかの潜在的NACKing受信機が自己にそれらのフィードバックを抑圧できるようなものは、より短い無作為のタイムアウト間隔を選択しました。 しかしながら、これらのプロトコルがさらに大きいグループサイズに比例するのを可能にするために適用できる追加ナック抑圧発見的教授法があるかもしれません。 大規模場合では、メンバーがグループの他のすべてのメンバー(特定の、そして、他の受信機の)の上で状態を維持するのは、禁止であるかもしれません。 グループサイズの影響は、適切なブロックの発展で考えられる必要があります。
Group size scalability may also be aided by intermediate system assistance; see section 2.7 below.
また、グループサイズスケーラビリティは中間システム支援で支援されるかもしれません。 下のセクション2.7を見てください。
2.5. Data Delivery Performance
2.5. データ配送パフォーマンス
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer- based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and to allow the sender of data to identify appropriate content for efficient repair transmission. For example, back-off timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at the cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
ナック指向のプロトコルを設計するとき、スケーラビリティとデータ配送潜在の間には、トレードオフがあります。 確率的であるなら、タイマベースのナックの抑圧が使用されていることである、いくつか遅滞するでしょうナックプロセスが抑圧が、起こって、データの送付者が効率的な修理送信のための適切な内容を特定するのを許容するのを許容するために組み込まれた。 例えば、効率的なナックの抑圧と修理送信を確実にするのに下に後部タイムアウトを使用できますが、これは送付者と受信機の両方のための増強された配送潜在と増強されたバッファリング要件の費用で来ます。 SHOULDがデータ配送性能のために領域をアプリケーションを確立させるブロック。 アプリケーション設計者がそのような領域が適用されているときされるスケーラビリティトレードオフを意識しているに違いないことに注意してください。
2.6. Network Environments
2.6. ネットワーク環境
The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively operating across a wide range of the networks to which general purpose IP service applies. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite, and other wireless communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fan-out" to which IP multicast service is highly applicable. Additionally, policy and/or technical issues may result in topologies where multicast connectivity is limited to a source-specific multicast (SSM) model from a specific source [RFC4607]. Receivers in the group may be
インターネットプロトコルは異機種ネットワークtopologiesの向こう側に提供サービスの役割を歴史的に引き受けました。 事実上、信頼できるマルチキャストプロトコルが汎用のIPサービスが申請されるさまざまなネットワークの向こう側に作動できるのは、望ましいです。 今日のただ一つのグループのメンバーの間のリンクで利用可能な帯域幅はワイヤレスのリンクへのkbit/sと高速のための複数のGbit/sの低い数字の間でLAN接続を変えるかもしれません、他の流れからの異なった度合いの主張で。 最近、56のK/ADSLモデム、CATVインターネットサービス、衛星、および他のワイヤレスの通信サービスを含む多くの非対称のネットワーク・サービスが増殖し始めました。 本来これらの多くがIPマルチキャストサービスがどれであるかに非常に適切な潜在的に大きい「四方八方に広がってください」がある放送メディアです。 さらに、方針、そして/または、専門的な問題はマルチキャストの接続性が特定のソース[RFC4607]からソース特有のマルチキャスト(SSM)モデルに制限されるtopologiesをもたらすかもしれません。 グループにおける受信機はそうです。
Adamson, et al. Standards Track [Page 7] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[7ページ]。
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.
NACKsと他のメッセージのためにユニキャストフィードバックに制限されます。 ブロック開発とプロトコルデザインで基本的なネットワークの本質に対して考慮を払わなければなりません。
2.7. Intermediate System Assistance
2.7. 中間システム支援
Intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to increase the performance and scalability of NACK-based reliable multicast protocols. Feedback aggregation and filtering of sender repair data may be possible with NACK-based protocols using FEC-based repair strategies as described in the present and other reliable multicast transport building block documents. However, there will continue to be a number of instances where intermediate system assistance is not available or practical. Any building block components for NACK- oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
基本的なネットワーク形態に関するダイレクト知識があるデバイス/システムからの中間的支援は、ナックベースの信頼できるマルチキャストプロトコルの性能とスケーラビリティを増強するのに使用されるかもしれません。 ナックベースのプロトコルが現在の、そして、他の信頼できるマルチキャスト輸送ブロックドキュメントで説明されるようにFECベースの修理戦略を使用していて、送付者修理データのフィードバック集合とフィルタリングは可能であるかもしれません。 しかしながら、中間システム支援が利用可能でもなくて、また実用的でもないところで多くのインスタンスが続くでしょう。 ナックのためのどんなブロックコンポーネントも信頼できるマルチキャストSHALLを適応させました。そのような支援なしで作動できてください。 しかしながら、それはまたそのようなプロトコルが利用可能であるときに、これらの特徴を利用することで考えるRECOMMENDEDです。
3. Functionality
3. 機能性
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NACK-based reliable multicast building block identification/design. This section describes different building block areas applicable to NACK-based reliable multicast protocols. Some of these areas are specific to NACK-based protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those general building block areas from the standpoint of NACK-based reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NACK-based reliable multicast protocols.
前項はナックベースの信頼できるマルチキャストブロック識別/デザインに影響するかもしれないプロトコルブロックの役割と評価基準のいくつかを提示しました。 このセクションはナックベースの信頼できるマルチキャストプロトコルに適切な異なったブロック領域について説明します。 これらの領域のいくつかがナックベースのプロトコルに特定です。 そのような領域の詳述を提供します。 他の場合では、領域(例えば、ノード識別子、前進型誤信号訂正(FEC)など)は他のフォームの信頼できるマルチキャストに適切であるかもしれません。 それらの場合では、以下での議論はナックベースの信頼できるマルチキャストの見地からそれらの一般的なブロック領域に置かれた要件について説明します。 適切であるところでは、他のブロックドキュメントがナックベースの信頼できるマルチキャストプロトコルへの可能な貢献のために参照をつけられます。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NACK-
各ブロックにおいて、1つのブロックコンポーネントの別のものか他のプロトコルパラメタに関するどんな依存も例証するために概念的な「インタフェース記述」を提供します。 ブロックコンポーネントは、機能を実行するために別のブロックコンポーネントか他のソースからの何らかのフォームの「入力」を必要とするかもしれません。 そして/またはどんな結果の「出力」も提供したブロックコンポーネントによって必要とされた「入力」は、それぞれのブロックコンポーネントのインタフェース記述で定義されて、説明されるでしょう。 ここに提示されたブロックのセットが完全に互いの「入力」と「出力」需要を満たすというわけではないことに注意してください。 いくつかの場合、ここのブロックのための「入力」はこのドキュメント(例えば、輻輳制御かFEC)への外部の他のブロックから来なければなりません。 他の場合ナックで
Adamson, et al. Standards Track [Page 8] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[8ページ]。
based reliable multicast building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
特定のプロトコル具体化か実装(例えば、アプリケーションデータとコントロール)でベースの信頼できるマルチキャストブロック「入力」を満たさなければなりません。
The following building block components relevant to NACK-based reliable multicast are identified:
ナックベースの信頼できるマルチキャストに関連している以下のブロックコンポーネントは特定されます:
NORM (NACK-Oriented Reliable Multicast)-Specific
標準(ナック-Orientedの信頼できるマルチキャスト)詳細
1. Multicast Sender Transmission
1. マルチキャスト送付者送信
2. NACK Repair Process
2. ナック修理プロセス
3. Multicast Receiver Join Policies and Procedures
3. マルチキャスト受信機は方針と手順を接合します。
General Purpose
汎用
1. Node (Member) Identification
1. ノード(メンバー)識別
2. Data Content Identification
2. データ内容識別
3. Forward Error Correction (FEC)
3. 前進型誤信号訂正(FEC)
4. Round-Trip Timing Collection
4. 往復のタイミング収集
5. Group Size Determination/Estimation
5. グループサイズ決断/見積り
6. Congestion Control Operation
6. 輻輳制御操作
7. Intermediate System Assistance
7. 中間システム支援
8. Ancillary Protocol Mechanisms
8. 付属のプロトコルメカニズム
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components, while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
図1はこれらのブロック領域とそれらの関係のいくつかの絵の概要を提供します。 例えば、送付者が初めは伝わるというデータメッセージの内容は「ノード識別」、「データ内容識別」、および"FEC"コンポーネントによります、メッセージ送信の速度は一般に「輻輳制御」コンポーネントによるでしょうが。 次に、これらのトランスミッション(例えば、修理のためのNACKing)への受信機の応答は他のブロックコンポーネントからのデータメッセージ内容と入力によるでしょう。 最終的に、送付者の受信機応答の処理はトランスミッション戦略にフィードバックされるでしょう。
The components on the left side of this figure are areas that may be applicable beyond NACK-based reliable multicast. The more significant of these components are discussed in other building block documents, such as the FEC Building Block [RFC5052]. Brief
この図の左側のコンポーネントはナックベースの信頼できるマルチキャストで適切であるかもしれない領域です。 FECビルBlockなどの他のブロックドキュメント[RFC5052]でこれらのコンポーネントで重要なより多くについて議論します。 要約
Adamson, et al. Standards Track [Page 9] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[9ページ]。
descriptions of these areas and their roles in NACK-based reliable multicast protocols are given below, and "RTT Collection" is discussed in detail in Section 3.7 of this document.
ナックベースの信頼できるマルチキャストプロトコルにおけるこれらの領域とそれらの役割の記述を以下に与えます、そして、このドキュメントのセクション3.7で詳細に「RTT収集」について議論します。
The components on the right are seen as specific to NACK-based reliable multicast protocols, most notably the NACK repair process. These areas are discussed in detail below (most notably, "Multicast Sender Transmission" and "NACK Repair Process" in Sections 3.1 and 3.2). Some other components (e.g., "Security") impact many aspects of the protocol, and others may be more transparent to the core protocol processing. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NACK-based reliable multicast transport for the Internet.
右のコンポーネントはナックベースの信頼できるマルチキャストプロトコル、最も著しくナック修理の過程に特定であるとみなされます。 (著しくセクション3.1と3.2のほとんどの「マルチキャスト送付者送信」と「ナック修理の過程」)の下で詳細にこれらの領域について議論します。 ある他のコンポーネント(例えば、「セキュリティ」)はプロトコルの多くの局面に影響を与えます、そして、他のものはコアプロトコル処理により透明であるかもしれません。 メカニズムのために適切で、特定の技術提言をするところでは、それは適切にインターネットのためのナックベースの信頼できるマルチキャスト輸送の目標を満たすでしょう。
Adamson, et al. Standards Track [Page 10] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[10ページ]。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |-------+-->| Sender Transmission |<---.
`---------------------' | `-----------------------' |
.---------------------. | | .------------------. |
| Data Identification |-------+ | | Rcvr Join Policy | |
`---------------------' | V `------------------' |
.---------------------. | .----------------------. |
.->| Congestion Control |-------+ | Receiver NACK | |
| `---------------------' | | Repair Process | |
| .---------------------. | | .------------------. | |
| | |-------' | | NACK Initiation | | |
| | FEC |-----. | `------------------' | |
| | |--. | | .------------------. | |
| `---------------------' | | | | NACK Content | | |
| .---------------------. | | | `------------------' | |
`--| RTT Collection |--|--+---->| .------------------. | |
| |--+ | | | NACK Suppression | | |
`---------------------' | | | `------------------' | |
.---------------------. | | `----------------------' |
| Group Size Est. |--|--' | .-----------------. |
| |--+ | | Intermediate | |
`---------------------' | | | System Assist | |
.---------------------. | v `-----------------' |
| Other | | .-------------------------. |
`---------------------' `------->| Sender NACK Processing |--'
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
アプリケーションデータとコントロール| v。---------------------. .-----------------------. | ノード識別|-------+-->| 送付者トランスミッション| <、-、--. `---------------------' | `-----------------------' | .---------------------. | | .------------------. | | データ識別|-------+ | | Rcvrは方針を接合します。| | `---------------------' | 'V‘------------------' | .---------------------. | .----------------------. | .->| 輻輳制御|-------+ | 受信機ナック| | | `---------------------' | | 修理の過程| | | .---------------------. | | .------------------. | | | | |-------' | | ナックInitiation| | | | | FEC|-----. | `------------------' | | | | |--. | | .------------------. | | | `---------------------' | | | | ナックContent| | | | .---------------------. | | | `------------------' | | `--| RTT収集|--|--+---->| .------------------. | | | |--+ | | | ナックSuppression| | | `---------------------' | | | `------------------' | | .---------------------. | | `----------------------' | | サイズエストを分類してください。 |--|--' | .-----------------. | | |--+ | | 中間的| | `---------------------' | | | システムアシスト| | .---------------------. | 'v‘-----------------' | | 他| | .-------------------------. | `---------------------' `------->| 送付者ナックの処理|--' | そして、応答を修理してください。| `-------------------------' ^ ^ | | .-----------------------------. | (セキュリティ) | `-----------------------------'
Figure 1: NACK-Based Reliable Multicast Building Block Framework
図1: ナック-Basedの信頼できるマルチキャストブロック枠組み
3.1. Multicast Sender Transmission
3.1. マルチキャスト送付者送信
Reliable multicast senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of the FEC Building Block [RFC5052]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), the sender transmission rate SHALL be controlled
頼もしいマルチキャスト送付者はマルチキャストセッションまでデータ内容を伝えるでしょう。 データ内容はアプリケーションに依存するようになるでしょう。 送付者はレートにおいてメッセージサイズに満足していて、アプリケーション、そして/または、ネットワークアーキテクチャ要件で決定しているデータを送るでしょう。 トランスミッションSHOULDを送付者にコード化するどんなFECもFECビルBlock[RFC5052]のガイドラインに従います。 混雑制御機構が必要であり(一般的なインターネット操作のためのREQUIRED)、送付者通信速度がSHALLである、制御されてください。
Adamson, et al. Standards Track [Page 11] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[11ページ]。
by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from multicast senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
混雑で、メカニズムを制御してください。 どのような場合でも、マルチキャスト送付者からのすべてのデータ伝送がアプリケーションか輻輳制御アルゴリズムによって決定しているレート制限を受けることがあるのは、RECOMMENDEDです。 送付者のトランスミッション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 NACK-based reliable multicast protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require, following the rules of the NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK responses from the receivers to this command.
データ内容に加えて、他の送付者メッセージかコマンドがプロトコル操作の一部として使われるかもしれません。 これらのメッセージは適用範囲データ転送の外に現れるかもしれません。 ナックベースの信頼できるマルチキャストプロトコルでは、積極的な承認がグループサイズスケーラビリティ関心のために禁止であるときに、そのようなプロトコルメッセージの信頼性は余分なトランスミッションで試みられるかもしれません。 プロトコルデザインSHOULDがそのようなメッセージがグループによって受け取られないケースに対処するのにメカニズムを提供することに注意してください。 例として、コマンドメッセージは、一時トランスミッションを止めているのを(永久に)示すために送付者によって冗長に送られるかもしれません。 このとき、受信機が彼らが必要とする傑出している修理のためにNACKsと共に応じるのは、適切であるかもしれません、ナック手順の規則に従って。 効率のために、送付者は余分なトランスミッションの間のどんな受信機からこのコマンドまでのナックの応答も受けることができるくらいの時間を許すべきです。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NACK-based reliable multicast protocol timeouts should be dependent upon the group greatest round-trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The sender GRTT is an estimate of the worst-case round-trip timing from a given sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to a given sender. NACK-based reliable multicast instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
どんな結果のナックや他のフィードバック操作もあるとき、一般に、送付者によって発行されたコントロールメッセージと他のナックベースの信頼できるマルチキャストプロトコルタイムアウトの余分なトランスミッションのタイミングはどんな予想されたグループ最も大きい往復のタイミング(GRTT)見積りと結果のナックや他のフィードバック操作にも依存しているべきです。 与えられた送付者からどんな受信機まで送付者GRTTはグループで、最悪の場合の往復のタイミングの見積りです。 GRTT間隔がネットワーク形態の向こう側の与えられた送付者に関するマルチキャストグループの最大スパン(遅れに関する)の内輪な見積りであると思われます。 ナックベースの信頼できるマルチキャスト具体化SHOULD、ダイナミックにさまざまなマルチキャストネットワークtopologiesに順応できてください。
Inputs:
入力:
1. Application data and control.
1. アプリケーションデータとコントロール。
2. Sender node identifier.
2. 送付者ノード識別子。
Adamson, et al. Standards Track [Page 12] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[12ページ]。
3. Data identifiers.
3. データ識別子。
4. Segmentation and FEC parameters.
4. 分割とFECパラメタ。
5. Transmission rate.
5. 通信速度。
6. Application controls.
6. アプリケーションは制御されます。
7. Receiver feedback messages (e.g., NACKs).
7. 受信機フィードバックメッセージ(例えば、NACKs)。
Outputs:
出力:
1. Controlled transmission of messages with headers uniquely
identifying data or repair content within the context of the
reliable multicast session.
1. ヘッダーが信頼できるマルチキャストセッションの文脈の中で唯一データか修理内容を特定しているメッセージの制御伝達。
2. Commands indicating sender's status or other transport control
actions to be taken.
2. 何らかの送付者の状態を示すコマンドは、取るためにコントロール動作を輸送します。
3.2. NACK Repair Process
3.2. ナック修理の過程
A critical component of NACK-based reliable multicast protocols is the NACK repair process. This includes both the receiver's role in detecting and requesting repair needs and the sender's response to such requests. There are four primary elements of the NACK repair process:
ナックベースの信頼できるマルチキャストプロトコルの重要な要素はナック修理の過程です。 これは修理の必要性を見つけて、要求することにおける受信機の役割とそのような要求への送付者の応答の両方を含んでいます。 ナック修理の過程の4つの第一の要素があります:
1. Receiver NACK process initiation,
1. 受信機ナックの過程開始
2. NACK suppression,
2. ナックの抑圧
3. NACK message content,
3. ナックメッセージ内容
4. Sender NACK processing and repair response.
4. 送付者ナックの処理と修理応答。
3.2.1. Receiver NACK Process Initiation
3.2.1. 受信機ナックの過程開始
The NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the sender data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
ナック過程(サイクル)は特定の送付者からの修理送信が信頼できるレセプションを実現する必要性を見つける受信機によって開始されるでしょう。 FECが適用されているとき、修理要件がデータ内容の与えられたコード化ブロックのための未定のFECトランスミッションの量を超えているのが知られている場合にだけ、受信機はナックの過程に着手するはずです。 これは変流器ブロック(それが示されるなら)の端において、または、その後のコード化ブロックかトランスミッション物のレセプションの始まりときの決定できます。 これは、送付者データ内容がFEC街区番号を特定するためにマークされて、その序数の関係がトランスミッションの順に保存されるのを含意します。
Adamson, et al. Standards Track [Page 13] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[13ページ]。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK process earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events, such as at the end-of- transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
あるいはまた、送付者のトランスミッションがそれがブロックに送るのを既に計画している修理パケットの量の広告を出すなら、受信機は、より早くナックの過程に着手できるかもしれません。 受信機が彼らが検出するサイクル何時でもナックを開始するのを彼らの修理の必要性が修理送信まで超えていた許容するのがわずかに迅速な修理サイクルで結果として生じるかもしれません。 しかしながら、ナックの過程開始を特定の出来事に制限するのは役に立つかもしれません、終わりなどのように-、-FECコード化のトランスミッションが、ブロックを妨げるか、またはその後の検出コード化します。 これで、受信機は、より少ない数のナックメッセージへのナック内容に集めて、ナックフィードバックの有効な確率的な抑圧を容易にするのを助けるために何らかの暗黙のゆるい同期を受信機セットに供給できます。 受信機は現在の修理の必要性を決定するために送付者から受け取られたデータ内容の歴史を維持しなければなりません。 FECが採用しているとき、歴史が未定の、または、部分的に受信されたコード化ブロックの記録に一致すると予想されます。
For probabilistic, timer-based suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
フィードバックの確率的で、タイマベースの抑圧のために、受信機がbackoffタイムアウトを観測している状態で、ナックサイクルは始まるべきです。 このbackoffタイムアウトを起こすことに関連して、受信機が彼らがナックサイクルを開始する送付者のトランスミッション系列に位置を記録するのは、重要です。 抑圧backoffタイムアウトが期限が切れると、受信機はナックを伝えるか、または抑圧するという決定をする際に彼らの修理の必要性をこの記録されたトランスミッション位置まで考えるだけであるはずです。 この制限がなければ、抑圧はナックメッセージがネットワークの向こう側に伝播される時の送付者から送付者と他の受信機まで追加内容を受け取るように大いに抑えられます。
Inputs:
入力:
1. Sender data content with sequencing identifiers from sender
transmissions.
1. 送付者トランスミッションから識別子を配列することの送付者データ内容。
2. History of content received from sender.
2. 内容の歴史は送付者から受信されました。
Outputs:
出力:
1. NACK process initiation decision.
1. ナックの過程開始決定。
2. Recorded sender transmission sequence position.
2. 記録された送付者トランスミッション系列位置。
3.2.2. NACK Suppression
3.2.2. ナックSuppression
An effective feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [SrmFramework]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have
有効なフィードバック抑圧メカニズムは修理[SrmFramework]を必要とする受信機によるナックのトランスミッションの前の無作為のbackoffタイムアウトの使用です。 backoffタイムアウトの満了のときに、未定の修理の必要性が要求していないと、受信機は修理を要求するでしょう。
Adamson, et al. Standards Track [Page 14] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[14ページ]。
been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or by providing some other indicator of the repair information it will be subsequently transmitting.
ナックによって完全に取って代わられて、メッセージは他の受信機(受信機がマルチキャスティングNACKsであるときに)か何らかのインディケータから送付者から聞かれました。 受信機がナックメッセージをunicastingしているとき、送付者は、それが全体のグループに受け取ったナック内容の表現を進めるか、またはそれが次に伝える修理情報のある他のインディケータを提供することによって、ナックの抑圧を容易にするかもしれません。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [McastFeedback]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of the sender's GRTT assessment and a group size estimate that is either determined by other mechanisms within the protocol or is preset by the multicast application.
有効でスケーラブルな抑圧性能において、端が欠けている指数分布[McastFeedback]で受信機によって費やされたbackoffタイムアウト時間は受信機によって独自に、手当たりしだいに選ばれるはずです。 これは「前のNACKers」の、より少ない数がグループの残りの修理の必要性に取って代わるという仮定でナックメッセージの伝達を食い止めるように設定された受信機の大部分をもたらします。 分配の平均はプロトコルの中の他のメカニズムで決定するか、またはマルチキャストアプリケーションであらかじめセットされる送付者の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.
適切な分配がある無作為のbackoffタイムアウトを発生させるように簡単なアルゴリズムを構成できます。 受信機(「R」)の数を考えて、さらに、アルゴリズムは、backoff分配を最適化するようにフィードバックを潜在的に発生させながら、設計されるかもしれません。 この「最適化」はすべての受信機がナックを発生させる最悪の場合状況における、フィードバックメッセージ(例えば、ナック)の数を最小にします。 最大のbackoffタイムアウト(「T_maxBackoff」)がフィードバック交通のボリュームに従った信頼できる配信潜在を制御するように設定できます。 「T_maxBackoff」の、より大きい値は与えられた修理サイクルの間のフィードバック交通の低い密度をもたらすでしょう。 「T_maxBackoff」の、より小さい値は、より短い潜在をもたらします。(また、それは、信頼できる輸送のために送付者と受信機のバッファリング要件を減らします)。
In the functions below, the "log()" function specified refers to the
"natural logarithm" and the "exp()" function is similarly based upon
the mathematical constant 'e' (a.k.a. Euler's number) where "exp(x)"
corresponds to '"e"' raised to the power of '"x"'. Given the
receiver group size ("groupSize") and maximum allowed backoff timeout
("T_maxBackoff"), random backoff timeouts ("t'") with a truncated
exponential distribution can be picked with the following algorithm:
以下での機能では、指定された「ログ()」機能は「自然対数」について言及します、そして、"exp(x)"が'「x」'のパワーに上げられた'「e」'に対応しているところに"exp()"機能は同様に数学の定数'e'(通称オイラーの番号)に基づいています。 'backoffタイムアウト(「T_maxBackoff」)が許容された受信機グループサイズ("groupSize")と最大を考えて、以下のアルゴリズムで端が欠けている指数分布がある無作為のbackoffタイムアウト(「t'」)を選ぶことができます:
1. Establish an optimal mean ("L") for the exponential backoff based
on the "groupSize":
1. "groupSize"に基づく指数のbackoffのために、最適の平均(「L」)を設立してください:
L = log(groupSize) + 1
Lはログ(groupSize)+1と等しいです。
Adamson, et al. Standards Track [Page 15] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[15ページ]。
2. Pick a random number ("x") from a uniform distribution over a
range of:
2. 以下の範囲の上の一様分布から乱数(「x」)を選んでください。
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
L L L-------------------- to-------------------- + ---------- T_maxBackoff*(exp(L)-1)T_maxBackoff*(exp(L)-1)T_maxBackoff
3. Transform this random variate to generate the desired random
backoff time ("t'") with the following equation:
3. 'この無作為の変量を変えて、以下の方程式で必要な無作為のbackoff時間(「t'」)を発生させてください:
t' = T_maxBackoff/L * log(x * (exp(L) - 1) * (T_maxBackoff/L))
't'=T_maxBackoff/L*ログ(x*(exp(L)--1)*(T_maxBackoff/L))
This "C" language function can be used to generate an appropriate random backoff time interval:
適切な無作為のbackoff時間間隔を発生させるのにこの「C」言語機能を使用できます:
double RandomBackoff(double T_maxBackoff, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/T_maxBackoff) +
lambda / (T_maxBackoff*(exp(lambda)-1));
return ((T_maxBackoff/lambda) *
log(x*(exp(lambda)-1)*(T_maxBackoff/lambda)));
} // end RandomBackoff()
二重RandomBackoff(T_maxBackoffを倍にしてください、二重groupSize)二重λ=ログ(groupSize)+1; 二重x=UniformRand(λ/T_maxBackoff) + λ/(T_maxBackoff*(exp(λ)-1)); (T_maxBackoff/λ)*が登録するリターン(x*(exp(λ)-1)*(T_maxBackoff/λ)));//エンド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(二重最大)」が一様分布がある乱数を「0」の範囲から返すところ。「最大限にしてください。」 例えば、POSIX「底ならし革()」機能に基づいて、以下の「C」コードを使用できます:
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
二重UniformRand(二重最大)リターン(最大*((二重)の底ならし革()/(二重)のRAND_MAX))。
The number of expected NACK messages generated ("N") within the first
round-trip time for a single feedback event is approximately:
単一のフィードバックイベントのための往復の1回目以内に発生した(「N」)予想されたナックメッセージの数はおよそ以下の通りです。
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
Nはexpと等しいです。(1.2*L/(_2*T maxBackoff/GRTT))
Thus, the maximum backoff time can be adjusted to trade off worst-
case NACK feedback volume versus latency. This is derived from the
equations given in [McastFeedback] and assumes "T_maxBackoff >=
GRTT", and "L" is the mean of the distribution optimized for the
given group size as shown in the algorithm above. Note that other
mechanisms within the protocol may work to reduce redundant NACK
generation further. It is suggested that "T_maxBackoff" be selected
as an integer multiple of the sender's current advertised GRTT
estimate such that:
T_maxBackoff = K * GRTT; where K >= 1
したがって、最もひどく潜在に対してケースナックフィードバック量を交換するように最大のbackoff時間を調整できます。 これは、[McastFeedback]で与えられた方程式から得られて、「T_maxBackoff>はGRTTと等しいです」と仮定します、そして、「L」は与えられたグループサイズのために上のアルゴリズムで示されるように最適化された分配の平均です。 プロトコルの中の他のメカニズムがさらに余分なナック世代を短縮するために働くかもしれないことに注意してください。 送付者の現在の広告を出しているGRTTの整数倍数が、そのようなものがそれであると見積もっているので「T_maxBackoff」が選択されることが提案されます: T_maxBackoffはK*GRTTと等しいです。 どこK>=1
Adamson, et al. Standards Track [Page 16] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[16ページ]。
For general Internet operation, a default value of "K=4" is RECOMMENDED for operation with multicast (to the group at large) NACK delivery; a value of "K=6" is the RECOMMENDED default for unicast NACK delivery. Alternate values may be used to achieve desired buffer utilization, reliable delivery latency, and group size scalability trade-offs.
一般的なインターネット操作、「K=4インチは操作のためにマルチキャスト(全体のグループへの)ナックの配送で推薦される」デフォルト値のために。 「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 Section 3.2.4.
(「K*GRTT」)が受信機によって費やされた、ナックのトランスミッションを開始した最大のbackoff時間であるなら、それに従って、ナック修理の過程に関連する他のタイムアウト時間はスケーリングできます。 それらのタイムアウトの1つはそれ自体を許容する前にナックメッセージを発生させた後に受信機がもう1ナックのbackoff/トランスミッションサイクル(「T_rcvrHoldoff」)開始するのを待つはずである時間です。 送付者が修理メッセージで容認されたナックに反応するように、この遅れは十分であるべきです。 適切な値はナックが修理応答を提供するために送付者と送付者に連絡する時間に依存します。 これは可能な倍数NACKsが効率的な修理応答を決定するために蓄積されるどんな量の送付者ナック集合の期間も含まなければなりません。 セクション3.2.4でこれらのタイムアウトについてさらに議論します。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
また、フィードバック抑圧の性能を向上させるために適用できる二次測定があります。 例えば、送付者のデータ内容送信はトランスミッションの序数の順序に従うことができます。 データ内容のための修理が起こると、受信機は、送付者がデータ・オブジェクト、FEC街区番号、およびFECシンボル識別子を観察することによってデータ内容トランスミッション位置を「巻き戻した」と述べることができます。 受信機SHOULDは送付者の変流器位置が受信機が不完全なレセプションを開くポイントを超えている時だけまでNACKsのトランスミッションを制限します。 これは送付者が他の受信機要求に対応して提供するのを計画しているかもしれないデータの修理を求める時期尚早な要求を減らします。 他の受信機(または、送付者からのインディケータ)からのNACKsのトランスミッションが無くなるとき、高い損失状態におけるプロトコル集合に、このメカニズムは非常に効果的である場合があります。 別のメカニズム(特に適切なFECが使用されていると)は送付者が現在のパケットのトランスミッションが送った差し迫っている修理のしるしを埋め込むことです。 例えば、指示は現在の適切なコード化ブロックに送られるFECパケットの数の広告と同じくらい簡単であるかもしれません。
Finally, some consideration might be given to using the NACKing history of receivers to bias their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not always be present in multicast networks. This adjustment of backoff timeout selection may
最終的に、彼らのナックbackoffタイムアウト間隔の品揃えに偏るために受信機のNACKing歴史を費やすことに対して何らかの考慮を払うかもしれません。 例えば、受信機が最大級の度の損失を歴史的に経験しているなら、それ自体を促進するかもしれない、統計的である、ナック、他の受信機より早く。 時間の連続した間隔の間、これが受信機によって経験された損失で相関関係を必要とすることに注意してください。そのような相関関係はマルチキャストネットワークでいつも存在していてもよいというわけではありません。 backoffタイムアウト選択のこの調整はそうするかもしれません。
Adamson, et al. Standards Track [Page 17] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[17ページ]。
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.
これらの歴史的なNACKersのために「初期のナック」スロットの創造を必要としてください。 ナックbackoffの窓のこの追加スロットはいくつかのアプリケーションには、望ましくないかもしれないより長い修理サイクルの過程をもたらすでしょう。 これらのトレードオフの解決はプロトコルの目標アプリケーションセットかネットワークに依存しているかもしれません。
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:
無作為のbackoffタイムアウトが期限が切れた後に、受信機はナックの修理要求を発生させるかどうかに関して決定するでしょう(すなわち、それは抑圧されました)。 以下の条件のどれかが現れたとき、ナックは抑圧されるでしょう:
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. 蓄積は、地方の受信機について他から聞かれたNACKsにおいて受信機(または、送付者によるこの状態の推進)が等しいと述べるか、または修理の必要性に取って代わります。地方の受信機が修理の必要性を単にナックのサイクル開始のときに記録された送付者トランスミッション位置まで考えるはずであることに注意してください(backoffタイマが動いたとき)。
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. 送付者のデータ内容トランスミッション位置は地方の受信機の修理の必要性の最も低い系列位置のものよりそれほど序数をポイントに「巻き戻します」。 (「巻き戻送付者」のこの検出は、送付者が既に地方の受信機が意識していなかったかもしれない他の受信機修理の必要性に応じたのを示します。) ナックサイクルがbackoffタイムアウト起動で開始された1と)2の何時でも) backoffタイムアウトがナックを抑圧するために期限が切れた現在の瞬間この「巻き戻し」出来事は起こることができます。 送付者のトランスミッション系列位置が受信機の最も低い序数の修理ポイントを超えているとき、受信機でもう1ナックサイクルを開始しなければなりません。 他の受信機の修理の必要性への送付者の応答の結果、地方の受信機で修理需要を満たしていたのが可能であり、一層のNACKingは全く必要でないことに注意してください。
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.
これらの状態が現れていなくて、受信機に未定の修理の必要性がまだあるなら、ナックメッセージは、発生して、送られます。 ナックは受信機の最も低い序数の修理ポイントからの修理の必要性の蓄積から現在の送付者トランスミッション系列位置まで成るべきです。 ただ一つのナックメッセージは発生するべきです、そして、ただ一つのプロトコルメッセージのペイロードサイズを超えているなら、ナックメッセージ内容は先端を切られるべきです。 そのようなナックペイロード限界が起こると、SHOULDが含むナック内容は序数的に最も低いように送付者から必要である修理内容を要求します。
Adamson, et al. Standards Track [Page 18] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[18ページ]。
Inputs:
入力:
1. NACK process initiation decision.
1. ナックの過程開始決定。
2. Recorded sender transmission sequence position.
2. 記録された送付者トランスミッション系列位置。
3. Sender GRTT.
3. 送付者GRTT。
4. Sender group size estimate.
4. 送付者グループサイズ見積り。
5. Application-defined bound on backoff timeout period.
5. backoffタイムアウト時間のアプリケーションで定義されたバウンド。
6. NACKs from other receivers.
6. 他の受信機からのNACKs。
7. Pending repair indication from sender (may be forwarded NACKs).
7. 送付者(NACKsを進めるかもしれない)からの未定の修理指示。
8. Current sender transmission sequence position.
8. 現在の送付者トランスミッション系列位置。
Outputs:
出力:
1. Yes/no decision to generate NACK message upon backoff timer
expiration.
1. backoffタイマ満了に関するナックメッセージを発生させるというはい/いいえ決定。
3.2.3. NACK Message Content
3.2.3. ナックメッセージ内容
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NACK repair process. The identification of repair needs is dependent upon the data content identification (see Section 3.5 below). At the highest level, the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NACK-based reliable multicast can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼できるマルチキャスト受信機で発生するナックメッセージの内容は彼らの現在の修理の必要性を詳しく述べる情報を含むでしょう。 特殊情報はナック修理の過程によるFECの使用とタイプに頼っています。 修理の必要性の識別はデータ内容識別に依存しています(以下のセクション3.5を見てください)。 上層部によって、ナック内容は修理を必要とする送付者のトランスミッションの中でナックが宛てられる送付者とデータ伝送物(流れる)を特定するでしょう。 そして、示された輸送実体のために、ナック内容はそれが完全な伝えられたデータを再建するのを必要とする特定のFECコード化ブロック、そして/または、シンボルを特定するでしょう。 この内容はなくなったブロックのFECブロック消去カウント、そして/または、明白なしるしかデータとFEC内容のシンボル(セグメント)から成るかもしれません。 また、事実上、信頼できるナックの配送のための要件なしでここで議論したテクニックを使用することでナックベースの信頼できるマルチキャストを例示できることに注意されるべきです。
3.2.3.1. NACK and FEC Repair Strategies
3.2.3.1. ナックとFEC修理戦略
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
FECベースであるところでは、修理が使用されています、メッセージ内容が最少量で修理が必要であるコード化ブロックとコード化のための消去(なくなったパケット)のカウントを特定する必要があるナック
Adamson, et al. Standards Track [Page 19] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[19ページ]。
block. An exact count of erasures implies the FEC algorithm is capable of repairing any loss combination within the coding block. This count may need to be adjusted for some FEC algorithms.
妨げます。 消去の正確なカウントは、FECアルゴリズムがコード化ブロックの中のどんな損失組み合わせも修理できるのを含意します。 このカウントは、いくつかのFECアルゴリズムのために調整される必要があるかもしれません。
Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually effect repair. For the most efficient repair strategy, the NACK content will need to also explicitly identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small- to medium-size block FEC codes (e.g., Reed Solomon [FecSchemes]) that are capable of providing a limited number of parity symbols per FEC coding block.
また、複数の修理ラウンドが首尾よく修理を終了するのに必要であるかもしれないと考える場合、消去カウントは、サーバが伝えるために利用可能にするユニークなFECパリティパケットの量が本質的には無制限であることを含意します(すなわち、サーバがいつも新しい状態で提供できるでしょう、ユニークである、以前に、いずれもに対応したその後のunsentパリティパケットは同じコード化ブロックに関する要求を修理します)。 あるいはまた、送付者は利用可能なセットの与えられたコード化ブロックFECシンボルと、結局、「コマドリ」に効果修理を伝えるかもしれません。 最も効率的な修理戦略のために、ナック内容は、また、受信機が、首尾よくコード化ブロックの内容を再建するのをどのシンボル(情報、そして/または、同等)を必要とするかを明らかに特定する必要があるでしょう。 これは特に限られた数の1FECあたりのパリティシンボルを提供できる中型ブロックFECコード(例えば、リード・ソロモン[FecSchemes])にわずかなコード化ブロックに関して本当になるでしょう。
When FEC is not used as part of the repair process, or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the "(delay*bandwidth*loss)" characteristics of the network topology), the NACK content will need to contain explicit coding block and/or segment loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set.
FECが修理の過程の一部として使用されないか、またはプロトコル具体化が送付者がすべての利用可能な同等を与えられたコード化ブロックに送ったときさえ(トランスミッション歴史をバッファリングする送付者の能力はネットワーク形態の「(遅れ*帯域幅*損失)」特性で超えられています)、信頼性を提供するのに必要であるときに; ナック内容は、送付者が適切な修理パケット、そして/または、データ「再-トランスミッション」を提供できるように明白なコード化ブロック、そして/または、セグメント損失情報を含む必要があるでしょう。 また、ナック内容の明白な損失情報は潜在的に他の目的に役立つかもしれません。 例えば、受信機の中のボトルネックが設定する候補輻輳制御を微分するのを助けるのは受信機のグループで損失の特性を反関連させることの役に立つかもしれません。
When FEC is used and NACK content is designed to contain explicit repair requests, there is a strategy where the receivers can NACK for specific content that will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that the sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity symbols to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block (e.g., Reed Solomon) is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of data content to the group.
FECが使用されていて、ナック内容が明白な修理要求を含むように設計されているとき、受信機がナックの抑圧と修理効率を容易にするのを助ける特定の内容のためのナックをそうすることができる戦略があります。 この戦略のための仮定は送付者が与えられたコード化ブロックに利用可能な新しくて、ユニークなパリティパケットの供給を潜在的に枯渇させるかもしれなくて、信頼できる転送を終了するために明らかにいくつかのデータかパリティシンボルを再送しなければならないということです。 別の仮定はどんなパリティパケットもコード化ブロック(例えば、リード・ソロモン)の中のどんな消去もいっぱいにすることができるFECアルゴリズムが使用されているということです。 この戦略の目標は、信頼できるデータ転送内容の間、グループに利用可能な同等の最大の使用をして、最小量のデータ量と修理送信を提供することです。
Adamson, et al. Standards Track [Page 20] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[20ページ]。
When systematic FEC codes are used, the sender transmits the data content of the coding block (and optionally some quantity of parity packets) in its initial transmission. Note that a systematic FEC coding block is considered to be logically made up of the contiguous set of source data vectors plus parity vectors for the given FEC algorithm used. For example, a systematic coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
系統的なFECコードが使用されているとき、送付者がコード化ブロックのデータ内容を伝える、(任意に、いくらかの量のパリティパケット) 初期のトランスミッションで。 ソースデータベクトルと与えられたFECアルゴリズムのためのベクトルが使用した隣接の同等から系統的なFECコード化ブロックが論理的に作られると考えられることに注意してください。 例えば、1コード化あたりシンボルと32のパリティシンボルが妨げる64のデータに備える系統的なコード構成は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.
そして、受信機は彼らの修理需要を満たすよう十分な内容に要求するナックメッセージを構成できます。 例えば、受信機が与えられた受信されたコード化ブロックに3つの消去を持っていると、それはコード化ブロックでの3つの最も低い序数のパリティベクトルの送信を要求するでしょう。 前のパラグラフからの私たちの例のコード構成で、受信機は、コード化ブロックに3つの消去をいっぱいにするよう明らかに64〜66にパリティシンボルに要求するでしょう。 コード化ブロックのための受信機の損失が有効なパリティ量(すなわち、私たちの例の32以上のなくなったシンボル)を超えていると、受信機がブロックを再建するために利用可能なパリティシンボルのすべての(32)と欠測値シンボルの数個の追加部分を要求するナックを組み立てなければならないことに注意してください。 受信機グループの向こう側に一貫してこれをすると、結果として起こるNACKsは、彼らの修理需要を満たすために1人の極小集合の送付者トランスミッションを包括するでしょう。
In summary, the rule is to request the lower ordinal portion of the parity content for the FEC coding block to satisfy the erasure repair needs on the first NACK cycle. If the available number of parity symbols is insufficient, the receiver will also request the subset of ordinally highest missing data symbols to cover what the parity symbols will not fill. Note this strategy assumes FEC codes such as Reed-Solomon for which a single parity symbol can repair any erased symbol. This strategy would need minor modification to take into account the possibly limited repair capability of other FEC types. On subsequent NACK repair cycles where the receiver may receive some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender.
概要では、規則は修理が最初のナックサイクルに必要とする消去を満たすようFECコード化ブロックでパリティ内容の下側の序数の部分に要求することです。 また、パリティシンボルの有効な数が不十分であるなら、受信機は、パリティシンボルがいっぱいにしないものをカバーするよう序数的に最も高い欠測値シンボルの部分集合に要求するでしょう。 この戦略がただ一つのパリティシンボルがどんな消されたシンボルも修理できるリード-ソロモンなどのFECコードを仮定することに注意してください。 この戦略は、他のFECタイプのことによると限られた修理能力を考慮に入れるために小さい方の変更を必要とするでしょう。 その後のナック修理サイクルに、受信機が以前に要求された修理内容の何らかの部分を受けるかもしれないところで受信機はそれがまだ受け取っていない同等、そして/または、データシンボルのセットに同じ戦略、しかし、ナックだけを使用するでしょう。 また、任意に、受信機は便利として消去のカウントを送付者に提供するかもしれません。
Other types of FEC schemes may require alteration to the NACK and repair strategy described here. For example, some of the large block or expandable FEC codes described in [RFC3453] may be less deterministic with respect to defining optimal repair requests by receivers or repair transmission strategies by senders. For these types of codes, it may be sufficient for receivers to NACK with an estimate of the quantity of additional FEC symbols required to
他のタイプのFEC計画は戦略がここで説明したナックと修理に変更を必要とするかもしれません。 例えば、[RFC3453]で説明された大量株か拡張可能なFECコードのいくつかが送付者で受信機か修理トランスミッション戦略で最適の修理要求を定義することに関してそれほど決定論的でないかもしれません。 これらのタイプのコードのために、ナックにとって、それは追加FECシンボルの量の見積りに必要な状態で受信機に十分であるかもしれません。
Adamson, et al. Standards Track [Page 21] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[21ページ]。
complete reliable reception and for the sender to respond accordingly. This apparent disadvantage, as compared to codes such as Reed Solomon, may be offset by the reduced computational requirements and/or ability to support large coding blocks for increased repair efficiency that these codes can offer.
信頼できるレセプションを終了して、それに従って、反応させる送付者のために。 リード・ソロモンなどのコードと比べるこの見かけの不都合はこれらのコードが提供できる増加する修理効率のために減少しているコンピュータの要件、そして/または、大きいコード化ブロックを支える能力によって相殺されるかもしれません。
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.
集合の期間のナックメッセージの領収書と蓄積の後に、それに以前に伝えられなかった十分な数量のパリティシンボルがあるなら、送付者は最も高い受信機消去カウントに基づくコード化ブロックの新鮮な(以前に「非-伝え」られた)パリティシンボルの送信を始めることができます。 さもなければ、送付者は明白なセットの修理ベクトルが要求した伝えるのによく行かなければなりません。 このアプローチで、送付者は、ほとんどそれがグループからグループから修理要求の同期の必要性なしで受け取った要求の状態を維持しない必要があります。 すべての受信機が彼らの明白な修理の必要性を述べるのに同じ一貫したアルゴリズムを使用するので、受信機の中のナックの抑圧は複数の修理サイクルの過程にわたって簡素化されます。 受信機は単にそれらが自己の未定のナックメッセージを送るべきであるか、または削除するべきであるかを決定するそれら自身の計算された修理の必要性に対して他の受信機から聞かれたNACKsを比較できます。
3.2.3.2. NACK Content Format
3.2.3.2. ナックContentの形式
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.
ナック内容の形式はプロトコルのデータサービスモデルとプロトコルが使用するデータ内容識別の形式に頼るでしょう。 また、このナック形式は(もしあれば)のコード化が使用したFECのタイプに頼っています。 図2はトランスミッションの論理的で、階層的な内容識別計画を例証します、物(または、流れ)、そして/または、FECブロッキングの概念がプロトコル具体化の裁量で任意であることを指示して。 与えられた送付者に関して物の識別があることに注意してください。 与えられたセッションのときに送付者の文脈の中で輸送データ内容識別をするのはお勧めです。 セッション「流れ」と「ブロック」の概念が任意であるので、枠組みは最も簡単なフォームでデータ分割と再アセンブリを典型的な輸送のものに堕落しています。
Session_
\_
Sender_
\_
[Object/Stream(s)]_
\_
[FEC Blocks]_
\_
Symbols
セッション_ \_送付者_ \_、[物/流れの(s)]_ \_[FECブロック]_ \_シンボル
Figure 2: Reliable Multicast Data Content Identification Hierarchy
図2: データの信頼できるマルチキャスト内容識別階層構造
Adamson, et al. Standards Track [Page 22] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[22ページ]。
The format of NACK messages should enable the following:
ナックメッセージの形式は以下を可能にするべきです:
1. Identification of transport data units required to repair the
received content, whether this is an entire missing object/stream
(or range), entire FEC coding block(s), or sets of symbols,
1. 輸送データ単位の識別が受信された内容を修理するのが必要です、これが全体のなくなった物/流れ(及ぶ)であるか否かに関係なく、全体のFECコード化ブロック、またはセットのシンボル
2. Simple processing for NACK aggregation and suppression,
2. ナック集合と抑圧のための簡単な処理
3. Inclusion of NACKs for multiple objects, FEC coding blocks,
and/or symbols in a single message, and
3. そして複数の物のためのNACKsの包含、ただ一つのメッセージでブロック、そして/または、シンボルをコード化するFEC。
4. A reasonably compact format.
4. 合理的にコンパクトな形式。
If the reliable multicast transport object/stream is identified with an <objectId> and the FEC symbol being transmitted is identified with an <fecPayloadId>, the concatenation of <objectId::fecPayloadId> comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receiver's repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
信頼できるマルチキャスト輸送の物/流れが<objectId>とFECシンボルと同一視されているなら、伝えられるのは<fecPayloadId>と同一視されています、<objectIdの連結:、:fecPayloadId>は与えられたソースからシンボルのための基本的なトランスポート・プロトコルデータ単位(TPDU)識別子を包括します。 受信機の修理の必要性について説明するナックメッセージを確立するためにこれらのTPDU識別子のリスト、そして/または、範囲でナック内容を構成できます。 階層的な物の輪郭描写かどんなFECブロッキングも使用されていないなら、TPDUは送付者によって伝えられたデータシンボルの簡単な直線的な表現です。 TPDUが物/流れの輪郭描写、そして/または、FECブロッキングの目的のために階層構造を表すとき、満足しているユニットが必要とするかもしれないナックは、TPDUのどの部分が適切であるかを示すために弛みます。 例えば、全体の「物」(または、物の範囲)が受信データでなくなるなら、受信機は、必ず修理を要求する<sourceBlockNumbers>か<encodingSymbolIds>の適切な範囲を知るというわけではなくて、その結果、<objectId>によって表された全体の単位の修理(または、「再-トランスミッション」)を要求するために何らかのメカニズムを必要とします。 1時までに表されたブロックかさまざまな<sourceBlockNumbers>をコード化する全体のFECがなくされたなら、同じくらいは本当です。
Inputs:
入力:
1. Sender identification.
1. 送付者識別。
2. Sender data identification.
2. 送付者データ識別。
3. Sender FEC object transmission information.
3. 送付者FEC物のトランスミッション情報。
4. Recorded sender transmission sequence position.
4. 記録された送付者トランスミッション系列位置。
5. Current sender transmission sequence position. History of repair
needs for this sender.
5. 現在の送付者トランスミッション系列位置。 この送付者の修理の必要性の歴史。
Adamson, et al. Standards Track [Page 23] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[23ページ]。
Outputs:
出力:
1. NACK message with repair requests.
1. 修理要求があるナックメッセージ。
3.2.4. Sender NACK Processing and Repair Response
3.2.4. 送付者ナックの処理と修理応答
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:
グループにおける受信機からの修理要求のレセプションでは、送付者は修理応答手順に着手するでしょう。 受信機セットから潜在的に複数のNACKsを蓄積できるくらいの時間を過すまで、送付者は修理内容の伝達を遅らせたがっているかもしれません。 これで、送付者は与えられた輸送流れ/物かFECコード化ブロックに最も効率的な修理戦略を決定できます。 使用されるアプローチによって、電流の一部がメッセージ内容を伝えたので送付者が未定の修理送信のインディケータを提供するのが、有益であることがいくつかのプロトコルによってわかるかもしれません。 これはいくつかのナック抑圧メカニズムを支援できます。このナック集合を実行する時間は、ナックメッセージの受信機から送付者までの最大の受信機ナックbackoffの窓(セクション3.2.2からの「「T_maxBackoff」」)と伝播を考慮するために十分であるべきです。 受信機から送付者までのメッセージの最大のトランスミッション遅れがトランスミッション遅れに関する非常に非対称のネットワーク形態の場合でおよそ1*GRTT()「」であるかもしれないと述べてください。 その結果、少なくとも集合の期間が等しいはずである送付者ナック最大の受信機ナックbackoff時間が「T_maxBackoffはK*GRTTと等しいです」であるなら:
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
T_sndrAggregateはT_maxBackoff+1*GRTT=(K+1)*GRTTと等しいです。
Immediately after the sender NACK aggregation period, the sender will begin transmitting repair content determined from the aggregate NACK state and continue with any new transmission. Also, at this time, the sender should observe a "hold-off" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "hold-off" time should be:
送付者ナック集合の期間直後、送付者は、集合ナック状態から決定している修理内容を伝え始めて、どんな新しいトランスミッションも続行するでしょう。 またと、このとき、送付者は、それが自制する「下に、成立すること」の期間が受信機グループへの修理応答のため新しいトランスミッション系列位置の伝播を許すために新しいナック集合の期間を開始しているのを観測するべきです。 この「下に、成立する」時間は、最悪の場合非対称を考慮するためには、以下の通りであるべきです。
T_sndrHoldoff = 1*GRTT
T_sndrHoldoffは1*GRTTと等しいです。
Recall that the receivers will also employ a "hold-off" timeout after generating a NACK message to allow time for the sender's response. Given a sender "<T_sndrAggregate>" plus "<T_sndrHoldoff>" time of "(K+1)*GRTT", the receivers should use hold-off timeouts of:
また、送付者の応答のための時間を許容するナックメッセージを発生させた後に受信機が「下に、成立する」タイムアウトを使うと思い出してください。 「(K+1)*GRTT」の送付者「<T_sndrAggregate>」と「<T_sndrHoldoff>」時間を考えて、受信機は以下の下に成立するタイムアウトを使用するはずです。
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
T_rcvrHoldoffはT_sndrAggregate+T_sndrHoldoff=(K+2)*GRTTと等しいです。
Adamson, et al. Standards Track [Page 24] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[24ページ]。
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.
これは受信機への送付者への受信機のナックの最悪の場合伝播時間、送付者の集合時間、および送付者の応答の伝播を考慮します。受信機セットからのユニキャストフィードバックの場合では、さらに、送付者が受信機セットの中にマルチキャストの接続性がないとき、ナックの抑圧を考慮するために集められたナック内容の表現をグループに送るのは(マルチキャストで)、役に立つかもしれません。
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>」タイムアウトの満了のときに、送付者はNACKsの蓄積された内容に従ったメッセージが受けた修理を伝え始めるでしょう。 FECベースの修理への尊敬があるいくつかのガイドラインと信頼できるマルチキャスト効率を高めることができる送付者からの修理応答の注文があります:
When FEC is used, it is beneficial that the sender transmit previously untransmitted parity content as repair messages whenever possible. This maximizes the receiving nodes' ability to reconstruct the entire transmitted content from their individual subsets of received messages.
FECが使用されているとき、可能であるときはいつも、送付者が修理メッセージとして以前に「非-伝え」られたパリティ内容を伝えるのは、有益です。 これはそれらの受信されたメッセージの個々の部分集合から全体の伝えられた内容を再建する受信ノードの性能を最大にします。
The transmitted object and/or stream data and repair content should be indexed with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content (e.g., ordinally lowest FEC blocks) first, the receivers can use a strategy of withholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help keep repair cycles relatively synchronized without dependence upon strict time synchronization among the sender and receivers. This also helps minimize the buffering requirements of receivers and senders and reduces redundant transmission of data to the group at large.
伝えられた物、そして/または、流れのデータと修理内容は単調に増加する一連番号(合理的に大きい序数のスペースの中の)で索引をつけられるべきです。 送付者が、伝えることの規律が最初に最も初期の内容(例えば、序数的に最も少ないFECブロック)のために修理されるのを観測するなら、送付者が物/流れ転送系列でそのポイントにもう一度戻るまで、受信機は後の内容に修理要求を差し控える戦略を使用できます。 これは、送付者と受信機の中でグループで総合的なメッセージ効率を増加させて、厳しい時間同期化で修理サイクルを保つのを依存なしで比較的連動していた状態で助けることができます。 これは、また、受信機と送付者のバッファリング要件を最小にするのを助けて、データの余分な伝達を全体のグループに抑えます。
Inputs:
入力:
1. Receiver NACK messages.
1. 受信機ナックメッセージ。
2. Group timing information.
2. タイミング情報を分類してください。
Outputs:
出力:
1. Repair messages (FEC and/or Data content retransmission).
1. メッセージ(FEC、そして/または、Data内容「再-トランスミッション」)を修理してください。
2. Advertisement of current pending repair transmissions when
unicast receiver feedback is detected.
2. ユニキャスト受信機フィードバックであるときに、現在の未定の修理送信の広告は検出されます。
Adamson, et al. Standards Track [Page 25] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[25ページ]。
3.3. Multicast Receiver Join Policies and Procedures
3.3. マルチキャスト受信機は方針と手順を接合します。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies that limit the opportunities for receivers to begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
新しい受信機が仲間に入って(恐らく信頼できるトランスミッションが既に進行しているところ)、修理を要求し始める方針と手順に対して考慮を払うべきです。 受信機が接合する、自由です、グループ会員資格の力学はデータ伝送の前進の進行の目標を達成するアプリケーションの能力を妨害するかもしれません。 受信機がナックの過程に参加し始める機会を制限する方針は、望まれた行動を達成するのに使用されるかもしれません。 例えば、受信機が単に流れの物か論理的な部分の最初のFECブロックでのデータの非修理送信のときに新たに聞かれた送付者からの信頼できるレセプションを試みるのは、有益であるかもしれません。 また、送付者はいくつかの状況におけるスケーラビリティ理由で禁止でしかし、それが受け入れる受信機を制限するナックが要求するこれが政策であるかもしれないことを実施するかもしれません。 あるいはまた、何人かのタイプのバルク転送アプリケーションにおける不十分な性能を引き起こす場合があるグループ・ダイナミックスを制限するために、よりゆるい輸送同期方針を持って、セッション管理メカニズムを当てにするのが望ましいかもしれない、(潜在的対話的な信頼できるマルチキャスト、アプリケーション)
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. データの信頼できるレセプションのための受信機はい/いいえの受信し始めるという決定とNACKing。
3.4. Node (Member) Identification
3.4. ノード(メンバー)識別
In a NACK-based reliable multicast protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers) within the group. Receivers that send NACK messages to the group will need to identify the sender to which the NACK is intended. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field SHOULD be present in packets transmitted by reliable multicast session members.
データの複数の源の可能性があるナックベースの信頼できるマルチキャストプロトコル(または、他のマルチキャストプロトコル)では、グループの中で唯一、ソース(そして、ことによるといくつかかすべての受信機)を特定するために何らかのメカニズムを提供するのが必要です。 グループへのメッセージをナックに送る受信機は、ナックが意図する送付者を特定する必要があるでしょう。 到着しているパケットソースアドレスに基づくアイデンティティはいくつかの理由で不十分です。 これらの理由は、ホストのために与えられたホストのための時間がたつにつれての異なったパケットソースアドレス、ネットワークアドレス変換(NAT)、ファイアウォール装置、または他の輸送/ネットワークの橋を架けることにおける結果がアプローチする複数のインタフェースで変化を発送するのを含んでいます。 その結果、ユニークなソース識別子<sourceId>のタイプは信頼できるマルチキャストによって伝えられたパケットでのプレゼントがセッションメンバーであったならSHOULDをさばきます。
Adamson, et al. Standards Track [Page 26] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[26ページ]。
3.5. Data Content Identification
3.5. データ内容識別
The data and repair content transmitted by a NACK-based reliable multicast sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/ reassembly, caching, integrated forward error correction coding, etc.) rather than being required to provide their own mechanisms for these functions at the application layer.
ナックベースの頼もしいマルチキャスト送付者によって送られたデータと修理内容はプロトコルヘッダーフィールドにおける、何らかの形式の識別を必要とします。 この識別が、信頼できるナック指向の修理の過程を容易にするのに必要です。 また、これらの識別子は発生するナックメッセージで使用されるでしょう。 このブロックドキュメントはバルク転送セッション内容を包括するかもしれない2つの非常に一般的なタイプに関するデータを仮定します。 1つのタイプが有限サイズの静的で、離散的な物です、そして、もう片方が連続した非有限な流れです。与えられたアプリケーションは、これらのパラダイムのどちらかか両方を使用することでマルチキャストデータ確かに満足していた状態でそうしたがっているかもしれません; いくつかのアプリケーションが流れの中で埋め込まれた内容として静的な物をカプセルに入れるためにさらにこのモデルを広めて、メカニズムを提供するのが、可能であるかもしれませんが、静的な大量の物とメッセージの異なったサポートを信頼できるマルチキャストセッションの文脈に提供する多くのアプリケーションにおける利点があります。 これらのアプリケーションは大量の内容でサーバ、ファイル転送、または協力的なツールをキャッシュする内容を含むかもしれません。 そして、それら自身のメカニズムをこれらの機能に提供するのが必要であるというよりもこれらの静的なオブジェクト・タイプのための要件があるアプリケーションは応用層でむしろ、トランスポート層メカニズム(すなわち、分割/再アセンブリ、キャッシュしていて、統合している前進型誤信号訂正コード化など)を利用できます。
As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-real-time message broadcasts (e.g., stock ticker) or some content types that are part of collaborative tools or other applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g., files) into one or more streams within a multicast session.
注意されるように、あるいはまた、いくつかのアプリケーションが、非有限なサイズの1つ以上の流れの形で大量の内容を伝えることを望むかもしれません。 例のストリームは連続した準リアルタイムのメッセージ放送(例えば、ストックチッカー)か協力的なツールか他のアプリケーションの一部である何人かの満足しているタイプを含んでいます。 そして、いくつかのアプリケーションがマルチキャストセッション以内に上で示されるように他の大量の内容(例えば、ファイル)を1つ以上の流れの中に要約したがっているかもしれません。
The components described within this building block document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast session. To support this requirement, the normal data content identification should include a field to uniquely identify the object or stream (e.g., <objectId>) within some reasonable temporal or ordinal interval. Note that it is not expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
このブロックドキュメントの中に説明されたコンポーネントは、ただ一つのマルチキャストセッション以内に両方のタイプのミックスの可能性でこれらのモデルの両方に適切になるように思い描かれます。 この要件を支持するなら、データの通常の内容識別は、いくつかの妥当な時の、または、序数の間隔以内に唯一、物か流れ(例えば、<objectId>)を特定するために分野を含むべきです。 このデータ内容識別がグローバルにユニークでなくなると予想されることに注意してください。 物/流れの識別子が信頼できるマルチキャストセッションと送付者がその物か流れの特定の輸送例を支持する時間与えられた送付者に関してユニークになると予想されます。
Since "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream
「大量」の物/流れの内容が通常分割を必要とするので、また、何らかの形式のセグメント識別を提供しなければなりません。 このセグメント識別子はどんな物や流れに比例しているでしょう。
Adamson, et al. Standards Track [Page 27] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[27ページ]。
identifier that has been provided. Thus, in some cases, NACK-based reliable multicast protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC, the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Basic Schemes building block [FECSchemes] and descriptions of additional FEC schemes that may be documented later provide a standard message format for identifying FEC transmission content. NACK-based reliable multicast protocol instantiations using FEC SHOULD follow such guidelines.
提供された識別子。 したがって、ナックベースの信頼できるマルチキャストプロトコル具体化は、平行な静的な物の複数の流れと1セット以上のためにトランスミッションを受けて、いくつかの場合、修理を要求できるかもしれません。 プロトコル具体化のために、FECを使って、データ内容識別子のセグメント識別部分はコード化ブロック識別子<sourceBlockNumber>の論理的な連結とコードブロックの特定のデータかパリティシンボル<encodingSymbolId>のための識別子から成るかもしれません。 後で記録されるかもしれない追加FEC計画のFEC Basic Schemesブロック[FECSchemes]と記述はFECトランスミッション内容を特定するための標準のメッセージ・フォーマットを提供します。 FEC 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 NACK-based reliable multicast protocol data content messages:
概要では、以下のデータ内容識別分野がデータのナックベースの信頼できるマルチキャストプロトコル内容メッセージに必要であるかもしれません:
1. Source node identifier (<sourceId>).
1. ソースノード識別子(<sourceId>)。
2. Object/Stream identifier (<objectId>), if applicable.
2. 物/流れの識別子(<objectId>)で、適切です。
3. FEC Block identifier (<sourceBlockNumber>), if applicable.
3. FEC Block識別子(<sourceBlockNumber>)で、適切です。
4. FEC Symbol identifier (<encodingSymbolId>).
4. FEC Symbol識別子(<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ビル単位でBlockをさばきます。
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data.
どんな発生しているナックメッセージも修理かデータの再伝送を要求する際にこれらの識別子を使用するので、これらの分野は特定されました。
3.6. Forward Error Correction (FEC)
3.6. 前進型誤信号訂正(FEC)
Multiple forward error correction (FEC) approaches using erasure coding techniques have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [FecBroadcast], [RmFec],
消去コーディング技法を使用する複数の前進型誤信号訂正(FEC)アプローチはこと特定されて、それはナック指向の、そして、他の信頼できるマルチキャストプロトコル[FecBroadcast]の修理の過程にかなりのパフォーマンス強化を提供できます、[RmFec]です。
Adamson, et al. Standards Track [Page 28] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[28ページ]。
[RFC3453]. NACK-based reliable multicast protocols can reap additional benefits since FEC-based repair does not generally require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NACK-based reliable multicast, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [FecHybrid]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large "delay*bandwidth" product with some nominal level of expected packet loss. While the application of FEC is not unique to NACK- based reliable multicast, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
[RFC3453]. NACK-based reliable multicast protocols can reap additional benefits since FEC-based repair does not generally require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NACK-based reliable multicast, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [FecHybrid]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large "delay*bandwidth" product with some nominal level of expected packet loss. While the application of FEC is not unique to NACK- based reliable multicast, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
A specific issue related to the use of FEC with NACK-based reliable multicast is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId:: sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [RFC5052] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
A specific issue related to the use of FEC with NACK-based reliable multicast is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId:: sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [RFC5052] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
3.7. Round-Trip Timing Collection
3.7. Round-Trip Timing Collection
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case of "one-to- many" transmission, it may be that only the sender requires RTT knowledge of the GRTT and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that each receiver in the group may need knowledge of its individual RTT. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender(s) and advertise them to the group or sender(s). Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case of "one-to- many" transmission, it may be that only the sender requires RTT knowledge of the GRTT and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that each receiver in the group may need knowledge of its individual RTT. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender(s) and advertise them to the group or sender(s). Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for
Adamson, et al. Standards Track [Page 29] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 29] RFC 5401 Multicast NACK BB November 2008
increased efficiency [DelayEstimation]. In some cases, there might be absolute time synchronization available among the participating hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various NACK timeouts used by receivers.
increased efficiency [DelayEstimation]. In some cases, there might be absolute time synchronization available among the participating hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various NACK timeouts used by receivers.
3.7.1. One-to-Many Sender GRTT Measurement
3.7.1. One-to-Many Sender GRTT Measurement
The goal of this form of RTT measurement is for the sender to estimate the GRTT among the receivers who are actively participating in NACK-based reliable multicast operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
The goal of this form of RTT measurement is for the sender to estimate the GRTT among the receivers who are actively participating in NACK-based reliable multicast operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
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:
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:
grttResponse = sendTime + (currentTime - recvTime)
grttResponse = sendTime + (currentTime - recvTime)
where the "<sendTime>" is the timestamp from the last probe message
received from the source and the ("<currentTime> - <recvTime>") is
the amount of time differential since that request was received until
the receiver generated the response.
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.
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:
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_rcvr = currentTime - grttResponse
RTT_rcvr = currentTime - grttResponse
During each periodic "GRTT" probing interval, the source keeps the
peak round-trip timing measurement ("RTT_peak") from the set of
responses it has received. A conservative estimate of "GRTT" is kept
During each periodic "GRTT" probing interval, the source keeps the peak round-trip timing measurement ("RTT_peak") from the set of responses it has received. A conservative estimate of "GRTT" is kept
Adamson, et al. Standards Track [Page 30] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 30] RFC 5401 Multicast NACK BB November 2008
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:
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:
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. 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:
GRTT = RTT_rcvr
GRTT = RTT_rcvr
2. At the end of the response collection period (i.e., the GRTT
probe interval), if the recorded "peak" response ("RTT_peak") is
less than the current GRTT estimate, the GRTT is updated to:
2. 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:
GRTT = MAX(0.9*GRTT, RTT_peak)
GRTT = MAX(0.9*GRTT, RTT_peak)
3. If no feedback is received, the sender "GRTT" estimate remains
unchanged.
3. If no feedback is received, the sender "GRTT" estimate remains unchanged.
4. At the end of the response collection period, the peak tracking
value ("RTT_peak") is reset to ZERO for subsequent peak
detection.
4. At the end of the response collection period, the peak tracking value ("RTT_peak") is reset to ZERO for subsequent peak detection.
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current estimate of GRTT (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. GRTT collection MAY also be coupled with collection of other information for congestion control purposes.
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current estimate of GRTT (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. GRTT collection MAY also be coupled with collection of other information for congestion control purposes.
In summary, although NACK repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not depend upon highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NACK-based reliable multicast protocols have been deployed to date. The estimate provided by the given algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
In summary, although NACK repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not depend upon highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NACK-based reliable multicast protocols have been deployed to date. The estimate provided by the given algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
Adamson, et al. Standards Track [Page 31] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 31] RFC 5401 Multicast NACK BB November 2008
3.7.2. One-to-Many Receiver RTT Measurement
3.7.2. One-to-Many Receiver RTT Measurement
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.
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.
3.7.3. Many-to-Many RTT Measurement
3.7.3. Many-to-Many RTT Measurement
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and senders "b" and "c", it is likely that:
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and senders "b" and "c", it is likely that:
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT with respect to a small subset of other group members and if information concerning RTT among those other group members is learned by the node during protocol operation.
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT with respect to a small subset of other group members and if information concerning RTT among those other group members is learned by the node during protocol operation.
3.7.4. Sender GRTT Advertisement
3.7.4. Sender GRTT Advertisement
To facilitate deterministic protocol operation, the sender should robustly advertise its current estimation of "GRTT" to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate
To facilitate deterministic protocol operation, the sender should robustly advertise its current estimation of "GRTT" to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate
Adamson, et al. Standards Track [Page 32] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 32] RFC 5401 Multicast NACK BB November 2008
to a single byte of information. The following C-language functions
allow this to be done over a wide range ("RTT_MIN" through "RTT_MAX")
of GRTT values while maintaining a greater range of precision for
small values and less precision for large values. Values of 1.0e-06
seconds and 1000 seconds are RECOMMENDED for "RTT_MIN" and "RTT_MAX"
respectively. NACK-based reliable multicast applications may wish to
place an additional, smaller upper limit on the GRTT advertised by
senders to meet application data delivery latency constraints at the
expense of greater feedback volume in some network environments.
to a single byte of information. The following C-language functions allow this to be done over a wide range ("RTT_MIN" through "RTT_MAX") of GRTT values while maintaining a greater range of precision for small values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for "RTT_MIN" and "RTT_MAX" respectively. NACK-based reliable multicast applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0 -
(13.0 * log(RTT_MAX/grtt)))));
}
unsigned char QuantizeGrtt(double grtt) { if (grtt > RTT_MAX) grtt = RTT_MAX; else if (grtt < RTT_MIN) grtt = RTT_MIN; if (grtt < (33*RTT_MIN)) return ((unsigned char)(grtt / RTT_MIN) - 1); else return ((unsigned char)(ceil(255.0 - (13.0 * log(RTT_MAX/grtt))))); }
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
double UnquantizeRtt(unsigned char qrtt) { return ((qrtt <= 31) ? (((double)(qrtt+1))*(double)RTT_MIN) : (RTT_MAX/exp(((double)(255-qrtt))/(double)13.0))); }
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NACK-based reliable multicast protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NACK-based reliable multicast protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
3.8. Group Size Determination/Estimation
3.8. Group Size Determination/Estimation
When NACK-based reliable multicast protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of any group size determination
When NACK-based reliable multicast protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of any group size determination
Adamson, et al. Standards Track [Page 33] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 33] RFC 5401 Multicast NACK BB November 2008
mechanism, a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. This conservative estimate (over-estimate) of group size in the algorithms described above will result in some added latency to the NACK repair process if the actual group size is smaller but with a guarantee of feedback implosion protection. The study of the timer-based feedback suppression mechanism described in [McastFeedback] and [NormFeedback] showed that the group size estimate need only be with an order-of-magnitude to provide effective suppression performance.
mechanism, a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. This conservative estimate (over-estimate) of group size in the algorithms described above will result in some added latency to the NACK repair process if the actual group size is smaller but with a guarantee of feedback implosion protection. The study of the timer-based feedback suppression mechanism described in [McastFeedback] and [NormFeedback] showed that the group size estimate need only be with an order-of-magnitude to provide effective suppression performance.
3.9. Congestion Control Operation
3.9. Congestion Control Operation
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] or Pragmatic General Multicast Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to NACK-based reliable multicast operation to meet this requirement. The former technique has been further documented in [RFC4654] and has been successfully applied in the NACK-Oriented Reliable Multicast Protocol (NORM) [RFC3940].
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] or Pragmatic General Multicast Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to NACK-based reliable multicast operation to meet this requirement. The former technique has been further documented in [RFC4654] and has been successfully applied in the NACK-Oriented Reliable Multicast Protocol (NORM) [RFC3940].
3.10. Intermediate System Assistance
3.10. Intermediate System Assistance
NACK-based multicast protocols may benefit from general purpose intermediate system assistance. In particular, additional NACK suppression where intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NACK-based reliable multicast protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Similarly, intermediate systems could monitor receiver NACKs and provide repair transmissions on-demand in response if sufficient state on the content being transmitted was being maintained. This can reduce the latency and volume of repair transmissions when the intermediate system is associated with a network link that is particularly problematic with respect to packet loss. These types of assist functions would require intermediate system interpretation of transport data unit content identifiers and flags. NACK-based protocol designs should consider the potential for intermediate system assistance in the specification of protocol messages and operations. It is likely that intermediate systems assistance will be more pragmatic if message parsing requirements are modest and if the amount of state an intermediate system is required to maintain is relatively small.
NACK-based multicast protocols may benefit from general purpose intermediate system assistance. In particular, additional NACK suppression where intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NACK-based reliable multicast protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Similarly, intermediate systems could monitor receiver NACKs and provide repair transmissions on-demand in response if sufficient state on the content being transmitted was being maintained. This can reduce the latency and volume of repair transmissions when the intermediate system is associated with a network link that is particularly problematic with respect to packet loss. These types of assist functions would require intermediate system interpretation of transport data unit content identifiers and flags. NACK-based protocol designs should consider the potential for intermediate system assistance in the specification of protocol messages and operations. It is likely that intermediate systems assistance will be more pragmatic if message parsing requirements are modest and if the amount of state an intermediate system is required to maintain is relatively small.
Adamson, et al. Standards Track [Page 34] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 34] RFC 5401 Multicast NACK BB November 2008
4. NACK-Based Reliable Multicast Applicability
4. NACK-Based Reliable Multicast Applicability
The Multicast NACK building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed NACK-based reliable multicast protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the multicast scalability property of NACK- based protocols [RmComparison], [RmClasses] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NACK- based reliable multicast protocols can make use of reciprocal (among senders and receivers) multicast communication under the any-source multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable of scalable operation in asymmetric topologies, such as source- specific multicast (SSM) [RFC4607], where there may only be unicast routing service from the receivers to the sender(s).
The Multicast NACK building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed NACK-based reliable multicast protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the multicast scalability property of NACK- based protocols [RmComparison], [RmClasses] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NACK- based reliable multicast protocols can make use of reciprocal (among senders and receivers) multicast communication under the any-source multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable of scalable operation in asymmetric topologies, such as source- specific multicast (SSM) [RFC4607], where there may only be unicast routing service from the receivers to the sender(s).
NACK-based reliable multicast protocol operation is compatible with transport layer forward error correction coding techniques as described in [RFC3453] and congestion control mechanisms such as those described in [TfmccPaper] and [PgmccPaper]. A principal limitation of NACK-based reliable multicast operation involves group size scalability when network capacity for receiver feedback is very limited. It is possible that, with proper protocol design, the intermediate system assistance techniques mentioned in Section 2.4 and described further in Section 3.10 can allow NACK-based approaches to scale to larger group sizes. NACK-based reliable multicast operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
NACK-based reliable multicast protocol operation is compatible with transport layer forward error correction coding techniques as described in [RFC3453] and congestion control mechanisms such as those described in [TfmccPaper] and [PgmccPaper]. A principal limitation of NACK-based reliable multicast operation involves group size scalability when network capacity for receiver feedback is very limited. It is possible that, with proper protocol design, the intermediate system assistance techniques mentioned in Section 2.4 and described further in Section 3.10 can allow NACK-based approaches to scale to larger group sizes. NACK-based reliable multicast operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
Prior experimental work included various protocol instantiations that implemented some of the concepts described in this building block document. This includes the Pragmatic General Multicast (PGM) protocol described in [RFC3208] as well as others that were documented or deployed outside of IETF activities. While the PGM protocol specification and some other approaches encompassed many of the goals of bulk data delivery as described here, this NACK-based building block provides a more generalized framework so that different application needs can be met by different protocol
Prior experimental work included various protocol instantiations that implemented some of the concepts described in this building block document. This includes the Pragmatic General Multicast (PGM) protocol described in [RFC3208] as well as others that were documented or deployed outside of IETF activities. While the PGM protocol specification and some other approaches encompassed many of the goals of bulk data delivery as described here, this NACK-based building block provides a more generalized framework so that different application needs can be met by different protocol
Adamson, et al. Standards Track [Page 35] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 35] RFC 5401 Multicast NACK BB November 2008
instantiation variants. The NACK-based building block approach described here includes compatibility with the other protocol mechanisms including FEC and congestion control that are described in other IETF reliable multicast building block documents. The NACK repair process described in this document can provide performance advantages compared to PGM when both are deployed on a pure end-to- end basis without intermediate system assistance. The round-trip timing estimation described here and its use in the NACK repair process allow protocol operation to more automatically adapt to different network environments or operate within environments where connectivity is dynamic. Use of the FEC payload identification techniques described in the FEC building block [RFC5052] and specific FEC instantiations allow protocol instantiations more flexibility as FEC techniques evolve than the specific sequence number data identification scheme described in the PGM specification. Similar flexibility is expected if protocol instantiations are designed to modularly invoke (at design time, if not run-time) the appropriate congestion control building block for different application or deployment purposes.
instantiation variants. The NACK-based building block approach described here includes compatibility with the other protocol mechanisms including FEC and congestion control that are described in other IETF reliable multicast building block documents. The NACK repair process described in this document can provide performance advantages compared to PGM when both are deployed on a pure end-to- end basis without intermediate system assistance. The round-trip timing estimation described here and its use in the NACK repair process allow protocol operation to more automatically adapt to different network environments or operate within environments where connectivity is dynamic. Use of the FEC payload identification techniques described in the FEC building block [RFC5052] and specific FEC instantiations allow protocol instantiations more flexibility as FEC techniques evolve than the specific sequence number data identification scheme described in the PGM specification. Similar flexibility is expected if protocol instantiations are designed to modularly invoke (at design time, if not run-time) the appropriate congestion control building block for different application or deployment purposes.
5. Security Considerations
5. Security Considerations
NACK-based reliable multicast protocols are expected to be subject to the same security vulnerabilities as other IP and IP multicast protocols. However, unlike point-to-point (unicast) transport protocols, it is possible that one badly behaving participant can impact the transport service experience of others in the group. For example, a malicious receiver node could intentionally transmit NACK messages to cause the sender(s) to unnecessarily transmit repairs instead of making forward progress with reliable transfer. Also, group-wise messaging to support congestion control or other aspects of protocol operation may be subject to similar vulnerabilities. Thus, it is highly RECOMMENDED that security techniques such as authentication and data integrity checks be applied for NACK-based reliable multicast deployments. Protocol instantiations using this building block MUST identify approaches to security that can be used to address these and other security considerations.
NACK-based reliable multicast protocols are expected to be subject to the same security vulnerabilities as other IP and IP multicast protocols. However, unlike point-to-point (unicast) transport protocols, it is possible that one badly behaving participant can impact the transport service experience of others in the group. For example, a malicious receiver node could intentionally transmit NACK messages to cause the sender(s) to unnecessarily transmit repairs instead of making forward progress with reliable transfer. Also, group-wise messaging to support congestion control or other aspects of protocol operation may be subject to similar vulnerabilities. Thus, it is highly RECOMMENDED that security techniques such as authentication and data integrity checks be applied for NACK-based reliable multicast deployments. Protocol instantiations using this building block MUST identify approaches to security that can be used to address these and other security considerations.
NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK-based protocols is that of NACK replay attacks, which could prevent a multicast sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. The IETF Multicast Security (MSEC) Working Group has developed a set of recommendations in its "Multicast Extensions to the Security Architecture for the Internet Protocol" [IpsecExtensions] that can be
NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK-based protocols is that of NACK replay attacks, which could prevent a multicast sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. The IETF Multicast Security (MSEC) Working Group has developed a set of recommendations in its "Multicast Extensions to the Security Architecture for the Internet Protocol" [IpsecExtensions] that can be
Adamson, et al. Standards Track [Page 36] RFC 5401 Multicast NACK BB November 2008
Adamson, et al. Standards Track [Page 36] RFC 5401 Multicast NACK BB November 2008
applied to appropriately extend IPsec mechanisms to multicast operation. An appendix of this document specifically addresses the NACK-Oriented Reliable Multicast protocol service model. As complete support for IPsec multicast operation may potentially follow reliable multicast deployment, NACK-based reliable multicast protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. This MAY be necessary when IPsec implementations are used that do not provide multicast replay attack protection when multiple sources are present.
applied to appropriately extend IPsec mechanisms to multicast operation. An appendix of this document specifically addresses the NACK-Oriented Reliable Multicast protocol service model. As complete support for IPsec multicast operation may potentially follow reliable multicast deployment, NACK-based reliable multicast protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. This MAY be necessary when IPsec implementations are used that do not provide multicast replay attack protection when multiple sources are present.
For NACK-based multicast deployments with large receiver groups using IPsec, approaches might be developed that use shared, common keys for receiver-originated protocol messages to maintain a practical number of IPsec Security Associations (SAs). However, such group-based authentication may not be sufficient unless the receiver population can be completely trusted. Additionally, this can make identification of badly behaving (although authenticated) receiver nodes problematic as such nodes could potentially masquerade as other receivers in the group. In deployments such as this, one SHOULD consider use of source-specific multicast (SSM) instead of any-source multicast (ASM) models of multicast operation. SSM operation can simplify security challenges in a couple of ways:
大きい受信機グループがIPsecを使用しているナックベースのマルチキャスト展開において、IPsec Security Associations(SAs)の実用的な数を維持する受信機で溯源されたプロトコルメッセージに共有されて、一般的なキーを使用するアプローチは開発されるかもしれません。 しかしながら、完全に受信機人口を信じることができるというわけではないなら、そのようなグループベースの認証は十分でないかもしれません。 さらに、これで、そのようなノードがグループで潜在的に他の受信機のふりをするかもしれないようにひどく振る舞っている(認証されますが)受信機ノードの識別は問題が多くなる場合があります。 の代わりにする、これなどの展開では、1SHOULDがソース特有のマルチキャスト(SSM)の使用を考える、いくらか、-、ソース、マルチキャスト操作のマルチキャスト(ASM)モデル。 SSM操作は2、3の方法でセキュリティ挑戦を簡素化できます:
1. A NACK-based protocol supporting SSM operation can eliminate
direct receiver-to-receiver signaling. This dramatically reduces
the number of security associations that need to be established.
1. SSMが操作であるとサポートするナックベースのプロトコルは受信機から受信機へのダイレクトシグナリングを排除できます。 これは設立される必要があるセキュリティ協会の数を劇的に減少させます。
2. The SSM sender(s) can provide a centralized management point for
secure group operation for its respective data flow as the sender
alone is required to conduct individual host authentication for
each receiver when group-based authentication does not suffice or
is not pragmatic to deploy.
2. グループベースの認証が十分でない、または配布するために実践的でないときに、送付者だけが各受信機のための個々のホスト認証を行わなければならないとき、SSM送付者はそれぞれのデータフローのために安全なグループ操作に集中的管理ポイントを提供できます。
When individual host authentication is required, then it is possible receivers could use a digital signature on the IPsec Encapsulating Security Protocol (ESP) payload as described in [RFC4359]. Either an identity-based signature system or a group-specific public key infrastructure could avoid per-receiver state at the sender(s). Additionally, implementations MUST also support policies to limit the impact of extremely or exceptionally poor-performing (due to bad behavior or otherwise) receivers upon overall group operation if this is acceptable for the relevant application.
個々のホスト認証が必要であると、可能な受信機が[RFC4359]で説明されるようにIPsec Encapsulating Securityプロトコル(超能力)ペイロードの上にデジタル署名を使用するかもしれないということです。 アイデンティティベースの署名システムかグループ特有の公開鍵認証基盤のどちらかが送付者で1受信機あたりの状態を避けるかもしれません。 また、さらに、実装が影響を制限する方針をサポートしなければならない、非常に、または、例外的に関連アプリケーションにおいて、これが許容できるなら、総合的なグループ操作での受信機を貧乏人と同じくらい実行します(悪い振舞いかそうでないため)。
As described in Section 3.4, deployment of NACK-based reliable multicast in some network environments may require identification of group members beyond that of IP addressing. If protocol-specific security mechanisms are developed, then it is RECOMMENDED that
セクション3.4で説明されるように、いくつかのネットワーク環境における、ナックベースの信頼できるマルチキャストの展開はIPアドレシングのものを超えてグループのメンバーの識別を必要とするかもしれません。 プロトコル特有のセキュリティー対策が開発されているならそれがRECOMMENDEDである、それ
Adamson, et al. Standards Track [Page 37] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[37ページ]。
protocol group member identifiers are used as selectors (as defined in [RFC4301]) for the applicable security associations. When IPsec is used, it is RECOMMENDED that the protocol implementation verify that the source IP addresses of received packets are valid for the given protocol source identifier in addition to usual IPsec authentication. This would prevent a badly behaving (although authorized) member from spoofing messages from other legitimate members, provided that individual host authentication is supported.
プロトコルグループメンバー識別子は適切なセキュリティ協会にセレクタ([RFC4301]で定義されるように)として使用されます。 IPsecが使用されているとき、プロトコル実装が、普通のIPsec認証に加えた与えられたプロトコルソース識別子に、容認されたパケットのソースIPアドレスが有効であることを確かめるのは、RECOMMENDEDです。 これによって、ひどく振る舞っている(認可されますが)メンバーは他の正統のメンバーからメッセージを偽造することができないでしょう、個々のホスト認証がサポートされれば。
The MSEC Working Group has also developed automated group keying solutions that are applicable to NACK-based reliable multicast security. For example, to support IPsec or other security mechanisms, the Group Secure Association Key Management Protocol [RFC4535] MAY be used for automated group key management. The technique it identifies for "Group Establishment for Receive-Only Members" may be application NACK-based reliable multicast SSM operation.
また、MSEC作業部会はナックベースの信頼できるマルチキャストセキュリティに適切なソリューションを合わせる自動化されたグループを発展させました。 例えば、IPsecか他のセキュリティがメカニズムであるとサポートするために、Group Secure Association Key Managementプロトコル[RFC4535]は自動化されたグループ重要管理に使用されるかもしれません。 それが「受信専用メンバーのためのグループ設立」のために特定するテクニックはアプリケーションのナックベースの信頼できるマルチキャストSSM操作であるかもしれません。
6. Changes from RFC 3941
6. RFC3941からの変化
This section lists the changes between the Experimental version of this specification, [RFC3941], and this version:
このセクションはこの仕様のExperimentalバージョンと、[RFC3941]と、このバージョンの間の変化を記載します:
1. Change of title to avoid confusion with NORM Protocol
specification,
1. NORMプロトコル仕様への混乱を避けるタイトルの変化
2. Updated references to related, updated RMT Building Block
documents, and
2. そして関連して、アップデートされたRMTビルBlockドキュメントの参照をアップデートした。
3. More detailed security considerations.
3. 以上はセキュリティ問題を詳しく述べました。
7. Acknowledgements
7. 承認
(and these are not Negative)
(これらはNegativeではありません)
The authors would like to thank George Gross, Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
作者はこのドキュメントの彼らの貴重なコメントについてジョージGross、リック・ジョーンズ、およびヨルク・ウィトマーに感謝したがっています。 また、作者はこの仕様の開発における彼らのサポート、およびこのドキュメントへの彼女の早めの入力のためのサリー・フロイドについてRMTワーキンググループいす(ロジャー・カーモードとロレンツォVicisano)に感謝したがっています。
Adamson, et al. Standards Track [Page 38] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[38ページ]。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1112] Deering, S., "Host extensions for IP
multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific
Multicast for IP", RFC 4607, August 2006.
[RFC4607] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、2006年8月。
8.2. Informative References
8.2. 有益な参照
[ArchConsiderations] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of
Protocols", Proc. ACM SIGCOMM, pp. 201-208,
September 1990.
[ArchConsiderations] クラークとD.とD.Tennenhouse、「プロトコルの新しい世代建築問題」、Proc。 ACM SIGCOMM、ページ 201-208と、1990年9月。
[DelayEstimation] Ozdemir, V., Muthukrishnan, S., and I. Rhee,
"Scalable, Low-Overhead Network Delay
Estimation", NCSU/AT&T White Paper,
February 1999.
[DelayEstimation] OzdemirとV.とMuthukrishnan、S.とI.Rhee、「スケーラブルで、低いオーバーヘッドのネットワーク遅延見積り」、NCSU/AT&T白書、1999年2月。
[FECSchemes] Watson, M., "Basic Forward Error Correction
(FEC) Schemes", Work in Progress, July 2008.
「基本的な前進型誤信号訂正(FEC)体系」という[FECSchemes]ワトソン、M.は進歩、2008年7月に働いています。
[FecBroadcast] Metzner, J., "An Improved Broadcast
Retransmission Protocol", IEEE Transactions on
Communications Vol. Com-32, No. 6, June 1984.
[FecBroadcast] Metzner、J.、「改良された放送Retransmissionプロトコル」、コミュニケーションVol.Com-32、No.6、1984年6月に関するIEEEトランザクション。
[FecHybrid] Gossink, D. and J. Macker, "Reliable Multicast
and Integrated Parity Retransmission with
Channel Estimation", IEEE Globecomm 1998, 1998.
[FecHybrid]GossinkとD.とJ.Macker、「チャネル推定がある信頼できるマルチキャストの、そして、統合しているパリティRetransmission」IEEE Globecomm1998、1998。
[FecSchemes] Lacan, J., Roca, V., Peltotalo, J., and S.
Peltotalo, "Reed-Solomon Forward Error
Correction (FEC) Schemes", Work in Progress,
November 2007.
[FecSchemes]ラカン、J.、ロカ、V.、J.、およびS.Peltotalo、「リード-ソロモンの前進型誤信号訂正(FEC)体系」というPeltotaloは進行中(2007年11月)で働いています。
[IpsecExtensions] Weis, B., Gross, G., and D. Ignjatic,
"Multicast Extensions to the Security
Architecture for the Internet Protocol", Work
in Progress, June 2008.
G.、およびD.Ignjatic、「インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡大」というウィス、B.が利益を上げる[IpsecExtensions]は、進行中(2008年6月)で働いています。
Adamson, et al. Standards Track [Page 39] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[39ページ]。
[McastFeedback] Nonnenmacher, J. and E. Biersack, "Optimal
Multicast Feedback", IEEE Infocom p. 964,
March/April 1998.
[McastFeedback] NonnenmacherとJ.とE.Biersack、「最適のマルチキャストフィードバック」、IEEE Infocom p。 964 1998年3月/4月。
[NormFeedback] Adamson, B. and J. Macker, "Quantitative
Prediction of NACK-Oriented Reliable Multicast
(NORM) Feedback", IEEE MILCOM 2002,
October 2002.
[NormFeedback]アダムソンとB.とJ.Macker、「ナック-Orientedの信頼できるマルチキャスト(標準)フィードバックの量的な予測」、IEEE MILCOM2002、2002年10月。
[PgmccPaper] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate
Multicast Congestion Control Scheme", ACM
SIGCOMM 2000, August 2000.
[PgmccPaper] リゾー、L.は「以下をpgmccします」。 「TCPに優しい単一賃率マルチキャスト輻輳制御体系」、ACM SIGCOMM2000、2000年8月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V.
Paxson, "IETF Criteria for Evaluating Reliable
Multicast Transport and Application Protocols",
RFC 2357, June 1998.
[RFC2357] マンキン、A.、ロマーノフ、A.、ブラドナー、S.、およびV.パクソン、「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J.,
Farinacci, D., Lin, S., Leshchiner, D., Luby,
M., Montgomery, T., Rizzo, L., Tweedly, A.,
Bhaskar, N., Edmonstone, R., Sumanasekera, R.,
and L. Vicisano, "PGM Reliable Transport
Protocol Specification", RFC 3208,
December 2001.
[RFC3208] Speakman、T.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、Luby、M.、モンゴメリ、T.、リゾー、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL.Vicisano、「PGMの信頼できる輸送プロトコル仕様」、RFC3208(2001年12月)。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines
for Reliable Multicast Transport (RMT) Building
Blocks and Protocol Instantiation documents",
RFC 3269, April 2002.
[RFC3269] カーモード、R.、およびL.Vicisanoは「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、2002年4月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M., and J. Crowcroft, "The Use of
Forward Error Correction (FEC) in Reliable
Multicast", RFC 3453, December 2002.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453(2002年12月)。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J.
Macker, "Negative-acknowledgment (NACK)-
Oriented Reliable Multicast (NORM) Protocol",
RFC 3940, November 2004.
[RFC3940] アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ.Macker、「否定応答(ナック)--信頼できるマルチキャスト(標準)プロトコルを適応する」RFC3940(2004年11月)。
[RFC3941] Adamson, B., Bormann, C., Handley, M., and J.
Macker, "Negative-Acknowledgment (NACK)-
Oriented Reliable Multicast (NORM) Building
Blocks", RFC 3941, November 2004.
[RFC3941] アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ.Macker、「否定応答(ナック)--信頼できるマルチキャスト(標準)ブロックを適応する」RFC3941(2004年11月)。
Adamson, et al. Standards Track [Page 40] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[40ページ]。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for
the Internet Protocol", RFC 4301,
December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures
within Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4359,
January 2006.
[RFC4359] ウィス、B.、「セキュリティが有効搭載量であるとカプセル化する中のRSA/SHA-1署名(超能力)と認証ヘッダー(ああ)の使用」、RFC4359(2006年1月)。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G.
Gross, "GSAKMP: Group Secure Association Key
Management Protocol", RFC 4535, June 2006.
[RFC4535] ハーニー、H.、メタンフェタミン、U.、コールグローブ、A.、およびG.グロス、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、2006年6月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly
Multicast Congestion Control (TFMCC): Protocol
Specification", RFC 4654, August 2006.
[RFC4654] ウィトマー、J.、およびM.ハンドレー、「TCPに優しいマルチキャスト混雑は(TFMCC)を制御します」。 「プロトコル仕様」、RFC4654、2006年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward
Error Correction (FEC) Building Block",
RFC 5052, August 2007.
[RFC5052] ワトソンとM.とLuby、M.とL.Vicisano、「前進型誤信号訂正(FEC)ブロック」、RFC5052、2007年8月。
[RmClasses] Levine, B. and J. Garcia-Luna-Aceves, "A
Comparison of Known Classes of Reliable
Multicast Protocols", Proc. International
Conference on Network Protocols (ICNP-
96) Columbus, OH, October 1996.
[RmClasses] レヴィンとB.とJ.ガルシアルーナAceves、「知られているクラスの信頼できるマルチキャストプロトコルの比較」、Proc。 おお、1996年10月のネットワーク・プロトコル(ICNP96)コロンブスに関する国際会議。
[RmComparison] Pingali, S., Towsley, D., and J. Kurose, "A
Comparison of Sender-Initiated and Receiver-
Initiated Reliable Multicast Protocols", Proc.
INFOCOMM San Francisco, CA, October 1993.
[RmComparison] Pingali、S.、Towsley、D.、およびJ.黒瀬、「送付者によって開始されるのと受信機の開始している信頼できるマルチキャストプロトコルの比較」、Proc。 INFOCOMMサンフランシスコ(カリフォルニア)1993年10月。
[RmFec] Macker, J., "Reliable Multicast Transport and
Integrated Erasure-based Forward Error
Correction", IEEE MILCOM 1997, October 1997.
[RmFec] Mackerと、J.と、「信頼できるマルチキャスト輸送と統合消去ベースの前進型誤信号訂正」、IEEE MILCOM1997、10月1997日
[SrmFramework] Floyd, S., Jacobson, V., McCanne, S., Liu, C.,
and L. Zhang, "A Reliable Multicast Framework
for Light-weight Sessions and Application Level
Framing", Proc. ACM SIGCOMM, August 1995.
[SrmFramework] フロイド、S.、ジェーコブソン、V.、McCanne、S.、リュウ、C.、およびL.チャン、「軽量のセッションとアプリケーションレベル縁どりのための信頼できるマルチキャストフレームワーク」、Proc。 1995年8月のACM SIGCOMM。
[TfmccPaper] Widmer, J. and M. Handley, "Extending Equation-
Based Congestion Control to Multicast
Applications", ACM SIGCOMM 2001, August 2001.
[TfmccPaper] ウィトマーとJ.とM.ハンドレー、「方程式のベースの輻輳制御をマルチキャストアプリケーションに広げています」、ACM SIGCOMM2001、2001年8月。
Adamson, et al. Standards Track [Page 41] RFC 5401 Multicast NACK BB November 2008
アダムソン、他 規格はマルチキャストナック掲示板2008年11月にRFC5401を追跡します[41ページ]。
Authors' Addresses
作者のアドレス
Brian Adamson Naval Research Laboratory Washington, DC 20375
ブライアン・アダムソン・海軍研究試験所のワシントン、DC 20375
EMail: adamson@itd.nrl.navy.mil
メール: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
EMail: cabo@tzi.org
メール: cabo@tzi.org
Mark Handley University College London Gower Street London, WC1E 6BT UK
マーク・ハンドレー・ユニバーシティ・カレッジロンドンガウアー・ストリートロンドン、WC1E 6BTイギリス
EMail: M.Handley@cs.ucl.ac.uk
メール: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
ジョー・Macker海軍研究試験所のワシントン、DC 20375
EMail: macker@itd.nrl.navy.mil
メール: macker@itd.nrl.navy.mil
Adamson, et al. Standards Track [Page 42]
アダムソン、他 標準化過程[42ページ]
一覧
スポンサーリンク
