Network Working Group J. Widmer
Request for Comments: 4654 DoCoMo Euro-Labs
Category: Experimental M. Handley
UCL
August 2006
TCP-Friendly Multicast Congestion Control (TFMCC):
Protocol Specification
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.
このドキュメントでは、TCPフレンドリーマルチキャスト輻輳制御（TFMCC）を指定します。 TFMCCはベストエフォート型のインターネット環境でのマルチキャスト伝送のための輻輳制御機構です。これは、送信速度が最悪のネットワーク条件を経験受信するように適合されたシングルレート輻輳制御方式です。 TFMCCはTCPフローに帯域幅を競合するとき、合理的に公正であり、時間を超えるスループットの比較的低い変動があり、そのようなメディアストリーミングなど比較的滑らかな送付レートが重要である用途、に適しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Related Documents ..........................................4
1.2. Environmental Requirements and Considerations ..............4
2. Protocol Overview ...............................................5
2.1. TCP Throughput Equation ....................................6
2.2. Packet Contents ............................................7
2.2.1. Sender Packets ......................................8
2.2.2. Feedback Packets ....................................9
3. Data Sender Protocol ...........................................10
3.1. Sender Initialization .....................................10
3.2. Determining the Maximum RTT ...............................10
3.3. Adjusting the Sending Rate ................................11
3.4. Controlling Receiver Feedback .............................12
3.5. Assisting Receiver-Side RTT Measurements ..................14
3.6. Slowstart .................................................15
3.7. Scheduling of Packet Transmissions ........................15
4. Data Receiver Protocol .........................................16
4.1. Receiver Initialization ...................................17
4.2. Receiver Leave ............................................17
4.3. Measurement of the Network Conditions .....................17
4.3.1. Updating the Loss Event Rate .......................17
4.3.2. Basic Round-Trip Time Measurement ..................17
4.3.3. One-Way Delay Adjustments ..........................18
4.3.4. Receive Rate Measurements ..........................19
4.4. Setting the Desired Rate ..................................19
4.5. Feedback and Feedback Suppression .........................20
5. Calculation of the Loss Event Rate .............................22
5.1. Detection of Lost or Marked Packets .......................22
5.2. Translation from Loss History to Loss Events ..............23
5.3. Inter-Loss Event Interval .................................24
5.4. Average Loss Interval .....................................24
5.5. History Discounting .......................................25
5.6. Initializing the Loss History after the First Loss Event ..27
6. Security Considerations ........................................28
7. Acknowledgments ................................................29
8. References .....................................................29
8.1. Normative References ......................................29
8.2. Informative References ....................................29
This document specifies TCP-Friendly Multicast Congestion Control (TFMCC) [3]. TFMCC is a source-based, single-rate congestion control scheme that builds upon the unicast TCP-Friendly Rate Control mechanism (TFRC) [4]. TFMCC is stable and responsive under a wide range of network conditions and scales to receiver sets on the order of several thousand receivers. To support scalability, as much congestion control functionality as possible is located at the receivers. Each receiver continuously determines a desired receive rate that is TCP-friendly for the path from the sender to this receiver. Selected receivers then report the rate to the sender in feedback packets.
この文書では、[3] TCPフレンドリーマルチキャスト輻輳制御（TFMCC）を指定します。 TFMCCユニキャストTCPフレンドリーレート制御機構（TFRC）に基づいて構築ソースベース、シングルレート輻輳制御方式である[4]。 TFMCCは数千受信機のオーダーの受信機セットへのネットワーク条件やスケールの広い範囲で安定して応答します。スケーラビリティをサポートするために、できるだけ多くの輻輳制御機能は、受信機に位置しています。各受信機は、連続的に、この送信側から受信側への経路のためのTCPフレンドリーれている所望の受信速度を決定します。選択された受信機は、フィードバックパケットで送信者に率を報告しています。
TFMCC is a building block as defined in RFC 3048 [1]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [11], in an application incorporating end-to-end congestion control at the application level. This document does not discuss packet formats, reliability, or implementation-related issues.
TFMCCは、RFC 3048で定義されているビルディングブロックである[1]。代わりに、完全なプロトコルを指定する、この文書は、単にアプリケーションレベルでエンドツーエンドの輻輳制御を組み込んだアプリケーションにおいて、そのようなRTP [11]などのトランスポートプロトコルで使用することができる輻輳制御機構を指定します。この文書では、パケットフォーマット、信頼性、または実装に関連する問題を議論しません。
TFMCC is designed to be reasonably fair when competing for bandwidth with TCP flows. A multicast flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow from the sender to the slowest receiver of the multicast group under the same network conditions.
TFMCCは、TCPフローと帯域幅を競合するとき、合理的に公平であるように設計されています。その送信速度は、同じネットワーク条件下でマルチキャストグループの最も遅い送信側から受信側へのTCPフローの送信レートの2倍内である場合、マルチキャストフローは、「合理的に公正」です。
In general, TFMCC has a low variation of throughput, which makes it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. The penalty of having smooth throughput while competing fairly for bandwidth is a reduced responsiveness to changes in available bandwidth. Thus TFMCC should be used when the application has a requirement for smooth throughput, in particular, avoiding halving of the sending rate in response to a single packet drop. For applications that simply need to multicast as much data as possible in as short a time as possible, PGMCC [10] may be more suitable.
一般に、TFMCCは、ストリーミングメディアのような比較的滑らかな送信速度が重要である用途に適していますスループットの低い変動を有します。帯域幅を公平に競争しながら滑らかなスループットを有するのペナルティは、利用可能な帯域幅の変化に還元反応です。アプリケーションが単一のパケット損失に応じて送信レートの半分を避け、特に滑らかなスループットの要件を有する場合したがってTFMCCを使用すべきです。単に、できるだけ短時間でできるだけ多くのデータをマルチキャストする必要があるアプリケーションのために、PGMCCは、[10]より適切であり得ます。
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）ワーキンググループの意図です。
As described in RFC 3048 [1], TFMCC is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. It follows the general guidelines provided in RFC 3269 [2]. In particular, TFMCC is a suitable congestion control building block for NACK-Oriented Reliable Multicast (NORM) [5].
RFC 3048 [1]に記載されているように、TFMCCは、プロトコルのインスタンスを指定するために役立つ、他のビルディングブロックと組み合わせて、使用されることが意図されるビルディングブロックです。これは、[2] RFC 3269で提供される一般的なガイドラインに従います。特に、TFMCCはNACK指向高信頼マルチキャスト（NORM）に適した輻輳制御ビルディングブロックである[5]。
TFMCC 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).
TFMCCオブジェクト及びストリーム（信頼性の高いコンテンツ配信及びマルチメディア情報のストリーミングの両方）を提供し、完全なプロトコルのインスタンス化に使用することができる輻輳制御方式であることを意図しています。
TFMCC is most applicable for sessions that deliver a substantial amount of data (i.e., in length from hundreds of kilobytes to many gigabytes) and whose duration is on the order of tens of seconds or more.
TFMCC（すなわち、キロバイト数百から数ギガバイトの長さの）データのかなりの量を提供し、その持続時間秒以上数十程度であるセッションのための最も適用可能です。
TFMCC is intended for multicast delivery. There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [6] and the Source-Specific Multicast (SSM) model as defined in [7]. TFMCC works with both multicast models, but in a slightly different way. When ASM is used, feedback from the receivers is multicast to the sender, as well as to all other receivers. Feedback can be either multicast on the same group address used for sending data or on a separate multicast feedback group address. For SSM, the receivers must unicast the feedback directly to the sender. Hence, feedback from a receiver will not be received by other receivers.
TFMCCは、マルチキャスト配信するためのものです。 [7]で定義されるように[6]およびソース固有マルチキャスト（SSM）モデルで定義されたような任意の-ソースマルチキャスト（ASM）モデル：マルチキャスト配信の2つのモデルが現在存在します。 TFMCCは若干異なる方法で、両方のマルチキャストモデルで動作します。 ASMを使用する場合は、受信機からのフィードバックは、送信者にだけでなく、他のすべての受信機にマルチキャストです。フィードバックは、データを送信するか、別のマルチキャストフィードバックグループアドレスに使用したのと同じグループアドレス上でマルチキャストのいずれかであり得ます。 SSMの場合、受信機は、送信者に直接フィードバックをユニキャストしなければなりません。したがって、受信機からのフィードバックは、他の受信機によって受信されることはありません。
TFMCC inherently works with all types of networks that allow bi-directional communication, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. However, in some network environments varying the sending rate to the receivers may not be advantageous (e.g., for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session).
TFMCCは本質的にLANやWANを、イントラネット、インターネット、非対称ネットワーク、無線ネットワーク、衛星ネットワークなどの双方向通信を可能にするネットワークのすべてのタイプで動作します。受信機が効果的に受信レートを低減するために割り当てられた固定された伝送レートが存在し得るので、いくつかのネットワークにおいて受信機に送信レートを変化させる環境は有利ではないかもしれない（例えば、衛星または無線ネットワークのための、メカニズムがなくてもよいですセッション）。
The difference in responsiveness of TFMCC and TCP may result in significant throughput differences in case of a very low bitrate. TFMCC requires an estimate of the loss event rate to calculate a fair sending rate. This estimate may be inaccurate in case TFMCC receives only very few packets per RTT. TFMCC should not be used together with TCP if the capacity of the bottleneck link is less than 30KBit/s (e.g., a very slow modem connection). TFMCC may also achieve a rate that is very different from the average TCP rate in case buffer space at the bottleneck is severely underprovisioned. In particular, TFMCC is less susceptible to small buffer sizes since TFMCC spaces out packets in time, whereas TCP sends them back to back. Thus TCP is much more likely to see a packet loss if buffer space is scarce.
TFMCCとTCPの応答性の差が非常に低いビットレートの場合の大幅なスループットの差が生じることがあります。 TFMCCは、公正、送信速度を計算するために、損失イベント率の推定値を必要とします。 TFMCCはRTTごとにごく少数のパケットを受信した場合には、この推定値は不正確になることがあります。ボトルネックリンクの容量は30KBit /秒（例えば、非常に遅いモデム接続）未満である場合TFMCCはTCPと一緒に使用されるべきではありません。 TFMCCも厳しくunderprovisionedされるボトルネックの場合バッファ空間の平均TCP率とは非常に異なっている率を達成することができます。 TCPは、背面にそれらを送り返すのに対し、特に、TFMCCは、時間内にTFMCCスペースアウトパケット以来、小さなバッファサイズの影響を受けにくいです。したがって、TCPはバッファスペースが不足している場合は、パケットロスを確認するために多くの可能性が高いです。
TFMCC is designed for applications that use a fixed packet size and vary their sending rate in packets per second in response to congestion. Some applications (e.g., those using audio) require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications.
TFMCCは固定パケットサイズを使用し、輻輳に応答して第2あたりのパケットでそれらの送信レートを変化させるアプリケーションのために設計されています。いくつかのアプリケーション（例えば、オーディオを使用するもの）は、パケット間の時間の一定間隔を必要とし、それらのパケットサイズの代わりに混雑に応じて、それらのパケットレートを変えます。このドキュメントの輻輳制御機構は、これらのアプリケーションで使用することはできません。
TFMCC extends the basic mechanisms of TFRC into the multicast domain. In order to compete fairly with TCP, TFMCC receivers individually measure the prevalent network conditions and calculate a rate that is TCP-friendly on the path from the sender to themselves. The rate is determined using an equation for TCP throughput, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time (RTT), and packet size. We define a loss event as one or more lost or marked packets from the packets received during one RTT, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [9]. The sending rate of the multicast transmission is adapted to the receiver experiencing the worst network conditions.
TFMCCは、マルチキャストドメインにTFRCの基本的なメカニズムを拡張します。 TCPと公平に競争するためには、TFMCC受信機は個別に普及しているネットワークの状態を測定し、自分自身への送信者からのパスにTCPフレンドリーれているレートを計算します。速度は、大きく損失イベント率、ラウンドトリップ時間（RTT）、およびパケットサイズの関数として、TCPの送信レートを記述するTCPスループット、の方程式を用いて決定されます。我々は、マークされたパケットは、明示的輻輳通知（ECN）から輻輳表示を指す1 RTT、[9]の間に受信したパケットから1つまたは複数の紛失またはマーキングされたパケットとして損失イベントを定義します。マルチキャスト送信の送信レートは、最悪のネットワーク条件を経験受信するように適合されます。
Basically, TFMCC's congestion control mechanism works as follows:
次のように基本的には、TFMCCの輻輳制御機構が動作します：
o Each receiver measures the loss event rate and its RTT to the sender.
O各受信機は、送信者に損失イベント率とそのRTTを測定します。
o Each receiver then uses this information, together with an equation for TCP throughput, to derive a TCP-friendly sending rate.
O各受信機は、TCPフレンドリーな送信レートを導出するために、一緒にTCPスループットのための式で、この情報を使用しています。
o Through a distributed feedback suppression mechanism, only a subset of the receivers are allowed to give feedback to prevent a feedback implosion at the sender. The feedback mechanism ensures that receivers reporting a low desired transmission rate have a high probability of sending feedback.
O分散フィードバック抑制機構を介して、受信機のサブセットのみが送信側にフィードバック内部破裂を防止するためにフィードバックを与えることを許可されています。フィードバック機構は、低い所望の伝送速度を通知する受信機がフィードバックを送信する確率が高いことを保証します。
o Receivers whose feedback is not suppressed report the calculated transmission rate back to the sender in so-called receiver reports. The receiver reports serve two purposes: they inform the sender about the appropriate transmit rate, and they allow the receivers to measure their RTT.
Oそのフィードバック抑制されていない受信機は、いわゆるレシーバレポートに送信者に算出された伝送速度を報告しています。レシーバレポートは2つの目的を果たす：彼らは、適切な送信レートについての送信者に通知し、彼らは受信機が彼らのRTTを測定することができます。
o The sender selects the receiver that reports the lowest rate as current limiting receiver (CLR). Whenever feedback with an even lower rate reaches the sender, the corresponding receiver becomes CLR and the sending rate is reduced to match that receiver's calculated rate. The sending rate increases when the CLR reports a calculated rate higher than the current sending rate.
O送信側は電流制限レシーバ（CLR）として最低レートを報告する受信機を選択します。さらに低いレートのフィードバックは、送信者に到達するたびに、対応する受信機は、CLRとなり、送信速度は、その受信機の計算速度と一致するように減少されます。 CLRは、現在の送信レートより高い計算された率を報告し、送信速度が上昇します。
The dynamics of TFMCC are sensitive to how the measurements are performed and applied and to what feedback suppression mechanism is chosen. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand how the interactions between mechanisms affect the dynamics of TFMCC.
TFMCCのダイナミクスは、測定が行われ、適用される方法とフィードバック抑制機構が選択されたものに敏感です。我々は、これらの測定を実行し、適用するには、以下の特定のメカニズムをお勧めします。他のメカニズムは可能ですが、メカニズム間の相互作用がTFMCCのダイナミクスにどのように影響するかを理解することが重要です。
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFMCC. However, we note that the TCP throughput equation used must reflect TCP's retransmit timeout behavior, as this dominates TCP throughput at higher loss rates. We also note that the assumptions implicit in the throughput equation about the loss event rate parameter have to be a reasonable match to how the loss rate or loss event rate is actually measured. While this match is not perfect for the throughput equation and loss rate measurement mechanisms given below, in practice the assumptions turn out to be close enough.
損失イベント率とRTTの関数としてTCPスループットを与える任意の現実的な方程式はTFMCCでの使用に適したものでなければなりません。しかし、我々はこれがより高い損失率のTCPスループットを支配として使用するTCPスループット方程式は、TCPの再送タイムアウトの動作を反映しなければならないことに注意してください。また、損失イベント・レート・パラメータのスループット式の暗黙の前提が損失率や損失イベント率を実際に測定する方法を合理的に一致する必要があることに注意してください。この試合は、下記のスループット方程式とロス率測定メカニズムのための完璧ではないですが、実際には仮定が十分に近いことが判明します。
The throughput equation we currently recommend for TFMCC is a slightly simplified version of the throughput equation for Reno TCP from [8]:
我々は現在、TFMCCのためにお勧めのスループット方程式はリノTCPのスループット方程式を少し単純化したバージョンであるから[8]：
8 s
X = --------------------------------------------------------- (1)
R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)))
where
どこ
X is the transmit rate in bits/second.
Xは、ビット/秒で伝送速度です。
s is the packet size in bytes.
Sはバイト単位のパケットサイズです。
R is the round-trip time in seconds.
Rは、秒単位の往復時間です。
p is the loss event rate, between 0.0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
pが送信されたパケットの数の分数として損失事象の数の0.0と1.0との間の損失イベント率、です。
In the future, different TCP equations may be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来的には、異なるTCP方程式は、この方程式に代入することができます。要件は、スループット方程式は、適合TCP輻輳制御のためのTCPの送信レートの合理的な近似であることです。
The parameters s (packet size), p (loss event rate), and R (RTT) need to be measured or calculated by a TFMCC implementation. The measurement of R is specified in Section 4.3.2, and the measurement of p is specified in Section 5. The parameter s (packet size) is normally known to an application. This may not be so in two cases:
パラメータs（パケットサイズ）、P（損失イベント率）、およびR（RTT）を測定又はTFMCC実装によって計算される必要があります。 Rの測定はセクション4.3.2で指定され、そしてpの測定は、通常、アプリケーションには知られている第5のパラメータs（パケットサイズ）で指定されています。これは、2つの場合にそうではないかもしれません。
o The packet size naturally varies depending on the data. In this case, although the packet size varies, that variation is not coupled to the transmit rate. It should normally be safe to use an estimate of the mean packet size for s.
Oパケットのサイズは、当然データに応じて変化します。パケットサイズが変化するが、この場合には、その変化は、送信レートに結合されていません。通常のための平均パケットサイズの推定値を使用しても安全でなければなりません。
o The application needs to change the packet size rather than the number of packets per second to perform congestion control. This would normally be the case with packet audio applications where a fixed interval of time needs to be represented by each packet. Such applications need to have a different way of measuring parameters.
Oアプリケーションは、輻輳制御を実行するためのパケットサイズではなく、1秒あたりのパケット数を変更する必要があります。これは、通常、時間の一定間隔は、各パケットによって表される必要があるパケット音声アプリケーションの場合であろう。このようなアプリケーションでは、パラメータを測定する別の方法を持っている必要があります。
Currently, TFMCC cannot be used for the second class of applications.
現在、TFMCCは、アプリケーションの第二のクラスのために使用することはできません。
Before specifying the sender and receiver functionality, we describe the congestion control information contained in packets sent by the sender and feedback packets from the receivers. Information from the sender can either be sent in separate congestion control messages or piggybacked onto data packets. If separate congestion control messages are sent at time intervals larger than the time interval between data packets (e.g., once per feedback round), it is necessary to be able to include timestamp information destined for more than one receiver to allow a sufficient number of receivers to measure their RTT.
送信者と受信者機能を指定する前に、我々は、受信機から送信側とフィードバックパケットが送信したパケットに含まれる輻輳制御情報を記述します。送信者からの情報は、いずれかの別の輻輳制御メッセージで送信されたか、データパケットにピギーバックすることができます。別輻輳制御メッセージはデータ・パケット（例えば、一度フィードバックラウンドあたり）の間の時間間隔よりも大きい時間間隔で送信された場合は、受信機の十分な数を可能にするために、複数の受信機宛のタイムスタンプ情報を含むことができることが必要です彼らのRTTを測定しました。
As TFMCC will be used along with a transport protocol, we do not specify packet formats, since these depend on the details of the transport protocol used. The recommended representation of the header fields is given below. Alternatively, if the computational overhead of a floating point representation is prohibitive, fixed point arithmetic can be used at the expense of larger packet headers. Sender and receivers of a specific TFMCC instance need to agree on a common encoding for the header fields.
TFMCCは、トランスポートプロトコルと一緒に使用されるように、我々はこれらが使用されるトランスポートプロトコルの詳細に依存するので、パケットのフォーマットを指定しないでください。ヘッダフィールドの推奨表現を以下に示します。浮動小数点表現の計算オーバーヘッドが法外である場合に代替的に、固定小数点演算は、より大きなパケットヘッダを犠牲にして使用することができます。特定TFMCCインスタンスの送信者と受信機は、ヘッダフィールドのための共通の符号化に同意する必要があります。
Each packet sent by the data sender contains the following information:
データ送信側によって送信される各パケットには、以下の情報が含まれています。
o A sequence number i. This number is incremented by one for each data packet transmitted. The field must be sufficiently large that it does not wrap, causing two different packets with the same sequence number to be in the receiver's recent packet history at the same time. In most cases, the sequence number will be supplied by the transport protocol used along with TFMCC.
Oシーケンス番号i。この数は、送信される各データパケットに対して1だけインクリメントされます。フィールドには、同じシーケンス番号を持つ2つの異なるパケットが同時に受信機の最近のパケット履歴であることを引き起こして、それがラップしていないことを十分に大きくなければなりません。ほとんどの場合、シーケンス番号はTFMCCと共に使用されるトランスポートプロトコルによって供給されます。
o A suppression rate X_supp in bits/s. Only receivers with a calculated rate lower than the suppression rate are eligible to give feedback, unless their RTT is higher than the maximum RTT described below, in which case they are also eligible to give feedback. The suppression rate should be represented as a 12-bit floating point value with 5 bits for the unsigned exponent and 7 bits for the unsigned mantissa (to represent rates from 100 bit/s to 400 Gbit/s with an error of less than 1%).
ビット/秒における抑制率X_supp O。抑制率よりも低い計算速度を有する唯一の受信機は、それらのRTTが彼らはまた、フィードバックを与えるために適格である場合、RTTは、後述する最大値よりも高い場合を除き、フィードバックを与えるために適格です。抑制率は、符号なしの仮数のために符号なし指数は5ビット、7ビット（1％未満の誤差で400ギガビット/秒に100ビット/ sの速度を表すために12ビット浮動小数点値として表現されなければなりません）。
o A timestamp ts_i indicating when the packet is sent. The resolution of the timestamp should typically be milliseconds, and the timestamp should be an unsigned integer value no less than 16 bits wide.
パケットが送信されたときを示すタイムスタンプts_i O。タイムスタンプの分解能は、典型的には、ミリ秒であるべきであり、タイムスタンプがない未満の16ビット幅の符号なし整数値でなければなりません。
o A receiver ID r and a copy of the timestamp tr_r' = tr_r of that receiver's last report, which allows the receiver to measure its RTT. If there is a delay ts_d between receiving the report from receiver r and sending the data packet, then tr_r' = tr_r + ts_d is included in the packet instead. The receiver ID is described in the next section. The resolution of the timestamp echo should be milliseconds, and the timestamp should be an unsigned integer value no less than 16 bits wide. If separate congestion control messages are used instead of piggybacked ones, the packet needs to contain a list of receiver IDs with corresponding timestamps to allow a sufficient number of receivers to simultaneously measure their RTT. For the default values used for the feedback process, this corresponds to a list size on the order of 10 to 20 entries.
受信機のID rと受信機がそのRTTを測定することができるよう受信者の最後のレポートのタイムスタンプtr_r」= tr_rのコピーO。レシーバRからレポートを受信し、データパケットを送信する間の遅延ts_dがある場合、次に= tr_r + ts_d」tr_r代わりパケットに含まれています。受信機IDは、次のセクションに記載されています。タイムスタンプ・エコーの解像度はミリ秒であるべきであり、タイムスタンプがない未満の16ビット幅の符号なし整数値でなければなりません。別輻輳制御メッセージを代わりにピギーバックのものを用いている場合、パケットは、受信機の十分な数が同時にそれらのRTTを測定することを可能にするために、対応するタイムスタンプと受信機IDのリストを含む必要があります。フィードバックプロセスに使用されるデフォルト値については、これは10〜20のエントリの順序にリストサイズに対応します。
o A flag is_CLR indicating whether the receiver with ID r is the CLR.
ID rの受信機は、CLRであるか否かを示すフラグis_CLR O。
o A feedback round counter fb_nr. This counter is incremented by the sender at the beginning of a new feedback round to notify the receivers that all feedback for older rounds should be suppressed. The feedback round counter should be at least 4 bits wide.
カウンターfb_nrラウンドフィードバックO。このカウンタは、古いラウンドのすべてのフィードバックが抑制される必要があることを受信者に通知するために、新たなフィードバックラウンドの開始時に送信者によってインクリメントされます。フィードバックラウンドカウンタは、少なくとも4ビット幅であるべきです。
o A maximum RTT value R_max, representing the maximum of the RTTs of all receivers. The RTT should be measured in milliseconds. An 8-bit floating point value with 4 bits for the unsigned exponent and 4 bits for the unsigned mantissa (to represent RTTs from 1 millisecond to 64 seconds with an error of ca. 6%) should be used for the representation.
全ての受信機ののRTTの最大値を表す、最大RTT値R_MAX O。 RTTは、ミリ秒単位で測定されなければなりません。符号なしの指数のための4ビットと符号なしの仮数のための4ビットと8ビットの浮動小数点値は、（約6％の誤差で1ミリ秒〜64秒のRTTを表すために）表現するために使用されるべきです。
Each feedback packet sent by a data receiver contains the following
information:
o A unique receiver ID r. In most cases, the receiver ID will be supplied by the transport protocol, but it may simply be the IP address of the receiver.
固有の受信機IDのR O。ほとんどの場合、受信機IDは、トランスポートプロトコルによって供給されるが、それは単に、受信機のIPアドレスであってもよいです。
o A flag have_RTT indicating whether the receiver has made at least one RTT measurement since it joined the session.
それがセッションに参加しましたので、受信機は、少なくとも一つのRTTの測定を行っているか否かを示すフラグhave_RTT O。
o A flag have_loss indicating whether the receiver experienced at least one loss event since it joined the session.
それがセッションに参加しましたので、受信機は、少なくとも一つの損失事象を経験したか否かを示すフラグhave_loss O。
o A flag receiver_leave indicating that the receiver will leave the session (and should therefore not be CLR).
受信機がセッションを終了します（したがって、CLRであってはならない）ことを示すフラグreceiver_leave O。
o A timestamp tr_r indicating when the feedback packet is sent. The representation of the timestamp should be the same as that of the timestamp echo in the data packets.
フィードバックパケットが送信されたときを示すタイムスタンプtr_r O。タイム・スタンプの表現は、データパケットのタイムスタンプのエコーと同じでなければなりません。
o An echo ts_i' of the timestamp of the last data packet received. If the last packet received at the receiver has sequence number i, then ts_i' = ts_i is included in the feedback. If there is a delay tr_d between receiving that last data packet and sending feedback, then ts_i' = ts_i + tr_d is included in the feedback instead. The representation of the timestamp echo should be the same as that of the timestamp in the data packets.
Oエコーts_i」最後のデータパケットのタイムスタンプのは受け取りました。受信機で受信された最後のパケットのシーケンス番号を持っている場合、私は、その後ts_i」= ts_iフィードバックに含まれています。その最後のデータ・パケットを受信し、フィードバックを送信する間の遅延tr_dがある場合、ts_i」= ts_i + tr_d代わりフィードバックに含まれています。タイムスタンプ・エコーの表現は、データパケットのタイムスタンプと同じでなければなりません。
o A feedback round echo fb_nr, reflecting the highest feedback round counter value received so far. The representation of the feedback round echo should be the same as the one used for the feedback round counter in the data packets.
フィードバックラウンドエコーfb_nr O、値がこれまでに受信した最高フィードバックラウンドカウンタを反映しています。フィードバックラウンドエコーの表現は、データパケットにフィードバックラウンドカウンタのために使用したものと同じであるべきです。
o The desired sending rate X_r. This is the rate calculated by the receiver to be TCP-friendly on the path from the sender to this receiver. The representation of the desired sending rate should be the same as that of the suppression rate in the data packets.
所望の送信速度X_R O。これは、この送信者から受信者のパス上でTCPフレンドリーであることを受信機で計算率です。所望の送信レートの表現は、データパケットにおける抑制率と同じであるべきです。
The data sender multicasts a stream of data packets to the data receivers at a controlled rate. Whenever feedback is received, the sender checks if it is necessary to switch CLRs and to readjust the sending rate.
データ送信側マルチキャスト制御された速度でデータ受信機へのデータパケットのストリーム。フィードバックは、送信者のチェックを受けているときはいつでも、のCLRを切り替えると、送信速度を再調整する必要がある場合。
The main tasks that have to be provided by a TFMCC sender are:
TFMCC送信者によって提供されなければならない主なタスクは以下のとおりです。
o adjusting the sending rate,
O送信レートを調整し、
o controlling receiver feedback, and
受信機フィードバック制御、およびo
o assisting receiver-side RTT measurements.
受信側のRTT測定値を補助O。
At initialization of the sender, the maximum RTT is set to a value that should be larger than the highest RTT to any of the receivers. It should not be smaller than 500 milliseconds for operation in the public Internet. The sending rate X is initialized to 1 packet per maximum RTT.
送信者の初期化時に、最大RTTは、受信機のいずれかに最高RTTよりも大きくなければならない値に設定されています。これは、公共のインターネットでの動作のために500ミリ秒より小さくすべきではありません。送信レートXが最大RTTあたり1つのパケットに初期化されます。
For each feedback packet that arrives at the sender, the sender computes the instantaneous RTT to the receiver as
送信者に到達する各フィードバックパケットのために、送信者は受信機と瞬時RTTを計算します
R_r = ts_now - ts_i'
R_r = ts_now - ts_i」
where ts_now is the time the feedback packet arrived. Receivers will have adjusted ts_i' for the time interval between receiving the last data packet and sending the corresponding report so that this interval will not be included in R_r. If the actual RTT is smaller than the resolution of the timestamps and ts_now equals ts_i', then R_r is set to the smallest positive RTT value larger than 0 (i.e., 1 millisecond in our case). If the instantaneous RTT is larger than the current maximum RTT, the maximum RTT is increased to that value:
ts_nowは、フィードバックパケットが到着した時間です。レシーバは、最後のデータパケットを受信し、この間隔はR_rには含まれないように対応するレポートを送信するまでの時間間隔のためのts_i「を調整しています。実際のRTTは、タイムスタンプの分解能よりも小さく、ts_now「はts_i等しい場合、次いでR_rは0（この場合には、すなわち、1ミリ秒）よりも大きい最小の正のRTT値に設定されています。瞬時RTTが現在の最大RTTよりも大きい場合、最大RTTはその値に増加されます。
R_max = R_r
R_MAX = R_r
Otherwise, if no feedback with a higher instantaneous RTT than the maximum RTT is received during a feedback round (see Section 3.4), the maximum RTT is reduced to
最大RTTより高い瞬時RTTとは、フィードバックがラウンドフィードバックの間に受信されない場合、さもなければ、最大RTTをに低減される（セクション3.4参照）
R_max = MAX(R_max * 0.9, R_peak)
R_MAX = MAX（R_MAX * 0.9、R_peak）
where R_peak is the peak receiver RTT measured during the feedback round.
R_peakは、RTTは、フィードバックのラウンド中に測定されたピークの受信機です。
The maximum RTT is mainly used for feedback suppression among receivers with heterogeneous RTTs. Feedback suppression is closely coupled to the sending of data packets, and for this reason, the maximum RTT must not decrease below the maximum time interval between consecutive data packets:
最大RTTは、主に異種のRTTと受信機の間でフィードバック抑制のために使用されます。フィードバック抑制は、密接にデータパケットの送信に連結されており、このため、最大RTTは、連続したデータ・パケット間の最大時間間隔を下回る減少してはなりません。
R_max = max(R_max, 8s/X + ts_gran)
R_MAX = MAX（R_MAX、8S / X + ts_gran）
where ts_gran is the granularity of the sender's system clock (see Section 3.7).
ts_granは、送信側のシステムクロックの精度です（3.7節を参照してください）。
When a feedback packet from receiver r arrives at the sender, the sender has to check whether it is necessary to adjust the transmission rate and to switch to a new CLR.
レシーバRからフィードバックパケットが送信者に到着すると、送信者は、送信レートを調整し、新しいCLRに切り替える必要があるかどうかをチェックしなければなりません。
How the rate is adjusted depends on the desired rate X_r of the receiver report. We distinguish four cases:
率が調整されてどのように受信レポートの所望の速度X_Rに依存します。私たちは4例を区別する：
1. If no CLR is present, receiver r becomes the current limiting receiver. The sending rate X is directly set to X_r, so long as this would result in a rate increase of less than 8s/R_max bits/s (i.e., 1 packet per R_max). Otherwise X is gradually increased to X_r at an increase rate of no more than 8s/R_max bits/s every R_max seconds.
1.ないCLRが存在しない場合、受信機Rは、電流制限受信機となります。送信速度Xは、直接であれば、これは8S / R_MAXビット/秒（R_MAXあたり即ち、1つのパケット）未満の速度の増加をもたらすように、X_Rに設定されています。それ以外の場合はXは徐々に8S / R_MAXビット/秒おきR_MAX秒を超えないの増加率でX_Rに増加しています。
2. If receiver r is not the CLR but a CLR is present, then receiver r becomes the current limiting receiver if X_r is less than the current sending rate X and the receiver_leave flag of that receiver's report is not set. Furthermore, the sending rate is reduced to X_r.
受信機RはCLRではなく、CLRが存在する場合X_Rが設定されていない現在の送信率Xとその受信機のレポートのreceiver_leaveフラグ未満である場合2.受信機Rは、電流制限受信機となります。さらに、送信レートはX_Rに減少しています。
3. If receiver r is not the CLR but a CLR is present and the receiver_leave flag of the CLR's last report was set, then receiver r becomes the current limiting receiver. However, if X_r > X, the sending rate is not increased to X_r for the duration of a feedback round to allow other (lower rate) receivers to give feedback and be selected as CLR.
受信機RはCLRではなく、CLRが存在し、CLRの最後のレポートのreceiver_leaveフラグが設定されている場合3.、受信機Rは、電流制限受信機となります。しかし、X_R> X場合、送信速度は、他の（より低いレート）受信機がフィードバックを与えるとCLRとして選択することができるようにラウンドフィードバックの期間X_Rに増加しません。
4. If receiver r is the CLR, the sending rate is set to the minimum of X_r and X + 8s/R_max bits/s.
4.受信機RはCLRである場合、送信レートはX_Rの最小値に設定し、X + 8S / R_MAXビット/ sです。
If the receiver has not yet measured its RTT but already experienced packet loss (indicated by the corresponding flags in the receiver report), the receiver report will include a desired rate that is based on the maximum RTT rather than the actual RTT to that receiver. In this case, the sender adjusts the desired rate using its measurement of the instantaneous RTT R_r to that receiver:
受信機は、まだそのRTTを測定したが、既に（受信報告に対応するフラグによって示される）、パケット損失を経験していない場合、レシーバレポートは、受信機への実際のRTTよりもむしろ最大RTTに基づいて所望の速度を含むであろう。この場合、送信側は、受信側に瞬時RTT R_rその測定を使用して所望の速度を調整します。
X_r' = X_r * R_max / R_r
X_R」= X_R * R_MAX / R_r
X_r' is then used instead of X_r to detect whether to switch to a new CLR.
X_R」は、新しいCLRに切り替えるかどうかを検出するために、代わりにX_Rの使用されています。
If the TFMCC sender receives no reports from the CLR for 4 RTTs, the sending rate is cut in half unless the CLR was selected less than 10 RTTs ago. In addition, if the sender receives no reports from the CLR for at least 10 RTTs, it assumes that the CLR crashed or left the group. A new CLR is selected from the feedback that subsequently arrives at the sender, and we increase as in case 3, above.
TFMCCの送信者が4つのRTTのためのCLRからのレポートを受信しない場合はCLRが10の未満のRTT前に選択された場合を除き、送信レートを半分にカットされます。送信者は、少なくとも10件のRTTのためのCLRからのレポートを受信しなかった場合に加えて、それはCLRがクラッシュまたはグループを去っていることを前提としています。新しいCLRは、その後、送信側に到着したフィードバックから選択され、我々は、上記のケース3のように増加しています。
If no new CLR can be selected (i.e., in the absence of any feedback from any of the receivers) it is necessary to reduce the sending rate further. For every 10 consecutive RTTs without feedback, the sending rate is cut in half. The rate is at most reduced to one packet every 8 seconds.
新しいCLR（すなわち、受信機のいずれかからのフィードバックが存在しない場合に）選択することができない場合には、さらに送信レートを低減する必要があります。フィードバックのないすべての連続した10件のRTTのために、送信レートが半分にカットされます。レートは最大1つのパケットごとに8秒に短縮されます。
Note that when receivers stop receiving data packets, they will stop sending feedback. This eventually causes the sending rate to be reduced in the case of network failure. If the network subsequently recovers, a linear increase to the calculated rate of the CLR will occur at 8s/R_max bits/s every R_max.
受信機は、データパケットの受信を停止するとき、彼らはフィードバックの送信を停止することに注意してください。これは、最終的には、送信速度は、ネットワークに障害が発生した場合に削減されます。ネットワークが、その後回復した場合、CLRの計算速度の直線的な増加は8S / R_MAXビット/秒毎R_MAXで起こります。
An application using TFMCC may have a minimum sending rate requirement, where the application becomes unusable if the sending rate continuously falls below this minimum rate. The application should exclude receivers that report such a low rate from the multicast group. The specific mechanism to do this is application dependent and beyond the scope of this document.
TFMCCを使用するアプリケーションは、送信レートを連続この最小速度を下回った場合、アプリケーションが使用できなくなる最小送信レート要求を有することができます。アプリケーションは、マルチキャストグループから、このような低金利を報告レシーバを除外する必要があります。これを行うための具体的なメカニズムは、アプリケーションに依存し、この文書の範囲を超えています。
The receivers allowed to send a receiver report are determined in so-called feedback rounds. Feedback rounds have a duration T of six times the maximum RTT. In case the multicast model is ASM (i.e., receiver feedback is multicast to the whole group) the duration of a feedback round may be reduced to four times the maximum RTT.
レシーバレポートを送信することを許可受信機は、いわゆるフィードバックラウンドで決定されます。フィードバックラウンドは6倍、最大RTTの持続時間Tを有します。場合にマルチキャストモデルは、ASMであるラウンド4倍最大RTTに還元することができるフィードバックの持続時間（すなわち、受信機からのフィードバックがグループ全体にマルチキャストされます）。
Only receivers wishing to report a rate that is lower than the suppression rate X_supp or those with a higher RTT than R_max may send feedback. At the beginning of each feedback round, X_supp is set to the highest possible value that can be represented. When feedback arrives at the sender over the course of a feedback round, X_supp is decreased such that more and more feedback is suppressed towards the end of the round. How receiver feedback is spread out over the feedback round is discussed in Section 4.5.
抑制率X_suppまたはR_MAXより高いRTTとのそれらのフィードバックを送信することがより低い率を報告したい受信機だけ。各フィードバックラウンドの開始時に、X_suppを表すことができ、可能な限り最高の値に設定されています。フィードバックは、フィードバックラウンドにわたって送信者に到着すると、X_suppは、より多くのフィードバックがラウンドの終わりに向かって抑制されるように減少しています。どのように受信機フィードバックフィードバックラウンドに広がっていることは4.5節で議論されています。
Whenever non-CLR feedback for the current round arrives at the sender, X_supp is reduced to
現在のラウンドのための非CLRのフィードバックが送信者に到着するたびに、X_suppはに減少し
X_supp = (1-g) * X_r
X_supp =（1-G）* X_R
if X_supp > X_r. Feedback that causes the corresponding receiver to be selected as CLR, but that was from a non-CLR receiver at the time of sending, also contributes to the feedback suppression. Note that X_r must not be adjusted by the sender to reflect the receiver's real RTT in case X_r was calculated using the maximum RTT, as is done for setting the sending rate (Section 3.3); otherwise, a feedback implosion is possible. The parameter g determines to what extent higher rate feedback can suppress lower rate feedback. This mechanism guarantees that the lowest calculated rate reported lies within a factor of g of the actual lowest calculated rate of the receiver set (see [13]). A value of g of 0.1 is recommended.
X_supp> X_R場合。対応する受信機は、CLRとして選択させるが、それは送信時に非CLR受信機から得たフィードバックは、フィードバック抑制に寄与する。 X_Rが最大RTTを用いて計算した場合の送信レート（3.3節）を設定するために行われているようX_Rは、受信機の実際のRTTを反映するために、送信者によって調整されてはならないことに注意してください。そうでない場合は、フィードバック爆縮が可能です。パラメータgがどの程度高いレートフィードバックは低レートフィードバックを抑制することができることを決定します。この機構は、最も低い計算されたレートは、受信機のセット（[13]参照）の実際の最低の計算された速度のG倍内にあることを報告することを保証します。 0.1 gの値が推奨されます。
To allow receivers to suppress their feedback, the sender's suppression rate needs to be updated whenever feedback is received. This suppression rate has to be communicated to the receivers in a timely manner, either by including it in the data packet header or, if separate congestion control messages are used, by sending a message with the suppression rate whenever the rate changes significantly (i.e., when it is reduced to less than (1-g) times the previously advertised suppression rate).
受信機が彼らのフィードバックを抑制できるようにするには、送信者の抑制率は、フィードバックが受信されるたびに更新する必要があります。この抑制率は、抑制率大幅たびに速度変化（すなわち、でメッセージを送信することによって、別個の輻輳制御メッセージが使用される場合、データパケットヘッダに含めるか、のいずれかにより、タイムリーに受信機に伝達されなければなりませんこれは（1-G）倍以前にアドバタイズ抑制率）未満に低下したとき。
After a time span of T, the feedback round ends if non-CLR feedback was received during that time. Otherwise, the feedback round ends as soon as the first non-CLR feedback message arrives at the sender but at most after 2T. The feedback round counter is incremented by one, and the suppression rate X_supp is reset to the highest representable value. The feedback round counter restarts with round 0 after a wrap-around.
非CLRフィードバックがその時間の間に受信された場合、Tの期間の後に、フィードバックがラウンド終了します。最初の非CLRのフィードバックメッセージが2T後に最大で差出人に到着するが、それ以外の場合のように、フィードバックは、ラウンドとすぐに終了します。フィードバックラウンドカウンタが1だけインクリメントされ、そして抑制率X_suppは最高表現可能な値にリセットされます。フィードバックラウンドカウンタはラップアラウンド後のラウンド0で再起動します。
Receivers measure their RTT by sending a timestamp with a receiver report, which is echoed by the sender. If congestion control information is piggybacked onto data packets, usually only one receiver ID and timestamp can be included. If multiple feedback messages from different receivers arrive at the sender during the time interval between two data packets, the sender has to decide which receiver to allow to measure the RTT. The same applies if separate congestion control messages allow echoing multiple receiver timestamps simultaneously, but the number of receivers that gave feedback since the last congestion control message exceeds the list size.
受信機は、送信者によってエコーされ受信レポート、とタイムスタンプを送信することによって、彼らのRTTを測定します。輻輳制御情報は、データパケットにピギーバックされている場合、通常は1つの受信機IDとタイムスタンプが含まれ得ます。異なる受信機から複数のフィードバック・メッセージが2つのデータパケットの間の時間間隔の間に送信側に到着した場合、送信者は、RTTを測定することを可能にするために受信機かを決定しなければなりません。別輻輳制御メッセージを同時に複数の受信機のタイムスタンプをエコー許可が、最後の輻輳制御メッセージは、リストのサイズを超えているので、フィードバックを与えた受信機の数ならば同じことが当てはまります。
The sender's timestamp echoes are prioritized in the following order:
送信者のタイムスタンプのエコーは、次の順序で優先順位付けされています。
1. a new CLR (after a change of CLR's) or a CLR without any previous RTT measurements
1.（CLRの変更後の）新しいCLRまたは任意の以前のRTT測定せずにCLR
2. receivers without any previous RTT measurements in the order of the feedback round echo of the corresponding receiver report (i.e., older feedback first)
対応する受信機レポートのフィードバックラウンドエコーのために以前のRTT測定値なしの2レシーバ（すなわち、古いフィードバック最初）
3. non-CLR receivers with previous RTT measurements, again in ascending order of the feedback round echo of the report
再びレポートのフィードバックラウンドエコーの小さい順に、前のRTT測定値3.非CLR受信機、
Ties are broken in favor of the receiver with the lowest reported rate.
ネクタイは最低の報告率と受信機の賛成で分割されます。
It is necessary to account for the time that elapses between receiving a report and sending the next data packet. This time needs to be deducted from the RTT and thus has to be added to the receiver's timestamp value.
レポートを受信し、次のデータパケットを送信する間に経過する時間を考慮することが必要です。この時間は、RTTから控除する必要がありますので、受信側のタイムスタンプ値に加算する必要があります。
Whenever no feedback packets arrive in the interval between two data packets, the CLR's last timestamp, adjusted by the appropriate offset, is echoed. When the number of packets per RTT is so low that all packets carry a non-CLR receiver's timestamp, the CLR's timestamp and ID are included in a data packet at least once per feedback round.
いかなるフィードバックパケットが2つのデータパケットの間隔で到着しないときはいつでも、CLRの最後のタイムスタンプは、適切なオフセットにより調整、エコーされます。 RTTあたりのパケット数は、全てのパケットが非CLR受信機のタイムスタンプを運ぶように低い場合、CLRのタイムスタンプとIDは、少なくとも一回のフィードバックラウンド当たりのデータパケットに含まれています。
TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth share at the start of a session. During slowstart, the sending rate increases exponentially. The rate increase is limited to the minimum of the rates included in the receiver reports, and receivers report twice the rate at which they currently receive data. As in normal congestion control mode, the receiver with the smallest reported rate becomes CLR. Since a receiver can never receive data at a rate higher than its link bandwidth, this effectively limits the overshoot to twice this bandwidth. In case the resulting increase over R_max is less than 8s/R_max bits/s, the sender may choose to increase the rate by up to 8s/R_max bits/s every R_max. The current sending rate is gradually adjusted to the target rate reported in the receiver reports over the course of an RTT. Slowstart is terminated as soon as any one of the receivers experiences its first packet loss. Since that receiver's calculated rate will be lower than the current sending rate, the receiver will be selected as CLR.
TFMCCはすぐにセッションの開始時にその公平な帯域幅のシェアに近づくためにスロースタートメカニズムを使用しています。スロースタートの間、指数関数的にレート増加を送信します。料金は、レシーバレポートに含まれるの割合の増加を最小限に制限され、受信機は二回、彼らは現在のデータを受信する速度を報告しています。通常輻輳制御モードと同様に、最小の報告レートを有する受信機は、CLRとなります。受信機は、そのリンクの帯域幅よりも高いレートでデータを受け取ることはできませんので、これは効果的に二回、この帯域幅にオーバーシュートを制限します。 R_MAXにわたって得られた増加は8S / R_MAXビット/秒未満である場合には、送信者は8S / R_MAXビット/秒毎R_MAXまでによって速度を増加させるために選択することができます。現在の送信レートを徐々にRTTの過程で受信機レポートで報告された目標レートに調整されています。スロースタートはすぐに受信機のいずれかが最初のパケット損失を経験すると終了します。その受信機の計算速度は、現在の送信速度よりも低くなるので、受信機は、CLRとして選択されます。
During slowstart, the upper bound on the rate increase of 8s/R_max bits/s every RTT does not apply. Only after the TFMCC sender receives the first report with the have_loss flag set is the rate increase limited in this way.
スロースタート時には、8S / R_MAXビット/ sの速度の増加の上限は、すべてのRTTは適用されません。 TFMCCの送信者がhave_lossフラグが設定された最初の報告を受けた後にのみ、このように限ら率の増加があります。
Slowstart may also be used after the sender has been idle for some time, to quickly reach the previous sending rate. When the sender stops sending data packets, it records the current sending rate X' = X. Every 10 RTTs, the allowed sending rate will be halved due to lack of receiver feedback, as specified in Section 3.3. This halving may take place multiple times. When the sender resumes, it may perform a slowstart from the current allowed rate up to the recorded rate X'. Slowstart ends after the first packet loss by any of the receivers or as soon as X' is reached.
送信者がしばらくの間アイドル状態になった後にスロースタートも素早く前の送信レートに到達するために、使用することができます。送信者は、データパケットの送信を停止すると、それはすべての10件のRTT = X.現在の送信レートX」を記録し、セクション3.3で指定されるように、許容される送信レートは、原因受信機からのフィードバックの欠如に半減されます。この半分は複数回行われてもよいです。送信者が再開されると、それは最高記録レートX」に現在の許容レートからスロースタートを行うことができます。スロースタートは、受信機のいずれか、または次第X」として到達したことにより、最初のパケットロスの後に終了します。
To this end, receivers have to clear the have_loss flag after 10 RTTs without data packets as specified in Section 4.3.1. The have_loss flag is only used during slowstart. Therefore, clearing the flag has no effect if no packets arrived due to network partitioning or packet loss.
このため、受信機は、4.3.1項で指定されたデータパケットなしで10件のRTT後have_lossフラグをクリアする必要があります。 have_lossフラグは、スロースタート時に使用されます。パケットがネットワーク分割やパケット損失に起因到着しない場合したがって、フラグをクリアしても効果はありません。
As TFMCC is rate-based, and as operating systems typically cannot schedule events precisely, it is necessary to be opportunistic about sending data packets so that the correct average rate is maintained despite the coarse-grain or irregular scheduling of the operating system. Thus, a typical sending loop will calculate the correct inter-packet interval, ts_ipi, as follows:
TFMCCとして率ベースで、オペレーティング・システムは、典型的には、正確にイベントをスケジュールすることができないように、正確な平均速度は、オペレーティングシステムの粗粒又は不規則なスケジュールにもかかわらず維持されるようにデータパケットを送信約日和見する必要があります。次のようにこのように、典型的な送信ループは、ts_ipi正しいパケット間の間隔を計算します。
ts_ipi = 8s/X
ts_ipi = 8S / X
When a sender first starts sending at time t_0, it calculates ts_ipi and calculates a nominal send time, t_1 = t_0 + ts_ipi, for packet 1. When the application becomes idle, it checks the current time, ts_now, and then requests re-scheduling after (ts_ipi - (ts_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, ts_now, again. If (ts_now > t_1 - delta) then packet 1 is sent (see below for delta).
送信者が初めてT_0で送信を開始すると、それはts_ipiを計算し、名目上の送信時間を算出し、T_1 = T_0 + ts_ipi、アプリケーションがアイドル状態になると、パケット1のために、それは現在の時刻をチェックし、ts_now、その後、再スケジューリングを要求します（ - （ts_now - T_0）ts_ipi）秒後。アプリケーションが再スケジュールされると、それは再び、現在の時刻、ts_nowをチェックします。 （ts_now> T_1 - デルタ）場合、パケット1が送信される（デルタについては以下を参照のこと）。
Now, a new ts_ipi may be calculated and used to calculate a nominal send time, t_2, for packet 2: t_2 = t_1 + ts_ipi. The process then repeats with each successive packet's send time being calculated from the nominal send time of the previous packet. Note that the actual send time ts_i, and not the nominal send time, is included as timestamp in the packet header.
T_2 = T_1 + ts_ipi：今、新しいts_ipiは、パケット2のために、T_2、計算され、名目上の送信時間を計算するために使用することができます。プロセスはその後、それぞれの連続したパケットの送信時刻が前のパケットの名目上の送信時間から計算された状態で繰り返されます。実際の送信時間ts_iはなく、公称送信時間は、パケットヘッダ内のタイムスタンプとして含まれることに留意されたいです。
In some cases, when the nominal send time, t_i, of the next packet is calculated, it may already be the case that ts_now > t_i - delta. In such a case, the packet should be sent immediately. Thus, if the operating system has coarse timer granularity and the transmit rate is high, then TFMCC may send short bursts of several packets separated by intervals of the OS timer granularity.
デルタ - いくつかのケースでは、とき公称送信時間、T_Iは、次のパケットが計算されるのではなく、すでにそのts_now> T_I場合があり得ます。そのような場合には、パケットがすぐに送信されなければなりません。オペレーティングシステムは粗いタイマー粒度を有しており、伝送速度が高い場合したがって、その後TFMCCはOSタイマー粒状の間隔によって分離されたいくつかのパケットの短いバーストを送信することができます。
The parameter delta is to allow a degree of flexibility in the send time of a packet. If the operating system has a scheduling timer granularity of ts_gran seconds, then delta would typically be set to:
パラメータデルタは、パケットの送信時間の自由度を可能にすることです。オペレーティングシステムはts_gran秒のスケジュールタイマーの粒度を有している場合には、デルタは一般的に設定されます。
delta = min(ts_ipi/2, ts_gran/2)
デルタ=分（ts_ipi / 2、ts_gran / 2）
ts_gran is 10 milliseconds on many Unix systems. If ts_gran is not known, a value of 10 milliseconds can be safely assumed.
ts_granは多くのUnixシステム上で10ミリ秒です。 ts_granが知られていない場合は、10ミリ秒の値が安全に仮定することができます。
Receivers measure the current network conditions (namely, RTT and loss event rate) and use this information to calculate a rate that is fair to competing traffic. The rate is then communicated to the sender in receiver reports. Due to the potentially large number of receivers, it is undesirable that all receivers send reports, especially not at the same time.
レシーバは、現在のネットワークの状態（すなわち、RTTおよび損失イベント率）を測定し、トラフィックの競合に公平である率を算出し、この情報を使用します。レートは、受信機のレポートで、送信者に通知されます。受信機の潜在的に多数のため、すべての受信機は特にないと同時に、レポートを送信することは望ましくありません。
In the description of the receiver functionality, we will first address how the receivers measure the network parameters and then discuss the feedback process.
受信機の機能の説明では、まず受信機がネットワークパラメータを測定する方法に対処して、フィードバックプロセスを説明します。
The receiver is initialized when it receives the first data packet. The RTT is set to the maximum RTT value contained in the data packet. This initial value is used as the receiver's RTT until the first real RTT measurement is made. The loss event rate is initialized to 0. Also, the flags receiver_leave, have_RTT, and have_loss are cleared.
それが最初のデータパケットを受信した場合に受信機が初期化されます。 RTTは、データパケットに含まれる最大RTT値に設定されています。最初の本当のRTTの測定が行われるまで、この初期値は、受信機のRTTとして使用されています。損失イベント率も0に初期化され、フラグは、have_RTTをreceiver_leave、そしてhave_lossがクリアされています。
A receiver that sends feedback but wishes to leave the TFMCC session within the next feedback round may indicate the pending leave by setting the receiver_leave flag in its report. If the leaving receiver is the CLR, the receiver_leave flag should be set for all the reports within the feedback round before the leave takes effect.
フィードバックを送信するが、そのレポートにreceiver_leaveフラグを設定することにより、保留中の休暇を示すことができる次フィードバックラウンド内TFMCCセッションを去ることを望む受信機。去る受信機がCLRであれば休暇が有効になる前に、receiver_leaveフラグは、フィードバックラウンド内のすべてのレポートのために設定する必要があります。
Receivers have to update their estimate of the network parameters with each new data packet they receive.
レシーバは、彼らが受け取るそれぞれの新しいデータ・パケットとのネットワークパラメータの彼らの推定値を更新する必要があります。
When a data packet is received, the receiver adds the packet to the packet history. It then recalculates the new value of the loss event rate p. The loss event rate measurement mechanism is described separately in Section 5.
データパケットを受信すると、受信機は、パケット履歴にパケットを追加します。その後、損失イベント率pの新しい値を再計算します。損失イベント率測定機構は、セクション5で個別に記載されています。
When a loss event is detected, the flag have_loss is set. In case no data packets are received for 10 consecutive RTTs, the flag is cleared to allow the sender to slowstart. It is set again when new data packets arrive and a loss event is detected.
損失イベントが検出されると、フラグhave_lossが設定されています。場合にパケットが連続する10件のRTTのための受信されたデータは、フラグは、送信者がスロースタートできるようにするためにクリアされません。新しいデータパケットが到着したときに再設定され、損失事象が検出されました。
When a receiver gets a data packet that carries the receiver's own ID in the r field, the receiver updates its RTT estimate.
受信機はRフィールドで受信機の独自のIDを運ぶデータパケットを取得すると、受信機は、そのRTT推定値を更新します。
R_sample = tr_now - tr_r'
R_sample = tr_now - tr_r」
where tr_now is the time the data packet arrives at the receiver and tr_r' is the receiver report timestamp echoed in the data packet. If the actual RTT is smaller than the resolution of the timestamps and tr_now equals tr_r', then R_sample is set to the smallest positive RTT value larger than 0 (i.e., 1 millisecond in our case).
tr_nowは、データパケットが受信機とtr_rに到着する時間である」データパケットにエコー受信レポートのタイムスタンプがあります。実際のRTTは、タイムスタンプの分解能よりも小さく、tr_now「はtr_r等しい場合、次いでR_sampleが最小の正のRTT値より大きい0に設定されている（すなわち、この例では、1ミリ秒）。
If no feedback has been received before
R = R_sample
Else R = q*R + (1-q)*R_sample
そうでなければR = Qの*のR +（1-Q）* R_sample
A filter parameter q of 0.5 is recommended for non-CLR receivers. The CLR performs RTT measurements much more frequently and hence should use a higher filter value. We recommend using q=0.9. Note that TFMCC is not sensitive to the precise value for the filter constant.
0.5のフィルタパラメータQは、非CLR受信機のために推奨されます。 CLRは、より高いフィルタ値を使用する必要がはるかに頻繁ひいてはRTT測定を行います。我々は、Q = 0.9を使用することをお勧めします。 TFMCCはフィルタ定数の正確な値に対して敏感ではないことに留意されたいです。
Optionally, sender-based RTT measurements may be used instead of receiver-based ones. The sender already determines the RTT to a receiver from the receiver's echo of the sender's own timestamp for the calculation of the maximum RTT. For sender-based RTT measurements, this RTT measurement needs to be communicated to the receiver. Instead of including an echo of the receiver's timestamp, the sender includes the receiver's RTT in the next data packet, using the prioritization rules described in Section 3.5.
必要に応じて、センダベースのRTT測定値ではなく、受信機ベースのものを用いてもよいです。送信者は、すでに最大RTTの計算のための送信者自身のタイムスタンプの受信機のエコーから受信機へのRTTを決定します。センダベースのRTT測定のために、このRTT測定は、受信機に伝達される必要があります。代わりに、受信機のタイムスタンプのエコーなどの、送信者は、セクション3.5に記載優先順位付け規則を使用して、次のデータパケットで受信機のRTTを含みます。
To simplify sender operation, smoothing of RTT samples as described above should still be done at the receiver.
センダ操作を簡素化するために、上記のようにRTTサンプルの平滑化は依然として受信機で行われるべきです。
When an RTT measurement is performed, the receiver also determines the one-way delay D_r from itself to the sender:
RTTの測定を行う場合、受信機は、送信側に自身から一方向遅延D_Rを決定します。
D_r = tr_r' - ts_i
D_R = tr_r」 - ts_i
where ts_i and tr_r' are the timestamp and receiver report timestamp echo contained in the data packet. With each new data packet j, the receiver can now calculate an updated RTT estimate as:
ts_iとtr_rは、」タイムスタンプと受信機レポートのタイムスタンプは、データパケットに含まれるエコーされています。それぞれの新しいデータパケットjに、受信機は、今のように更新RTT推定値を計算することができます。
R' = max(D_r + tr_now - ts_j, 1 millisecond)
R」= MAX（D_R + tr_now - ts_j、1ミリ秒）
In between RTT measurements, the updated R' is used instead of the smoothed RTT R. Like the RTT samples, R' must be strictly positive. When a new measurement is made, all interim one-way delay measurements are discarded (i.e., the smoothed RTT is updated according to Section 4.3.2 without taking the interim one-way delay adjustments into account).
RTT測定値との間に、更新されたR「は代わりRTTサンプルと同様に、平滑化RTT Rのに使用され、R」は厳密に正でなければなりません。新たな測定が行われたとき、全ての中間一方向遅延測定値は破棄される（すなわち、平滑化RTTを考慮中間一方向遅延調整を取ることなく、セクション4.3.2に従って更新されます）。
For the one-way delay measurements, the clocks of sender and receivers need not be synchronized. Clock skew will cancel itself out when both one-way measurements are added to form an RTT estimate, as long as clock drift between real RTT measurements is negligible.
一方向遅延測定では、送信者と受信機のクロックは同期する必要はありません。両方の一方向の測定が実際のRTT測定値との間のクロックドリフト無視できるものである限り、RTT推定を形成するために添加されたとき、クロック・スキューは、それ自体を相殺します。
The same one-way delay adjustments should be applied to the RTT supplied by the sender when using sender-based RTT measurements.
同一方向遅延調整は、センダベースのRTT測定値を使用した場合、送信者によって供給されたRTTに適用すべきです。
When a receiver has not experienced any loss events, it cannot calculate a TCP-friendly rate to include in the receiver reports. Instead, the receiver measures the current receive rate and sets the desired rate X_r to twice the receive rate.
受信機は、任意の損失イベントを経験していない場合は、受信機レポートに含めるTCPフレンドリーなレートを計算することはできません。その代わりに、受信機は、現在の受信率を測定し、二回受信率を所望の速度X_Rを設定します。
The receive rate in bits/s is measured as the number of bits received over the last k RTTs, taking into account the IP and transport packet headers, but excluding the link-layer packet headers. A value for k between 2 and 4 is recommended.
ビット数がIPトランスポートパケットヘッダを考慮したが、リンク層パケットヘッダを除いた、最後のk個のRTTを介して受信したとしてビット/秒で受信率を測定します。 2と4の間のkの値が推奨されます。
When a receiver measures a non-zero loss event rate, it calculates the desired rate using Equation (1). In case no RTT measurement is available yet, the maximum RTT is used instead of the receiver's RTT. The desired rate X_r is updated whenever the loss event rate or the RTT changes.
受信機が非ゼロ損失イベント率を測定する場合は、式を使用して所望の速度を算出する（1）。全くRTT測定値がまだ利用可能でない場合には、最大RTT代わりに受信機のRTTを使用します。損失イベント率やRTTが変化するたびに所望の速度X_Rが更新されます。
A receiver may decide not to report desired rates that are below 1 packet per 8 seconds, since a sender is very slow to recover from such low sending rates. In this case, the receiver reports a desired rate of 1 packet per 8 seconds. However, it must leave the multicast group if for more than 120 seconds, the calculated rate falls below the reported rate and the current sending rate is higher than the receiver's calculated rate.
受信機は、送信者がこのような低い送信速度から回復することは非常に遅いため、8秒ごとに1つのパケット未満の希望率を報告しないことを決定してもよいです。この場合、受信機は、8秒ごとに1つのパケットの所望の速度を報告します。 120秒以上のため、計算量が報告された割合を下回ると、現在の送信レートは、受信側の計算レートよりも高い場合しかし、それは、マルチキャストグループを離れなければなりません。
As mentioned above, calculation of the desired rate is not possible before the receiver experiences the first loss event. In that case, twice the rate at which data is received is included in the receiver reports as X_r to allow the sender to slowstart as described in Section 3.6. This is also done when the sender resumes sending data packets after the have_loss flag was cleared due to the sender being idle.
上述したように、受信機は、最初の損失事象を経験する前に、所望のレートの計算は不可能です。その場合には、データが受信された2倍の速度は、セクション3.6で説明したように、送信者は、スロースタートを可能にするX_Rとしてレシーバレポートに含まれています。 have_lossフラグが原因送信者がアイドル状態にクリアされた後、送信者は、データパケットの送信を再開するときこれも行われます。
Let fb_nr be the highest feedback round counter value received by a receiver. When a new data packet arrives with a higher feedback round counter than fb_nr, a new feedback round begins and fb_nr is updated. Outstanding feedback for the old round is canceled. In case a feedback number with a value that is more than half the feedback number space lower than fb_nr is received, the receiver assumes that the feedback round counter wrapped and also cancels the feedback timer and updates fb_nr.
fb_nrは、受信機で受信した最高のフィードバックラウンドカウンタ値とします。新しいデータパケットがfb_nrよりも高いフィードバックラウンドカウンターに到着すると、新しいフィードバックラウンドが始まり、fb_nrが更新されます。古いラウンドのための優れたフィードバックが解除されます。場合fb_nrが受信されるよりも半分以上のフィードバック番号空間低い値を有するフィードバック番号が、受信機がフィードバックラウンドカウンタがラップされたと仮定し、またフィードバック・タイマと更新fb_nrを解除します。
The CLR sends its feedback independently from all the other receivers once per RTT. Its feedback does not suppress other feedback and cannot be suppressed by other receiver's feedback.
CLRはRTTごとに一度、他のすべての受信機から独立してそのフィードバックを送信します。そのフィードバックは、他のフィードバックを抑制しないと、他の受信者のフィードバックによって抑制することができません。
Non-CLR receivers set a feedback timer at the beginning of a feedback round. Using an exponentially weighted random timer mechanism, the feedback timer is set to expire after
非CLR受信機は、フィードバックラウンドの最初にフィードバックタイマーを設定します。指数関数的に重み付けランダムタイマーメカニズムを使用して、フィードバックタイマは後に満了するように設定されています
t = max(T * (1 + log(x)/log(N)), 0)
T = MAX（T *（1 +ログ（X）/ログ（N））、0）
where
どこ
x is a random variable uniformly distributed in (0,1],
xは、均一に分布したランダム変数（0,1]であります
T is the duration of a feedback round (i.e., 6 * R_max),
Tは、フィードバック・ラウンド（すなわち、6 * R_MAX）の期間であります
N is an estimated upper bound on the number of receivers.
Nは、受信機の数に限界推定上位です。
N is a constant specific to the TFMCC protocol. Since TFMCC scales to up to thousands of receivers, setting N to 10,000 for all receivers (and limiting the TFMCC session to at most 10,000 receivers) is recommended.
NはTFMCCプロトコルに固有の定数です。 TFMCCは、受信機の数千人にまでスケールするので、すべての受信機10,000にNを設定する（そして最も10,000レシーバにTFMCCセッションを制限する）をお勧めします。
A feedback packet is sent when the feedback timer expires, unless the timer is canceled beforehand. When the multicast model is ASM, feedback is multicast to the whole group; otherwise, the feedback is unicast to the sender. The feedback packet includes the calculated rate valid at the time the feedback packet is sent (not the rate at the point of time when the feedback timer is set). The copy of the timestamp ts_i of the last data packet received, which is included in the feedback packet, needs to be adjusted by the time interval between receiving the data packet and sending the report to allow the sender to correctly infer the instantaneous RTT (i.e., that time interval has to be added to the timestamp value).
フィードバックタイマーが満了したときにタイマーが事前に解除されない限り、フィードバックパケットは、送信されます。マルチキャストモデルは、ASMがある場合は、フィードバックは、グループ全体にマルチキャストされます。そうでない場合は、フィードバックは、送信者にユニキャストされます。フィードバックパケットは、フィードバックパケットが送信される時間（ないフィードバックタイマーが設定された時点での速度）で、有効な計算速度を含みます。フィードバックパケットに含まれる受信した最後のデータパケットのタイムスタンプts_iのコピーが、送信者が正しく瞬時RTTを推測できるように、データパケットを受信し、レポートを送信するまでの時間間隔で調整する必要があります（つまり、 、その時間間隔）のタイムスタンプ値に加算されなければなりません。
The timer is canceled if a data packet is received that has a lower suppression rate than the receiver's calculated rate and a higher or equal maximum RTT than the receiver's RTT. Likewise, a data packet indicating the beginning of a new feedback round cancels all feedback for older rounds. In case of ASM, the timer is also canceled if a feedback packet is received from another non-CLR receiver reporting a lower rate.
データパケットが受信機の計算されたレートよりも低い抑制率と受信機のRTTよりも高いか又は等しい最大RTTを有する受信された場合、タイマーはキャンセルされます。同様に、新しいフィードバックラウンドの始まりを示すデータパケットは、古いラウンドのすべてのフィードバックをキャンセルします。フィードバックパケットは、より低いレートを報告する別の非CLR受信機から受信された場合、ASMの場合には、タイマーも解除されます。
The feedback suppression process is complicated by the fact that the calculated rates of the receivers will change during a feedback round. If the calculated rates decrease rapidly for all receivers, feedback suppression can no longer prevent a feedback implosion, since earlier feedback will always report a higher rate than current feedback. To make the feedback suppression mechanism robust in the face of changing rates, it is necessary to introduce X_fbr, the calculated rate of a receiver at the beginning of a feedback round. A receiver needs to suppress its feedback not only when the suppression rate is less than the receiver's current calculated rate but also in the case that the suppression rate falls below X_fbr.
フィードバック抑制プロセスは、受信機の計算速度は、フィードバックのラウンド中に変化するという事実によって複雑になります。計算速度は、すべての受信機のために急激に低下した場合、以前のフィードバックは常に電流帰還よりも高い率を報告しますから、フィードバック抑制は、もはや、フィードバック爆縮を防ぐことはできません。変化率の顔で堅牢なフィードバック抑制機構を作るために、フィードバックラウンドの開始時にX_fbr、受信機の計算された割合を導入する必要があります。受信機は、抑制率は、受信機の現在の計算されたレート未満であるが、抑制率はX_fbr下回った場合にない場合にのみ、そのフィードバックを抑制する必要があります。
When the maximum RTT changes significantly during one feedback round, it is necessary to reschedule the feedback timer in proportion to the change.
最大RTTはラウンド1人の帰還中に著しく変化したとき、変更に比例してフィードバックタイマーのスケジュールを変更する必要があります。
t = t * R_max / R_max'
T = T * R_MAX / R_MAX」
where R_max is the new maximum RTT and R_max' is the previous maximum RTT. The same considerations hold when the last data packets were received more than a time interval of R_max ago. In this case, it is necessary to add the difference of the inter-packet gap and the maximum RTT to the feedback time to prevent a feedback implosion (e.g., in case the sender crashed).
R_MAXは新しい最大RTTとR_MAXがどこにあるか」以前の最大のRTTです。最後のデータ・パケットは前R_MAXの時間間隔よりも多くを受け取った場合、同じ考慮事項が保持します。この場合、パケット間ギャップとフィードバック爆縮を防止するために、フィードバック時に最大RTTの差を追加する必要がある（例えば、場合に送信者が墜落しました）。
t = t + max(tr_now - tr_i - R_max, 0)
T = T + MAX（tr_now - tr_i - R_MAX、0）
where tr_i is the time when the last data packet arrived at the receiver.
どこtr_iは、最後のデータ・パケットが受信機に到着した時間があります。
More details on the characteristics of the feedback suppression mechanism can be found in [13] and [3].
フィードバック抑制機構の特性の詳細は[13]に見ることができる[3]。
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFMCC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets.
損失イベント率の正確で安定した測定を取得することTFMCCのための最も重要です。損失率の測定は、到着するパケットのシーケンス番号から紛失したり、マークされたパケットの検出に基づいて、受信機で実行されます。
TFMCC assumes that all packets contain a sequence number that is incremented by one for each packet that is sent. For the purposes of this specification, we require that if a lost packet is retransmitted, the retransmission is given a new sequence number that is the latest in the transmission sequence, and not the same sequence number as the packet that was lost. If a transport protocol has the requirement that it must retransmit with the original sequence number, then the transport protocol designer must figure out how to distinguish delayed from retransmitted packets and how to detect lost retransmissions.
TFMCCは、すべてのパケットが送信されたパケットごとに1ずつインクリメントされるシーケンス番号が含まれていることを前提としています。本明細書の目的のために、私たちは失われたパケットが再送された場合、再送が失われたパケットと同じシーケンス番号送信シーケンスにおける最新の、そしてない新しいシーケンス番号が付与されていることが必要です。トランスポートプロトコルは、それが元のシーケンス番号を再送しなければならないという要件がある場合、トランスポートプロトコルの設計者は、再送パケットより遅れとどのように失われた再送信を検出するために、区別するために方法を見つけ出す必要があります。
The receivers each maintain a data structure that keeps track of which packets have arrived and which are missing. For the purposes of specification, we assume that the data structure consists of a list of packets that have arrived along with the timestamp when each packet was received. In practice, this data structure will normally be stored in a more compact representation, but this is implementation-specific.
受信機は、それぞれのパケットが到着しており、その不足しているかを追跡するデータ構造を維持します。明細書の目的のために、我々は、データ構造は、各パケットを受信したタイムスタンプと一緒に到着したパケットのリストで構成されていることを前提としています。実際には、このデータ構造は、通常、よりコンパクトな表現に格納されるが、これは実装固有です。
The loss of a packet is detected by the arrival of at least three packets with a higher sequence number than the lost packet. The requirement for three subsequent packets is the same as with TCP, and it is to make TFMCC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after 3 subsequent packets arrived) at a receiver, the late packet can fill the hole in the reception record, and the receiver can recalculate the loss event rate. Future versions of TFMCC might make the requirement for three subsequent packets adaptive based on experienced packet reordering, but we do not specify such a mechanism here.
パケットの損失が失われたパケットよりも高いシーケンス番号を有する少なくとも3つのパケットの到着によって検出されます。 3つの後続のパケットのための要件は、TCPと同じです、そしてそれは、並べ替えの存在下でTFMCCをより堅牢にすることです。 （3つの後続のパケットが到着した後に）パケットが受信機に遅れて到着した場合、TCPとは対照的に、遅いパケットが受信レコード内の穴を埋めることができ、受信機は、損失イベント率を再計算することができます。 TFMCCの将来のバージョンでは、経験豊富なパケットの並べ替えに基づいて3つの後続のパケットの適応のための要件を作るかもしれませんが、我々はここで、このようなメカニズムを指定しないでください。
For an ECN-capable connection, a marked packet is detected as a congestion event as soon as it arrives, without having to wait for the arrival of subsequent packets.
ECN対応の接続では、マークされたパケットは、後続のパケットの到着を待たずに、できるだけ早くそれが到着すると、輻輳イベントとして検出されます。
TFMCC requires that the loss event rate be robust to several consecutive packets lost where those packets are part of the same loss event. This is similar to TCP, which (typically) only performs one halving of the congestion window during any single RTT. Thus the receivers need to map the packet loss history into a loss event record, where a loss event is one or more packets lost in an RTT.
TFMCCは、損失イベント率は、それらのパケットが同じ損失事象の一部で失われたいくつかの連続したパケットに対してロバストであることが必要です。これは、任意の単一のRTTの間に、輻輳ウィンドウの半分を実行する（典型的に）TCP、同様です。したがって、受信機は、損失事象がRTTで失われた1つ以上のパケットである損失イベント記録、にパケットロス履歴をマップする必要があります。
To determine whether a lost or marked packet should start a new loss event or be counted as part of an existing loss event, we need to compare the sequence numbers and timestamps of the packets that arrived at the receiver. For a marked packet S_new, its reception time T_new can be noted directly. For a lost packet, we can interpolate to infer the nominal "arrival time". Assume:
紛失したり、マークされたパケットが、新たな損失イベントを開始すべきか、既存の損失事象の一部としてカウントされるかどうかを決定するために、我々は、受信機に到着したパケットのシーケンス番号とタイムスタンプを比較する必要があります。マークされたパケットS_newについて、その受信時刻T_newは直接言及することができます。失われたパケットのために、私たちは、公称「到着時刻」を推論するために補間することができます。想定します。
S_loss is the sequence number of a lost packet.
S_lossは、失われたパケットのシーケンス番号です。
S_before is the sequence number of the last packet to arrive with sequence number before S_loss.
S_beforeはS_loss前のシーケンス番号と到着する最後のパケットのシーケンス番号です。
S_after is the sequence number of the first packet to arrive with sequence number after S_loss.
S_afterはS_loss後のシーケンス番号と到着する最初のパケットのシーケンス番号です。
T_before is the reception time of S_before.
T_beforeはS_beforeの受信時刻です。
T_after is the reception time of S_after.
T_afterはS_afterの受信時刻です。
Note that T_before can be either before or after T_after due to reordering.
T_beforeが原因並べ替えにT_after前または後のいずれかであることに注意してください。
For a lost packet S_loss, we can interpolate its nominal "arrival time" at the receiver from the arrival times of S_before and S_after. Thus
失われたパケットS_lossのために、私たちはS_beforeとS_afterの到着時間から受信機にその公称「到着時間」を補間することができます。したがって
T_loss = T_before + ( (T_after - T_before) * (S_loss - S_before)/(S_after - S_before) );
T_loss = T_before +（（T_after - T_before）*（S_loss - S_before）/（S_after - S_before））。
Note that if the sequence space wrapped between S_before and S_after, the sequence numbers must be modified to take this into account before the calculation is performed. If the largest possible sequence number is S_max, and S_before > S_after, then modifying each sequence number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be sufficient.
S_beforeとS_afterの間で包まれたシーケンス空間場合、シーケンス番号は計算が実行される前に、このことを考慮するように修正しなければならないことに注意してください。可能な最大のシーケンス番号は、次にS」=（S +（S_MAX + 1）/ 2）MOD（S_MAX + 1）によって、各シーケンス番号Sを修正S_MAX、及びS_before> S_after、ある場合に通常十分であろう。
If the lost packet S_old was determined to have started the previous loss event, and if we have just determined that S_new has been lost, then we interpolate the nominal arrival times of S_old and S_new, called T_old and T_new, respectively.
失われたパケットS_oldは以前損失事象を開始しているために、私たちはちょうどS_newが失われたと判断した場合に決定されたなら、私たちは、それぞれ、T_oldとT_new呼ばS_oldとS_newの公称到着時間を、補間します。
If T_old + R >= T_new, then S_new is part of the existing loss event. Otherwise, S_new is the first packet of a new loss event.
T_old + R> = T_new場合、S_newは、既存の損失事象の一部です。それ以外の場合は、S_newは、新たな損失事象の最初のパケットです。
If a loss interval, A, is determined to have started with packet sequence number S_A and the next loss interval, B, started with packet sequence number S_B, then the number of packets in loss interval A is given by (S_B - S_A).
損失間隔、Aは、パケットシーケンス番号S_A及び次損失間隔Bで開始したと判定された場合、パケットシーケンス番号S_Bを開始し、損失区間A内のパケット数がによって与えられる（S_B - S_A）。
To calculate the loss event rate p, we first calculate the average loss interval. This is done using a filter that weights the n most recent loss event intervals in such a way that the measured loss event rate changes smoothly.
損失イベント率pを計算するためには、まず平均損失間隔を計算します。これは、測定損失イベント率が滑らかに変化するような方法で、重みnは、最新の損失事象間隔というフィルタを使用して行われます。
Weights w_0 to w_(n-1) are calculated as:
重みは、のように計算されるW_するW_0（N-1）：
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
Thus if n=8, the values of w_0 to w_7 are:
N = 8の場合したがって、w_7にW_0の値は次のとおりです。
The value n for the number of loss intervals used in calculating the loss event rate determines TFMCC's speed in responding to changes in the level of congestion. As currently specified, TFMCC should not be used for values of n significantly greater than 8, for traffic that might compete in the global Internet with TCP. At the very least, safe operation with values of n greater than 8 would require a slight change to TFMCC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率を計算する際に使用される損失間隔の数の値nは、輻輳のレベルの変化に応答してTFMCCの速度を決定します。現在指定されているように、TFMCCはTCPとグローバルなインターネットで競争可能性があるトラフィックのために、8よりも有意に大きい、nの値に使用すべきではありません。少なくとも、8よりもn個以上の値を持つ安全な操作が重いパケットロスで二つ以上の往復時間に、より厳しい対応を含めTFMCCのメカニズムにわずかな変更を必要とします。
When calculating the average loss interval, we need to decide whether to include the interval since the most recent packet loss event. We only do this if it is sufficiently large to increase the average loss interval.
平均損失間隔を計算するとき、我々は、最新のパケット損失イベントからの間隔を含めるかどうかを決定する必要があります。平均損失間隔を長くするために十分に大きい場合に私たちはこれを行います。
Thus, if the most recent loss intervals are I_0 to I_n, with I_0 being the interval since the most recent loss event, then we calculate the average loss interval I_mean as:
最も最近の損失間隔が値InにI_0であればこのように、I_0は、最新の損失事象以来の間隔であると、我々は、平均損失間隔I_meanを計算します。
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
The loss event rate, p is simply:
損失イベント率は、pは単純です：
p = 1 / I_mean;
P = 1 / I_mean。
As described in Section 5.4, the most recent loss interval is only assigned 4/(3*n) of the total weight in calculating the average loss interval, regardless of the size of the most recent loss interval. This section describes an optional history discounting mechanism that allows the TFMCC receivers to adjust the weights, concentrating more of the relative weight on the most recent loss interval, when the most recent loss interval is more than twice as large as the computed average loss interval.
セクション5.4で説明したように、最新の損失間隔のみにかかわらず、最新の損失間隔の大きさの、平均損失間隔を計算する際に総重量の4 /（3×n）を割り当てられます。このセクションでは、最新の損失間隔が計算された平均損失間隔の2倍以上である最も最近の損失間隔で相対重量の濃縮、重みを調整するTFMCC受信を可能にするオプションの履歴割引機構を記載しています。
To carry out history discounting, we associate a discount factor DF_i with each loss interval L_i, where each discount factor is a floating point number. The discount array maintains the cumulative history of discounting for each loss interval. At the beginning, the values of DF_i in the discount array are initialized to 1:
歴史の割引を行うために、我々は、各割引率は、浮動小数点数である各損失間隔L_iを、と割引率DF_iを関連付けます。割引配列は、それぞれの損失間隔の割引の累積履歴を保持します。初めに、割引配列のDF_iの値が1に初期化されます。
for (i = 0 to n) { DF_i = 1; }
（nはI = 0）のための{DF_i = 1。 }
History discounting also uses a general discount factor DF, also a floating point number, that is also initialized to 1. First, we show how the discount factors are used in calculating the average loss interval, and then we describe later in this section how the discount factors are modified over time.
歴史の割引も、我々は、割引率は平均損失間隔の計算に使用されている方法を示し、その後、私たちはこのセクションの後半で説明することも1.最初に初期化される一般的な割引率DF、また、浮動小数点数を、どのように使用しますか割引率は、時間の経過とともに変更されます。
As described in Section 5.4, the average loss interval is calculated using the n previous loss intervals I_1, ..., I_n, and the interval I_0 that represents the number of packets received since the last loss event. The computation of the average loss interval using the discount factors is a simple modification of the procedure in Section 5.4, as follows:
セクション5.4で説明したように、平均損失間隔は、n前損失間隔I_1、...、値In、及び最後損失イベント以降に受信したパケットの数を表す間隔I_0を使用して計算されます。次のように割引率を用いて、平均損失間隔の計算は、セクション5.4の手順の簡単な変更です。
I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
p = min(W_tot0/I_tot0, W_tot1/I_tot1);
The general discounting factor DF is updated on every packet arrival as follows. First, a receiver computes the weighted average I_mean of the loss intervals I_1, ..., I_n:
次のように一般的な割引係数DFは、すべてのパケットの到着時に更新されます。まず、受信機は、損失間隔I_1の加重平均I_meanを計算...、値Inを：
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets received since the last loss event. If I_0 is greater than twice I_mean, then the new loss interval is considerably larger than the old ones, and the general discount factor DF is updated to decrease the relative weight on the older intervals, as follows:
この加重平均I_meanはI_0、最後損失イベント以降に受信したパケットの数と比較されます。 I_0がI_mean倍よりも大きい場合には、新たに損失間隔は、古いものよりもかなり大きく、次のように一般的な割引率DFは、古い間隔の相対的な重みを減少させるために更新されます。
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
A nonzero value for THRESHOLD ensures that older loss intervals from an earlier time of high congestion are not discounted entirely. We recommend a THRESHOLD of 0.5. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
THRESHOLDにゼロ以外の値が高い混雑の早い時間からの古い損失間隔は完全に割り引かれていないことを保証します。我々は0.5のTHRESHOLDをお勧めします。それぞれの新しいパケットの到着で、I_0がさらに増加し、割引率DFが更新されることに注意してください。
When a new loss event occurs, the current interval shifts from I_0 to I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval I_n is forgotten. The previous discount factor DF has to be incorporated into the discount array. Because DF_i carries the discount factor associated with loss interval I_i, the DF_i array has to be shifted as well. This is done as follows:
新しい損失イベントが発生すると、I_1にI_0から現在の間隔シフト、損失間隔I_IはI_の間隔に移行する（I + 1）、及び損失間隔値Inを忘れています。前回の割引率DFは割引配列に組み込まれることがあります。 DF_iは損失間隔I_Iに関連付けられた割引率を運ぶので、DF_iアレイも同様にシフトされなければなりません。これは以下のように行われます。
for (i = 1 to n) {
DF_i = DF * DF_i;
}
for (i = n-1 to 0 step -1) {
DF_(i+1) = DF_i;
}
I_0 = 1;
DF_0 = 1;
DF = 1;
This completes the description of the optional history discounting mechanism. We emphasize that this is an optional mechanism whose sole purpose is to allow TFMCC to respond more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これはオプションの履歴割引メカニズムの説明を終えます。私たちは、これが唯一の目的長い電流損失間隔によって表されるようTFMCCは、混雑の突然の欠如に迅速に対応できるようにすることで、オプションのメカニズムであることを強調する。
The number of packets received before the first loss event usually does not reflect the current loss event rate. When the first loss event occurs, a TFMCC receiver assumes that the correct data rate is the rate at which data was received during the last RTT when the loss occurred. Instead of initializing the first loss interval to the number of packets sent until the first loss event, the TFMCC receiver calculates the loss interval that would be required to produce the receive rate X_recv, and it uses this synthetic loss interval l_0 to seed the loss history mechanism.
最初の損失イベントの前に受信したパケットの数は、通常電流損失イベント率を反映するものではありません。最初の損失イベントが発生すると、TFMCC受信機は、正しいデータレートがデータ損失が発生した最後のRTTの間に受信されたレートであることを前提としています。代わりに、最初の損失事象まで、送信されたパケットの数に最初の損失間隔を初期化する、TFMCC受信機は、受信率X_recvを生成するために必要とされるであろう損失間隔を計算し、それが損失履歴をシードするために、この合成損失間隔L_0を使用します機構。
The initial loss interval is calculated by inverting a simplified version of the TCP Equation (1).
初期損失間隔は、TCP（1）式の簡略化されたバージョンを反転することによって計算されます。
8s
X_recv = sqrt(3/2) * -----------------
R * sqrt(1/l_0)
X_recv * R
==> l_0 = (----------------)^2
sqrt(3/2) * 8s
The resulting initial loss interval is too small at higher loss rates compared to using the more accurate Equation (1), which leads to a more conservative initial loss event rate.
得られた初期の損失間隔は、より保守的な初期損失イベント率につながる、より正確な式（1）を使用する場合に比べ、より高い損失率には小さすぎます。
If a receiver still uses the initial RTT R_max instead of its real RTT, the initial loss interval is too large in case the initial RTT is higher than the actual RTT. As a consequence, the receiver will calculate too high a desired rate when the first RTT measurement R is made and the initial loss interval is still in the loss history. The receiver has to adjust l_0 as follows:
受信機はまだ代わりにその本当のRTTの初期RTT R_MAXを使用している場合は、最初の損失間隔は、初期RTTは、実際のRTTよりも高い場合には大きすぎます。その結果、受信機は、最初のRTT計測Rが行われ、最初の損失間隔が損失履歴に残っている高すぎる所望の速度を計算します。受信機は、次のようにL_0を調整することがあります。
l_0 = l_0 * (R/R_max)^2
L_0 = L_0 *（R / R_MAX）^ 2
No action needs to be taken when the first RTT measurement is made after the initial loss interval left the loss history.
アクションは、最初の損失間隔が損失履歴を残した後の最初のRTTの測定が行われたときに取られる必要はありません。
TFMCC is not a transport protocol in its own right, but a congestion control mechanism that is intended to be used in conjunction with a transport protocol. Therefore, security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms.
TFMCCは、それ自体でトランスポートプロトコルが、トランスポート・プロトコルに関連して使用されることが意図される輻輳制御機構はありません。したがって、セキュリティは、主に特定のトランスポートプロトコルと、その認証メカニズムの文脈において考慮される必要があります。
Congestion control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus, any transport protocol that uses TFMCC should take care to ensure that feedback is only accepted from valid receivers of the data. However, the precise mechanism to achieve this will depend on the transport protocol itself.
輻輳制御機構は、潜在的にサービス拒否を作成するために悪用される可能性があります。これは、偽装されたフィードバックにより発生する可能性があります。したがって、TFMCCを使用するすべてのトランスポートプロトコルは、フィードバックがデータのみの有効な受信側から受け入れられていることを保証するために注意を払う必要があります。しかし、これを達成するための正確なメカニズムは、トランスポートプロトコル自体に依存します。
Congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. However, in TFMCC a receiver can only influence the sending rate if it is the CLR and thus has the lowest calculated rate of all receivers. If the calculated rate is then manipulated such that it exceeds the calculated rate of the second to lowest receiver, it will cease to be CLR. A greedy receiver can only significantly increase the transmission rate if it is the only participant in the session. If such scenarios are of concern, possible defenses against such a receiver would normally include some form of nonce that the receiver must feed back to the sender to prove receipt. However, the details of such a nonce would depend on the transport protocol and, in particular, on whether the transport protocol is reliable or unreliable.
輻輳制御メカニズムは、潜在的にネットワーク帯域幅のその公正な取り分より多くを受信したい貪欲受信機によって操作することができます。それはCLRであり、したがって、すべての受信機の最低の計算された率を持っている場合は、TFMCCに受信機は、送信速度に影響を与えることができます。計算されたレートは、それは最低の受信機への第2の計算されたレートを超えるように操作された場合、それは、CLRを失うだろう。それはセッションでのみ参加の場合は貪欲受信機は大幅に伝送速度を向上させることができます。このようなシナリオが懸念される場合には、このような受信機に対して実行される可能性のある防衛力は、通常、受信機が受信したことを証明するために、送信者にフィードバックしなければならないナンスのいくつかのフォームが含まれるであろう。しかし、そのようなナンスの詳細は、トランスポートプロトコルが信頼できるか信頼できないかどうか、具体的には、トランスポートプロトコルに依存します。
It is possible that a receiver sends feedback claiming that it has a very low calculated rate. This will reduce the rate of the multicast session and might render it useless but obviously cannot hurt the network itself.
受信機は、それは非常に低く算出された率を持っていると主張し、フィードバックを送信することが可能です。これは、マルチキャストセッションの割合を減らすことになり、それは無用かもしれないが、明らかにネットワーク自体を傷つけることはできません。
We expect that protocols incorporating ECN with TFMCC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [12]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol and are not addressed in this document.
私たちは、[12] TFMCCとECNを取り入れたプロトコルはまた、ECN nonceを使用して送信側に受信機からのフィードバックを取り入れたいと思うことを期待しています。 ECNのナンスは、マークされたパケットの偶発的または悪質な隠蔽から送信者を保護ECNの変形です。また、このようなナンスの詳細は、トランスポートプロトコルに依存するであろうと、この文書で扱われていません。
We would like to acknowledge feedback and discussions on equation-based congestion control with a wide range of people, including members of the Reliable Multicast Research Group, the Reliable Multicast Transport Working Group, and the End-to-End Research Group. We would particularly like to thank Brian Adamson, Mark Pullen, Fei Zhao, and Magnus Westerlund for feedback on earlier versions of this document.
私たちは、フィードバックと信頼性の高いマルチキャスト研究グループ、信頼性の高いマルチキャスト交通ワーキンググループ、およびエンドツーエンドの研究グループのメンバーを含む人々の広い範囲、と方程式ベースの輻輳制御に関する議論を確認したいと思います。私たちは、特にこのドキュメントの以前のバージョンへのフィードバックのためにブライアン・アダムソン、マーク・プーレン、飛趙、およびマグヌスウェスターに感謝したいと思います。
[1] 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.
[1] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.、およびM.ルビー、 "信頼できるマルチキャストトランスポート・ビルディング・ブロック一対多バルクデータ転送のための" 、RFC 3048、2001年1月。
[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] J. Widmer and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM Sigcomm 2001, San Diego, August 2001.
[3] J.ウィトマーとM.ハンドリー、「マルチキャストアプリケーションへの拡張式ベースの輻輳制御」、PROC ACM SIGCOMM 2001、サンディエゴ、2001年8月。
[4] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[4] S.フロイド、M.ハンドレー、J. Padhye、およびJ.ウィトマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御"、PROCのACM SIGCOMM 2000、ストックホルム、2000年8月。
[5] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[5]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "否定応答（NACK）配向高信頼マルチキャスト（NORM）ビルディングブロック"、RFC 3941、2004年11月。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[6]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[7] H. W. Holbrook, "A Channel Model for Multicast," Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[7] H. W.ホルブルック、「マルチキャスト用チャネルモデル、」博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニア州、2001年8月。
[8] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
[8] J. Padhye、V. Firoiu、D. Towsley、及びJ.黒瀬、 "モデルTCPスループット：簡単なモデルとその実証的検証"、PROCのACM SIGCOMM 1998。
[9] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[9] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[10] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast congestion control scheme", Proc ACM Sigcomm 2000, Stockholm, August 2000.
[10] L.リゾー、 "pgmcc：TCPフレンドリーなシングルレートのマルチキャスト輻輳制御方式"、PROC ACM SIGCOMM 2000、ストックホルム、2000年8月。
[11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[11] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[12] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[12]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[13] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large Multicast Groups", Proc NGC 2001, London, November 2001.
[13] J.ウィドマー及びT. Fuhrmann、 "大規模なマルチキャストグループのための極値フィードバック"、PROC NGC 2001、ロンドン、2001年11月。
Authors' Addresses
著者のアドレス
Joerg Widmer DoCoMo Euro-Labs Landsberger Str. 312, Munich, Germany EMail: widmer@acm.org
イェルクウィドマードコモユーロ-LabsのランデスのStr。 312、ミュンヘン、ドイツEメール：widmer@acm.org
Mark Handley UCL (University College London) Gower Street, London WC1E 6BT, UK EMail: m.handley@cs.ucl.ac.uk
マーク・ハンドリーUCL（ロンドン大学）ガウアーストリート、ロンドンWC1E 6BT、英国Eメール：m.handley@cs.ucl.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎と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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。