RFC2887 日本語訳
2887 The Reliable Multicast Design Space for Bulk Data Transfer. M.Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. August 2000. (Format: TXT=51135 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley
Request for Comments: 2887 S. Floyd
Category: Informational ACIRI
B. Whetten
Talarian
R. Kermode
Motorola
L. Vicisano
Cisco
M. Luby
Digital Fountain, Inc.
August 2000
コメントを求めるワーキンググループM.ハンドレー要求をネットワークでつないでください: 2887秒間フロイドCategory: 情報のACIRIのM.Luby Digital噴水Inc.B.Whetten Talarian R.カーモードモトローラL.Vicisanoコクチマス2000年8月
The Reliable Multicast Design Space for Bulk Data Transfer
バルク・データ転送のための信頼できるマルチキャストデザインスペース
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions.
多くの可能なソリューションが工夫された状態で、信頼できるマルチキャストのためのデザインスペースは豊かです。 しかしながら、アプリケーション要件は、比較的小さいソリューションスペースにこのデザインスペースを抑制するのに役立ちます。 このドキュメントはアプリケーション規制が可能なソリューションに影響するデザインスペースと方法の概要を提供します。
1. Introduction
1. 序論
The term "general purpose reliable multicast protocol" is something of an oxymoron. Different applications have different requirements of a reliable multicast protocol, and these requirements constrain the design space in ways that two applications with differing requirements often cannot share a single solution. There are however many successful reliable multicast protocol designs that serve more special purpose requirements well.
「汎用の信頼できるマルチキャストプロトコル」という用語はある種の撞着語法です。 異なったアプリケーションには、信頼できるマルチキャストプロトコルの異なった要件があります、そして、これらの要件は異なった要件があるその2つのアプリケーションがしばしばただ一つのソリューションを共有できるというわけではない方法でデザインスペースを抑制します。 しかしながら、より専用である要件によく役立つ多くのうまくいっている信頼できるマルチキャストプロトコルデザインがあります。
In this document we attempt to review the design space for reliable multicast protocols intended for bulk data transfer. The term bulk data transfer should be taken as having broad meaning - the main limitations are that the data stream is continuous and long lived -
本書では私たちは、バルク・データ転送のために意図する信頼できるマルチキャストプロトコルのためにデザインスペースを見直すのを試みます。 用語バルク・データ転送は広い意味を持っているとみなされるべきです--主な制限がデータ・ストリームが連続し長い間送られるということである、-
Handley, et al. Informational [Page 1] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[1ページ]のRFC2887マルチキャストデザインスペース
constraints necessary for the forms of congestion control we currently understand. The purpose of this review is to gather together an overview of the field and to make explicit the constraints imposed by particular mechanisms. The aim is to provide guidance to the standardization process for protocols and protocol building blocks. In doing this, we cluster potential solutions into a number of loose categories - real protocols may be composed of mechanisms from more than one of these clusters.
私たちが現在理解している輻輳制御のフォームに必要な規制。 このレビューの目的は、分野の概要を集めて、特定のメカニズムによって課された規制を明白にすることです。目的はプロトコルとプロトコルブロックのために指導を標準化過程に提供することです。 これをする際に、私たちは多くのゆるいカテゴリに潜在的ソリューションをクラスタリングさせます--本当のプロトコルはこれらのクラスタの1つ以上からメカニズムで構成されるかもしれません。
The main constraint on solutions is imposed by the need to scale to large receiver sets. For small receiver sets the design space is much less restricted.
ソリューションにおける主な規制は大きい受信機セットに比例する必要性によって課されます。 小さい受信機セットにおいて、まして、デザインスペースは制限されます。
2. Application Constraints
2. アプリケーション規制
Application requirements for reliable multicast (RM) are as broad and varied as the applications themselves. However, there are a set of requirements that significantly affect the design of an RM protocol. A brief list includes:
信頼できるマルチキャスト(RM)のためのアプリケーション要件は、アプリケーション自体と同じくらい広くて、同じくらい様々です。 しかしながら、RMプロトコルのデザインにかなり影響する1セットの要件があります。 簡潔なリストは:
o Does the application need to know that everyone received the data?
o アプリケーションは、皆がデータを受信したのを知る必要がありますか?
o Does the application need to constrain differences between
receivers?
o アプリケーションは、受信機の違いを抑制する必要がありますか?
o Does the application need to scale to large numbers of receivers?
o アプリケーションは、多くの受信機に比例する必要がありますか?
o Does the application need to be totally reliable?
o アプリケーションは、完全に信頼できる必要がありますか?
o Does the application need ordered data?
o アプリケーションは規則正しいデータを必要としますか?
o Does the application need to provide low-delay delivery?
o アプリケーションは、低い遅延配送を提供する必要がありますか?
o Does the application need to provide time-bounded delivery?
o アプリケーションは、時間で境界がある配送を提供する必要がありますか?
o Does the application need many interacting senders?
o アプリケーションは、送付者に相互作用しながら、多くを必要としますか?
o Is the application data flow intermittent?
o アプリケーションデータフローは間欠ですか?
o Does the application need to work in the public Internet?
o アプリケーションは、公共のインターネットで働く必要がありますか?
o Does the application need to work without a return path (e.g.
satellite)?
o アプリケーションは、リターンパス(例えば、衛星)なしで働く必要がありますか?
o Does the application need to provide secure delivery?
o アプリケーションは、安全な配送を提供する必要がありますか?
Handley, et al. Informational [Page 2] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[2ページ]のRFC2887マルチキャストデザインスペース
In the context of standardizing bulk data transfer protocols, we can rule out applications with multiple interacting senders and intermittent data flows. It is not that these applications are unimportant, but that we do not yet have effective congestion control for such applications.
大量のデータ転送プロトコルを標準化することの文脈では、私たちは複数の相互作用している送付者と間欠データフローがあるアプリケーションを除外できます。 これらのアプリケーションが重要でなくはありませんが、私たちにはそのようなアプリケーションのための有効な輻輳制御がまだないということです。
2.1. Did everyone receive the data?
2.1. 皆はデータを受信しましたか?
In many applications a logically defined unit or units of data is to be delivered to multiple clients, e.g., a file or a set of files, a software package, a stock quote or package of stock quotes, an event notification, a set of slides, a frame or block from a video. An application data unit (ADU) is defined to be a logically separable unit of data that is useful to the application. In some cases, an application data unit may be short enough to fit into a single packet (e.g., an event notification or a stock quote), whereas in other cases an application data unit may be much longer than a packet (e.g., a software package).
多くのアプリケーションでは、論理的に定義されたユニットかユニットのデータは複数のクライアントに提供されることです、ストックの例えば、ファイル、1セットのファイル、ソフトウェアパッケージ、株価またはパッケージが引用します、イベント通知、ビデオからスライド、フレームまたは1ブロックの1セット。 アプリケーションデータ単位(ADU)は、アプリケーションの役に立つデータの論理的に分離できるユニットになるように定義されます。 いくつかの場合、アプリケーションデータ単位が単一のパケット(例えば、イベント通知か株価)に収まることができるくらい短いかもしれませんが、アプリケーションデータ単位は他の場合がパケット(例えば、ソフトウェアパッケージ)よりはるかに長いかもしれません。
A protocol may optionally provide delivery confirmation to ensure reliable delivery, i.e., a mechanism for receivers to inform the sender when data has been delivered. There are two types of confirmation, at the application data unit level and at the packet level. Application data unit confirmation is useful at the application level, e.g., to inform the application about receiver progress and to decide when to stop sending packets about a particular application data unit. Packet confirmation is useful at the transport level, e.g., to inform the transport level when it can release buffer space being used for storing packets for which delivery has been confirmed.
プロトコルは、信頼できる配信(すなわち、受信機が、データがいつ提供されたかを送付者に知らせるメカニズム)を確実にするために任意に配送確認を提供するかもしれません。 データ単位が平らにするアプリケーションにおいてパケット・レベルにおいて確認の2つのタイプがあります。 アプリケーションデータユニット確認は、例えば受信機進歩に関するアプリケーションを知らせて、特定用途データ単位に関してパケットを送るのをいつ止めるかを決めるためにアプリケーションレベルで役に立ちます。 パケット確認は、例えばそれがいつ配送が確認されたパケットを保存するのに使用されることでバッファ領域をリリースできるかを輸送レベルに知らせるために輸送レベルで役に立ちます。
Some applications have a strong requirement for confirmation that all the receivers got an ADU, or if not, to be informed of which specific receivers failed to receive the entire ADU. Examples include applications where receivers pay for data, and reliable file-system replication. Other applications do not have such a requirement. An example is the distribution of free software.
いくつかのアプリケーションには、確認のためのすべての受信機がADUを手に入れたか、またはそうでなければ、どの特定の受信機に知識があるかが全体のADUを受け取らなかったという強い要件があります。 例は受信機がデータの代価を払うアプリケーション、および信頼できるファイルシステム模写を含んでいます。 他のアプリケーションには、そのような要件がありません。 例はフリーソフトウェアの分配です。
If the application does need to know that every receiver got the ADU, then a positive acknowledgment must be received from every receiver, although it may be possible to aggregate these acknowledgments. If the application needs to know precisely which receivers failed to get the ADU, additional constraints are placed on acknowledgment aggregation.
アプリケーションが、あらゆる受信機がADUを手に入れたのを知る必要があるなら、あらゆる受信機から肯定応答を受けなければなりません、これらの承認に集めるのが可能であるかもしれませんが。 アプリケーションが、どの受信機がADUを手に入れなかったかを正確に知る必要があるなら、追加規制は承認集合に置かれます。
It should be noted that different mechanisms can be used for ADU- level confirmation and packet-level confirmation in the same application. For example, an ADU-level confirmation mechanism using
同じアプリケーションにおけるADUの平らな確認とパケット・レベル確認に異なったメカニズムを使用できることに注意されるべきです。 例えば、ADU-レベル確認メカニズム使用
Handley, et al. Informational [Page 3] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[3ページ]のRFC2887マルチキャストデザインスペース
positive acknowledgments may sit on top of a packet-level NACK or FEC-based transport. Typically this only makes sense when ADUs are significantly larger than a single packet.
肯定応答はパケット・レベルナックかFECベースの輸送の上に座るかもしれません。 ADUsが単一のパケットよりかなり大きいときにだけ、通常、これは理解できます。
2.2. Constraining differences
2.2. 違いを抑制します。
Some applications need to constrain differences between receivers so that the data reception characteristics for all receivers falls within some range. An example is a stock price feed, where it is unacceptable for a receiver to suffer delivery that is delayed significantly more than any other receiver.
いくつかのアプリケーションが、受信機の違いを抑制する必要があるので、いくつか中のすべての受信機滝へのデータ受信の特性は及びます。 例は株価給送です、受信機がさらにかなり遅れる配送を受けるのが、いかなる他の受信機よりも容認できないところで。
This requirement is difficult to satisfy without harming performance. Typically solutions involve not sending more than a limited amount of new data until positive acknowledgments have been received from all the receivers. Such a solution does not cope with network and end- system failures well.
この要件は性能に害を及ぼさないで満たすのが難しいです。 通常、ソリューションは、新しいデータの数量限定よりすべての受信機から肯定応答を受けるまで発信することを伴いません。 そのようなソリューションはネットワークと終わりのシステム障害をよく切り抜けません。
2.3. Receiver Set Scaling
2.3. 受信機セットスケーリング
There are many applications for RM that do not need to scale to large numbers of receivers. For such applications, a range of solutions may be available that are not available for applications where scaling to large receiver sets is a requirement.
多くの受信機に比例する必要はないRMにおける多くの利用があります。 そのようなアプリケーションに、さまざまなソリューションが利用可能であるかもしれません。それは大きい受信機セットに比例するのが、要件であるアプリケーションに利用可能ではありません。
A protocol must achieve good throughput of application data units to receivers. This means that most data that is delivered to receivers is useful in recovering the application data unit that they are trying to receive. A protocol must also provide good congestion control to fairly share the available network resources between all applications. Receiver set scaling is one of the most important constraints in meeting these requirements, because it strictly limits the mechanisms that can be used to achieve these requirements to those that will efficiently scale to a large receiver population. Acknowledgement packets have been employed by many systems to achieve these goals, but it is important to understand the strength and limitations of different ways of using such packets.
プロトコルはアプリケーションデータ単位の良い効率を受信機に実現しなければなりません。 これは、受信機に提供されるほとんどのデータが彼らが受けようとしているアプリケーションデータ単位を回復する際に役に立つことを意味します。 また、プロトコルは、すべてのアプリケーションの間の利用可能なネットワーク資源を公正に共有するために良い輻輳制御を提供しなければなりません。 比例するように設定された受信機はこれらの必要条件を満たすのにおいて最も重要な規制の1つです、厳密に、効率的に大きい受信機人口に比例するものにこれらの要件を達成するのに使用できるメカニズムを制限するので。 確認応答パケットは多くのシステムによって使われて、これらの目標を達成しましたが、そのようなパケットを使用する異なった方法の強さと制限を理解しているのは重要です。
In a very small system, it may be acceptable to have the receivers acknowledge every packet. This approach provides the sender with the maximum amount of information about reception conditions at all the receivers, information that can be used both to achieve good throughput and to achieve congestion control.
非常に小さいシステムでは、受信機にあらゆるパケットを承認させるのは、許容できるかもしれません。 このアプローチは、ともに良い効率を達成して、輻輳制御を達成するためにすべての受信機のレセプション状態、使用できる情報に関する最大の情報量を送付者に提供します。
Handley, et al. Informational [Page 4] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[4ページ]のRFC2887マルチキャストデザインスペース
For larger systems, such "flat ACK" schemes cause acknowledge implosions at the sender. Attempts have been made to reduce this problem by sending aggregate ACKs infrequently [RMWT98, BC94], but it is very difficult to incorporate effective congestion control into such protocols because of the spareceness of feedback.
より大きいシステムのために、体系が引き起こすそのような「平坦なACK」は送付者で内部破裂を承諾します。 送付の集合ACKsでこの問題をまれに[RMWT98、BC94]減少させるのを試みをしましたが、フィードバックのsparecenessのために有効な輻輳制御をそのようなプロトコルに組み入れるのは非常に難しいです。
Using negative acknowledgments (NACKs) instead of ACKs reduces this problem to one of NACK implosion (only from the receivers missing the packets), and because the sender really only needs to know that at least one receiver is missing data in order to achieve good throughput, various NACK suppression mechanisms can be applied.
ACKsの代わりに否定応答(NACKs)を使用すると、この問題はナックの内部破裂(単にパケットを逃す受信機からの)について1まで減少します、そして、送付者が、本当に少なくとも1台の受信機が良い効率を達成する欠測値であることを知る必要があるだけであるので、様々なナック抑圧メカニズムは適用できます。
An alternative to NACKs is ACK aggregation, which can be done by arranging the receivers into a logical tree, so that each leaf sends ACKs to its parent which aggregates them, and passes them on up the tree. Tree-based protocols scale well, but tree formation can be problematic.
NACKsへの代替手段はACK集合です、各葉が親への彼らに集めるACKsを送って、彼らを木に伝えるように。(論理的な木に受信機をアレンジすることによって、それをできます)。 木のベースのプロトコルはよく比例しますが、木の構成は問題が多い場合があります。
Other ACK topologies such as rings are also possible, but are often more difficult to form and maintain than trees are. An alternative strategy is to add mechanisms to routers so that they can help out in achieving good throughput or in reducing the cost of achieving good throughput.
リングなどの他のACK topologiesはまた、可能ですが、形成して、維持するのは木よりしばしば難しいです。 代替の戦略は良い効率を達成するか、または良い効率を達成するコストを削減する際に助けることができるようにルータにメカニズムを加えることです。
All these solutions improve receiver set scaling, but they all have limits of one form or another. One class of solutions scales to an infinite number of receivers by having no feedback channel whatsoever in order to achieve good throughput. These open-loop solutions take the initial data and encode it using an FEC-style mechanism. This encoded data is transmitted in a continuous stream. Receivers then join the session and receive packets until they have sufficient packets to decode the original data, at which point they leave the session.
これらのすべてのソリューションが比例するように設定された受信機を改良しますが、それらには皆、何らかのフォームの限界があります。 フィードバックチャンネルが良い効率を達成するために全くないことによって、1つのクラスのソリューションは無限の数の受信機に比例します。 これらの転々流通ソリューションは、FEC-スタイルメカニズムを使用することで初期のデータを取って、それをコード化します。 このコード化されたデータは連続したストリームで送られます。 それらにはオリジナルのデータを解読できるくらいのパケットがあるまで、受信機は、次に、セッションに参加して、パケットを受けます、それらがセッションを残すどのポイントで。
Thus, it is clear that the intended scale of the session constrains the possible solutions. All solutions will work for very small sessions, but as the intended receive set increases, the range of possible solutions that can be deployed safely decreases.
したがって、セッションの意図しているスケールが可能なソリューションを抑制するのは、明確です。 すべてのソリューションが、非常に小さいセッションの間働いていますが、意図としてセット増加を受け取って、安全に配布することができる可能なソリューションの範囲は減少します。
It should also be noted that hybrids of these mechanisms are possible, and that using one mechanism at the packet-level and a different (typically higher overhead) solution at the ADU level may also scale reasonably if the ADUs are large compared to packets.
また、パケットと比べて、ADUsが大きいなら、これらのメカニズムのハイブリッドが可能であり、また、パケット・レベルと異なった(通常高いオーバーヘッド)ソリューションに1つのメカニズムをADUレベルに使用するのが合理的に比例するかもしれないことに注意されるべきです。
Handley, et al. Informational [Page 5] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[5ページ]のRFC2887マルチキャストデザインスペース
2.4. Total vs Semi-reliable
2.4. 合計対準信頼できる
Many applications require delivery of application data units to be totally reliable; if any of the application data unit is missing, none of the received portion of the application data unit is useful. File transfer applications are a good example of applications requiring total reliability.
多くのアプリケーションが、アプリケーションデータ単位の配送が完全に信頼できるのを必要とします。 アプリケーションデータ単位のどれかがなくなるなら、アプリケーションデータ単位の容認された部分のいずれも役に立ちません。 ファイル転送アプリケーションは総信頼性を必要とするアプリケーションの好例です。
However, some applications do not need total reliability. An example is audio broadcasting, where missing packets reduce the quality of the received audio but do not render it unusable. Such applications can sometimes get by without any additional reliability over native IP reliability, but often having a semi-reliable multicast protocol is desirable.
しかしながら、いくつかのアプリケーションは総信頼性を必要としません。 例はオーディオ放送です、なくなったパケットが容認されたオーディオの品質を減少させますが、それを使用不可能にしないところで。 そのようなアプリケーションはネイティブのIPの信頼性の上で少しも追加信頼性なしで時々なんとかやっていくことができますが、しばしば準信頼できるマルチキャストプロトコルを持っているのは望ましいです。
2.5. Time-bounded Delivery
2.5. 時間で境界がある配送
Many applications just require data to be delivered to the receivers as fast as possible. They have no absolute deadline for delivery.
多くのアプリケーションが、データができるだけ速く受信機に提供されるのをただ必要とします。 彼らは配送のためのどんな絶対締め切りも過しません。
However, some applications have hard delivery constraints - if the data does not arrive at the receiver by a certain time, there is no point in delivering it at all. Such time-boundedness may be as a result of real-time constraints such as with audio or video streaming, or as the result of new data superseding old data. In both cases, the requirement is for the application to have a greater degree of control over precisely what the application sends at which time than might be required with applications such as file transfer.
しかしながら、いくつかのアプリケーションには、難産規制があります--データが、ある時間までに受信機に到着しないなら、それを全く提供する意味が全くありません。 そのような時間有界性はオーディオやビデオ・ストリーミングなどのリアルタイムの規制の結果、新しいデータが古いデータに取って代わるという結果としてあるかもしれません。 どちらの場合も、要件はアプリケーションにはアプリケーションがどの時に正確に何を送るかの、より大きい度合いのコントロールがファイル転送などの応用で必要とされるかもしれないよりあることです。
Time-bounded delivery usually also implies a semi-reliable protocol, but the converse does not necessarily hold.
また、時間で境界がある配送は通常準信頼できるプロトコルを含意しますが、逆は必ず成立するというわけではありません。
3. Network Constraints
3. ネットワーク規制
The properties of the network in which the application is being deployed may themselves constrain the reliable multicast design space.
アプリケーションが配布されているネットワークの特性がそうするかもしれない、自分たち、信頼できるマルチキャストデザインスペースを抑制してください。
3.1. Internet vs Intranet
3.1. インターネット対イントラネット
In principle the Internet and intranets are the same. In practice however, the fact that an intranet is under one administration might allow for solutions to be configured that can not easily be done in the public Internet. Thus, if the data is of very high value, it might be appropriate to enhance the routers to provide assistance to a reliable multicast transport protocol. In the public Internet, it is less likely that the additional expense required to support this state in the routers would be acceptable.
原則として、インターネットとイントラネットは同じです。 しかしながら、実際には、イントラネットが1つ未満の管理であるという事実は公共のインターネットで容易にできない構成されるべきソリューションを考慮するかもしれません。 したがって、データに非常に高い価値があるなら、信頼できるマルチキャストトランスポート・プロトコルに対する支援を提供するためにルータを高めるのは適切であるかもしれません。 公共のインターネットでは、ルータでこの状態をサポートするのに必要である追加費用が許容できるのは、それほどありそうではありません。
Handley, et al. Informational [Page 6] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[6ページ]のRFC2887マルチキャストデザインスペース
3.2. Return Path
3.2. リターンパス
In principle, when feedback is required from receivers, this feedback can be multicast or unicast. Multicast feedback has advantages, especially in NACK-based protocols where it is valuable for NACK suppression. However, it is not clear at this time whether all ISPs will allow all members of a session to send to that session. If multicast feedback is not allowed, then unicast feedback can almost always be substituted, although often at the expense of additional messages and mechanisms.
フィードバックが受信機から必要であるときに、原則として、このフィードバックは、マルチキャストかユニキャストであるかもしれません。 マルチキャストフィードバックは特にナックの抑圧に、それが貴重であるナックベースのプロトコルにおいてうま味があります。 しかしながら、セッションのすべてのメンバーがすべてのISPでそのセッションまで発信できるかどうかは、このとき、明確ではありません。 マルチキャストフィードバックを許さないなら、しばしばですが、追加メッセージとメカニズムを犠牲にしてユニキャストフィードバックをほとんどいつも代入できます。
Some networks may not allow any form of feedback however. The primary example of this occurs with satellite broadcasts where the back channel may be very narrow or even non-existent. For such networks the solution space is very constrained - only FEC-based encodings have any real chance of working. If the receivers are direct satellite receivers, then no congestion control is needed, but it is dangerous to make such assumptions because it is possible for a satellite hop to feed downstream networks. Thus, congestion control still needs to be considered with solutions that do not have a return path.
しかしながら、どんなフォームのフィードバックも許さないネットワークもあるかもしれません。衛星放送が戻っているチャンネルが非常に狭いか、または実在しなくさえあるかもしれないところにある状態で、このプライマリ例は現れます。 そのようなネットワークにおいて、ソリューションスペースは非常に強制的です--FECベースのencodingsだけには、働いているというどんな本当の機会もあります。 受信機がダイレクト衛星電波受信装置であるなら、輻輳制御は全く必要ではありませんが、衛星ホップが川下のネットワークに食べさせるのが、可能であるので、そのような仮定をするのは危険です。 したがって、輻輳制御は、まだリターンパスを持っていないソリューションで考えられる必要があります。
3.3. Network Assistance
3.3. ネットワーク支援
A reliable multicast protocol must involve mechanisms running in end hosts, and must involve routers forwarding multicast packets. However under some circumstances, it is possible to rely on some additional degree of assistance from network elements. Broadly speaking we can cluster RM protocols into four classes depending on the degree of support received from other network elements.
信頼できるマルチキャストプロトコルは、終わりのホストへ駆け込むメカニズムにかかわらなければならなくて、マルチキャストパケットを進めるルータにかかわらなければなりません。 しかしながら、いくつかの状況で、ネットワーク要素から何らかの追加度合いの支援に依存するのは可能です。 概して私たちは他のネットワーク要素から受けられたサポートの度合いに依存する4つのクラスにRMプロトコルをクラスタリングさせることができます。
No Additional Support
The routers merely forward packets, and only the sender and
receivers have any reliable multicast protocol state.
ルータが単にパケット、送付者、および受信機だけを送るどんなAdditional Supportもどんな信頼できるマルチキャストプロトコル状態も持っていません。
Layered Approaches
Data is split across multiple multicast groups. Receivers join
appropriate groups to receive only the traffic they require. This
may in some cases require fast join or leave functionality from
the routers, and may require more forwarding state in the routers.
層にされたApproaches Dataは複数のマルチキャストグループの向こう側に分割されます。 受信機は、彼らが必要とするトラフィックだけを受けるために適切なグループに加わります。 ルータから機能性を速く接合するか、または外して、ルータで、より多くの推進状態を必要とするかもしれませんいくつかの場合、これが、必要であるかもしれない。
Server-based Approaches
Additional nodes are used to assist with data delivery or feedback
aggregation. These additional nodes might not be normal senders
or receivers, and may be present on the distribution or feedback
tree only to provide assistance to the reliable multicast
protocol. They would not otherwise receive the multicast traffic.
サーバベースのApproaches Additionalノードは、データ配送かフィードバック集合を助けるのに使用されます。 これらの追加ノードは、信頼できるマルチキャストプロトコルに対する支援を提供するためだけに普通の送付者か受信機でないかもしれなく、分配かフィードバック木に存在しているかもしれません。 そうでなければ、彼らはマルチキャストトラフィックを受けないでしょう。
Handley, et al. Informational [Page 7] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[7ページ]のRFC2887マルチキャストデザインスペース
Router-based Approaches
With router-based approaches, routers on the normal data
distribution tree from the sender to the receivers assist in the
delivery of data or feedback aggregation or suppression. As
routers can directly influence multicast routing, they have more
control over which traffic goes to which group members than
server-based approaches. However routers do not normally have a
large amount of spare memory or processing power, which restricts
how much functionality can be placed in the routers. In addition,
router code is normally more difficult to upgrade than application
code, so router-based approaches need to be very general as they
are more difficult to deploy and to change.
ルータベースのApproaches Withルータベースのアプローチ、送付者から受信機までの正常な情報配給木の上のルータはデータ、フィードバック集合または抑圧の配送を助けます。 ルータが直接マルチキャストルーティングに影響を及ぼすことができるように、それらにはサーバベースのアプローチよりトラフィックがどのグループのメンバーのものになるコントロールがあります。 ルータにどのようにを制限する多量の予備メモリか処理能力がどのように通常なくても、多くの機能性をルータに置くことができます。 さらに、通常、ルータコードはアップグレードさせるのが応用コードより難しいです、非常にルータベースであるので、アプローチは、配布して、変えるのが、より難しいので非常に一般的である必要があります。
4. Good Throughput Mechanisms
4. 良いスループットメカニズム
Two main concerns that a RM protocol must address are congestion control and good throughput. Packet loss plays a major role with respect to both concerns. The primary symptom of congestion in many networks is packet loss. The primary obstacle that must be overcome to achieve good throughput is packet loss. Thus, measuring and reacting to packet loss is crucial to address both concerns. RM solutions that address these concerns can be roughly categorized as using one or more of the following techniques:
RMプロトコルが扱わなければならない2回の主な関心事が、輻輳制御と良い効率です。 パケット損失は両方の関心に関して大きな役割を果たします。 多くのネットワークの混雑のプライマリ兆候はパケット損失です。 良い効率を達成するので克服しなければならないプライマリ障害はパケット損失です。 したがって、パケット損失に測定して、反応するのは、両方の関心を扱うために重要です。 以下のテクニックの1つ以上を使用するとして手荒くこれらの関心を扱うRMソリューションは分類できます:
o Data packet acknowledgment.
o データ・パケット承認。
o Negative acknowledgment of missing data packets.
o 欠測値パケットの否定応答。
o Redundancy allowing not all packets to be received.
o すべてのパケットが受け取られるというわけではないのを許容する冗長。
These techniques themselves can be usefully subdivided, so that we can examine the parts of the requirement space in which each mechanism can be deployed. In this section, we focus on using these mechanisms for achieving good throughput, and in the next section we focus on using these mechanisms for congestion control.
有効にこれらのテクニック自体を細分できます、私たちが各メカニズムを配布することができる要件スペースの地域を調べることができるように。 このセクションでは、私たちは、良い効率を達成する、および私たちが焦点を合わせる次のセクションのこれらのメカニズムを使用するのは輻輳制御にこれらのメカニズムを使用することで焦点を合わせます。
4.1. ACK-based Mechanisms
4.1. ACKベースのメカニズム
The simplest ACK-based mechanism involves every receiver sending an ACK packet for every data packet it receives and resending packets that are lost by any receiver. Such mechanisms are limited to very small receiver groups by the implosion of ACKs received at the sender, and for this reason they are impractical for most applications.
最も簡単なACKベースのメカニズムはそれが受けるあらゆるデータ・パケットのためにACKパケットを送って、どんな受信機によっても失われているパケットを再送するあらゆる受信機にかかわります。そのようなメカニズムは送付者に受け取られたACKsの内部破裂、およびほとんどのアプリケーションに、彼らが非実用的であるこの理由で非常に小さい受信機グループに制限されます。
Handley, et al. Informational [Page 8] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[8ページ]のRFC2887マルチキャストデザインスペース
Putting multiple ACKs into a single data packet [RMWT98] reduces the implosion problem by a constant amount, allowing slightly larger receiver groups. However a limit is soon reached whereby feedback to the sender is too infrequent for sender-based congestion control mechanisms to work reliably.
単一のデータ・パケット[RMWT98]に複数のACKsを入れると、内部破裂問題は一定の量で減少します、わずかに大きい受信機グループを許容して。 しかしながら、送付者へのフィードバックが送付者ベースの混雑制御機構が確かに扱うことができないくらい珍しい限界にすぐ、達しています。
Arranging the receivers into a ring [WKM94] whereby an "ACK-token" is passed around the ring prevents the implosion problem for data. However ring creation and maintenance may itself be problematic. Also if ring creation does not take into account network topology (something which is difficult to achieve in practice), then the number of ACK packets crossing the network backbone for each data packet sent may increase O(n) with the number of receivers.
「ACK-トークン」がリングの周りで通過されるリング[WKM94]に受信機をアレンジすると、内部破裂問題はデータのために防がれます。 しかしながら、リング作成とメインテナンスがそうするかもしれない、それ自体、問題が多くいてください。 また、リング作成がネットワーク形態実際には達成するのが(何か難しいもの)を考慮に入れないなら、各データ・パケットが発信したので、受信機の数に従って、ネットワーク基幹を越えるACKパケットの数はO(n)を増強するかもしれません。
4.1.1. Tree-based ACK Mechanisms
4.1.1. 木のベースのACKメカニズム
Arranging the receivers into a tree [MWB+98, KCW98] whereby receivers generate ACKs to a parent node, which aggregates those ACKs to its parent in turn, is both more robust and more easily configured than a ring. The ACK-tree is typically only used for ACK-aggregation - data packets are multicast from the sender to the receivers as normal. Trees are easier to construct than rings because more local information can be used in their construction. Also they can be more fault tolerant than rings because node failures only affect a subset of receivers, each of which can easily and locally decide to by-pass its parent and report directly to the node one level higher in the tree. With good ACK-tree formation, tree-based ACK mechanisms have the potential to be one of the most scalable RM solutions.
受信機が順番に親へのそれらのACKsに集める親ノードにACKsを生成する木[MWB+98、KCW98]に受信機をアレンジするのは、リングより強健で、かつ容易に構成されています。 ACK-木はACK-集合に通常使用されるだけです--送付者から正常な同じくらい受信機までデータ・パケットはマルチキャストです。 木はそれらの構造によりローカルの情報を使用できるので鳴るより組み立てやすいです。 また、ノード障害が、受信機の部分集合のふりをするだけであり、木では、1つのレベルが、より高いと直接ノードに報告するので、それらもリングよりフォルト・トレラントである場合があります。それのそれぞれが受信機のために親を無視すると簡単に局所的に決めることができます。 良いACK-木の構成によって、木のベースのACKメカニズムには、最もスケーラブルなRMソリューションの1つである可能性があります。
To be simple to deploy, tree-based protocols must be self-organizing - the receivers must form the tree themselves using local information in a scalable manner. Such mechanisms are possible, but are not trivial. The main scaling limitations of tree-based protocols therefore come from the tree formation and maintenance mechanisms rather than from the use of ACKs. Without such a scalable and automatic tree-formation mechanism, tree-based protocols must rely on manual configuration, which significantly limits their applicability (often to intranets) and (due to the complexity of configuration) their scalability.
配布するのが簡単であるように、木のベースのプロトコルは自己組織化でなければなりません--受信機はスケーラブルな方法によるローカルの情報を使用することで自分たちで木を形成しなければなりません。 そのようなメカニズムは、可能ですが、些細ではありません。 したがって、木のベースのプロトコルの主なスケーリング制限は木の構成とACKsの使用からというよりむしろメインテナンスメカニズムから来ます。 そのようなスケーラブルで自動である木構成メカニズムがなければ、木のベースのプロトコルは手動の構成、どれが彼らの適用性(しばしばイントラネットへの)をかなり制限するか、そして、およびそれらの(構成の複雑さによる)スケーラビリティを当てにしなければなりません。
Orthogonal to the issue of tree formation is the issue of subtree retransmission. With appropriate router mechanisms, or the use of multiple multicast groups, it is possible to allow the intermediate tree nodes to retransmit missing data to the nodes below them in the tree rather than relying on the original sender to retransmit the data. This relies on there being a good correlation at the point of the intermediate node between the ACK tree and the actual data tree, as well as there being a mechanism to constrain the retransmission to
木の構成の問題と直交しているのは、下位木「再-トランスミッション」の問題です。 適切なルータメカニズム、または複数のマルチキャストグループの使用では、中間的木のノードがデータを再送するために元の送り主に頼るよりむしろ木のそれらの下のノードに欠測値を再送するのを許容するのは可能です。 これは、良い相関関係であるのでACK木と実際のデータ木の間の中間的ノードのポイントでそこを当てにして、「再-トランスミッション」を抑制するメカニズムでありそこで当てにします。
Handley, et al. Informational [Page 9] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[9ページ]のRFC2887マルチキャストデザインスペース
the subtree. A good automatic tree formation mechanism combined with the use of administrative scoped multicast groups might provide such a solution. Without such tree formation mechanisms, subtree retransmission is difficult to deploy in large groups in the public internet. This could also be solved by the use of transport- level router mechanisms to assist or perform retransmission, although existing router mechanisms [FLST98] support NACK-based rather than ACK-based protocols.
下位木。 管理見られたマルチキャストグループの使用に結合された良い自動木の構成メカニズムはそのような解決法を提供するかもしれません。 そのような木の構成メカニズムがなければ、下位木「再-トランスミッション」は公共のインターネットにおける大きいグループで配布するのが難しいです。 また、「再-トランスミッション」を補助するか、または実行するために輸送の平らなルータメカニズムの使用でこれを解決できるでしょう、既存のルータメカニズム[FLST98]はACKベースであるというよりむしろナックベースのプロトコルをサポートしますが。
Another important issue is the nature of the aggregation performed at interior nodes on the ACK-tree. Such nodes could:
別の切迫した課題は内部のノードでACK-木に実行された集合の本質です。 そのようなノードはそうすることができました:
1. aggregate ACKs by sending a single ACK when all their children
have ACKed,
1. 彼らのすべての子供がACKedを持っているとき独身のACKを送ることによって、ACKsに集めてください。
2. aggregate ACKs by listing all the children that have ACKed,
2. ACKedを持っているすべての子供を記載することによって、ACKsに集めてください。
3. send an aggregated ACK with a NACK-like exception list.
3. ナックのような免責摘要表がある集められたACKを送ってください。
For data packets, 1. is clearly more scalable, and should be preferred. However if the sender needs to know exactly which receivers received the data, 2. and 3. provide this information. Fortunately, there is usually no need to do this on a per-packet basis, but rather on a per-ADU basis. Doing 1. on a per packet basis, and 3. on a per ADU basis is the most scalable solution for applications that need this information, and suffers virtually no disadvantage compared to the other solutions used on a per-packet basis.
データ・パケットに関しては、1は、明確にスケーラブルであり、好まれるべきです。 2 3 しかしながら、送付者が、どの受信機がデータを受信したかをまさに知る必要があるなら、この情報を提供してください。 幸い、1パケットあたり1個のベースにもかかわらず、むしろ1ADUあたり1個のベースでこれをする必要は全く通常ありません。 1パケット基礎あたりのa、および3に、1パケットあたり1個のベースで使用される他のソリューションにたとえられなかった不都合は、全くADU基礎あたりのaでは、この情報を必要とするアプリケーションのための最もスケーラブルなソリューションであり、実際には苦しんでいます。
4.2. NACK-based mechanisms
4.2. ナックベースのメカニズム
Instead of sending an ACK for every data packet received, receivers can send a negative acknowledgment (NACK) for every data packet they discover they did not receive. This has a number of advantages over ACK-based mechanisms:
あらゆるデータ・パケットのためのACKが受けた発信の代わりに、受信機はそれらが、彼らが受けたというわけではないと発見するあらゆるデータ・パケットのために(ナック)を否定応答に送ることができます。 これには、ACKベースのメカニズムより多くの利点があります:
o The sender no longer needs to know exactly how many receivers
there are. This removes the topology-building phase needed for
ring- or tree-style ACK-based algorithms.
o 送付者は、もうちょうどいくつの受信機があるかを知る必要はありません。 これはリングか木スタイルのACKベースのアルゴリズムに必要であるトポロジーを造るフェーズを取り除きます。
o Fault-tolerance is made somewhat simpler by making receivers
responsible for reliability.
o 受信機を信頼性に責任があるようにすることによって、耐障害性をいくらか簡単にします。
o Sender state can be significantly reduced because the sender does
not need to keep track of the receivers state.
o 送付者が受信機状態の動向をおさえる必要はないので、送付者状態はかなり減少できます。
Handley, et al. Informational [Page 10] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[10ページ]のRFC2887マルチキャストデザインスペース
o Only a single NACK is needed from any receiver to indicate a
packet that is missing by any number of receivers. Thus NACK
suppression is possible.
o 独身のナックだけが、いろいろな受信機でなくなったパケットを示すのにどんな受信機からも必要です。 したがって、ナックの抑圧は可能です。
The disadvantages are that it is more difficult for the sender to know that it can free transmission buffers, and that additional session level mechanisms are needed if the sender really needs to know if a particular receiver actually received all the data. However for many applications, neither of these is an issue.
損失は送付者が、トランスミッションバッファを解放できて、送付者が、本当に特定の受信機が実際にすべてのデータを受け取ったかどうかを知る必要があるならセッションの追加レベルメカニズムが必要であることを知るのが、より難しいということです。 しかしながら、多くのアプリケーションのために、これらのどちらも問題ではありません。
4.2.1. NACK Suppression
4.2.1. ナックSuppression
The key differences between NACK-based protocols is in how NACK- suppression is performed. The goal is for only one NACK to reach the sender (or a node that can resend the missing data) as soon as possible after the loss is first noticed, and for only one copy of the missing data to be received by those nodes needing retransmission.
ナックベースのプロトコルの主要な違いがナックの抑圧がどう実行されるかであります。 目標は損失の後にできるだけ早く送付者(または、欠測値を再送できるノード)に届くナックが1だけのために、最初に気付かれていて、それらのノードによって受け取られるべき欠測値のコピー1部だけに「再-トランスミッション」を必要としているということです。
Different mechanisms come close to satisfying these goals in different ways.
異なった方法でこれらの目標を満たす近くで異なったメカニズムは来ます。
o SRM [FJM95] uses random timers weighted by the round trip time
between the sender and each node missing the data. This is
effective, but requires computing the RTT to each receiver before
suppression works properly.
o SRM[FJM95]は、データを逃しながら、送付者と各ノードの間で周遊旅行時間までに荷重している無作為のタイマを使用します。 これは、有効ですが、抑圧が適切に働く前に各受信機にRTTを計算するのを必要とします。
o NTE [HC97] uses a sender-triggered mechanism based on random keys
and sliding masks. This does not require random timers, and works
for very large sessions, but makes it difficult to provide the
constant low-level stream of feedback needed to perform congestion
control.
o ランダムキーとマスクを滑らせることに基づいてNTE[HC97]は送付者によって引き起こされたメカニズムを使用します。 これで、無作為のタイマを必要としないで、非常に大きいセッションの間働いていますが、輻輳制御を実行するのに必要であるフィードバックの一定の低レベルである流れを供給するのは難しくなります。
o AAP [Ha99] uses exponentially distributed random timers and is
effective for large sessions without needing to compute the RTT to
each receiver.
o 各受信機にRTTを計算する必要はなくて、AAP[Ha99]は指数関数的に分配された無作為のタイマを使用して、大きいセッションに有効です。
o PGM [FLST98] and LMS [PPV98] use additional mechanisms in routers
to suppress duplicate NACKs. In the case of PGM, router
assistance suppliments SRM-stype random timers and localizes the
suppression so that the whole group does not need suppressing.
o PGM[FLST98]とLMS[PPV98]は、写しNACKsを抑圧するのにルータに追加メカニズムを使用します。 そして、PGMに関するケース、ルータの支援のsuppliments SRM-stypeの無作為のタイマ、全体のグループが抑圧する必要はないように、抑圧を局所化します。
The most general of these mechanisms is probably exponentially weighted random timers. Although SRM style timers can reduce feedback delay, they are harder to use correctly in situations where all the RTTs are not known, or where the number of respondees is
これらのメカニズムで最も一般的なことはたぶん指数関数的に荷重している無作為のタイマです。 SRMスタイルタイマはフィードバック遅れを減少させることができますが、すべてのRTTsが知られているというわけではないか、または「再-強強格」の数がある状況でそれらは正しくより使用しにくいです。
Handley, et al. Informational [Page 11] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[11ページ]のRFC2887マルチキャストデザインスペース
unknown. In contrast, exponentially weighted random timers work well across a large range of session sizes with good worst case delay characteristics.
未知。 対照的にと、指数関数的に荷重している無作為のタイマは良い最悪の場合遅れの特性に従った広範囲なセッションサイズの向こう側にうまくいきます。
Either form of random timer based mechanism can be supplemented by router-support where it is available. Sender triggered NACK mechanisms (e.g. [HC97]) are more difficult to integrate with router-based support mechanisms.
それが利用可能であるところでルータサポートでどちらかのフォームの無作為のタイマに基づいているメカニズムを補うことができます。 送付者の引き起こされたナックメカニズム(例えば、[HC97])はルータベースのサポートメカニズムと統合するのが、より難しいです。
4.3. Replication
4.3. 模写
Some RM protocols can be designed so as to not need explicit reliability mechanisms except in comparatively rare cases. An example is in a multicast game, where the position of a moving object is continuously multicast. This positional stream does not require additional reliability because a new position superseding the old one will be sent before any retransmission could take place. However, when the moving object interacts with other objects or stops moving, then an explicit reliability mechanism is required to reliably send the interaction information or last position.
いくつかのRMプロトコルが、比較的まれなケース以外に、明白な信頼性のメカニズムを必要としないように設計される場合があります。 例は動く物の位置が絶え間なく勝負事をするところでマルチキャストでは、マルチキャストが勝負事をしているということです。 どんな「再-トランスミッション」も行われることができる前に古い方に取って代わる新しい位置を送るので、この位置の流れは追加信頼性を必要としません。 しかしながら、動く物が、他の物と対話するか、または動くのを止めると、そして、明白な信頼性のメカニズムが、確かに相互作用情報を送るか、または位置を持続するのに必要です。
It is not just games that can be built in this manner - the NTE shared text editor[HC97] uses just such a mechanism with changes to a line of text. For every change the whole line is sent, and so long as the user keeps typing no explicit reliability mechanism is needed. The major advantage of replication is that it is not susceptible to spatially uncorrelated packet loss. With a traditional ACK or NACK based protocol, the probability of any particular packet being received by all the receivers in a large group can be very low. This leads to high retransmission rates. In contrast, replicated streams do not suffer as the size of the receiver group increases - different receivers lose different packets, but this does not increase network traffic.
それはこの様に組み込むことができるゲームであるだけではありません--共有されたテキストエディタ[HC97]とまさしくそのようなメカニズムを使用するNTEはテキスト行に変化します。 あらゆる変化に関しては、全体の線を送ります、そして、ユーザがタイプし続ける限り、どんな明白な信頼性のメカニズムも必要としません。 それが空間的に影響されやすくない模写の主要な利点があります。非相関パケット損失。 伝統的なACKかナックに基づいているプロトコルで、すべての受信機によって大きいグループで受け取られるどんな特定のパケットの確率も非常に低い場合があります。 これは高い「再-トランスミッション」レートに通じます。 対照的に、受信機グループのサイズが増加するのに従って、模写された流れに苦しみません--異なった受信機は異なったパケットを失いますが、これはネットワークトラフィックを増加させません。
4.4. Packet-level Forward Error Correction
4.4. パケット・レベル前進型誤信号訂正
Forward Error Correction (FEC) is a well known technique for protecting data against corruption. For reliable multicast it is most useful in the form of erasure codes.
前方に、Error Correction(FEC)は、不正に対してデータを保護するためのよく知られているテクニックです。 信頼できるマルチキャストに、それは消去コードの形で最も役に立ちます。
The simplest form of packet-level FEC is to take a group of packets that is to be sent, and to XOR the packets together to form a newpacket which is also sent. If there were three original packets plus the XOR packet sent, then if a receiver is missing any one of the original data packets, but receives the XOR packet, then it can reproduce the missing original packet.
パケット・レベルFECの最も簡単なフォームが送られることになっているパケットのグループを取ることであり、XORへの形成するために一緒にいるパケットはまた、送られるnewpacketです。 3つのオリジナルのパケットがあって、XORパケットが発信したなら、受信機がオリジナルのデータ・パケットのどれかを逃していますが、XORパケットを受けるなら、それはなくなったオリジナルのパケットを再生させることができます。
Handley, et al. Informational [Page 12] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[12ページ]のRFC2887マルチキャストデザインスペース
More general erasure codes exist [BKKKLZ95], [Ri97], [LMSSS97] that allow the generation of n encoding packets from k original data packets. In such cases, so long as at least k of the n encoding packets are received, then the k original data packets can be reproduced.
より一般的な消去コードは存在しています[BKKKLZ95]、[Ri97]、kオリジナルのデータ・パケットからパケットをコード化しながらnの世代を許容する[LMSSS97。] パケットが受け取られている、次に、kオリジナルのデータ・パケットが再生できるように少なくともnコード化のkと同じくらいそのような場合、そして、同じくらい長さ。
To apply FEC the sender groups data packets into rounds, and encoding packets are produced based on all the data packets in a round. A round may consist of all data packets in an entire application data unit in some cases, whereas in other cases it may consist of a group of data packets that make up only a small portion of an application data unit.
FECを適用するために、送付者はデータ・パケットをラウンドに分類します、そして、コード化パケットはラウンドにおけるすべてのデータ・パケットに基づいて作り出されます。 ラウンドはいくつかの場合全体のアプリケーションデータ単位のすべてのデータ・パケットから成るかもしれませんが、他の場合では、それはアプリケーションデータ単位の少量だけを作るデータ・パケットのグループから成るかもしれません。
Using erasure codes to repair packet loss is a significant improvement over simple retransmission because the dependency on which packets have been lost is removed. Thus, the amount of repair traffic required to repair spatially uncorrelated packet loss is considerably lessened.
パケットが失われた依存を取り除くので、パケット損失を修理するのに消去コードを使用するのは、簡単な「再-トランスミッション」の上のかなりの改善です。 したがって、交通が非相関パケット損失を空間的に修理するのを必要とした修理の量はかなり少なくされます。
We can divide packet-level FEC schemes into two categories: proactive FEC and reactive FEC. The difference between the two is that for proactive FEC the sender decides a priori how many encoding packets to send for each round of data packets, whereas for reactive FEC the sender initially transmits only the original data packets for each round. Then, the sender uses feedback from the receivers to compute how many packets were lost by the receiver that experienced the most loss in each round, and then only that number of additional encoding packets are sent for that round. These encoding packets will then also serve to repair loss at the other receivers that are missing fewer packets. The receivers report via ACKs or NACKs how many packets are missing from each round. With NACKs, only the receiver missing the most packets need send a NACK for this round, so this is used to weight the random timers in the NACK calculation.
私たちはパケット・レベルFEC計画を2つのカテゴリに分割できます: FECと反応FECを予測してください。 2の違いは先を見越すFECに関して、送付者が、データ・パケットの各丸さのためにいくつのコード化パケットを送るかを先験的に決めるということですが、反応FECに関して、送付者は初めは、各丸さのためにオリジナルのデータ・パケットだけを伝えます。 そして、送付者は追加コード化パケットの数がいくつのパケットが各ラウンドにおける最も多くの損失を経験した受信機によって失われたか、そして、その時専用ですが、そんなにぐるりと呼びにやられて、計算する受信機からフィードバックを使用します。 そして、また、パケットをコード化するこれらは、より少ないパケットを逃している他の受信機で損失を修理するのに役立つでしょう。 受信機は、ACKsかNACKsを通して何パケットが各ラウンドによってなくなると報告します。 ナックが最も多くのパケットを逃す受信機だけで行かなければならないので、この丸さのためにNACKsと共に、これはナックの計算で無作為のタイマに重みを加えるのに使用されます。
Proactive and reactive FEC can be combined, e.g., a certain amount of proactive FEC can be sent for each round and if there are receivers that experience more loss than can be overcome by this for some rounds then they can request and receive additional encoding packets for these rounds.
先を見越して反応しているFECを結合できて、各丸さのために例えば先を見越すFECのある量を送ることができて、これが数ラウンドのために打ち勝つことができるより多くの損失を経験する受信機があれば、彼らは、これらのラウンドのために追加コード化パケットを要求して、受けることができます。
FEC is very effective at reducing the repair traffic for packet loss. However, it requires that the data to be sent to be grouped into rounds, which can add to end-to-end latency. For bulk-data applications this is typically not a problem, but this may be an issue for interactive applications where replication may be a better solution.
FECはパケット損失のための修理交通を抑えるところで非常に効果的です。 しかしながら、それは、送られるデータがラウンドに分類されるのを必要とします。(ラウンドは終わりから終わりへの潜在に加えることができます)。 大量のデータアプリケーションのための、通常問題ではありませんが、これは模写が、より良い解決策であるかもしれない対話型アプリケーションのための問題であるかもしれません。
Handley, et al. Informational [Page 13] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[13ページ]のRFC2887マルチキャストデザインスペース
4.5. Layered FEC
4.5. 層にされたFEC
An alternative use of packet level FEC is possible when data is spread across several multicast groups [RVC98], [BLMR98]. In such cases, the original k data packets are used to generate n encoding packets, where n is much larger than k. The n encoded packets are then striped across multiple multicast groups. When a receiver wishes to receive the original data it joins one or more of the multicast groups, and receives the encoding packets. Once it has received k different encoding packets, the receiver can then leave all the multicast groups and reconstruct the original data.
[BLMR98]、データがいくつかのマルチキャストグループ[RVC98]の向こう側に広げられるとき、パケット・レベルFECの代替の使用は可能です。 そのような場合、オリジナルのkデータ・パケットは、パケットをコード化するnを発生させるのに使用されます。(そこでは、nがkよりはるかに大きいです)。 そして、nコード化されたパケットが複数のマルチキャストグループの向こう側にしまをつけられます。 受信機がオリジナルのデータを受け取りたがっているとき、それは、マルチキャストグループの1つ以上を接合して、コード化パケットを受けます。 パケットをコード化しながらいったん容認されたkを異なるようにすると、受信機は、次に、すべてのマルチキャストグループを出て、オリジナルのデータを再建できます。
The primary importance of such a layering is that it allows different receivers to be able to receive the traffic at different rates according to the available capacity. Such schemes do not require any form of feedback from the receivers to the sender to ensure good throughput, and therefore the need for good throughput does not constrain the size of the receiver set. However, to perform adequate network congestion control using receiver joins and leaves in this manner may require coordination between members that are behind the same congested link from the sender. As described in the next section, [RVC98] suggests such a layered congestion control scheme.
そのようなレイヤリングの第一の重要性は有効な容量に応じて異なった受信機が異なったレートで交通を受けることができるのを許容するということです。 そのような計画は良い効率を確実にするために受信機から送付者までどんなフォームのフィードバックも必要としません、そして、したがって、良い効率の必要性は受信機セットのサイズを抑制しません。 しかしながら、受信機を使用することで適切なネットワーク輻輳制御を実行するのは接合します、そして、葉はこの様に同じ混雑しているリンクの後ろで送付者から来ているメンバーの間のコーディネートを必要とするかもしれません。 次のセクションで説明されるように、[RVC98]はそのような層にされた輻輳制御計画を示します。
5. Congestion Control Mechanisms
5. 輻輳制御メカニズム
The basic delivery model of the Internet is best-effort service. No guarantees are given as to throughput, delay or packet loss. End- systems are expected to be adaptive, and to reduce their transmission rate to a level appropriate for the congestion state of the network. Although increasingly the Internet will start to support reserved bandwidth and differentiated service classes for specialist applications, unless an end-system knows explicitly that it has reserved bandwidth, it must still perform congestion control.
インターネットの基本的な配送モデルはベストエフォート型サービスです。 スループット、遅れまたはパケット損失に関して保証を全く与えません。 エンドシステムは、適応型であり、ネットワークの混雑事情に、適切なレベルにそれらの通信速度を引き下げると予想されます。 エンドシステムが、帯域幅を控えたのを明らかに知らないと、インターネットは専門家アプリケーションのためにますます予約された帯域幅と微分されたサービスのクラスを支持し始めるでしょうが、それはまだ輻輳制御を実行しなければなりません。
Broadly speaking, there are five classes of single-sender multicast congestion control solution:
概して、独身の送付者マルチキャスト輻輳制御対策の5つのクラスがあります:
o Sender-controlled, one group.
o 送付者によって制御されていて、1つは分類します。
A single multicast group is used for data distribution. Feedback
from the group members is used to control the rate of this group.
The goal is to transmit at a rate dictated by the slowest
receiver.
ただ一つのマルチキャストグループは情報配給に使用されます。 グループのメンバーからのフィードバックは、このグループのレートを制御するのに使用されます。 目標は最も遅い受信機によって書き取られたレートで伝わることです。
Handley, et al. Informational [Page 14] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[14ページ]のRFC2887マルチキャストデザインスペース
o Sender-controlled, multiple groups.
o 送付者によって制御されていて、倍数は分類されます。
One initial multicast group is adaptively subdivided into multiple
subgroups with subdivisions centered on congestion points in the
network. Application-level relays buffer data from a group nearer
the original sender, and retransmit it at a slower rate into a
group further from the original sender. In this way, different
receivers can receiver the data at different rates. Sender-based
congestion control takes place between the members of a subgroup
and their relay.
区画分譲地が混雑ポイントの上のネットワークで中心に置かれている状態で、1つの初期のマルチキャストグループが適応型に複数のサブグループに細分されます。 アプリケーションレベルリレーは、より多くの元の送り主の近くでグループからデータをバッファリングして、より遅い速度でさらに元の送り主からグループにそれを再送します。 このように、異なった受信機は異なるところのデータが評定する受信機をそうすることができます。 送付者ベースの輻輳制御はサブグループと彼らのリレーのメンバーの間の場所を取ります。
o Receiver-controlled, one group.
o 受信機によって制御されていて、1つは分類します。
A single multicast group is used for data distribution. The
receivers determine if the sender is transmitting too rapidly for
the current congestion state of the network, and they leave the
group if this is the case.
ただ一つのマルチキャストグループは情報配給に使用されます。 受信機は、送付者があまりに急速にネットワークの現在の混雑事情に伝わっているかどうか決定します、そして、それらはこれがそうであるなら仲間から抜けます。
o Receiver-controlled, layered organization.
o 受信機で制御されて、層にされた組織。
A layered approach for how to combine this scheme with a
congestion control protocol that requires no receiver feedback is
described in [RVC98]. The sender stripes data across multiple
multicast groups simultaneously. Receivers join and leave these
layered groups depending on their measurements of the congestion
state of the network, so that the amount of data being received is
always appropriate. However, this scheme relies on receivers to
join and leave the different multicast groups in a coordinated
fashion behind a bottleneck link, and it has not yet been
completely confirmed that this approach will scale in practice to
the Internet. As a result, more work on this congestion control
mechanism would be beneficial.
どう受信機フィードバックを全く必要としない混雑制御プロトコルにこの計画を結合するかためには層にされたアプローチは[RVC98]で説明されます。 送付者は同時に、複数のマルチキャストグループの向こう側にデータにしまをつけます。 受信機は、接合して、これらの層にされたグループがそれらのネットワークの混雑事情の測定値によっているままにします、受け取られるデータ量がいつも適切であるように。 しかしながら、この計画はボトルネックリンクの後ろの連携ファッションで異なったマルチキャストグループに加わって、出るために受信機を当てにします、そして、このアプローチがインターネットへの習慣を計量するとまだ完全に確認されるというわけではありませんでした。 その結果、この混雑制御機構への、より多くの作業が有益でしょう。
o Router-based congestion control.
o ルータベースの輻輳制御。
It is possible to add additional mechanisms to multicast routers
to assist in multicast congestion control. Such mechanisms could
include:
マルチキャスト輻輳制御を助けるためにマルチキャストルータに追加メカニズムを加えるのは可能です。 そのようなメカニズムは以下を含むかもしれません。
o Conditional joins (a multicast join that specifies a loss rate
above which it is acceptable for the router to reject the
join).
o 条件付きである、接合、(ルータが拒絶するのにおいてそれが許容できる損失率を指定するマルチキャストが接合する、接合、)
o Router filtering of traffic that exceeds a reasonable rate.
This may include mechanisms for filtering traffic at different
points in the network at different rates depending on local
congestion conditions [LVS99].
o 妥当なレートを超えている交通のルータフィルタリング。 これは異なったポイントで地方の混雑条件[LVS99]に依存する異なったレートで交通をネットワークでフィルターにかけるためのメカニズムを含むかもしれません。
Handley, et al. Informational [Page 15] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[15ページ]のRFC2887マルチキャストデザインスペース
o Fair queuing schemes combined with end-to-end adaptation.
o 公正な列を作り計画は終わりから終わりへの適合に結合しました。
Router-based schemes generally require more state in network
routers than has traditionally been acceptable for backbone
routers. Thus, in the near-term, such schemes are only likely to
be applicable for intranet solutions.
一般に、ルータベースの計画はネットワークルータにおける背骨ルータにおいて伝統的に許容できたより多くの状態を必要とします。 したがって、単に短期間、そのような計画はイントラネット解決に適切である傾向があります。
For reliable multicast protocols, it is important to consider congestion control at the same time as reliability is being considered. The same mechanisms that are used to provide reliability will sometimes be used to provide congestion control.
信頼できるマルチキャストプロトコルにおいて、信頼性と同時に混雑がコントロールであると考えるのが考えられるのは、重要です。 信頼性を提供するのに使用されるのと同じメカニズムは、輻輳制御を提供するのに時々使用されるでしょう。
In the case of receiver-based congestion control, open-loop delivery using FEC is the likely choice for achieving good throughput for bulk- data transfer. This is because open-loop delivery requires no feedback from receivers, and thus it is a perfect match with a receiver-based congestion-control mechanism that operates without feedback from receivers.
受信機ベースの輻輳制御の場合では、FECを使用する転々流通配送は、大量データ転送のための良い効率を達成するためのありそうな選択です。 これが転々流通配送が受信機からフィードバックを全く必要としないからであるその結果、それは受信機からフィードバックなしで動作する受信機ベースの輻輳制御メカニズムがある似合いの二人です。
6. Security Considerations
6. セキュリティ問題
Generally speaking, security considerations have relatively little effect on constraining the design space for reliable multicast protocols. The primary issues constraining the design space are all related to receiver-set scaling. For authentication of the source and of data integrity, receiver-set scaling is not a significant issue. However, for data encryption, key distribution and particularly re-keying may be significantly affected by receiver-set scaling. Tree and graph based re-keying solutions[WHA98,WGL97] would appear to be appropriate solutions to these problems. It is not clear however that such re-keying solutions need to directly affect the design of the data distribution part of a reliable multicast protocol.
概して、セキュリティ問題は信頼できるマルチキャストプロトコルのためにデザインスペースを抑制するのに比較的少ない影響を与えます。 デザインスペースを抑制する第一の問題は受信機セットスケーリングにすべて関連します。 ソースとデータ保全の認証のために、受信機セットスケーリングは重要な問題ではありません。 しかしながら、データ暗号化において、主要な分配と特に再の合わせることは受信機セットスケーリングでかなり影響を受けるかもしれません。 解決策[WHA98、WGL97]を再合わせながら基づく木とグラフはこれらの問題の適切な解決であるように見えるでしょう。しかしながら、そのような再の合わせる解決策が、直接信頼できるマルチキャストプロトコルの情報配給部分のデザインに影響する必要があるのは、明確ではありません。
The primary question to consider for the security of reliable multicast protocols is the role of third-parties. If nodes other than the original source of the data are allowed to send or resend data packets, then the security model for the protocol must take this into account. In particular, it must be clear whether such third parties are trusted or untrusted. A requirement for trusted third parties can make protocols difficult to deploy on the Internet.
信頼できるマルチキャストプロトコルのセキュリティのために考える第一の質問は第三者の役割です。 データ・パケットを送るか、またはデータの一次資料以外のノードが再送できるなら、プロトコルのための機密保護モデルはこれを考慮に入れなければなりません。 そのような第三者が信じられるか、または信頼されていないかが、特に、明確でなければなりません。 信頼できる第三者機関のための要件は、インターネットでプロトコルを配備するのを難しくすることができます。
Untrusted third parties (such as receivers that retransmit the data) may be used so long as the data authentication mechanisms take this into account. Typically this means that the original sender digitally signs and timestamps the data, and that the third parties resend this signed timestamped payload unmodified.
データ認証機構がこれを考慮に入れる限り、信頼されていない第三者(データを再送する受信機などの)は使用されるかもしれません。 通常、これは、元の送り主がデジタルにサインして、タイムスタンプがデータにサインして、第三者が変更されていなくこのサインされたtimestampedペイロードを再送することを意味します。
Handley, et al. Informational [Page 16] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[16ページ]のRFC2887マルチキャストデザインスペース
Unlike unicast protocols, denial-of-service attacks on multicast transport state are easy if the protocol design does not take such attacks into account. This is because any receiver can join the session, and can then produce feedback that influences the progress of a session involving many other receivers. Hence protection against denial-of-service attacks on reliable multicast protocols must be carefully considered. A receiver that requests retransmission of every packet, or that refuses to acknowledge packets in an ACK-based protocol can potentially bring a reliable multicast session to a standstill. Senders must have appropriate policy to deal with such conditions, and if necessary, evict the receiver from the group. A single receiver masquerading as a large number of receivers may still be an issue under such circumstances with protocols that support NACK-like functionality. Providing unique "keys" to each NACKer when they first NACK using a unicast response might potentially prevent such attacks.
ユニキャストプロトコルと異なって、プロトコルデザインがそのような攻撃を考慮に入れないなら、マルチキャスト輸送状態におけるサービス不能攻撃は簡単です。 これがどんな受信機もセッションに参加できるからである次に、他の多くの受信機にかかわるセッションの進歩に影響を及ぼすフィードバックは作成できます。 したがって、慎重に信頼できるマルチキャストプロトコルにおけるサービス不能攻撃に対する保護を考えなければなりません。 あらゆるパケットの「再-トランスミッション」を要求するか、またはACKベースのプロトコルのパケットが潜在的に信頼できるマルチキャストセッションを静止にもたらすことができると認めるのを拒否する受信機。 Sendersには、そのような状態に対処するのが適切である方針がなければなりません、そして、必要なら、グループから受信機を追い立ててください。 多くの受信機のふりをする単一の受信機はまだこれではナックのような機能性を支持するプロトコルの問題であるかもしれません。 それらであるときに、ユニークな「キー」を各NACKerに供給して、最初に、ユニキャスト応答を使用しているナックは潜在的にそのような攻撃を防ぐかもしれません。
Denial-of-service attacks caused by traffic flooding are however somewhat easier to protect against than with unicast. Unwanted senders can simply be pruned from the distribution tree using the mechanisms implemented in IGMP v3[CDT99].
守るのがユニキャストよりどのようにいくらか簡単であっても、交通氾濫によって引き起こされたサービス不能攻撃はそうです。 分配木からIGMP v3[CDT99]で実行されたメカニズムを使用することで求められていない送付者を単に剪定できます。
7. Conclusions
7. 結論
In this document we present an overview of the design space for reliable multicast within the context of one-to-many bulk-data transfer. Other flavors of multicast application are not considered in this document, and hence the overview given should not be considered inclusive of the design space for protocols that fall outside the context of one-to-many bulk-data transfer. During the course of this overview, we have reaffirmed the notion that the process of reliable multicast protocol design is affected by a number of factors that render the generation of a "one size fits all solution" moot. These factors are then described to show how an application's needs serve to constrain the set of available techniques that may be used to create a reliable multicast protocol. We examined a number of basic techniques and to show how well they can meet the needs of certain types of applications.
本書では私たちは多くへの1回のバルク・データ転送の文脈の中の信頼できるマルチキャストのためにデザインスペースの概観を提示します。 本書ではマルチキャストアプリケーションの他の風味を考えません、そして、したがって、デザインスペースで多くへの1回のバルク・データ転送の文脈をそらせるプロトコルに包括的であると与えられた概観を考えるべきではありません。 この概観のコースの間、私たちは信頼できるマルチキャストプロトコルデザインの過程が「フリーサイズ解決策」の世代を論争中にする多くの要因で影響を受けるという概念を再び断言しています。 そして、これらの要素は、アプリケーションの必要性が、使用されるかもしれない利用可能なテクニックのセットが信頼できるマルチキャストプロトコルを作成するのを抑制するのにどう役立つかを示しているために説明されます。 私たちは多くの基本技術を調べました、そして、どれくらいよく目立つように、彼らはあるタイプのアプリケーションの需要を満たすことができるか。
This document is intended to provide guidance to the IETF community regarding the standardization of reliable multicast protocols for bulk-data transfer. Given the degree to which application requirements constrain reliable multicast solutions, and the diverse set of applications that need to be supported, it should be clear that any standardization work should take great pains to be future- proof. This would seem to imply not standardizing complete reliable multicast transport protocols in one pass, but rather examining the degree to which such protocols are separable into functional building
このドキュメントがバルク・データ転送のために信頼できるマルチキャストプロトコルの標準化に関してIETF共同体に指導を提供することを意図します。 それのアプリケーション要件に信頼できるマルチキャスト解決策を抑制してください。そうすれば、支持される必要があるさまざまのアプリケーションでありそれが明確であるはずである度を考えて、どんな標準化も働いているのは、未来の証拠になるように苦心するべきです。 1個のパスで完全な信頼できるマルチキャストを標準化しないで、プロトコルを輸送するように含意するように思えますが、度を調べて、そのようなプロトコルが機能本位の建物に分離できるこれはむしろ思えるでしょう。
Handley, et al. Informational [Page 17] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[17ページ]のRFC2887マルチキャストデザインスペース
blocks, and standardizing these blocks separately to the maximum degree that makes sense. Such an approach allows for protocol evolution, and allows applications with new constraints to be supported with maximal reuse of existing and tested mechanisms.
ブロックと、別々に理解できる最大の程度にこれらのブロックを標準化すること。 そのようなアプローチは、存在とテストされたメカニズムの最大限度の再利用で支持されるという新しい規制でプロトコル発展を考慮して、アプリケーションを許容します。
8. Acknowledgments
8. 承認
This document represents an overview of the reliable multicast design space. The ideas presented are not those of the authors, but are collected from the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions.
このドキュメントは信頼できるマルチキャストデザインスペースの概観を表します。 提示された考えは、作者のものではありませんが、IRTF Reliable Multicast Research Groupに様々なプレゼンテーションと議論から集められます。 それらはここに記載できないくらい非常に多いのですが、私たちは彼らの貢献のためにこれらの議論に参加した皆に感謝します。
9. Authors' Addresses
9. 作者のアドレス
Mark Handley ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSIでのインターネット調査のためのマークハンドレーATTセンター、国際電子計算機科学協会、1947は通り、スイート600、バークレー、カリフォルニア 94704、米国を中心に置きます。
EMail: mjh@aciri.org
メール: mjh@aciri.org
Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSIでのインターネット調査のためのサリーフロイドATTセンター、国際電子計算機科学協会、1947は通り、スイート600、バークレー、カリフォルニア 94704、米国を中心に置きます。
EMail: floyd@aciri.org
メール: floyd@aciri.org
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
ブライアンWhetten Talarian社、333ディステル会、ロスアルトス、カリフォルニア 94022、米国
EMail: whetten@talarian.com
メール: whetten@talarian.com
Handley, et al. Informational [Page 18] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[18ページ]のRFC2887マルチキャストデザインスペース
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
ロジャー・カーモード・モトローラオーストラリアの研究センターレベル3、12 主の通り、NSW2019、Botanyオーストラリア
EMail: Roger.Kermode@motorola.com
メール: Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
サンノゼ、170の西タスマン博士カリフォルニア 95134、ロレンツォVicisanoシスコシステムズ(米国)
EMail: lorenzo@cisco.com
メール: lorenzo@cisco.com
Michael Luby Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110
マイケル・Lubyのデジタル噴水Inc.600アラバマ通りサンフランシスコ、カリフォルニア 94110
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
10. References
10. 参照
[BC94] K. Birman, T. Clark. "Performance of the Isis Distributed
Computing Toolkit." Technical Report TR-94-1432, Dept. of
Computer Science, Cornell University.
[BC94] K.バーマン、T.クラーク。 「イシス分散コンピューティングツールキットのパフォーマンス。」 技術報告書TR-94-1432、コンピュータサイエンスの部、コーネル大学。
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D.
Zuckerman, "An XOR-based Erasure Resilient Coding Scheme",
ICSI Technical Report No. TR-95-048, August 1995.
[BKKKLZ95]J.Bloemer、M.Kalfane、M.Karpinski、R.カープ、M.Luby、D.ザッカーマン、「XORベースの消去弾力があるコード構成」、ICSI技術報告書No. 1995年8月のTR-95-048。
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital
Fountain Approach to Reliable Distribution of Bulk Data",
Proc ACM SIGCOMM 98.
[BLMR98] J.バイアーズ、M.Luby、M.Mitzenmacher、A.リージ、「大量のデータの信頼できる分配へのデジタル噴水アプローチ」、Proc ACM SIGCOMM98。
[CDT99] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3", Work in Progress.
[CDT99] カインとB.とデアリング、S.とA.Thyagarajan、「集団経営プロトコル、バージョン3インチが進行中で扱うインターネット。」
[FLST98] Farinacci, D., Lin, S., Speakman, T. and A. Tweedly, "PGM
reliable transport protocol specification", Work in
Progress.
[FLST98] ProgressのファリナッチとD.とリンとS.とSpeakmanとT.とA.Tweedly、「PGMの信頼できる輸送プロトコル仕様」、Work。
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast
Framework for Light-weight Sessions and Application Level
Framing", Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
[FJM95] S.フロイド、V.ジェーコブソン、S.McCanne、「軽量のセッションとアプリケーションレベル縁どりのための信頼できるマルチキャスト枠組み」、Proc ACM SIGCOMM95、1995年8月ページ 342-356.
Handley, et al. Informational [Page 19] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[19ページ]のRFC2887マルチキャストデザインスペース
[Ha99] Handley, M., "Multicast address allocation protocol
(AAP)", Work in Progress.
[Ha99] ハンドレー、M.、「マルチキャストアドレス配分プロトコル(AAP)」、ProgressのWork。
[HC97] M. Handley and J. Crowcroft, "Network text editor (NTE) a
scalable shared text editor for MBone," ACM Computer
Communication Review, vol. 27, pp. 197-208, Oct. 1997. ACM
SIGCOMM'97, Sept. 1997.
[HC97] M.ハンドレーとJ.クロウクロフト、「MBoneのためにテキストエディタ(NTE)のaスケーラブルな分配しているテキストエディタをネットワークでつないでください」、ACMコンピュータCommunication Review、vol.27、ページ 197-208と、1997年10月。 1997年9月のACM SIGCOMM97年。
[KCW98] Kadansky, M., Chiu, D. and J. Wesley, "Tree-based reliable
multicast (TRAM)", Work in Progress.
[KCW98] ProgressのKadanskyとM.とチウとD.とJ.ウエスリー、「木のベースの信頼できるマルチキャスト(TRAM)」、Work。
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V.
Stemann, "Practical Loss-Resilient Codes", Proc ACM
Symposium on Theory of Computing, 1997.
[LMSSS97] M.Luby、M.Mitzenmacher、A.Shokrollahi、D.Spielman対Stemann、「実用的な損失弾力があるコード」、コンピューティング、1997年の理論に関するProc ACMシンポジウム
[MWB+98] Montgomery, T., Whetten, B., Basavaiah, M., Paul, S.,
Rastogi, N., Conlan, J. and T. Yeh, "THE RMTP-II
PROTOCOL", Work in Progress.
[MWB+98] 「RMTP-IIプロトコル」というモンゴメリ、T.、Whetten、B.、Basavaiah、M.、ポール、S.、ラストーギ、N.、コンラン、J.、およびT.イップは進行中で働いています。
[PPV98] C. Papadopoulos, G. Parulkar, and G. Varghese, "An error
control scheme for large-scale multicast applications," in
Proceedings of the Conference on Computer Communications
(IEEE Infocom), (San Francisco, California), p. 1188,
March/April 1998.
[PPV98]C.パパドプロス、G.ParulkarとG.Varghese、コンピュータCommunications(IEEE Infocom)の上のコンファレンスのProceedingsの「大規模なマルチキャストアプリケーションの誤り制御計画」(サンフランシスコ(カリフォルニア))p。 1998年3月/4月の1188。
[Ri97] L. Rizzo, "Effective erasure codes for reliable computer
communication protocols," ACM Computer Communication
Review, vol. 27, pp. 24-36, Apr. 1997.
[Ri97]L.リゾー、「信頼できるコンピュータ通信プロトコルのための有効な消去コード」、ACMコンピュータCommunication Review、vol.27、ページ 24-36と、1997年4月。
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast data
Distribution Protocol based on software FEC techniques",
Proc. of The Fourth IEEE Workshop on the Architecture and
Implementation of High Performance Communication Systems
(HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25,
1997.
[RV97] L.リゾー、L.Vicisano、「ソフトウェアFECのテクニックに基づくReliable MulticastデータDistributionプロトコル」Proc1997年6月23日〜25日の間のArchitectureの上のFourth IEEE WorkshopとHighパフォーマンスCommunication Systems(HPCS97年)、SaniビーチChalkidiki、ギリシアのImplementationについて。
[RVC98] L. Rizzo, L. Vicisano, J. Crowcroft, "The RLC multicast
congestion control algorithm", submitted to IEEE Network -
special issue multicast.
[RVC98]L.リゾー、L.Vicisano、「RLCマルチキャスト輻輳制御アルゴリズム」というJ.クロウクロフトはIEEE Networkに提出しました--増刊マルチキャスト。
[RMWT98] Robertson, K., Miller, K., White, M. and A. Tweedly,
"StarBurst multicast file transfer protocol (MFTP)
specification", Work in Progress.
[RMWT98] ProgressのロバートソンとK.とミラーとK.とホワイトとM.とA.Tweedly、「StarBurstマルチキャストファイル転送プロトコル(MFTP)仕様」、Work。
[WHA98] Wallner, D., Hardler, E. and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[WHA98] ウォルナー、D.、Hardler、E.、およびR.エージー、「マルチキャストのための管理を合わせてください」 「問題と構造」、RFC2627、6月1999日
Handley, et al. Informational [Page 20] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[20ページ]のRFC2887マルチキャストデザインスペース
[WKM94] Brian Whetten, Simon Kaplan, and Todd Montgomery, "A high
performance totally ordered multicast protocol," research
memorandum, Aug. 1994.
サイモン・キャプラン、およびトッドモンゴメリ、「マルチキャストプロトコルが完全に注文された高性能」という[WKM94]ブライアンWhettenは1994年8月にメモについて研究します。
[WGL97] C.K. Wong, M. Gouda, S. Lam, "Secure Group Communications
Using Key Graphs," Technical Report TR 97-23, Department
of Computer Sciences, The University of Texas at Austin,
July 1997.
[WGL97]C.K.ウォン、M.合田、S.ラムは「主要なグラフを使用して、グループコミュニケーションを保証します」、技術報告書TR97-23、コンピューターサイエンシズの部、テキサス大学オースティン校、1997年7月。
Handley, et al. Informational [Page 21] RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
ハンドレー、他 バルク・データ転送2000年8月のための情報[21ページ]のRFC2887マルチキャストデザインスペース
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Handley, et al. Informational [Page 22]
ハンドレー、他 情報[22ページ]
一覧
スポンサーリンク
