Network Working Group M. Luby
Request for Comments: 3738 Digital Fountain
Category: Experimental V. Goyal
M.I.T.
April 2004
Wave and Equation Based Rate Control (WEBRC) Building Block
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.
このドキュメントでは、波とデータ配信のためのレートと輻輳制御を提供し、式ベースのレート制御（WEBRC）を指定します。 WEBRCは、特にIPマルチキャストを使用してプロトコルをサポートするように設計されています。これは即ち、異なる受信機が同じセッションが送信者への個々の接続の帯域幅に及びこれらの接続に沿ってトラフィックを競合に依存して異なる速度でパケットを受信することができるに接合さ、受信機へのマルチレート、輻輳制御された送達を提供します。 WEBRC、すなわち、それが完全に受信機駆動型の輻輳制御プロトコルであり、受信機から送信側へのフィードバックを必要としません。従って、単一の送信者からのセッションに取り付けられた受信機の潜在的に膨大な数まで拡張するように設計されています。各個々の受信者が送信者とその受信機との間の利用可能な帯域幅に調整するためにさらに、単一の送信者を使用して、さらに高度に異種ネットワークアーキテクチャにおいて、その受信機のための最速の速度で各個々の受信機にデータを配信する可能性があります。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Sender Operation . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Sender inputs and initialization. . . . . . . . . 9
3.1.2. Sending packets to the session. . . . . . . . . . 10
3.2. Receiver Operation . . . . . . . . . . . . . . . . . . . 12
3.2.1. Receiver inputs and initialization. . . . . . . . 12
3.2.2. Receiver measurements and calculations. . . . . . 13
3.2.2.1. Average loss probability . . . . . . . . 13
3.2.2.2. Average round-trip time. . . . . . . . . 16
3.2.2.3. Rate Equation. . . . . . . . . . . . . . 16
3.2.2.4. Epochs . . . . . . . . . . . . . . . . . 17
3.2.2.5. Average reception rate . . . . . . . . . 17
3.2.2.6. Slow start . . . . . . . . . . . . . . . 19
3.2.2.7. Target rate. . . . . . . . . . . . . . . 20
3.2.3. Receiver events . . . . . . . . . . . . . . . . . 20
3.2.3.1. Packet reception . . . . . . . . . . . . 20
3.2.3.2. First packet after join. . . . . . . . . 20
3.2.3.3. Time slot change . . . . . . . . . . . . 20
3.2.3.4. Loss event . . . . . . . . . . . . . . . 21
3.2.3.5. Epoch change . . . . . . . . . . . . . . 21
3.2.3.6. Join the next higher layer . . . . . . . 21
3.2.3.7. Join timeout . . . . . . . . . . . . . . 23
3.2.3.8. Exceptional timeouts . . . . . . . . . . 23
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 23
4.1. Environmental Requirements and Considerations. . . . . . 23
5. Packet Header Fields. . . . . . . . . . . . . . . . . . . . . 25
5.1. Short Format Congestion Control Information. . . . . . . 26
5.2. Long Format Congestion Control Information . . . . . . . 27
6. Requirements From Other Building Blocks . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 31
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
This document specifies Wave and Equation Based Rate Control (WEBRC). WEBRC is a congestion control building block that is designed to be massively scalable when used with the IP multicast network service. WEBRC is also suitable as the basis for unicast congestion control, but this is outside the scope of this document. WEBRC is designed to compete fairly with TCP and similar congestion-controlled sessions. WEBRC can be used as a congestion control protocol for any type of data delivery, including reliable content delivery and streaming delivery.
この文書では、波と方程式ベースのレート制御（WEBRC）を指定します。 WEBRCは、IPマルチキャストネットワークサービスで使用した場合、大規模な拡張できるように設計されて輻輳制御のビルディングブロックです。 WEBRCはまた、ユニキャスト輻輳制御のための基礎として適しているが、これはこの文書の範囲外です。 WEBRCは、TCPと同様の輻輳制御セッションで公正な競争するように設計されています。 WEBRCは、信頼性の高いコンテンツ配信やストリーミング配信を含むデータ配信の任意のタイプのための輻輳制御プロトコルとして使用することができます。
WEBRC is a receiver-driven congestion control protocol in the spirit of [5] and [18]. This means that all measurements and decisions to raise or lower the reception rate are made by each individual receiver, and these decisions are acted upon by sending join and leave messages for channels to the network. A receiver using WEBRC adjusts its reception rate without regard for other concerns such as reliability. This is different from TCP, where the congestion control protocol and the reliability protocol are intricately interwoven.
WEBRC [5]及び[18]の精神における受信機駆動型の輻輳制御プロトコルです。これは、受信レートを上げるか下げるために、すべての測定および決定は、個々の受信機によって作られており、これらの決定が参加し、ネットワークへのチャネルにメッセージを残す送ることによって作用していることを意味します。 WEBRCを用いた受信機は、信頼性のような他の問題に関係なく、その受信レートを調整します。これは、輻輳制御プロトコルおよび信頼性プロトコルが複雑に織り込まれているTCP、異なっています。
WEBRC takes the same basic equation-based approach as TFRC [9]. In particular, each WEBRC receiver measures parameters that are plugged into a TCP-like equation to compute the receiver target reception rate and adjusts its reception rate up and down to closely approximate the target reception rate. The sender sends packets to multiple channels; one channel is called the base channel and the remaining channels are called wave channels. Each wave channel follows the same pattern of packet rate transmission spread out over equally-spaced intervals of time. The pattern of each wave is that it starts at a high rate and the rate decreases gradually and continually over a long period of time. (Picture an infinite sequence of waves.) The receiver increases its reception rate by joining the next wave channel earlier in the descent of the wave than it joined the previous wave channel, and the receiver decreases its reception rate by joining the next wave channel later in the descent of the wave than it joined the previous wave channel.
WEBRC [9] TFRCと同じ基本的な方程式ベースのアプローチをとります。具体的には、TCPのような式に差し込まれる各WEBRCレシーバ測定パラメータは、受信機の目標受信速度を計算し、密接に目標受信速度を近似するために上下の受信レートを調整します。送信者は、複数のチャネルにパケットを送信します。一方のチャネルは、ベースチャネルと呼ばれ、残りのチャネルは波長チャネルと呼ばれます。各波長チャネルは、時間の等間隔に広がるパケットレート伝送の同じパターンに従います。各波のパターンは、それが高速で始まり、レートが長期間にわたって徐々にかつ継続的に減少することです。 （波の無限配列を写真。）が前波のチャンネルに参加しより受信機は、以前の波の下降における次の波のチャンネルを結合して、その受信速度を増加させ、受信機は、後に次の波のチャンネルを結合して、その受信率を低下させますそれよりも波の降下の前の波のチャンネルに参加しました。
The wave channels are ordered at each point in time from a lowest layer to a highest layer. At each point in time, the lowest layer is the wave channel that among all active wave channels is nearest to the end of its active period; the highest layer is the wave channel that is furthest from the end of its active period. Because waves are dynamically becoming active and quiescent over time, the designation of which wave channel is at which layer changes dynamically over time. In addition to being joined to the base channel, at each point in time a receiver is joined to a consecutive set of layers starting at the lowest layer and proceeding towards the highest.
波チャネルは時間で最下層から最上層までの各点で順序付けられます。各時点で、最下位層は、すべてのアクティブな波チャネル間のアクティブ期間の終わりに最も近いこと波チャネルです。最上位層は、そのアクティブ期間の終了から遠い波チャネルです。波が動的に経時的にアクティブと休止になってきているので、チャネルを振ったの指定を動的に時間をかけた層の変化です。各時点で、ベースチャンネルに結合されることに加えて、受信機は、層の連続セット最下層から開始し、最高に向かって進行に接合されています。
WEBRC introduces a natural notion of a multicast round-trip time (MRTT). An MRTT is measured individually by each receiver and averaged as a substitute for conventional unicast round-trip time (RTT). Because the throughput of a TCP session depends strongly on RTT, having some measure of RTT is essential in making the WEBRC equation-based rate control protocol "TCP-friendly". The use of the MRTT also helps to coordinate and equalize the reception rates of proximate receivers joined to a session behind a bottleneck link. This implies that packets for the session that flow through the bottleneck link are on average sent to almost all downstream receivers, and thus the efficiencies of multicast are realized. Furthermore, WEBRC is designed to be massively scalable in the sense that the sender is insensitive to the number of receivers joined to a multicast session.
WEBRCは、マルチキャスト往復時間（MRTT）の自然の概念を導入しています。 MRTTは、各受信機によって個々に測定され、従来のユニキャストラウンドトリップ時間（RTT）の代わりに平均化されます。 TCPセッションのスループットはRTTに強く依存するので、RTTのいくつかの指標を持つことはWEBRC方程式ベースの速度制御プロトコル「TCPに優しい」を作るに不可欠です。 MRTTの使用はまた、ボトルネックリンクの背後にあるセッションに参加しました近接受信機の受信速度を調整し、均一化するのに役立ちます。これは、ボトルネックリンクを流れるセッションのパケットは、平均してほぼすべてのダウンストリーム受信機に送信されていることを意味し、したがって、マルチキャストの効率が実現されています。さらに、WEBRCは、送信者がマルチキャストセッションに参加受信器の数に影響されないという意味で大規模にスケーラブルであるように設計されています。
WEBRC is designed for applications that use a fixed packet size and vary their packet reception rates in response to congestion. WEBRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its reception rate is generally within a factor of two of the reception rate of a TCP flow under the same conditions. However WEBRC has a much lower variation of throughput over time compared to TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth rate is of importance. The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that WEBRC responds more slowly than TCP to changes in available bandwidth.
WEBRCは混雑に応じて、そのパケットの受信レートを固定パケットサイズを使用し、異なるアプリケーション用に設計されています。 WEBRCは、その受信レートが同じ条件でTCPフローの受信レートの2倍以内であれば、一般的にフローが「合理的公正」であるTCPフロー、と帯域幅を競合するとき、合理的に公平であるように設計されています。しかしながらWEBRCは、比較的滑らかな速度が重要である電話やストリーミングメディアなどのアプリケーションのためにそれがより適してTCPに比べて経時スループットのはるかに低い変動を有します。帯域幅を公平に競争しながら、TCPよりも滑らかなスループットを持つことのペナルティはWEBRCが利用可能な帯域幅の変化に、よりゆっくりとTCPよりも応答することです。
The receiver measures and performs the calculation of congestion control parameters (e.g., the average loss probability, the average MRTT) and makes decisions on how to increase or decrease its rate based on these parameters. The receiver-based approach is well suited to an application where the sender is handling many concurrent connections and therefore WEBRC is suitable as a building block for multicast congestion control.
レシーバ対策や輻輳制御パラメータ（例えば、平均損失確率、平均MRTT）の計算を行い、これらのパラメータに基づいてその速度を増減する方法について決定を行います。レシーバベースのアプローチは、送信者が、多くの同時接続を処理するアプリケーションに適している、したがってWEBRCマルチキャスト輻輳制御のためのビルディングブロックとして好適です。
The paper [16] and technical report [15] provide much of the rationale and intuition for the WEBRC design and describe some preliminary simulations.
紙[16]と技術レポート[15] WEBRC設計のための根拠と直感の多くを提供し、いくつかの予備のシミュレーションについて説明します。
This document describes a building block as defined in RFC 3048 [4]. This document describes a congestion control building block that conforms to RFC 2357 [3]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [2]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
この文書は、RFC 3048で定義されるように構築ブロックを説明し[4]。この文書は、RFC 2357に準拠し、輻輳制御構築ブロックを説明した[3]。この文書は、IETF RMT WGの製品であり、[2] RFC 3269に設けられた一般的なガイドラインに従います。キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "NOT SHALL"、
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
、 "SHOULD"、 "推奨"、 "SHOULD NOT"、 "MAY"、及び "OPTIONAL" この文書に記載されているBCP 14、RFC 2119に記載されているように[1]に解釈されるべきです。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme. This document specifies an experimental congestion control scheme. While waiting for initial deployment and experience to show this scheme to be effective and scalable, the IETF publishes this scheme in the "Experimental" category.
このメモは、完全にRFC 2357を1としてRFC 2357.に従い、信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれている、インターネットのいずれかの信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式が必要です。この文書では、実験的な輻輳制御方式を指定します。効果的かつスケーラブルになるように、このスキームを示すために、初期の展開と経験を待っている間、IETFは、「実験」カテゴリでこのスキームを公開しています。
It is the intent of the Reliable Multicast Transport (RMT) Working Group to re-submit the specification as an IETF Proposed Standard as soon as the scheme is deemed adequate.
スキームが適切であると見なされるとすぐにIETFのProposed Standardとしての仕様を再提出する信頼性の高いマルチキャストトランスポート（RMT）ワーキンググループの意図です。
WEBRC provides congestion control for massively scalable protocols using the IP multicast network service. The congestion control that WEBRC provides is common to a variety of applications, including reliable content delivery and streaming applications.
WEBRCは、IPマルチキャストネットワークサービスを使用して大規模なスケーラブルなプロトコルのための輻輳制御を提供します。 WEBRCが提供する輻輳制御は、信頼性の高いコンテンツ配信とストリーミングアプリケーションなど、さまざまなアプリケーションに共通です。
WEBRC is designed to provide congestion control for all packets that are sent to a session. A session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. The rationale for providing congestion control that uses multiple channels within the same session is that this allows the data on the channels to be layered, which in turn allows each receiver to control its reception rate by joining and leaving channels during its participation in the session. There are advantages to layered data for streaming, where the most important data can be sent to the lower layers and incrementally valuable data to the higher layers. For reliable content delivery, as described in [13], an application can send in packets encoded data generated from an object in such a way that the arrival of enough packets by a receiver is sufficient to reliably reconstruct the original object. A primary advantage of WEBRC is that each receiver controls it reception rate independent of other receivers. Thus, for example, a receiver with a slow connection to the sender does not slow down the receivers with faster connections.
WEBRCは、セッションに送信されるすべてのパケットの輻輳制御を提供するように設計されています。セッションは、受信機に関心のあることができる1つまたは複数のオブジェクトの伝送に関係するパケットを運ぶためにある期間に使用される単一の送信者から発信複数のチャネルを含みます。単一の送信者から発信されたものとしてセッションを定義するの背後にある論理は、これは輻輳制御を介してパケットトラフィックを規制する適切な粒度であることです。同じセッション内で複数のチャネルを使用して輻輳制御を提供するための理論的根拠は、これが順番に受信機が参加し、セッションへの参加中にチャネルを残すことによって、その受信速度を制御することを可能にする、チャネル上のデータが積層されることを可能にすることです。最も重要なデータは、上位レイヤに下位層とインクリメンタルに貴重なデータを送信することができますストリーミング用の階層化データへの利点があります。 [13]に記載のように信頼性の高いコンテンツの配信のために、アプリケーションは、受信機によって十分にパケットの到着を確実に元のオブジェクトを再構築するのに十分であるような方法でオブジェクトから生成されたパケットの符号化データで送信することができます。 WEBRCの主な利点は、各受信機はそれを他の受信機の受信レート独立した制御を行うことです。したがって、例えば、送信者への低速接続での受信機は、より高速な接続で受信機が遅くなることはありません。
There are coding techniques that provide massively scalable reliability and asynchronous delivery which are compatible with WEBRC, e.g., as described in [11]. When combined the result is a massively scalable, reliable, asynchronous content delivery protocol that is network friendly. WEBRC also provides congestion control that is suitable for streaming applications.
[11]に記載されているように、例えば大規模なスケーラブルな信頼性とWEBRCと互換性のある非同期の配信を提供する符号化技術があります。組み合わせると、結果はネットワークやさしい大規模スケーラブルで信頼性の高い、非同期のコンテンツ配信プロトコルです。 WEBRCまた、ストリーミングアプリケーションに適している輻輳制御を提供します。
WEBRC avoids using techniques that are not massively scalable. For example, WEBRC does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use WEBRC and that send information from receivers to senders.
WEBRCは、大規模スケーラブルではない技術を使用して回避します。これは両方ともWEBRCを使用し、それは、送信者に受信機からの情報を送信するプロトコルを除外するものではないが、例えば、WEBRCは、送信者に受信機からの情報を送信するための任意のメカニズムを提供しません。
WEBRC provides congestion control that can be tuned for different applications that may have differing application requirements. For example, a content delivery protocol may aggressively strive to use all available bandwidth between receivers and the sender, and thus to maintain fairness it must drastically reduce its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and thus it may not reduce its rate as fast when there is competing traffic.
WEBRCは、異なるアプリケーション要件を有することができるさまざまな用途に合わせて調整することができ、輻輳制御を提供します。例えば、コンテンツ配信プロトコルは、積極的に受信機と送信者の間のすべての利用可能な帯域幅を使用するように努力することが、ひいては競合するトラフィックがあるとき、それは劇的にそのレートを下げる必要があり、公平性を維持するために。一方、ストリーミング配信プロトコルではなく、すべての利用可能な帯域幅を使用しようとしているの一定速度を維持するために努力することが、ひいてはそれが早く、競合するトラフィックがあるときにその速度を低減することがありません。
WEBRC does not provide any support beyond congestion control, and thus WEBRC is to be combined with other building blocks to provide a complete protocol instantiation. For example, WEBRC does not provide any means that can be used to identify which session each received packet belongs to. As another example, WEBRC does not provide support for identifying which object each packet is carrying information about.
WEBRCは、輻輳制御を越えたサポートを提供していませんので、WEBRCは完全なプロトコルのインスタンスを提供するために、他のビルディングブロックと結合することです。例えば、WEBRCは、各受信したパケットが属するセッションを識別するために使用することができる任意の手段を提供しません。別の例として、WEBRCは、各パケットについての情報を運んでどのオブジェクト識別するためのサポートを提供しません。
A WEBRC session comprises a logically related set of channels originating from a single sender that are used for some period of time to carry data packets with a header carrying WEBRC Congestion Control Information. When packets are received, they are first checked to see that they belong to the appropriate session before WEBRC is applied. A session label defined by a protocol instantiation may be carried in each packet to identify to which session the packet belongs. For example, if LCT [12] is being used with the session, then the sender IP address together with the Transport Session Identifier supported by LCT would be used to determine which session a received packet belongs to. The particular details of how this filtering is performed is outside the scope of this document. In the remainder of this document, references to channels are always within the scope of a single session.
WEBRCセッションはWEBRC輻輳制御情報を運ぶヘッダとデータパケットを搬送するためにある期間に使用される単一の送信者から発信チャネルの論理的に関連するセットを含みます。パケットが受信されると、彼らは最初のWEBRCが適用される前に、彼らは適切なセッションに属していることを確認するためにチェックされます。プロトコルのインスタンスによって定義されたセッション・ラベルは、パケットが属するセッションを識別するために、各パケットで運ばれてもよいです。 LCT [12]セッションに使用されている場合、例えば、次にLCTによってサポート交通セッション識別子とともに送信元IPアドレスは、受信したパケットが属するセッションを決定するために使用されるであろう。このフィルタリングが実行される方法の特定の詳細は、この文書の範囲外です。この文書の残りでは、チャネルへの言及は、単一のセッションの範囲内に常にあります。
A channel can be uniquely identified at the network layer by a (sender IP address, multicast group address) pair, and this is the address to which the receiver sends messages to join and leave the channel. The channels used by a WEBRC session are mapped uniquely to consecutive channel numbers. In each packet sent to a channel, the channel number that corresponds to the channel is carried in the WEBRC Congestion Control Information. A WEBRC receiver uses the channel number to determine which channel within a session a packet is received from.
チャネルは、一意（送信元IPアドレス、マルチキャストグループアドレス）対によってネットワーク層で識別することができ、これは、受信機がチャンネルに参加し、残してメッセージを送信先のアドレスです。 WEBRCセッションによって使用されるチャネルは、連続したチャネル番号に一意にマッピングされます。チャネルに送信される各パケットに、チャンネルに対応するチャンネル番号はWEBRC輻輳制御情報で搬送されます。 WEBRC受信機は、パケットから受信されたセッション内でどのチャネルを決定するチャネル番号を使用します。
At the sender, time is partitioned into time slots, each of duration TSD seconds. There is a fixed number T of time slot indices associated with a session. As time progresses, the current time slot index increases by one modulo T each TSD seconds. The current time slot index CTSI is carried in the WEBRC Congestion Control Information. This allows receivers to perform very coarse-grained synchronization within a session.
送信側では、時間はタイムスロット、継続期間TSD秒のそれぞれに分割されます。セッションに関連付けられたタイム・スロットインデックスの固定数Tがあります。時間が進むにつれて、1つのモジュロT各TSD秒による現在タイムスロットインデックスが増加します。現在のタイムスロットインデックスCTSIはWEBRC輻輳制御情報で運ばれます。これは、受信機がセッション内で非常に粒度の粗い同期を実行することができます。
WEBRC congestion control is achieved by having the sender send packets associated with a given session to several different channels. Individual receivers dynamically join and leave these channels according to the network congestion they experience. These congestion control adjustments are performed at each receiver independently of all other receivers, without any impact on the sender. A packet sequence number is carried in the WEBRC Congestion Control Information. The packet sequence numbers are consecutively numbered per channel and are used by receivers to measure packet loss.
WEBRC輻輳制御は、送信者がいくつかの異なるチャンネルに指定されたセッションに関連付けられたパケットを送信することによって達成されます。個々の受信機は、動的に参加し、彼らが経験するネットワークの混雑に応じてこれらのチャネルを残します。これらの輻輳制御調整は、送信者に影響を与えることなく、独立して、他のすべての受信機の各受信機で行われます。パケットシーケンス番号はWEBRC輻輳制御情報で運ばれます。パケットシーケンス番号が連続してチャンネルごとに番号付けされると、パケット損失を測定するために受信機によって使用されます。
The channels associated with a session consist of one base channel and T wave channels. The packet rate for each channel varies over time. For the base channel, packets are sent to the channel at a low rate BCR_P at the beginning of a time slot and this rate gradually decreases to P*BCR_P at the end of the time slot, where P < 1 is a constant defined later. This pattern for the base channel repeats over each time slot. For each wave channel i, packets are sent to channel i at a rate that first increases very quickly to a high rate and then decreases over time by a fixed fraction P per time slot until a rate of BCR_P is reached at the end of time slot i. Then, for a period of time called the quiescent period, no packets are sent to wave channel i, and thereafter the whole cycle repeats itself, where the duration of the cycle is T*TSD seconds. Thus, the wave channels are going through the same cyclic pattern of packet rate transmission spaced out evenly by TSD seconds.
セッションに関連付けられたチャネルは、一つのベースチャネルとT波のチャネルから成ります。各チャネルのパケットレートは、経時的に変化します。ベースチャネルに対して、パケットは、タイムスロットの開始時に低レートBCR_Pでチャネルに送信され、この速度は徐々にP <1が後で定義される定数であるタイムスロットの末尾にP * BCR_Pに減少します。ベースチャンネルのためのこのパターンは、各タイムスロットにわたって繰り返します。各波長チャネルiについては、パケットがBCR_Pの速度を時間スロットの終わりに到達するまで、最初の高いレートに非常に迅速に増加し、タイムスロット当たりの固定フラクションPによって経時的に低下すること速度で、Iチャネルに送られます私。次に、休止期間と呼ばれる時間の間、全くパケットがチャネルiを振るために送信されず、サイクルの持続時間はT *のTSD秒であり、その後、全体のサイクルは、繰り返されます。したがって、波チャネルはTSD秒によって均等に離間パケットレート伝送の同じ周期パターンを通過しています。
Before joining a session, the receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters needed by a receiver to participate in the session and perform WEBRC congestion control. The session description is determined by the sender and is typically communicated to the receivers out of band. How receivers obtain the session description is outside the scope of this document.
セッションに参加する前に、受信機は、セッションを開始するセッション記述を十分に取得する必要があります。これは、セッションに参加し、WEBRC輻輳制御を実行するための受信機が必要とする関連セッションパラメータを含まなければなりません。セッション記述は、送信者によって決定され、典型的には、帯域外受信機に伝達されます。受信機は入手方法セッション記述は、この文書の範囲外です。
When a receiver initiates a session, it first joins the base channel. The packets in the base channel help the receiver orient itself in terms of what the current time slot index is, which in turn allows the receiver to know the relative rates on the wave channels. The receiver remains joined to the base channel for the duration of its participation in the session.
受信機は、セッションを開始するとき、それは最初のベースチャンネルに参加します。ベースチャネル内のパケットは、次に、受信機は、波のチャネル上の相対速度を知ることができ、現在のタイムスロットインデックスが何であるかの観点において、受信機配向自体を助けます。受信機は、セッションへの参加の期間ベースチャンネルに結合されたままです。
At each point in time the active (non-quiescent) wave channels are ordered into layers, where the lowest layer is the active wave channel whose wave is nearest to completion and the highest layer is the active wave channel whose wave is furthest from completion. (This is almost the same as saying that the lowest layer has the lowest rate and the highest layer has the highest rate. The possible deviation from this is due to the optional non-exponential beginnings of the waves as described in [8].) Each time a wave channel becomes active, it is the highest layer. At the end of each time slot the lowest-layer wave channel becomes quiescent, and thus all active wave channels move down a layer at this point in time. At each point in time a receiver is joined to the base channel and a consecutive set of layers starting with the lowest. Each time a receiver joins a wave channel it joins the lowest layer not yet joined. A receiver always leaves the lowest layer when it becomes quiescent.
各時点でアクティブ（非静止）波チャネルが最も低い層は波完了に最も近い、最も高い層は、その波完了から遠い活性波チャネルでアクティブ波チャネルである層に順序付けられます。 （これは、最下位層が最も低い速度を有し、最上層が最高速度を持っていることを言うとほぼ同じである。このことから可能な偏差は、に記載されているように波の任意の非指数関数始まりによるものである[8]。）波のチャンネルがアクティブになるたびに、最上位層です。各タイムスロットの終わりに最下層の波チャネルが静止状態となり、すべてのアクティブな波チャネルがこの時点で層を下に移動させます。各時点で、受信機は、ベースチャンネルと最も低い始まる層の連続的なセットに結合されています。各時間は、受信機は、それがまだ参加していない最下層を結合波チャネルを合流します。それが静止状態になったときに受信機が常に最下層を残します。
After joining a session the receiver adjusts its rate upwards by joining wave channels in sequence, starting with the lowest layer and moving towards the highest. The rates on the active wave channels are decreasing with time, so the receiver adjusts its rate downwards simply by refraining from joining additional wave channels. Since the layer ordering among the channels changes dynamically over time depending on the current time slot index, it is important that the receiver continually monitor the current time slot index contained in received packets. The reception rate at the receiver is determined by how early each wave channel is joined by the receiver: the earlier the receiver joins a channel with respect to when its wave started, the higher the reception rate.
セッションに参加した後、受信機は、シーケンス内の波のチャンネルを接合最下層で開始し、最高に向かって移動させることにより、上向きの速度を調整します。アクティブ波チャネル上のレートは時間とともに減少しているので、受信機は、追加の波チャネルに参加から単に控えるによって下方にその速度を調整します。チャネル間の層の順序は、現在のタイムスロットインデックスに依存して時間をかけて動的に変化するので、受信機は、連続的に受信したパケットに含まれる現在のタイムスロットインデックスを監視することが重要です。以前の受信機は、その波の開始時に対してチャネル、より高い受信レートを結合：受信機での受信率は、各波長チャネルが受信機によって接合されている方法を早くすることによって決定されます。
Once the receiver is joined to a wave channel, the receiver remains joined to the wave channel until the channel goes quiescent, at which point the receiver MUST leave the channel.
受信機は、波チャネルに結合されると、チャネルが静止状態になるまで、受信機は、受信機がチャネルを残しておく必要があり、その時点で、波長チャネルに結合されたままです。
The way the receiver adjusts its reception rate is inspired by TFRC [9]. The receiver at all points in time maintains a target reception rate, and the receiver is allowed to join the next wave channel if after joining its anticipated reception rate from all the layers it is joined to would be at most its target reception rate. The target rate is continually updated based on a set of measured parameters. The primary parameters are an estimate LOSSP of the average loss probability and an estimate ARTT of the average multicast round-trip time.
受信機は、その受信レートを調整する方法は、TFRCに触発されている[9]。時間内のすべての点における受信機は、目標受信速度を維持し、受信機は、すべての層からの予想される受信レートを接合した後、多くとも、その目標受信速度であろうに参加している場合、次の波チャネルへの参加を許可されています。目標レートを継続的に測定されたパラメータのセットに基づいて更新されます。主要パラメータは、平均損失確率の推定LOSSPと平均マルチキャストラウンドトリップ時間の推定ARTTあります。
In the remainder of this document, log(X) denotes the natural logarithm of X, i.e., the logarithm base 2.71828459... of X.
この文書は、ログ（X）の残りの部分にXのXの自然対数、すなわち、対数ベース2.71828459を示し...
The sender operation is by design much simpler than the receiver operation.
送信者の操作は、設計によって、受信機の動作よりもはるかに簡単です。
The primary input to the sender for the session is SR_b. SR_b is an upper bound to the sender transmission rate in bits per second at any point in time (with some reasonable granularity) in aggregate to all channels. Naturally, this is then also the maximum rate in bits per second that any receiver could receive data from the session at any point in time. It is RECOMMENDED that the sender transmission rate in aggregate to all channels be made constant as described in [8]. It is also RECOMMENDED that the session description indicate whether the aggregate transmission rate is constant, unless there is no ambiguity.
セッションの送信者への主な入力はSR_bです。 SR_bは、すべてのチャネルに集約し（いくつかの合理的な精度で）任意の時点で秒あたりのビットで送信元送信レートの上限です。当然のことながら、これはまた、その後の任意の受信機は、任意の時点でセッションからデータを受信できることをbps単位での最大速度です。 [8]に記載されているように、すべてのチャネルに集約における送信側の伝送速度を一定にすることが推奨されます。また、セッション記述が曖昧存在しない場合を除き、集約伝送速度は、一定であるかどうかを示すことが推奨されます。
The secondary inputs to the sender are listed below. These inputs are secondary because their values will generally be fixed to default values that will not change, because they will be derived from SR_b, or because they are chosen based on non-WEBRC considerations.
送信者への二次入力は以下のとおりです。彼らはSR_bから派生されますので、それらの値は、一般的に、変更されませんデフォルト値に固定されるため、またはそれらは非WEBRCの考慮事項に基づいて選択されているので、これらの入力は、二次的なもの。
o LENP_B is the length of packets in bytes sent to the session. The value of LENP_B depends on the complete protocol, but in general this SHOULD be set to as high a value as possible without exceeding the MTU size for the network that would cause fragmentation.
O LENP_Bセッションに送信されたバイト単位のパケットの長さです。 LENP_Bの値は、完全なプロトコルに依存するが、一般的に、これは断片化を引き起こすネットワークのMTUサイズを超えることなく、できるだけ高い値に設定する必要があります。
o BCR_P is the transmission rate on the base channel at the beginning of a time slot in packets per second. The default value for BCR_P is 1.
O BCR_P毎秒パケット内のタイムスロットの開始時に基本チャネル上の伝送レートです。 BCR_Pのデフォルト値は1です。
o TSD is the time slot duration measured in seconds. The RECOMMENDED value for TSD is 10.
O TSDは秒単位で測定された時間スロット期間です。 TSDの推奨値は10です。
o QD is the minimum quiescent period duration measured in seconds. The RECOMMENDED value for QD is 300.
O QDは秒単位で測定された最小休止時間の期間です。 QDの推奨値は300です。
o P is the multiplicative drop in every channel rate over each time slot. The default value for P is 0.75.
O Pは、各タイムスロットにわたって全てのチャンネルレートで乗算低下です。 Pのデフォルト値は0.75です。
o N is the duration in time slots for each wave. N is also the number of wave channels active at any time. (A wave channel is called active when it is not quiescent.) A sender may choose any value that allows it to produce waves that substantially follow the required exponential shape described in Section 3.1.2. A RECOMMENDED mechanism for relating N to SR_b, BCR_P and P is described in [8].
O Nは、各波のタイムスロットに持続時間です。 Nは、任意の時点でアクティブ波チャネルの数です。 （それが静止しない場合に波チャネルがアクティブと呼ばれている。）、送信者は、それが実質的セクション3.1.2に記載必要な指数形状に従う波を生成することを可能にする任意の値を選択することができます。 SR_b、BCR_PおよびP Nに関連するための推奨メカニズムは、[8]に記載されています。
From these inputs the following fixed sender parameters can be derived as follows.
次のようにこれらの入力から、次の固定送信者のパラメータを導出することができます。
o SR_P = SR_b/(8*LENP_B) is the sender transmission rate in packets per second.
O SR_P = SR_b /（8 *のLENP_B）秒あたりのパケットで送信元送信レートです。
o BCR_b = 8*LENP_B*BCR_P is the rate of the base channel at the beginning of a time slot in bits per second.
O BCR_b = 8 * LENP_B * BCR_P bps単位でタイムスロットの開始時に基本チャネルの割合です。
o L = ceil(BCR_P*TSD*(P-1)/log(P)) is the number of base channel packets sent in each time slot.
O L = CEIL（BCR_P * TSD *（P-1）/ログ（P））が各タイムスロットで送信されたベースチャンネルパケットの数です。
o Q = ceil(QD/TSD) is the number of quiescent time slots per cycle for a wave channel.
O Q = CEIL（QD / TSD）は波長チャネルのサイクル当たりの休止時間スロットの数です。
o T = N + Q is the total number of time slots in a cycle. T is also the total number of wave channels.
O T = N + Qは、サイクルにおけるタイムスロットの総数です。 Tはまた、波チャネルの総数です。
o For the base channel CN = T and for the wave channels CN = 0,1,...,T-1. The sender has the description of the channels assigned to the session and the mapping between the channels and the CNs.
O CNベースチャンネルCN = Tの場合と波長チャネルのため= 0,1、...、T-1。送信者は、セッションに割り当てられたチャネルの記述およびチャネルおよびCNSとの間のマッピングを有します。
o C = TSD*T is the total duration of a cycle in seconds.
O C = TSD * Tは、秒サイクルの全継続時間です。
The sender keeps track of the current time slot index CTSI. The value of CTSI is incremented by 1 modulo T each TSD seconds. The value of CTSI is placed into each packet in the format described in Section 5. For each packet sent to the session, the sender also places the channel number CN of the channel into the packets in the format described in Section 5. Recall that CN = T for the base channel and CN = 0,1,...,T-1 for the wave channels.
送信者は、現在のタイムスロットインデックスCTSIを追跡します。 CTSIの値が1つのモジュロT各TSD秒だけインクリメントされます。 CTSIの値をセッションに送信される各パケットについて第5節に記述された形式で各パケットに配置され、送信者はまた、セクション5リコールに記載の形式でパケットにチャンネルのチャンネル番号CNを配置し、そのCN =ベースチャネルに対するT及びCN = 0,1、...、T-1波長チャネルのため。
For each packet sent to the session, the sender calculates a packet sequence number PSN and places it into the packet. The value of PSN is scoped by CN, and the value of PSN is consecutively increasing within each channel. Furthermore, for each wave channel, the last packet sent before the channel becomes quiescent must have the maximum possible PSN value. When the short format for Congestion Control Information is used (see Section 5.1), this implies that for any wave channel the last PSN value sent to the channel just before the channel becomes quiescent is 2^16-1 = 65,535. Similarly, when the long format for Congestion Control Information is used (see Section 5.2), the PSN for the final packet of any wave is 2^32-1 = 4,294,967,295. The PSN of the initial packet of a wave thus depends on TSD, P, BCR_P and SR_P. For the base channel, the first packet of each time slot has a PSN congruent to zero modulo L. Hence, instead of 2^16 - 1 or 2^32 - 1 being the highest PSN used (depending on the choice of short format or long format Congestion Control Information), the highest PSN is one less than the largest multiple of L that does not exceed 2^16 (short format) or 2^32 (long format). The format for the PSN within packets is described in Section 5.
セッションに送信された各パケットについて、送信側はパケットシーケンス番号PSNを計算し、パケットにそれを配置します。 PSNの値は、CNによってスコープされ、PSNの値が連続して各チャンネル内に増加しています。また、各波長チャネルについて、チャネルの前に送信された最後のパケットは可能な最大PSN値を有していなければならない静止状態となります。輻輳制御情報の短い形式は（セクション5.1を参照）が使用される場合、これは任意の波のためのチャネルが静止状態になる直前のチャンネルに送られた最後のPSN値チャネルことを意味し、2 ^ 16-1 = 65,535です。輻輳制御情報の長い形式（セクション5.2を参照）を使用する場合も同様に、任意の波の最終パケットのPSNは、2 ^ 32-1 = 4,294,967,295です。波の最初のパケットのPSNは、このようにTSD、P、BCR_PとSR_Pに依存します。ベースチャネルに対して、各タイムスロットの最初のパケットは、したがってゼロモジュロLに一致PSNを有し、代わりに2 ^ 16 - 1または2 ^ 32 - 1使用される最高PSNである（短い形式の選択に応じて、または長い形式の輻輳制御情報）は、最高のPSNは、2 ^ 16（短い形式）、または2 ^ 32（長い形式）を超えないLの最大倍数より1つ少ないです。パケット内でPSNの形式は、セクション5に記載されています。
The rate at which packets are sent to the base channel starts at BCR_P packets per second at the beginning of each time slot and decreases exponentially to P*BCR_P at the end of that time slot.
パケットがベースチャンネルに送信される速度は、各タイムスロットの開始時に毎秒BCR_Pパケットで開始し、そのタイムスロットの終わりでP * BCR_Pに指数関数的に減少します。
The packet rate for the wave channels is more complicated. Each wave channel carries a sequence of waves separated by quiescent periods. On each wave channel each wave is active during N time slots followed by a quiescent period of Q time slots. The waves on wave channel i end at the ends of time slots with CTSI i. Therefore wave channel i is active during time slots i-N+1 modulo T, i-N+2 modulo T, ..., i and is quiescent for time slots i+1 modulo T, i+2 modulo T, ..., i+Q modulo T. Wave channel i first becomes active within time slot i-N+1 modulo T at a point in time that may depend on the value of SR_b.
波チャネルのパケットレートはより複雑です。各波長チャネルは、休止期間によって分離された波のシーケンスを運びます。各波長チャネル上の各波がQタイムスロットの休止期間が続くN個のタイムスロットの間アクティブです。波長チャネル上の波iはCTSI Iとタイムスロットの端部で終わります。したがって、iはタイムスロットI-N + 1モジュロT、I-N + 2モジュロT、...、iおよびiは+ 1つのモジュロT、I + 2モジュロTタイムスロットのために静止している、中にアクティブであるチャネル波.. 。、私が最初SR_bの値に依存してもよい時点で+ 1つのモジュロT I-Nのタイムスロット内でアクティブになるQモジュロT.波チャネルを+。
Except for at most the first two time slots after a wave becomes active, the packet rate of the wave MUST decrease exponentially by a factor of P per TSD seconds, down to a rate of BCR_P at the end of the last active time slot. At the beginning of each wave, i.e., for at most the first two time slots when the wave becomes active, the rate MAY deviate from this exponential form so that the total sending rate in aggregate to all of the channels is constant. A RECOMMENDED design for the beginnings of waves to achieve this goal is described in [8].
波がアクティブになった後で最も最初の2つのタイムスロットを除いて、波のパケットレートは、ダウン最後のアクティブなタイムスロットの終わりにBCR_Pの速度に、TSD秒あたりPの係数で指数関数的に減少しなければなりません。チャネルの全てを総計でレートを送信合計が一定となるように各波の開始時、すなわち、波がアクティブになると多くとも最初の2つのタイムスロットのために、速度は、この指数関数形からずれてもよいです。この目標を達成するために、波の始まりのために推奨される設計は、[8]に記載されています。
The bulk of the complexity in WEBRC is in the receiver operation. For ease of explanation, suppose for the moment that during the reception there is no packet loss and packets are arriving at exactly the rate at which they were sent. The sender transmission rate to the channels is designed so that the receiver reception rate behaves as follows.
WEBRCにおける複雑さの大部分は受信機動作です。説明を容易にするために、受信時にパケット損失がないと、パケットは、彼らが送信された時に正確な速度で到着している瞬間を仮定します。次のように受信機の受信レートが振る舞うようにチャネルの送信元送信レートに設計されています。
Upon entering a session, the receiver immediately joins the base channel. When the receiver wants to increase its rate, it joins consecutive layers starting with the lowest and moving towards the highest. (Recall that the designations of lowest to highest change as waves become active and quiescent.) When the receiver wants to maintain its current reception rate and it is already joined to the lowest NWC layers, if the receiver joins channel i-1+NWC modulo T sometime during time slot i then the receiver joins channel i+NWC modulo T TSD seconds later in time slot i+1. When the lowest layer becomes quiescent the receiver leaves the channel.
セッションに入ると、受信機は直ちにベースチャンネルに参加します。受信機はそのレートを増加させたい場合は、最低で始まり、最高に向かって移動の連続した層を結合します。 （最高変化に対する最低の指定が波がアクティブおよび休止になるようにすることを思い出してください。）受信機は、チャネルI-1 + NWCモジュロ参加した場合、受信機は、現在の受信レートを維持したいとそれが既に最低NWC層に接合されている場合Tはいつかタイムスロットの間、私は、受信機iは、後のタイムスロットI + 1にNWCモジュロT TSDの秒+チャネルに参加します。最下層が静止になったとき、受信機は、チャネルを出ます。
Suppose the receiver wants to decrease its rate till it is joined to just the base channel. Assume that a receiver is joined to the lowest NWC < N-2 layers at the beginning of time slot i, i.e., wave channels i, i+1 modulo T,..., i+NWC-1 modulo T. Then, the aggregate packet reception rate of the receiver over the next NWC time slots will behave as follows if the receiver does not join any wave channels during this time. At the beginning of time slot i the receiver reception rate is BCR_P*(1 + (1/P) + (1/P)^2 + ... + (1/P)^NWC). Then the receiver reception rate decreases by a factor of P over the duration of each time slot, and at the end of each time slot the reception rate decreases by an additive amount of P*BCR_P. At the end of time slot i+NWC-1 mod T, the receiver reception rate is BCR_P*(1+P), and at the beginning of time slot i+NWC mod T the receiver is joined only to the base channel and its reception rate is BCR_P.
受信機は、それがちょうどベースチャンネルに結合されるまでその速度を低下させたいとします。受信機は、タイムスロットの開始時に最低NWC <N-2層に接合されていると仮定するI、すなわち、波チャネルiは、iが+ 1つのモジュロT、...、私はその後、NWC-1モジュロTを+受信機はこの時間の間の任意の波長チャネルに参加していない場合、次のように次NWCタイムスロットにわたる受信機の集約パケット受信速度が動作します。タイムスロットの開始時に私は、受信機の受信率がBCR_P *（1 +（1 / P）+（1 / P）^ 2 + ... +（1 / P）^ NWC）です。 P * BCR_Pの添加量によって、各タイムスロットの持続時間にわたってP倍レシーバ受信速度が低下し、各タイムスロットの終わりの受信速度が低下します。 iはNWC-1 MOD Tを+タイムスロットの終わりには、受信機の受信レートはBCR_P *（1つの+ P）であり、タイムスロットの開始時に私は、受信機のみのベースチャンネルに結合し、そのされるNWC MOD Tを+受信レートはBCR_Pです。
Before joining a session the receiver MUST know the mapping between the CNs and the channels. Upon joining the session or shortly thereafter, it SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of these values may be computed or measured once the receiver has joined the session. For example, the receiver MAY obtain LENP_B and T from the first packet received from the base channel, and the receiver MAY measure BCR_P once it is joined to the base channel. The values of P, Q and TSD MAY be fixed to default values built into the receiver that do not change from session to session, and the value of N MAY be computed as T-Q. The receiver
セッションに参加する前に、受信機は、CNSおよびチャネル間のマッピングを知っている必要があります。セッションに参加する際、または受信機がセッションに参加した後直後、それはこれらの値のいくつかはLENP_B、BCR_P、TSD、P、N、L、Q及びTの値を計算または測定することができる有していなければなりません。例えば、受信機は、ベースチャネルから受信した最初のパケットからLENP_B及びTを得ることができ、それはベースチャンネルに結合されると、受信機はBCR_Pを測定することができます。 P、QおよびTSDの値は、セッション間で変化しない受信機に組み込まれているデフォルト値に固定してもよいし、Nの値は、T-Qとして計算することができます。受信機
SHOULD know whether the sender is employing a technique to produce constant aggregate rate as described in [8].
送信者が[8]に記載のように一定の集約レートを生成する手法を採用しているかどうかを知るべきです。
When a receiver first joins a session, it MUST first join just the base channel and start receiving packets to determine the current time slot index. If during the course of the session the receiver continually loses a high fraction of the packets from the base channel even when the receiver is only joined to the base channel, the receiver SHOULD leave the session.
受信機は、最初のセッションに参加するとき、それは最初だけベースチャンネルに参加し、現在のタイムスロットインデックスを決定するために、パケットの受信を開始しなければなりません。セッションの進行中に、受信機が連続的に受信機が唯一のベースチャンネルに結合されていても、ベースチャネルからのパケットの高い画分を失った場合、受信機は、セッションを終了すべきです。
The receiver MAY also have other individually set parameters that may be used to determine its behavior. One such parameter is MRR_b:
受信機はまた、その挙動を決定するために使用され得る他の個別セットのパラメータがあるかもしれません。このようなパラメータの一つはMRR_bです。
o MRR_b is the maximum receiver reception rate in bits per second. This may be used to determine the maximum reception rate this receiver is willing to reach. Thus, the maximum reception rate that the receiver can possibly achieve in the session is the minimum of SR_b and MRR_b. A recommended value of MRR_b for a receiver is the bandwidth capacity of the last link to the receiver. MRR_P is the maximum receiver reception rate in packets per second, i.e., MRR_P = MRR_b/(8*LENP_B).
O MRR_b毎秒ビット単位での最大受信機受信レートです。これは、この受信機が到達する意思がある最大受信レートを決定するために使用することができます。したがって、受信機は、可能性のセッションで達成可能な最大受信レートはSR_bとMRR_bの最小値です。受信機のためのMRR_bの推奨値は、受信機への最後のリンクの帯域幅容量です。 MRR_Pは、秒あたりのパケットの最大受信機の受信速度であり、即ち、MRR_P = MRR_b /（8 *のLENP_B）。
As outlined in the introduction, the way a receiver adjusts its reception rate is inspired by TFRC [9]. The receiver at all points in time maintains a target reception rate, and the receiver is allowed to join the next wave channel if joining would increase its reception rate to at most its target reception rate. The target rate is continually updated based on a set of measured parameters.
導入部で概説したように、方法は、受信機は、受信レートがTFRC触発さ調整[9]。時間内のすべての点における受信機は、目標受信速度を維持し、受信機は、最大で、その目標受信レートにその受信レートを増加させる接合場合は次の波チャネルへの参加を許可されています。目標レートを継続的に測定されたパラメータのセットに基づいて更新されます。
Two primary parameters are the estimate LOSSP of the average loss probability and the estimate ARTT of the average MRTT. Both LOSSP and ARTT are moving averages of measurements based on discrete events. For many of the other estimates calculated by WEBRC, using an exponentially weighted moving average (EWMA) with a fixed averaging fraction is sufficient. However, the calculations of LOSSP and ARTT require a more general and sophisticated filtering approach.
二つの主要なパラメータは、平均損失確率の推定LOSSP平均MRTTの推定ARTTあります。 LOSSPとARTT双方は、離散イベントに基づいて測定値の平均を移動します。一定の平均分率指数加重移動平均（EWMA）を使用して、WEBRCによって算出他の見積りの多くのために十分です。しかし、LOSSPとARTTの計算がより一般的で洗練されたフィルタリングアプローチが必要です。
The design of TFRC [9] reflects that, because the average packet loss probability can vary by orders of magnitude, any estimate of the average loss probability based on either a fixed number of packets or on a fixed period of time with a fixed averaging fraction will be poor. In TFRC the average is estimated from the numbers of packets between beginnings of loss events, and the number of loss events used is fixed.
TFRCの設計は、[9]平均パケット損失確率が、桁違いにパケットの固定された数のいずれかまたは固定平均画分と一定時間に基づいて、平均損失確率の推定値を変化させることができるので、ことを反映します悪くなります。 TFRCに平均は損失事象の始まりとの間のパケットの数から推定され、使用される損失事象の数が固定されています。
The estimate LOSSP of the average loss probability of the receiver is maintained in a manner somewhat similar to that described in TFRC [9]. The WEBRC receiver estimates the inverse of the average loss probability by applying two EWMA filters to the packet reception measurements, a time-based filter with smoothing constant 0 < Nu < 1 and a loss-based filter with smoothing constant 0 < Delta < 1. The recommended values for the smoothing constants are Nu = 0.3 and Delta = 0.3. The reason for the time-based filter is that the loss events in WEBRC are bursty; they typically occur just after a new wave has been joined. To smooth out this burstiness, the time-based filter is applied to the packet reception measurements at the end of each epoch to smooth out the bursty loss events over a few time slot durations. Intuitively, the time-based filter averages packet reception events such that the events are smoothed out over an interval of time proportional to TSD/Nu seconds. The loss-based filter, similar to what is suggested in TFRC, is applied to the output of the time-based filter to produce the estimate of the inverse of the average loss probability. Intuitively, the loss-based filter averages loss events such that each loss event is averaged in with weight Delta.
受信機の平均損失確率の推定LOSSPはTFRC [9]に記載のものと幾分同様に維持されます。 WEBRC受信機は、パケット受信測定値、定数0 <デルタ<1を平滑化して一定0 <ニュ<1及び損失ベースの平滑化フィルタを用いて時間ベースのフィルタへの2つのEWMAフィルタを適用することによって、平均損失確率の逆数を推定します。平滑化定数の推奨値は、ニュースキン= 0.3とデルタ= 0.3です。時間ベースのフィルタの理由はWEBRCの損失イベントがバースト性であるということです。彼らは通常、新しい波が参加された直後に発生します。このバーストを平滑化するために、時間ベースのフィルタは、いくつかのタイムスロット期間にわたってバースト損失事象を平滑化するために、各エポックの終わりにパケット受信測定値に適用されます。直感的に、イベントはTSD /ニュー秒に比例した時間間隔に渡って平滑化されるような時間ベースのフィルタ平均パケット受信イベント。 TFRCで提案されているものと同様の損失ベースのフィルタは、平均損失確率の逆数の推定値を生成するために時間ベースのフィルタの出力に適用されます。直感的に、各損失事象が重量デルタで平均化されるように、損失ベースのフィルタの平均損失イベント。
As described later, LOSSP is initialized at the end of slow start and occasionally reset due to other events. Let W and X be counts of packets, let Y be a count of loss events and let Z be the long-term estimate of the inverse of the average loss probability. Whenever the value of LOSSP is initialized or reset, the values of W, X, Y and Z are also initialized or reset.
後述するように、LOSSPはスロースタートの終了時に初期化され、時には他のイベントのためにリセットされます。 Yは、損失事象の数であるとすると、Zは、平均損失確率の逆数の長期的な推定値であるとする、WおよびXは、パケットのカウントとします。 LOSSPの値が初期化またはリセットされたとき、W、X、Y及びZの値も初期化又はリセットされます。
Recall that TSD is the duration of a time slot. The epoch length EL is the duration of time between decisions to adjust the reception rate. Generally EL is much smaller than TSD, and the RECOMMENDED values are EL = 0.5 seconds and TSD = 10 seconds.
TSDは、タイムスロットの持続時間であることを思い出してください。エポックの長さELは、受信レートを調整するための決定との間の時間の持続時間です。一般にELはTSDよりもはるかに小さく、推奨値は、EL = 0.5秒であり、TSDは、10秒=
Define G = Nu*EL/TSD as the amount of time-based smoothing to perform at the end of each epoch. The update rules for W, X, Y, Z, and LOSSP are the following:
各エポックの終わりに実行するために時間ベースの平滑化の量としてG =ニュー* EL / TSDを定義します。 W、X、Y、Z、およびLOSSPの更新ルールは以下の通りです。
o At the end of each epoch, adjust X, Y and Z and compute LOSSP as follows:
各エポックの終わりに、O、X、Y及びZを調整し、次のようにLOSSPを計算します。
Z = Z*(1-Delta)^(G*Y) + G*X/(G*Y+1)*(1-(1-Delta)^(G*Y+1))
Z = Z×（1-デルタ）+（G * Y）+ G * X /（G * Y + 1）*（1-（1-デルタ）+（G * Y + 1））
X = X*(1-G)
X = X *（1-G）
Y = Y*(1-G)
Y = Y *（1-G）
Z1 = Z*(1-Delta)^Y + X/(Y+1)*(1-(1-Delta)^(Y+1))
Z1 = Z×（1-デルタ）+ Y + X /（Y + 1）*（1-（1-デルタ）+（Y + 1））
Z2 = Z*(1-Delta)^(Y+1) + (X+W+1)/(Y+2)*(1-(1-Delta)^(Y+2))
Z2 = Z×（1-デルタ）+（Y + 1）+（X + W + 1）/（Y + 2）*（1-（1-デルタ）+（Y + 2））
LOSSP = 1/max{Z1,Z2,1}
LOSSP = 1 /最大{Z1、Z2,1}
o For each packet event (whether it is a received packet or a lost packet), W = W + 1
各パケット・イベント（それが受信したパケットまたは紛失したパケットであるかどうか）、W = W + 1のためにO
o At the beginning of each loss event, update W, X, and Y as follows:
各損失事象の開始時にO、次のようにW、X、およびYを更新します。
X = X + W
X = X + W
W = 0
W = 0
Y = Y + 1
Y = Y + 1
The intuition behind these update rules is the following. If just loss-filtering were used to update Z, then Z would be decreased by a multiplicative amount 1 - Delta for each loss event and Z would be increased by an additive amount Delta for each packet. To smooth out loss events over more than one time slot, these adjustments are filtered into Z over time, at the rate of a fraction G at the end of each epoch. Thus, the variables X and Y are counts of the portions of the packets and loss events, respectively, that have not yet been filtered into the long-term memory Z. W is the count of packets since the last loss event started. This explains why W is increased by one for each packet and Y is increased by one for each loss event. At the end of each epoch a fraction G of both X and Y are filtered into Z according to the loss-filter rule described above, and then the same fraction G is removed from both X and Y to account for the fact that this portion has been filtered into Z. The LOSSP calculation combines the short-term history (X,Y) with the long-term history Z and also allows the arrivals since the last loss W to have some influence. The value of Z2 is what Z1 would become were the next packet to be lost.
これらの更新ルールの背後にある直感は以下の通りです。各損失事象のデルタ及びZは、各パケットの添加量デルタだけ増加されるであろう - ちょうど損失フィルタリングがZを更新するために使用された場合には、Zは乗法量1だけ減少されるであろう。複数のタイムスロットにわたって損失イベントを平滑化するために、これらの調整は、各エポックの終わりにフラクションGの速度で、時間をかけてZに濾過します。最後の損失イベントが開始されてからこのように、変数XとYは、まだ長期メモリZ.のW中に濾過されていないそれぞれのパケットおよび損失事象の部分の数は、パケットのカウントがされています。これは、Wは、パケットごとに1ずつ増加され、Yは、各損失事象のために1つずつ増加される理由を説明します。それぞれの端部にXとYの両方の画分Gは、上記損失フィルタルールに従ってZに濾過され、その後、同じ画分Gは、この部分が持っているという事実を考慮するために、XとYの両方から除去され、エポックZ.ザLOSSP計算に濾過されては長期履歴Zと短期履歴（X、Y）を組み合わせ、また、最後の損失W以降の到着は、いくつかの影響を与えることを可能にします。 Z2の値は、次のパケットが失われたZ1はなるものです。
To reset the loss calculation to a value LOSSP = a, the state variables are set as follows:
次のように値LOSSPに損失計算をリセットする=、状態変数が設定されています。
W = 0
W = 0
X = 0
X = 0
Y = 0
Y = 0
Z = 1/a
Z = 1 / A
The receiver maintains an average round-trip time, ARTT, as a measurement-based filter of MRTT measurements using a smoothing constant 0 < Alpha < 1. The RECOMMENDED value for Alpha is 0.25.
受信機は、α<1 <平滑化定数0を使用してMRTT測定の測定系フィルタとして、平均往復時間、ARTTを維持アルファの推奨値は0.25です。
Each time the receiver joins a channel (either the base channel upon entering a session or wave channels continually), it makes a measurement of the multicast round-trip time MRTT as follows. Let V be an auxiliary variable that is used that keep track of the average of the square of the MRTT measurements. When the receiver sends the join for the channel it records the current time JoinTime and sets a Boolean variable JOINING to true. When the first packet is received from the channel the receiver records the current time FirstTime and resets the value of JOINING to false. If it is the base channel that has been joined, ARTT is set to FirstTime-JoinTime and V is set to ARTT*ARTT. Otherwise, the value of MRTT is set to (FirstTime - JoinTime) - log(1/P)/2/(1-P)/BCR_P * P^NWC. (Note that this value can be negative.) Then, ARTT is updated as follows. Let Omega = Alpha*ARTT*ARTT/V, and at the Kth MRTT measurement let Rho = Omega/(1-(1-Omega)^(K+1)). (Note that as K grows Rho approaches Omega.) Then, V is updated to (1-Rho)*V+Rho*MRTT*MRTT and ARTT is updated to max{P*ARTT,(1-Rho)*ARTT+Rho*MRTT}.
次のように、受信機がチャネル（連続セッションまたは波チャネルに入るとベースチャンネルのいずれか）を参加するたびに、マルチキャスト往復時間MRTTの測定を行います。 VはMRTT測定値の二乗の平均を追跡することに使用される補助変数とします。受信機は、チャネルのために参加し送信すると、それは現在の時刻JoinTimeを記録し、真との接合ブール変数を設定します。最初のパケットがチャネルから受信した場合、受信機は、現在時刻FIRSTTIMEを記録し、falseに接合する値をリセットします。それが接合されたベースチャネルである場合、ARTTはFIRSTTIME-JoinTimeおよびVに設定されているARTT * ARTTに設定されています。ログ（1 / P）/ 2 /（1-P）/ BCR_P * P ^ NWC - そうでなければ、MRTTの値は、（ - JoinTime FIRSTTIME）に設定されています。 （この値は負であってもよいことに留意されたい。）以下のように、ARTTが更新されます。オメガ=アルファ* ARTT * ARTT / Vをしてみましょう、とK番目MRTT測定でのRhoをしましょう=オメガ/（1-（1-オメガ）^（K + 1））。 （Kが大きくなるにつれてのRhoオメガに近づくことに注意してください。）次に、V（1-のRho）に更新される* V +のRho * MRTT * MRTTとARTTが最大{P * ARTT、（1-のRho）* ARTT +のRhoに更新されます* MRTT}。
Usually ARTT is updated to the second term in the max, and in this case ARTT is the EWMA of the previous value of ARTT and the new MRTT, with a weighting on the new MRTT that as K grows is proportional to the square of the previous ARTT divided by the previous average V of the square of the MRTT. Thus, if there is not much variance in the previous MRTTs relative to the square of their average then the new MRTT will be filtered into ARTT with a high weight, whereas if there is a lot of variance in the previous MRTTs relative to the square of their average then the new MRTT will be filtered into ARTT with a low weight. The intuitive rationale for this is that in general the number of measurements needed to compute a meaningful average for a random variable is proportional to its variance divided by the square of its average; see, e.g., [6]. By making the weight factor depend on previous measurements in this way, the appropriate weight to use to average the new MRTT into the ARTT self-adjusts automatically to the variability in the measurements.
通常ARTTは、最大で第二項に更新されており、この場合にはARTTはKの成長に合わせて、前の2乗に比例することが新しいMRTTの重みで、ARTTと新しいMRTTの前の値のEWMAですMRTTの正方形の前の平均Vで割っARTT。それらの平均の平方に対する前MRTTsにおける多くの変動がない場合に分散の多くの正方形に対して前MRTTsであった場合に対し、このように、新しいMRTTは、高重量でARTTに濾過しますその平均は、新しいMRTTは、低体重でARTTにフィルタリングされます。このため、直感的な理論的根拠は、一般にランダム変数の意味のある平均値を計算するために必要な測定値の数は、その平均の平方で割ったその分散に比例するということです。参照、例えば、[6]。重み係数は、このように、以前の測定値に依存することにより、適切な重量が測定の変動に自動的ARTT自己調整するに新しいMRTTを平均化するために使用します。
The receiver calculates the reception rate REQN based on the TCP equation as follows: REQN = 1/(ARTT*sqrt{LOSSP}(0.816 + 7.35*LOSSP*(1+32*LOSSP^2))). This equation comes from TFRC [9].
次のように受信機は、TCPの式に基づいて受信率を計算REQN：REQN = 1 /（ARTTの*のSQRT {LOSSP}（0.816 + 7.35 * LOSSP *（1 + 32 * LOSSP ^ 2）））。この式は、TFRCから来ている[9]。
The receiver makes decisions on whether or not to join another wave channel at equally-spaced units of time called epochs. The duration of an epoch in seconds, EL, is set to be a small fraction of TSD, so that decisions to join a channel can be made at a much finer granularity than TSD. A standard setting is EL = TSD/20. Thus, with the recommended setting of TSD = 10, it is RECOMMENDED that EL = 0.5.
受信機は、時間と呼ばれるエポックの等間隔単位で別の波長チャネルに参加するか否かの決定を行います。チャンネルに参加する意思決定がTSDよりもはるかに細かい粒度で行うことができるように秒でエポックの期間、ELは、TSDのごく一部に設定されています。標準設定では、EL = TSD / 20です。したがって、TSD = 10の推奨設定で、それはそれがEL = 0.5が推奨されます。
There are two averaged reception rates maintained by the receiver: TRR_P, the true reception rate, and ARR_P, the anticipated reception rate. These are used for different purposes and thus are calculated quite differently. Recommended values for the filtering weights Beta and Zeta are provided at the end of this subsection.
TRR_P、真の受信レート、およびARR_P、予想される受信レート：受信機によって維持2人の平均受信率があります。これらは、異なる目的のために使用されているので、全く異なる計算されます。フィルタリングの重みベータ版とゼータの推奨値は、このサブセクションの端に設けられています。
In start-up mode, the true reception rate TRR_P is used to ensure that the receiver does not increase its reception rate too quickly above its current reception rate. In the transition from start-up mode to normal operation and in normal operation, TRR_P is used in setting the slow start rate. TRR_P is calculated based on the measurement of RR_P, where RR_P is the receiver reception rate in packets per second measured at the beginning of an epoch averaged over the epoch that just ended. TRR_P is initialized to BCR_P + k*log(P)/TSD when the first base channel packet of the session arrives, where k is the PSN of the packet reduced modulo L. TRR_P is updated to (1-Zeta)*TRR_P + Zeta*RR_P at the beginning of each epoch after RR_P is measured for the previous epoch.
起動モードでは、真の受信レートTRR_Pは、受信機が現在の受信レートの上にあまりにも早くその受信率を増加させないことを確実にするために使用されます。起動モードから通常動作に、通常動作中の遷移において、TRR_Pはスロースタート速度を設定する際に使用されます。 TRR_PはRR_Pがちょうど終了したエポックにわたって平均エポックの開始時に測定された秒当たりのパケット内の受信機の受信速度でRR_P、の測定に基づいて計算されます。 TRR_Pは、kが（1-ゼータ）* TRR_P +ゼータに更新されるモジュロL. TRR_Pを低減パケットのPSNであるBCR_P + K *ログ（P）セッションの最初の基本チャネルパケットが到着/ TSD、に初期化されます* RR_P後の各エポックの先頭にRR_Pは、以前のエポックのために測定されます。
The anticipated reception rate ARR_P is the receiver's estimate of the total instantaneous rate of the currently joined channels. It is used to compare against the target rate to decide whether or not the receiver should increase its reception rate by joining the next higher unjoined layer. ARR_P is calculated based on a measurement IRR_P and on the number of joined wave channels NWC. The ideal reception rate IRR_P is the reception rate in packets per second including both received and lost packets; like RR_P, it is measured at the beginning of the epoch and averaged over the previous epoch. ARR_P, IRR_P and NWC are updated as follows:
予想される受信レートARR_P現在参加チャネルの合計瞬間レートの受信機の推定値です。受信機が次のより高い非接合層を接合することにより、その受信速度を増加させるかどうかを決定する目標レートと比較するために使用されます。 ARR_Pは、測定IRR_P上と接合波チャネルNWCの数に基づいて計算されます。理想的な受信レートIRR_P両方受信し、失われたパケットを含む第2あたりのパケットの受信レートです。 RR_Pのように、それは、エポックの開始時に測定され、前のエポックで平均化。次のようにARR_P、IRR_PとNWCが更新されます。
o NWC is initialized to 0.
O NWCは0に初期化されます。
o When the first base channel packet arrives, ARR_P is set to BCR_P + k*log(P)/TSD, where k is the PSN of the packet reduced modulo L.
最初のベース・チャネル・パケットが到着すると、ARR_PをBCR_P + K *ログ（P）に設定されているO / kはパケットのPSNであるTSDは、モジュロL.を低減しました
o At the beginning of each epoch, IRR_P is measured over the previous epoch and then ARR_P is updated to P^(EL/TSD)*(1-Beta)*ARR_P + Beta*IRR_P. Then if ARR_P exceeds ARR_P_max = ((1/P)^(NWC+1)-1)/((1/P)-1)*BCR_P, ARR_P is updated to ARR_P_max.
各エポックの開始時Oは、IRR_Pは前のエポックに亘って測定され、その後、ARR_Pは、P ^（EL / TSD）*（1-ベータ版）に更新される* ARR_P +ベータ* IRR_P。 ARR_Pを超える場合、ARR_P_max =（（1 / P）^（NWC + 1）-1）/（（1 / P）-1）* BCR_P、ARR_PはARR_P_maxに更新されます。
o When a join is made to the next higher unjoined layer, NWC is updated to NWC+1 and then ARR_P is multiplicatively increased by the factor ((1/P)^(NWC+1)-1)/((1/P)^NWC-1). (Joins happen at epoch boundaries; this adjustment is in addition to the adjustment above.)
次に高い未結合層に言及する場合参加O、NWCはNWC + 1に更新され、その後ARR_Pは乗算係数（（1 / P）^（NWC + 1）-1）/（（1 / Pだけ増加されます）^ NWC-1）。 （エポックの境界で起こる参加、この調整は、上記の調整に加えてあります。）
o Each time a next time slot index is detected, ARR_P is additively increased by (1-P)*BCR_P to account for the change in rate on the base channel. In addition, the bottom layer in the previous time slot has just gone quiescent and thus a message to leave this layer has been sent, ARR_P is additively decreased by BCR_P and NWC is decremented by 1. Thus, the combination of these effects on ARR_P is that it is additively decreased by P*BCR_P.
O次のタイムスロットインデックスが検出されるたびに、ARR_Pは加法ベースチャネル上のレートの変化を考慮するために、（1-P）* BCR_Pだけ増加させます。加えて、前の時間スロットにおける底層がちょうど送信された静止し、この層を残す従ってメッセージなった、ARR_PはARR_P上のこれらの効果の組み合わせである、加法BCR_Pにより減少し、NWCは、このように1だけデクリメントされますそれは付加的にPの*のBCR_P減少していること。
Consider for the moment what happens if Beta = 0 and ARR_P is an accurate estimate of the total rate of the joined channels. The adjustments to ARR_P upon joining and leaving wave channels, with the passage of epochs, and with the detection of time slot changes will then cause ARR_P to remain an accurate estimate. In practice, Beta MUST be positive; allowing an influence of IRR_P prevents ARR_P from drifting away from being an accurate estimate of the total joined rate.
ベータ= 0とARR_Pが参加チャネルの合計量の正確な推定値である場合に何が起こるのか一瞬考えてみましょう。エポックの経過とともに、タイムスロット変化の検出を、波長チャネルに参加し、離脱時ARR_Pする調整がその後ARR_Pが正確な推定値のままになります。実際には、ベータ版は正でなければなりません。 IRR_Pの影響を許容する離れる総参加率の正確な推定値であることから漂流からARR_Pを防止します。
The motivation for separate estimates TRR_P and ARR_P is as follows. ARR_P is needed for comparison with the TFRC-inspired target rate because there is no lag before it reflects the potential rate increase resulting from joining the next higher layer and because it measures the total possible impact on the network since it also includes lost packets. TRR_P is needed because it reflects the rate of data arriving at the receiver and this is used to ensure that there is not a large gap between the joined rate and the receiving rate.
次のように個別の見積りのTRR_PとARR_Pの動機です。それは次の上位層を接合するから、それはまた、失われたパケットが含まれているので、ネットワーク上の合計の可能な影響を測定するため、得られた潜在的なレート増加を反映する前に、何の遅れがないためARR_PはTFRC風の目標レートと比較するために必要とされます。 TRR_Pは、それが受信機に到着するデータのレートを反映するために必要とされ、これは接合速度と受信速度との間に大きなギャップが存在しないことを保証するために使用されます。
The recommended values for Beta and Zeta depend on whether the receiver is in start-up mode (SSR_P = infinity). In start-up mode, it is RECOMMENDED that Beta = (1 - P^(0.25))/2 and Zeta = sqrt(P)/(1 + sqrt(P)). In normal operation, it is RECOMMENDED that Beta = 1 - (P/(1+P))^(EL/TSD) and Zeta = 2*EL/(4+TSD).
ベータおよびゼータの推奨値は、受信機は、起動モード（SSR_P =無限大）であるか否かに依存します。起動モードでは、それが推奨されているベータ=（1 - P ^（0.25））/ 2とゼータはSQRT（P）を= /（1 + SQRT（P））。通常の動作では、それが推奨されるベータ= 1 - （P /（1 + P））^（EL / TSD）とゼータ= 2×EL /（4 + TSD）。
WEBRC uses a slow start mechanism to quickly ramp up its rate at both the beginning of the session and in the middle of a session when the rate drops precipitously. To enact this, the receiver maintains the following parameters:
WEBRCはレートが急激に低下したときにすぐにセッションの開始の両方で、セッションの途中でそのレートを立ち上げするためにスロースタートメカニズムを使用しています。これを制定するために、受信機は、以下のパラメータを保持しています。
o SSMINR_P is the minimum allowed slow start threshold rate in packets per second. The recommended value for SSMINR_P is BCR_P*(1+1/P+1/P^2).
O SSMINR_Pは秒あたりのパケットの最小許容スロースタート閾値速度です。 SSMINR_Pの推奨値はBCR_P×（1 + 1 / P + 1 / P ^ 2）です。
o SSR_P is the slow start threshold rate in packets per second. It is adjusted at the beginning of loss events as described in Section 3.2.3.4. SSR_P is initialized to infinity and is first set to a finite value when the receiver leaves the initial start-up period as described below.
O SSR_Pは秒あたりのパケットにおけるスロースタート閾値速度です。これは、セクション3.2.3.4で説明したように損失事象の開始時に調整されています。 SSR_Pは無限大に初期化され、以下に説明するように、受信機が初期の始動期間を離れるときに第1の有限値に設定されています。
At the beginning of a session, the receiver cannot compute a meaningful target rate from its measurements. Thus, it uses SSR_P = infinity until one of the following events causes an end to this start-up mode:
セッションの開始時に、受信機は、その測定値から意味のある目標レートを計算することはできません。次のいずれかのイベントが、この起動モードに終了を引き起こしまでこのように、それはSSR_P =無限大を使用しています。
o A packet loss is detected. In this case the value of SSR_P is updated to max{SSMINR_P, P*TRR_P} as with the beginning of any other loss event.
パケットロスが検出され、O。この場合SSR_Pの値は、他の損失事象の始まりと同様に、最大{SSMINR_P、P * TRR_P}に更新されます。
o A sharp increase in MRTT is detected. While SSR_P = infinity the receiver MUST compute, in the notation of Section 3.2.2.2, differences in successive measurements of (FirstTime-JoinTime) from successive waves and MUST set SSR_P to max{SSMINR_P, P*TRR_P} when a large increase in (FirstTime-JoinTime) is observed. It is RECOMMENDED that an increase in (FirstTime-JoinTime) be considered large if it exceeds (P^(NWC+1)-1)/(P*log(P)) / ARR_P.
O MRTTの急激な増加が検出されます。 SSR_P =無限ながら、受信機は、セクション3.2.2.2の表記で、計算しなければならない、及び連続波から（FIRSTTIME-JoinTime）の連続した測定の違いは、MAX {SSMINR_P、P * TRR_P}にSSR_Pを設定しなければならないときに大きな増加（ FIRSTTIME-JoinTime）が観察されます。 （P ^（NWC + 1）-1）/（P *のログ（P））/ ARR_Pを超える場合（FIRSTTIME-JoinTime）の増加が大きいと見なされることが推奨されます。
o The maximum reception rate is reached. When SSR_P = infinity, if (P^(-NWC-2)-1)/(P^(-NWC-1)-1)*ARR_P exceeds MRR_P or SR_P, the receiver MUST set SSR_P to max{SSMINR_P, TRR_P}.
O最大受信レートが達成されます。場合SSR_P =無限大（P ^（ - NWC-2）-1）の場合、/（P ^（ - NWC-1）-1）* ARR_PがMRR_P又はSR_Pを超えて、受信機は、MAX {SSMINR_P、TRR_P}にSSR_Pを設定しなければなりません。
o TRR_P is not increasing consistent with the last join of a wave channel. While SSR_P = infinity, it is RECOMMENDED that the receiver wait at least one full epoch after the first packet of a wave is received before joining the next wave. If the TRR_P after that full epoch is greatly below ARR_P the receiver SHOULD NOT join and SHOULD then set SSR_P to max{SSMINR_P, TRR_P}. It is RECOMMENDED that TRR_P be considered greatly below ARR_P if TRR_P < c * ARR_P - 2/EL, where c = Zeta + (1-Zeta)*(P^(-EL/TSD))*(Zeta + (1-Zeta)*sqrt(P)*(P^(-EL/TSD)))/g with g = (P^(-NWC-1)-1)/(P^(- NWC)-1).
O TRR_Pは、最後の波チャネルの結合と一致増加していません。 SSR_Pが無限大に=ながら、波の最初のパケットが次の波に参加する前に受信された後、受信機は、少なくとも一つの完全なエポックを待つことが推奨されます。その完全なエポックが大きくARR_P未満でTRR_P後の場合、受信機は、参加すべきではなく、その後、最大{SSMINR_P、TRR_P}にSSR_Pを設定する必要があります。 TRR_Pが大幅ARR_Pについて考察することが推奨される場合TRR_P <C *とのARR_P - 2 / EL、C =ゼータ+（1-ゼータ）*（P ^（ - EL / TSD））*（ゼータ+（1-ゼータ）* SQRT（P）*（P ^（ - EL / TSD）））/ GとG =（P ^（ - NWC-1）-1）/（P ^（ - NWC）-1）。
In any of these four cases, the variables associated with LOSSP are reset to make REQN, calculated as in Section 3.2.2.3 with the current value of ARTT, equal TRR_P.
これら四つのいずれの場合も、LOSSPに関連付けられた変数はARTT、等しいTRR_Pの現在の値を持つセクション3.2.2.3のように計算さREQNを作るためにリセットされます。
In typical operation, SSR_P has a finite value and the target rate TRATE is computed as TRATE = min{max{SSR_P, REQN}, MRR_P}. When SSR_P = infinity, TRATE is computed as TRATE = min{4*TRR_P, MRR_P}.
典型的な動作では、SSR_Pは有限の値を有し、目標レートTRATEはTRATE =分{maxの{SSR_P、REQN}、MRR_P}として計算されます。場合SSR_P =無限、TRATEはTRATE =分{4 * TRR_P、MRR_P}として計算されます。
There are various receiver events, some of which are triggered by the passing of time on the receiver, and others by events such as packet reception, detection of packet loss, reception of a first packet from a channel, and exceptional time-outs.
そのようなパケットの受信、パケット損失の検出、チャネルからの最初のパケットの受信、および例外タイムアウトなどのイベントによって、様々な受信機受信機に時間の経過によってトリガされるいくつかのイベント、などがあります。
Most packet reception events require the receiver to merely register the reception for later calculation of RR_P and IRR_P (see Section 3.2.2.5) and increment W for later calculation of LOSSP (see Section 3.2.2.1).
ほとんどのパケット受信イベントは単にRR_PとIRR_Pの後の計算のための受信を登録する受信機を必要とLOSSPの後の計算（セクション3.2.2.1を参照）Wと増分（セクション3.2.2.5を参照）。
Additional actions, described in the following three subsections, are required if the packet is the first packet received in response to a join operation, the CTSI of the packet indicates a time slot change, or the CN and PSN of the packet indicate a packet loss.
パケットが結合操作に応答して受信された最初のパケットである場合は次の三つのサブセクションで説明する追加アクションは、必要とされる、パケットのCTSIは、タイムスロットの変化を示し、又はCNとパケットのPSNは、パケット損失を示します。
When channel i is the most recently joined channel and the Boolean variable JOINING is true, the reception of a packet with PSN = i is a special event because it is the first packet received in response to the most recent join. MRTT is calculated and ARTT and V are updated as described in Section 3.2.2.2, and JOINING is set to false. The first received packet of the session furthermore necessitates initialization of ARR_P and TRR_P as described in Section 3.2.2.5.
チャンネルは、私が最近参加したチャネルで接合ブール変数がtrueの場合、それは参加直近に応じて、受信した最初のパケットであるため、PSNとのパケットの受信が=私は特別なイベントです。 MRTTが計算され、第3.2.2.2項で説明したようにARTTとVが更新され、接合がfalseに設定されています。セクション3.2.2.5に記載されているように、セッションの最初の受信されたパケットは、さらにARR_PとTRR_Pの初期化を必要とします。
This is an event that is triggered by the reception of a packet with a CTSI value that is one larger modulo T than the previous CTSI value. When a packet with a new CTSI = i is received, a leave is sent for the lowest layer in the previous time slot, i.e., wave channel i-1 modulo T, NWC is updated to NWC-1, and ARR_P is updated to ARR_P - P*BCR_P as described in Section 3.2.2.5. If the channel for which the leave is sent is also the most recently joined wave channel and JOINING is true, then JOINING is set to false.
これは、以前のCTSI値より大きい方モジュロTであるCTSI値を有するパケットの受信によってトリガされるイベントです。新しいCTSI有するパケットが= iが受信されると、休暇は、前のタイムスロットにおいて最下層のために送られる、即ち、I-1モジュロT、NWCはNWC-1に更新され、そしてARR_Pが更新される波長チャネルARR_Pします - P *セクション3.2.2.5で説明したようにBCR_P。休暇を送信するチャネルでも最近加わっ波チャンネルで接合がtrueの場合は、falseに設定されている参加。
It is possible due to packet reordering for some packets from the previous time slot to be received after packets from the current time slot. It is RECOMMENDED that measures be put into place to handle this situation appropriately, i.e., to not trigger a time slot change in this situation. One simple mechanism for this is as follows: Compute the difference i-j modulo T, where i is the CTSI of the received packet and j is the current CTSI of the receiver. A difference of zero is, of course, not a time slot change. In addition, a very large difference, for example a difference larger than T-Q/2, should also not trigger a time slot change.
それにより、現在のタイムスロットからのパケットの後に受信される前のタイムスロットからいくつかのパケットのパケット並べ替えが可能です。すなわち、このような状況でのタイムスロットの変更をトリガしないように、対策が適切にこの状況に対処するための場所に置かれることが推奨されます。差iが受信したパケットのCTSIであり、jは受信機の現在のCTSIあるI-JモジュロTを計算する：このための一つの簡単なメカニズムは以下の通りです。ゼロの差が、当然のことながら、タイムスロット変化はありません。加えて、非常に大きな差が、T-Q / 2よりも差が大きいほど、例えば、時間スロットの変更をトリガするべきではありません。
Each time the receiver detects a lost packet (based on the sequence numbers in the packets scoped by the channel number), the receiver records the start of a new loss event and sets a Boolean variable LOSS_EVENT to true that will automatically reset to false after ARTT seconds. All subsequent packet loss for a period of ARTT seconds is considered as part of the same loss event. When a start of a loss event is detected, the value of SSR_P is updated to max{SSMINR_P, P*TRR_P}.
受信機は、（チャンネル番号でスコープパケット内のシーケンス番号に基づいて）失われたパケットを検出するたびに、受信機は、新たな損失事象の開始を記録し、自動的にARTT後falseにリセットされますtrueにブール変数LOSS_EVENTを設定し、秒。 ARTT秒の期間、その後のすべてのパケット損失は、同一の損失事象の一部として考えられています。損失事象の開始が検出されると、SSR_Pの値は、MAX {SSMINR_P、P * TRR_P}に更新されます。
It is RECOMMENDED that the receiver account for simple misordering of packets without inferring a loss.
これは、損失を推定することなく、パケットの簡単な誤った順序のための受信機の口座ことが推奨されます。
This is an event that is triggered by the passage of time at the receiver, which occurs each EL seconds. When this happens, TRR_P and ARR_P are computed as described in Section 3.2.2.5. Immediately after these updates, a decision is made about whether to join the next higher layer as described in Section 3.2.3.6.
これは、各EL秒を発生する受信機、時間の経過によってトリガされるイベントです。このような場合は、セクション3.2.2.5で説明したように、TRR_PとARR_Pが計算されます。すぐにこれらの更新後、決定は、セクション3.2.3.6で説明したように次の上位層に参加するかどうかについて行われます。
At the beginning of each epoch, after updating the values of ARR_P and TRR_P as described in Section 3.2.2.5, the receiver decides whether or not to join the next higher layer as follows:
各エポックの開始時に、セクション3.2.2.5に記載されるようにARR_PとTRR_Pの値を更新した後、受信機は、次のように次の上位層に参加するか否かを判定する。
o If the first base channel packet has not yet arrived the receiver MUST not join.
最初のベース・チャネル・パケットがまだ到着していない場合はO受信機が参加していないしなければなりません。
o If there is a loss event in progress (LOSS_EVENT = true) the receiver MUST not join.
進行中の損失事象がある場合には、O（LOSS_EVENT =真）受信機が参加しないしなければなりません。
o If a join of a channel is in progress (JOINING = true) the receiver MUST not join.
Oチャンネルの結合が進行中（JOINING =真）である場合、受信機は、結合はいけません。
o If NWC = N the receiver MUST not join.
O NWC = N場合は受信機が参加していないしなければなりません。
o If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has not passed since the first packet arrival on the most recently joined wave channel then the receiver MUST not join.
O受信機は、セクション3.2.2.6に記載の選択ルールを採用している場合、SSR_Pは無限大=、最も最近接合波長チャネル上の最初のパケットの到着は、受信機が参加していないしなければならないので、完全なエポックが経過していません。
o If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has passed since the first packet arrival on the most recently joined wave channel, then the receiver checks if TRR_P is greatly below ARR_P as described in Section 3.2.2.6. If TRR_P is greatly below ARR_P the receiver MUST not join.
TRR_PとしてARR_P下に大きくなる場合、O、受信機は、セクション3.2.2.6に記載の選択ルールを採用している場合、SSR_P =無限大、フルエポックは、最も最近接合波長チャネル上の最初のパケットの到着ので、受信機のチェックを通過しましたセクション3.2.2.6で説明しました。 TRR_Pが大幅ARR_P未満である場合に受信機が参加していないしなければなりません。
o The receiver calculates REQN as described in Section 3.2.2.3.
セクション3.2.2.3に記載されるように、受信機がREQNを算出O。
o The receiver calculates TRATE as described in Section 3.2.2.7.
セクション3.2.2.7に記載されるように、受信機がTRATEを算出O。
o If the sender is not sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1), the receiver MUST not join. If the sender is sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1) and TRATE < SR_P, the receiver MUST not join.
O送信者は、一定の凝集速度とTRATE <ARR_P *（（1 / P）^ {NWC + 2} -1）/（（1 / P）^ {NWC + 1} -1）、受信機に送信されていない場合参加しないしなければなりません。送信者は、一定の凝集速度とTRATE <ARR_P *（（1 / P）^ {NWC + 2} -1）/（（1 / P）^ {NWC + 1} -1）とTRATE <SR_P、で送信された場合受信機は参加しませんしなければなりません。
o If SSR_P is finite and the sender is not sending at constant aggregate rate or SSR_P is finite and the sender is sending at constant aggregate rate and TRATE < SR_P then the receiver MAY apply one additional OPTIONAL check before deciding to join.
O SSR_Pは有限であり、送信側が一定の集約レートで送信していないか、SSR_Pは有限であり、送信側が一定の集約レートとTRATE <SR_Pで送信され、受信機が参加することを決定する前に一つの追加オプションのチェックを適用することができる場合。
It is RECOMMENDED that the receiver not join if the value of RR_P is not sufficiently lower than the maximum value of RR_P observed since the last join. It is RECOMMENDED that RR_P is sufficiently low to allow a join if RR_P <= max{RRmax-2/EL,P*RRmax}, where RRmax is the maximum measured RR_P since the last join.
RR_Pの値が最後に参加するためRR_Pの最大値が観察されるよりも十分に低くない場合に受信機が参加しないことをお勧めします。 RR_PがRRMAXが最後に参加するため、最大測定RR_PあるRR_P <=最大{RRMAX-2 / EL、P * RRMAX}、場合参加できるように十分に低くすることが推奨されます。
If the receiver does not join because RR_P is not sufficiently small then a value of LOSSP is calculated so as to make the value of the REQN equation given in Section 3.2.2.3 evaluate to ARR_P*((1/P)^(NWC+2)-1)/((1/P)^(NWC+1)-1) with respect to the current value of ARR_P. Then, the variables associated with LOSSP are reset based on this calculated value of LOSSP as described at the end of Section 3.2.2.1.
RR_Pが十分に小さくないため、受信機が参加しない場合、セクション3.2.2.3に示さREQN式の値がARR_Pするために評価するように、その後LOSSPの値が算出される*（（1 / P）^（NWC + 2 ARR_Pの現在の値に対する）-1）/（（1 / P）^（NWC + 1）-1）。セクション3.2.2.1の末尾に記載されるように、次いで、LOSSPに関連付けられた変数はLOSSPこの算出値に基づいてリセットされます。
o Otherwise, the receiver MAY join the next higher layer.
Oそれ以外の場合、受信機は、次の上位層に参加することができます。
Suppose the receiver has decided to join and CTSI = i. The receiver joins the next higher wave channel, i.e., the wave channel with CN = i+NWC modulo T, increments NWC by 1, and then updates ARR_P to ARR_P*((1/P)^{NWC+1}-1)/((1/P)^NWC-1) as described in Section 3.2.2.5. The time of the join is recorded for use in updating ARTT as described in Section 3.2.2.2.
私は=受信機が参加し、CTSIすることを決定しましたと仮定します。受信機は、すなわち、CNと波チャンネルを次のより高い波長チャネルに参加= iはNWCモジュロTを+（（1 / P）^ {NWC + 1} -1）* 1 NWCをインクリメントし、その後ARR_PするARR_Pを更新します/（（1 / P）^ NWC-1）のセクション3.2.2.5に記載されるように。参加の際は、セクション3.2.2.2で説明したようにARTTを更新する際に使用するために記録されています。
When no packet arrives in response to the join of channel for a long period of time, the join times out. The receiver sets JOINING to false, updates ARR_P to ARR_P*((1/P)^NWC-1)/((1/P)^{NWC+1}-1), and then decrements NWC by 1.
何のパケットは長時間のチャンネルの加入に応じて、到着しなかった場合、タイムアウトに参加します。受信機偽との接合セットは、更新がARR_PするARR_P *（（1 / P）^ NWC-1）/（（1 / P）^ {NWC + 1} -1）、及び1 NWCをデクリメントします。
The RECOMMENDED threshold for a join timeout is max{2*V/ARTT,10*ARTT} seconds.
タイムアウトに参加するための推奨しきい値は{2 * V / ARTT、10 * ARTT}秒以内です。
These are timeouts when the packet reception behavior is far from what it should be and these MUST trigger the receiver to leave the session. Exceptional timeouts include
パケット受信動作がはるかにそれがあるべき、これらはセッションを終了する受信機をトリガしなければならないものとされている場合、これらは、タイムアウトです。抜群のタイムアウトが含ま
o No packets are received for a long period. A RECOMMENDED threshold is max{10,TSD} seconds.
Oなしパケットは、長い期間のために受信されません。推奨しきい値は、最大{10、TSD}秒です。
o There is no change in time slot index for a long period. A RECOMMENDED threshold is max{20,2*TSD} seconds.
O長い期間のタイムスロットインデックスに変更はありません。推奨しきい値は{20,2 * TSD}秒以内です。
WEBRC is intended to be a congestion control scheme that can be used in a complete protocol instantiation that delivers objects and streams (both reliable content delivery and streaming of multimedia information). WEBRC is most applicable for delivery of objects or streams of substantial length, i.e., objects or streams that range in length from hundreds of kilobytes to many gigabytes, and whose transfer time is on the order of tens of seconds or more.
WEBRCオブジェクト及びストリーム（信頼性の高いコンテンツ配信及びマルチメディア情報のストリーミングの両方）を提供し、完全なプロトコルのインスタンス化に使用することができる輻輳制御方式であることを意図しています。 WEBRCは、オブジェクトまたは実質的な長さのストリーム、転送時間秒以上数十程度である多くのギガバイト、およびキロバイト数百の長さの範囲、すなわち、オブジェクトまたはストリームの配信のための最も適用可能です。
WEBRC can be used with both multicast and unicast networks. However, the scope of this document is limited to multicast. WEBRC requires connectivity between a sender and receivers, but does not require connectivity from receivers to the sender.
WEBRCは、マルチキャストおよびユニキャストネットワークの両方で使用することができます。しかし、この文書の範囲は、マルチキャストに限定されています。 WEBRCは、送信者と受信者間の接続を必要としますが、受信機から送信側への接続を必要としません。
WEBRC inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of WEBRC is unlimited. However, in some network environments varying reception rates to receivers may not be advantageous. For example, the network may have dedicated a fixed amount of bandwidth to the session or there may be no effective way for receivers to dynamically vary the set of channels they are joined to, as in a satellite network.
WEBRCは本質的にLANやWANを、イントラネット、インターネット、非対称ネットワーク、無線ネットワーク、衛星ネットワークを含むネットワークのすべてのタイプで動作します。このように、WEBRCの固有の生のスケーラビリティは無制限です。しかしながら、受信機に受信率を変化させるいくつかのネットワーク環境では有利ではないかもしれません。例えば、ネットワークは、セッションへの帯域幅の固定量を捧げているか、または受信機が衛星ネットワークのように、それらが結合されているチャネルのセットを変える動的にする効果的な方法が存在しなくてもよいです。
Receivers join and leave channels using the appropriate multicast join and leave messages. For IPv4 multicast, IGMP messages are used by receivers to join and leave channels. For IPv6, MLDv2 messages are used by receivers to join and leave channels. This is the only dependency of WEBRC on the IP version.
レシーバは、参加して、適切なマルチキャストJoinおよびLeaveメッセージを使用してチャンネルを残します。 IPv4マルチキャストの場合は、IGMPメッセージが参加し、チャンネルを残すために受信機によって使用されています。 IPv6の場合、MLDv2のメッセージが参加し、チャンネルを残すために受信機によって使用されています。これは、IPバージョンにWEBRCの唯一の依存関係です。
WEBRC requires receivers to be able to uniquely identify and demultiplex packets associated with a session in order to effectively perform congestion control over all packets associated with the session. How receivers achieve this is outside the scope of this document.
WEBRC一意有効セッションに関連付けられたすべてのパケット上輻輳制御を実行するために、セッションに関連するパケットを識別し、逆多重化できるように受信機を必要とします。受信機は、これを実現する方法このドキュメントの範囲外です。
WEBRC is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [7] is such a best effort network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers.
WEBRCは、パケット受信、パケットの受信順序を保証するものではありません「ベストエフォート」のサービスである基礎となるネットワークまたはトランスポートサービスで使用していると推定され、これは、フローや輻輳制御のためのあらゆるサポートしていません。例えば、IPマルチキャストの任意-ソースマルチキャスト（ASM）モデルは、RFC 1112 [7]であるようなベストエフォート型のネットワークサービスで定義されています。 RFC 1112が提供する基本的なサービスは、主にスケーラブルですが、輻輳制御や信頼性を提供することは、特に受信機の異質セットの存在下で、深刻なスケーラビリティの制限を回避するために、慎重に行われるべきです。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [7] and the Source-Specific Multicast (SSM) model as defined in [10]. WEBRC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and the WEBRC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the WEBRC channel address coincides with the SSM channel address.
マルチキャスト配信の2つのモデルが現在あり、RFC 1112で定義されるような任意の-ソースマルチキャスト（ASM）モデル[7]及び[10]で定義されるようにソース固有マルチキャスト（SSM）モデル。 WEBRCは両方のマルチキャストモデルで動作しますが、多少異なる環境への懸念と少し異なる方法インチASMを使用する場合、送信者Sは、マルチキャストグループGにパケットを送信し、WEBRCチャネルアドレスは、Sは、送信者のIPアドレスでありGはマルチキャストグループアドレスである対（S、G）、から成ります。 SSMを使用する場合、送信者Sは、SSMチャネル（S、G）にパケットを送信し、WEBRCチャネルアドレスは、SSMチャネルアドレスと一致します。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of channel addresses easy with SSM. To allocate channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of WEBRC channel addresses more difficult with ASM. This is an issue for WEBRC because several channels are used per session.
送信者は、ローカルで一意SSMチャンネルアドレスを割り当てることができ、そしてこれは、SSMとチャネルアドレスの割り当てが容易になります。 ASMを使用して、チャネルアドレスを割り当てるために、送信者は、一意のグループの範囲を横切るASMマルチキャストグループアドレスを選択しなければならず、これは、ASMとWEBRCチャネルアドレスの割り当てをより困難にします。いくつかのチャンネルはセッションごとに使用されているので、これはWEBRCための問題です。
WEBRC channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested WEBRC channel. With ASM, the receiver joins a channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources.
WEBRCチャネルとSSMチャネルが一致するので、受信機は、要求されたWEBRCチャネルに送信されたパケットを受信します。 ASMと、受信機にかかわらず、送信者の受信機によって受信されるマルチキャストグループGに参加することによって、チャネル、およびGに送信されたすべてのパケットを、合流します。このように、SSMは、サービス拒否攻撃の防止のためのASM以上の魅力的なセキュリティ上の利点があります。いずれの場合においても、受信機は、不要なソースからパケットをフィルタリングするためのメカニズムを使用すべきです。
WEBRC assumes that the packet route between the sender and a particular receiver is the same for all channels associated with a session. For SSM this assumption is true because the multicast tree is a shortest path tree from each receiver to the sender and generally this path changes infrequently. For ASM there are some issues that if not properly considered may invalidate this assumption. With ASM, the packet route between the sender and receivers may initially be through the Rendezvous Point (RP) and then switch over to the shortest path to the sender as packets start flowing in a channel. The first issue is that the RP may not be the same for all channels associated with a session, and thus the first packets sent to the channels may follow a route that depends on the RP of the channel. This depends on the RP configuration for the sender. If the sender registers all channels associated with the session with the same RP then the assumption is true, but if the sender registers different channels with different RPs then the assumption may not be true. Thus, it is RECOMMENDED that the sender register all channels associated with a session with the same RP. Another issue is that when the channel switches over from the RP to the sender-based tree then the route to the receivers may vary within a channel. Furthermore, this may cause either the receipt of duplicate packets at receivers or loss of packets depending on the smoothness of the switchover. Thus, it is RECOMMENDED that the RP be placed as close as possible to the sender. The best location for the RP is that it be the first-hop router closest to the sender, in which case the path to the sender and the path to the RP is the same for each receiver and the problems mentioned above are eliminated. The consequences of this assumption not being true are that the receiver reaction to congestion may not be appropriate. Generally, the WEBRC receiver will act conservatively and reduce its reception rate too much if this assumption is not true, but there can be cases where the receivers will act inappropriately.
WEBRCは、送信者と特定の受信機との間のパケット経路がセッションに関連付けられたすべてのチャネルについて同じであると仮定しています。マルチキャストツリーは、送信者に各受信機からの最短経路ツリーであり、一般的に、この経路は、まれに変化するため、SSMの場合、この仮定は真です。 ASMの場合ならば、適切にこの仮定を無効にする可能性が考えられていないことをいくつかの問題があります。 ASMと、送信者と受信機の間のパケット経路は、最初にランデブーポイント（RP）を介していてもよく、次いで、パケットがチャネルに流れ始めるように送信者への最短経路に切り替えます。最初の問題は、RPは、セッションに関連付けられたすべてのチャネルで同じではないかもしれないので、チャネルに送信される最初のパケットはチャネルのRPに依存する経路をたどることができることです。これは、送信者のためのRPの構成によって異なります。送信者が同じRPとのセッションに関連付けられているすべてのチャンネルを登録した場合、仮定は本当ですが、送信者が異なるのRPと異なるチャネルを登録した場合、その後の仮定は本当ではないかもしれません。したがって、送信者が同じRPとのセッションに関連付けられているすべてのチャンネルを登録することが推奨されます。もう一つの問題は、チャネルは、送信者ベースのツリーにRPから切り替わるときに受信機へのルートは、チャネル内で変えることができるということです。さらに、これは、受信機での重複したパケットの受信またはスイッチオーバーの滑らかさに応じて、パケットの損失のいずれかが発生することがあります。したがって、RPは送信元にできるだけ近くに配置することが推奨されます。 RPのための最良の場所は、それが送信者へのパスとRPへのパスは、各受信機のために同じであり、上記の問題が解消された場合には、送信者に最も近い最初のホップルータであることです。この仮定の結果は真輻輳受信反応が適切ではないかもしれないということであるれていません。一般的に、WEBRC受信機は保守的に行動し、この仮定が真でない場合は、その受信率があまりにも多くの削減が、受信機が不適切に行動する場合があることができます。
Packets sent to a session using WEBRC MUST include Congestion Control Information fields as specified in this section. This document specifies short and long formats for the Congestion Control Information, and it is RECOMMENDED that protocol instantiations use one of these two formats. Other formats for the Congestion Control
このセクションで指定されWEBRCを使用してセッションに送信されたパケットは、輻輳制御情報フィールドを含まなければなりません。この文書では、輻輳制御情報のための短期および長期の形式を指定し、プロトコルのインスタンス化は、これら2つの形式のいずれかを使用することをお勧めします。輻輳制御のための他のフォーマット
Information fields MAY be used by protocol instantiations, but all protocol instantiations are REQUIRED to use these fields in a format that is compatible with the interpretations of these fields. Thus, if a protocol does use a different format for the fields in the Congestion Control Information then it MUST specify the lengths and positions of these fields within the packet header.
情報フィールドは、プロトコルのインスタンス化で使用することができるが、すべてのプロトコルのインスタンス化は、これらのフィールドの解釈と互換性のある形式で、これらのフィールドを使用する必要があります。プロトコルは、輻輳制御情報のフィールドに別の形式を使用しない場合したがって、それは、パケットヘッダ内のこれらのフィールドの長さと位置を指定しなければなりません。
All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. All constants, unless otherwise specified, are expressed in base ten.
すべての整数フィールドは、最上位バイト（オクテット）最初、つまり、「ビッグエンディアン」または「ネットワーク順」形式で行われています。すべての定数は、特に指定のない限り、ベース10で表現されています。
The short format for the Congestion Control Information is shown in Fig. 1. The total length of the short format is 32-bits.
輻輳制御情報の短い形式は、図2に示されている。1.ショートフォーマットの合計長さは32ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTSI | Channel Number| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 - Short format for Congestion Control Information
図1 - 。輻輳制御情報のショートフォーマット
The function of each field in the Congestion Control Information is the following.
輻輳制御情報の各フィールドの機能は以下の通りです。
Current Time Slot Index (CTSI): 8 bits
現在のタイムスロットインデックス（CTSI）：8ビット
CTSI indicates the index of the current time slot. This must be sent in each packet within the session. The Current Time Slot Index increases by one modulo T each TSD seconds at the sender, where T is the number of time slots associated with the session and TSD is the time slot duration. Note that T is also the number of wave channels associated with the session, and thus T MUST be at most 255.
CTSIは、現在のタイムスロットのインデックスを示しています。これは、セッション内の各パケットで送信されなければなりません。 Tは、セッションに関連付けられているタイムスロットの数であり、TSDは、タイムスロットの持続時間である送信者、1つのモジュロT各TSD秒による現在タイムスロットのインデックスが増加します。 Tは、セッションに関連付けられた波チャネルの数であり、したがって、Tが最も255でなければならないことに留意されたいです。
Channel Number (CN): 8 bits
チャネル番号（CN）8ビット
CN is the channel number that this packet belongs to. CN for the base channel is T, and the CNs for the wave channels are 0 through T-1. Thus, T+1 channels in total are used, and thus T MUST be at most 255.
CNは、このパケットが属するチャネル番号です。ベースチャンネル用のCNは、波長チャネルのためのTであり、およびCNS T-1を介して0です。したがって、合計でT + 1つのチャネルが使用され、したがって、Tは、最大で255なければなりません。
Packet Sequence Number (PSN): 16 bits
パケットシーケンス番号（PSN）：16ビット
The PSN of each packet is scoped by its CN value. The sequence numbers of consecutive packets sent to the base channel are numbered consecutively modulo 2^16. The same sequence of PSNs are used for each wave channel in each cycle. The sequence numbers of consecutive packets sent to a wave channel are numbered consecutively modulo 2^16 within each cycle, ending with the last packet sent to the channel before the channel goes quiescent with PSN = 2^16-1.
各パケットのPSNは、そのCNの値によってスコープされます。ベースチャンネルに送信された連続したパケットのシーケンス番号が2 ^ 16連続モジュロ番号が付けられています。 PSNの同じシーケンスが、各サイクルにおける各波長チャネルのために使用されます。波のチャンネルに送られた連続したパケットのシーケンス番号は、チャネルがPSN = 2 ^ 16-1と静止進む前にチャネルに送信された最後のパケットで終わる、各サイクル内で2 ^ 16連続モジュロ番号が付けられています。
The long format for the Congestion Control Information is shown in Fig. 2. The total length of the long format is 64-bits.
輻輳制御情報のための長いフォーマットを図2に示す。2.ロングフォーマットの全長が64ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTSI | Channel Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2 - Long format for Congestion Control Information
図2 - 。輻輳制御情報のロングフォーマット
The meaning of each field for the long format is the same as for the short format, the only difference is that each field is twice as long.
長いフォーマットの各フィールドの意味は短い形式の場合と同じである、唯一の違いは、各フィールドには2倍の長さということです。
Current Time Slot Index (CTSI): 16 bits
現在のタイムスロットインデックス（CTSI）：16ビット
CTSI indicates the index of the current time slot. This must be sent in each packet within the session. The Current Time Slot Index increases by one modulo T each TSD seconds at the sender, where T is the number of time slots associated with the session and TSD is the time slot duration. Note that T is also the number of wave channels associated with the session, and thus T MUST be at most 65,535.
CTSIは、現在のタイムスロットのインデックスを示しています。これは、セッション内の各パケットで送信されなければなりません。 Tは、セッションに関連付けられているタイムスロットの数であり、TSDは、タイムスロットの持続時間である送信者、1つのモジュロT各TSD秒による現在タイムスロットのインデックスが増加します。 Tは、セッションに関連付けられた波チャネルの数であり、したがって、Tが最大で65,535である必要があります。
Channel Number (CN): 16 bits
チャネル番号（CN）：16ビット
CN is the channel number that this packet belongs to. CN for the base channel is T, and the CNs for the wave channels are 0 through T-1. Thus, T+1 channels in total are used, and thus T MUST be at most 65,535.
CNは、このパケットが属するチャネル番号です。ベースチャンネル用のCNは、波長チャネルのためのTであり、およびCNS T-1を介して0です。したがって、合計でT + 1つのチャネルが使用され、したがって、Tが最も65,535でなければなりません。
Packet Sequence Number (PSN): 32 bits
パケットシーケンス番号（PSN）：32ビット
The PSN of each packet is scoped by its CN value. The sequence numbers of consecutive packets sent to the base channel are numbered consecutively modulo 2^32. The same sequence of PSNs are used for each wave channel in each cycle. The sequence numbers of consecutive packets sent to a wave channel are numbered consecutively modulo 2^32 within each cycle, ending with the last packet sent to the channel before the channel goes quiescent with PSN = 2^32-1.
各パケットのPSNは、そのCNの値によってスコープされます。ベースチャンネルに送信された連続したパケットのシーケンス番号が2 ^ 32連続モジュロ番号が付けられています。 PSNの同じシーケンスが、各サイクルにおける各波長チャネルのために使用されます。波のチャンネルに送られた連続したパケットのシーケンス番号は、チャネルがPSN = 2 ^ 32-1と静止進む前にチャネルに送信された最後のパケットで終わる、各サイクル内で2 ^ 32連続モジュロ番号が付けられています。
As described in RFC 3048 [4], WEBRC is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation.
RFC 3048 [4]に記載されているように、WEBRCは、プロトコルのインスタンスを指定するために役立つ、他のビルディングブロックと組み合わせて、使用されることが意図されるビルディングブロックです。
WEBRC does not provide higher level session support, e.g., how receivers obtain the necessary session description and how the receivers demultiplex received packets based on their session. There is support provided by other building blocks that can be used in conjunction with WEBRC to provide some of this support. For example, LCT [12] can provide some of the higher level in-band session support that may be needed by receivers, and the WEBRC Congestion Control Information (CCI) required in each packet can be carried in the CCI field of the LCT header [12].
WEBRCは、受信機は、必要なセッション記述とどの受信機がそれらのセッションに基づいて、受信したパケットを逆多重化し得る、例えば、どのように、より高いレベルのセッション・サポートを提供しません。このサポートの一部を提供するために、WEBRCと組み合わせて使用することができ、他のビルディングブロックによって提供されるサポートがあります。例えば、LCT [12]受信機によって必要とされ得るより高いレベルの帯域内のセッション・サポートの一部を提供することができ、各パケットに必要WEBRC輻輳制御情報（CCI）は、LCTヘッダのCCIフィールドで実施することができます[12]。
WEBRC does not provide any type of reliability, and in particular does not provide support for retransmission of loss packets. Reliability can be added by independent means, such as by the use of FEC codes as described in [13] and specified in the FEC building block [14].
WEBRCは、信頼性のいずれかのタイプを提供していない、特に、損失パケットの再送信のためのサポートを提供していません。信頼性は、[13]に記載され、FECビルディングブロック[14]で指定されるようにFECコードを使用することによって、独立した手段によって付加することができます。
WEBRC can be subject to denial-of-service attacks by attackers that try to confuse the congestion control mechanism for receivers by injecting forged packets into the multicast stream. This attack most adversely affects network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Because of this and because of the potential attacks due to the use of FEC described above, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
WEBRCは、マルチキャストストリームに偽造パケットを注入することによって、受信機のための輻輳制御機構を混同しようとする攻撃者によって、サービス拒否攻撃の対象にすることができます。この攻撃は、ほとんど悪影響ネットワーク要素と受信機の攻撃の下流で、かつあまり大幅にネットワークの他の部分や他のレシーバに影響を与えます。このため、および理由によるFECの使用に対する潜在的な攻撃は、上述した、リバースパス転送チェックは不良剤の可能性を制限するために受信機に送信者からのパスに沿ってすべてのネットワークルータとスイッチで有効にすることが推奨されますマルチキャストツリーデータパスに偽造パケットを注入します。
It is also RECOMMENDED that packet authentication be used to authenticate each packet immediately upon receipt before the receiver performs any WEBRC actions based upon its receipt. Unfortunately, there are currently no practical multicast packet authentication schemes that offer instant packet authentication upon receipt. However, TESLA [17] can be used to authenticate each packet a few
また、受信機はその受信に基づいて任意のWEBRCのアクションを実行する前にパケット認証を受けるとすぐに各パケットを認証するために使用することをお勧めします。残念ながら、現在受信したときにインスタントパケット認証を提供する実用的なマルチキャストパケットの認証方式はありません。しかし、テスラ[17]は、いくつかの各パケットを認証するために使用することができます
seconds after receipt. Thus, TESLA could be used in conjunction with WEBRC to authenticate packets and for example terminate the session upon detection of a forged packet. However, it is RECOMMENDED that the normal WEBRC receiver responses to received packets occur immediately -- not delayed by the TESLA authentication process. This is because the overall WEBRC performance would be greatly degraded if the receiver delayed its WEBRC response to packet receipt for several seconds.
領収書秒後。したがって、TESLAは、パケットを認証するWEBRCと組み合わせて使用され、例えば、偽造パケットを検出すると、セッションを終了することができます。 TESLA認証プロセスによって遅延されていない - しかし、受信されたパケットに対して垂直WEBRC受信応答が即座に起こることが推奨されます。受信機は、数秒のパケット受信にそのWEBRC応答が遅れた場合、全体的なWEBRC性能が大幅に低下するだろうからです。
A receiver with an incorrect or corrupted implementation of WEBRC may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session.
WEBRCの間違ったまたは破損実装と受信機は、送信機と受信機との間の経路内のネットワークの健康に影響を与えることができ、また、他の受信機の受信レートに影響を与える可能性があるセッションに参加しました。したがって、受信機は、彼らがセッションに参加するために必要なセッション記述を受ける前に、正当として自分自身を識別するために要求されることが推奨されます。
Another vulnerability of WEBRC is the potential of receivers obtaining an incorrect session description for the session. The consequences of this could be that legitimate receivers with the wrong session description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders.
WEBRCのもう一つの脆弱性は、セッションの不正なセッション記述を取得する受信機の可能性です。これの結果は、間違ったセッション記述を持つ、正当な受信機が正しくセッションコンテンツを受信することができない、または受信機が誤って、それによってネットワークの一部でトラフィックを中断、彼らがすることができるよりもはるかに高いレートで受信しようということである可能性があります。これらの問題を回避するために、対策は受信機が唯一認可された送信者からの正当なセッション記述を受け入れることを確認するために、ソースの認証を使用することにより、例えば、間違ったセッション記述を受け入れるのレシーバを防ぐために取られることが推奨されます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[2] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[3] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[3]マンキン、A.、Romanow、A.、RFC 2357、1998年6月ブラドナー、S.およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"。
[4] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[4] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
[5] Byers, J., Horn, G., Luby, M., Mitzenmacher, M. and W. Shaver. "FLID-DL: Congestion control for layered multicast," IEEE J. on Selected Areas in Communications, Special Issue on Network Support for Multicast Communication, Vol. 20, No. 8, October 2002, pp. 1558-1570.
[5]バイヤーズ、J.、ホーン、G.、ルビー、M.、Mitzenmacher、M.およびW.シェーバー。 「FLID-DL：階層化マルチキャストのための輻輳制御、」コミュニケーションで選択された領域上のIEEE J.、マルチキャスト通信、巻のためのネットワークサポート特集。 20、第8号、2002年10月、頁。1558年から1570年。
[6] Dagum, P., Karp, R., Luby, M. and S. Ross, "An optimal algorithm for Monte Carlo estimation," SIAM J. Comput., 29(5):1484-1496, April 2000.
[6] Dagum、P.、カープ、R.、ルビー、M.およびS.ロス、 "モンテカルロ推定のための最適なアルゴリズム、" SIAM J. Comput、29（5）：1484年から1496年、2000年4月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[8] Goyal, V., "On WEBRC Wave Design and Server Implementation", Digital Fountain Technical Report no. DF2002-09-001, September 2002, available at http://www.digitalfountain.com/technology/.
[8] Goyal氏、V.、デジタル噴水技術報告書なし「WEBRCウェーブデザインとサーバーの実装に」。 DF2002-09-001、2002年9月、http://www.digitalfountain.com/technology/でご利用いただけます。
[9] Handley, M., Floyd, S., Padhye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[9]ハンドレー、M.、フロイド、S.、Padhye、J.およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[10] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[10]ホルブルック、H.、「マルチキャスト用チャネルモデル」、博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニア州、2001年8月。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[11]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.及びJ.クロウクロフト、RFC 3450、2002年12月 "非同期階層は（ALC）プロトコルインスタンス化コーディング"。
[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[12]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451、2002年12月。
[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[13]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453、 2002年12月。
[14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[14]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[15] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report", Digital Fountain Technical Report no. DF2002-07-001, September 2002, available at http://www.digitalfountain.com/technology/.
[15]ルビー、M.およびV. Goyal氏、「波動と式ベースのレートコントロールは、マルチキャストラウンドトリップ時間の使用：レポートの拡張」を、デジタル泉テクニカルレポートなし。 DF2002-07-001、2002年9月、http://www.digitalfountain.com/technology/でご利用いただけます。
[16] Luby, M., Goyal, V., Skaria, S. and G. Horn, "Wave and Equation Based Rate Control Using Multicast Round Trip Time", Proc. ACM SIGCOMM 2002, Pittsburgh, PA, August 2002, pp. 191-214.
[16]ルビー、M.、Goyal氏、V.、Skaria、S.及びG.ホーン、 "波と式ベースのレート制御はマルチキャストラウンドトリップ時間の使用"、PROC。 ACMのSIGCOMM 2002、ピッツバーグ、PA、2002年8月、頁191から214まで。
[17] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[17] Perrig、A.、カネッティ、R.、歌、D.とJ. Tygar、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、頁35-46、2001年2月。
[18] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", Proc. IEEE Infocom '98, San Francisco, CA, March-April 1998, pp. 996-1003.
[18] Vicisano、L.、リゾー、L.及びJ.クロウクロフト、 "階層化マルチキャストデータ転送のためのTCPのような輻輳制御"、PROC。 IEEEインフォコム'98、サンフランシスコ、CA、3月〜1998年4月、頁996から1003。
Michael Luby Digital Fountain 39141 Civic Center Drive, Suite 300 Fremont, CA, USA, 94538
マイケル・ルビーデジタル噴水39141シビックセンタードライブ、スイート300フリーモント、CA、USA、94538
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Vivek K Goyal Massachusetts Institute of Technology Room 36-690 77 Massachusetts Avenue Cambridge, MA, USA, 02139
テクノロジーのヴィヴェックK Goyal氏マサチューセッツ工科大学ルーム36から690 77マサチューセッツアベニューケンブリッジ、MA、USA、02139
EMail: v.goyal@ieee.org
メールアドレス：v.goyal@ieee.org
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。