Network Working Group S. Floyd
Request for Comments: 5348 ICIR
Obsoletes: 3448 M. Handley
Updates: 4342 University College London
J. Padhye
Microsoft
J. Widmer
DoCoMo
September 2008
TCP Friendly Rate Control (TFRC): Protocol Specification
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.
このドキュメントでは、TCPフレンドリーレート制御（TFRC）を指定します。 TFRCは、ベストエフォート型のインターネット環境で動作するユニキャストフローの輻輳制御機構です。これは、TCPと帯域幅を競合するが流れたときに合理的に公平であるが、TCPに比べて時間をかけてスループットのはるかに低いばらつきがあり、このような比較的滑らかで、送信速度が重要であるメディアのストリーミングなどのアプリケーションのためにそれがより適しています。
This document obsoletes RFC 3448 and updates RFC 4342.
この文書は、RFC 3448およびRFC 4342の更新プログラムを廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Protocol Mechanism ..............................................4
3.1. TCP Throughput Equation ....................................5
3.2. Packet Contents ............................................7
3.2.1. Data Packets ........................................7
3.2.2. Feedback Packets ....................................8
4. Data Sender Protocol ............................................8
4.1. Measuring the Segment Size .................................9
4.2. Sender Initialization .....................................10
4.3. Sender Behavior When a Feedback Packet Is Received ........10
4.4. Expiration of Nofeedback Timer ............................15
4.5. Reducing Oscillations .....................................17
4.6. Scheduling of Packet Transmissions ........................18
5. Calculation of the Loss Event Rate (p) .........................19
5.1. Detection of Lost or Marked Packets .......................19
5.2. Translation from Loss History to Loss Events ..............20
5.3. The Size of a Loss Interval ...............................22
5.4. Average Loss Interval .....................................22
5.5. History Discounting .......................................24
6. Data Receiver Protocol .........................................26
6.1. Receiver Behavior When a Data Packet Is Received ..........27
6.2. Expiration of Feedback Timer ..............................27
6.3. Receiver Initialization ...................................28
6.3.1. Initializing the Loss History after the
First Loss Event ...................................29
7. Sender-Based Variants ..........................................30
8. Implementation Issues ..........................................31
8.1. Computing the Throughput Equation .........................31
8.2. Sender Behavior When a Feedback Packet Is Received ........32
8.2.1. Determining If an Interval Was a
Data-Limited Interval ..............................32
8.2.2. Maintaining X_recv_set .............................34
8.3. Sending Packets before Their Nominal Send Time ............34
8.4. Calculation of the Average Loss Interval ..................36
8.5. The Optional History Discounting Mechanism ................36
9. Changes from RFC 3448 ..........................................36
9.1. Overview of Changes .......................................36
9.2. Changes in Each Section ...................................37
10. Security Considerations .......................................39
10.1. Security Considerations for TFRC in DCCP .................40
11. Acknowledgments ...............................................40
Appendix A. Terminology ...........................................41
Appendix B. The Initial Value of the Nofeedback Timer .............43
Appendix C. Response to Idle or Data-Limited Periods ..............44
C.1. Long Idle or Data-Limited Periods ........................45
C.2. Short Idle or Data-Limited Periods .......................48
C.3. Moderate Idle or Data-Limited Periods ....................49
C.4. Losses During Data-Limited Periods .......................50
C.5. Other Patterns ...........................................53
C.6. Evaluating TFRC's Response to Idle Periods ...............53
References ........................................................54
Normative References ...........................................54
Informative References .........................................54
This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [FHPW00]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as DCCP (Datagram Congestion Control Protocol) [RFC4340], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [BRS99]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
このドキュメントでは、TCPフレンドリーレート制御（TFRC）を指定します。 TFRCは、ユニキャストフローは、インターネット環境で動作し、[FHPW00] TCPトラフィックと競合するために設計された輻輳制御機構です。代わりに、完全なプロトコルを指定する、この文書は、単にアプリケーションでエンドツーエンドの輻輳制御を組み込んだアプリケーションにおいて、そのようなDCCP（データグラム輻輳制御プロトコル）[RFC4340]などのトランスポートプロトコルで使用することができる輻輳制御メカニズムを指定しますレベル、またはエンドポイントの輻輳管理の文脈における[BRS99]。この文書では、パケットフォーマットや信頼性については説明しません。実装関連の問題は、第8章では、簡単にしか説明されています。
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where we call a flow "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
TFRCは、その送信レートが同じ条件の下でTCPフローの送信レートの2倍以内であれば、一般的に、我々は「合理的公正」の流れを呼び出すTCPフロー、と帯域幅を競合するとき、合理的に公平であるように設計されています。しかし、TFRCは、このような比較的滑らかな送付レートが重要である電話やストリーミングメディアなどのアプリケーションのためにそれをより適切にするTCP、と比較して時間をかけてスループットのはるかに低い変動を持っています。
The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds slower than TCP to changes in available bandwidth. Thus, TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible, we recommend using TCP, or if reliability is not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) congestion control scheme with similar parameters to those used by TCP.
帯域幅を公平に競争しながら、TCPよりも滑らかなスループットを持つことのペナルティは、TFRCは、利用可能な帯域幅の変化にTCPよりも遅く応答することです。アプリケーションが単一のパケット損失に応じて送信レートのTCPの半分を避け、特に、滑らかなスループット要件を有する場合したがって、TFRCにのみ使用されるべきです。同様のパラメータを持つ単純に、できるだけ短い時間でできるだけ多くのデータを転送する必要があるアプリケーションでは、我々は添加剤-増加を使用して、TCPを使用することをお勧めします、または信頼性が要求されていない場合は、乗法-減少（AIMD）輻輳制御方式TCPによって使用されるものに。
TFRC is designed for best performance with applications that use a fixed segment size, and vary their sending rate in packets per second in response to congestion. TFRC can also be used, perhaps with less optimal performance, with applications that do not have a fixed segment size, but where the segment size varies according to the needs of the application (e.g., video applications).
TFRCは、固定セグメントサイズを使用し、輻輳に応答して第2あたりのパケットでそれらの送信レートを変化させるアプリケーションで最高の性能のために設計されています。 TFRCはまた、固定されたセグメントサイズを持っていないが、セグメントのサイズは、アプリケーション（例えば、ビデオ・アプリケーション）のニーズに応じて変化する場合のアプリケーションと、おそらくより少ない最適なパフォーマンスで使用することができます。
Some applications (e.g., some audio applications) require a fixed interval of time between packets and vary their segment size instead of their packet rate in response to congestion. The congestion control mechanism in this document is not designed for those applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for applications that have a fixed sending rate in packets per second but either use small packets or vary their packet size in response to congestion. TFRC-SP is specified in a separate document [RFC4828].
いくつかの用途（例えば、一部のオーディオアプリケーション）パケット間の時間の一定間隔を必要とし、それらのセグメントサイズの代わりに混雑に応じて、それらのパケットレートを変えます。このドキュメントの輻輳制御機構は、これらのアプリケーション用に設計されていません。 TFRC-SP（小パケットTFRC）は秒あたりのパケットに固定された送信速度を有するが、いずれか小さいパケットを使用するか、または輻輳に応答して、それらのパケットサイズを変化させる用途のためのTFRCの変異体です。 TFRC-SPは、別の文書[RFC4828]で指定されています。
This document specifies TFRC as a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control. However, it is also possible to implement TFRC in sender-based variants, as allowed in DCCP's Congestion Control ID 3 (CCID 3) [RFC4342].
この文書ではなく、データ送信側でデータ受信機における輻輳制御情報（すなわち、損失イベント率）の計算と、受信機ベースのメカニズムとして、TFRCを指定します。これは、送信者が多数の同時接続を処理大規模なサーバであり、受信機は、計算のために利用可能なより多くのメモリとCPUサイクルを持つアプリケーションに適しています。加えて、受信機ベースのメカニズムは、マルチキャスト輻輳制御のためのビルディングブロックとしてより適しています。しかし、DCCPの輻輳制御ID 3（CCID 3）[RFC4342]で許可され、送信者ベースの変種でTFRCを実現することも可能です。
This document obsoletes RFC 3448. In the transport protocol DCCP (Datagram Congestion Control Protocol) [RFC4340], the Congestion Control ID Profiles CCID-3 [RFC4342] and CCID-4 [CCID-4] both specify the use of TFRC from RFC 3448. CCID-3 and CCID-4 implementations SHOULD use this document instead of RFC 3448 for the specification of TFRC.
この文書は、トランスポートプロトコルDCCP（データグラム輻輳制御プロトコル）[RFC4340]、輻輳制御IDプロファイルCCID-3 [RFC4342]及びCCID -4- [CCID-4]でRFC 3448.を時代遅れの両方RFC 3448からTFRCの使用を指定します。CCID-3およびCCID-4の実装はTFRCの仕様のために代わりにRFC 3448のこのドキュメントを使用すべきです。
The normative specification of TFRC is in Sections 3-6. Section 7 discusses sender-based variants, Section 8 discusses implementation issues, and Section 9 gives a non-normative overview of differences with RFC 3448.
TFRCの規範的な仕様は、セクション3-6です。第7節は、第8章は、実装の問題について説明し、送信者ベースのバリエーションについて説明し、第9節は、RFC 3448との相違点の非規範的な概要を説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Appendix A gives a list of technical terms used in this document.
付録Aは、このドキュメントで使用される技術用語のリストを与えます。
For its congestion control mechanism, TFRC directly uses a throughput equation for the allowed sending rate as a function of the loss event rate and round-trip time. In order to compete fairly with TCP, TFRC uses the TCP throughput equation, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time, and segment size. We define a loss event as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [RFC3168].
その輻輳制御機構のために、TFRCは、直接損失イベント率および往復時間の関数としての許容送信レートのスループット方程式を使用します。 TCPと公平に競争するためには、TFRCは、おおよそ損失イベント率、ラウンドトリップ時間、およびセグメントサイズの関数としてTCPの送信レートを記述するTCPスループット方程式を、使用しています。マークされたパケットは、明示的輻輳通知（ECN）[RFC3168]から輻輳表示を指し、我々はデータのウィンドウから1つまたは複数の紛失またはマーキングされたパケットのような損失事象を定義します。
Generally speaking, TFRC's congestion control mechanism works as follows:
次のように一般的に言えば、TFRCの輻輳制御機構が動作します：
o The receiver measures the loss event rate and feeds this information back to the sender.
O受信機は、損失イベント率を測定し、送信者にこの情報をフィードバックします。
o The sender also uses these feedback messages to measure the round-trip time (RTT).
O送信者はまた、ラウンドトリップ時間（RTT）を測定するために、これらのフィードバックメッセージを使用しています。
o The loss event rate and RTT are then fed into TFRC's throughput equation, and the resulting sending rate is limited to at most twice the receive rate to give the allowed transmit rate X.
O損失イベント率およびRTTは、その後、TFRCのスループット方程式に供給され、得られた送信レートを最大で二回許容送信率Xを与える速度を受信するように制限されています
o The sender then adjusts its transmit rate to match the allowed transmit rate X.
送信者は、その後、許容送信レートXを一致させるために、その送信レートを調整するoを
The dynamics of TFRC are sensitive to how the measurements are performed and applied. 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 TFRC.
TFRCのダイナミクスは、測定が行われ、どのように適用されるかに敏感です。我々は、これらの測定を実行し、適用するには、以下の特定のメカニズムをお勧めします。他のメカニズムは可能ですが、メカニズムの間の相互作用は、TFRCのダイナミクスにどのように影響するかを理解することが重要です。
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFRC. 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スループットを与える任意の現実的な方程式は、TFRCでの使用に適したものでなければなりません。しかし、我々はこれがより高い損失率のTCPスループットを支配として使用するTCPスループット方程式は、TCPの再送タイムアウトの動作を反映しなければならないことに注意してください。また、損失イベント・レート・パラメータのスループット式の暗黙の前提が損失率や損失イベント率を実際に測定する方法を合理的に一致する必要があることに注意してください。この試合は、下記のスループット方程式とロス率測定メカニズムのための完璧ではないですが、実際には仮定が十分に近いことが判明します。
The throughput equation currently REQUIRED for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [PFTK98]. Ideally, we would prefer a throughput equation based on selective acknowledgment (SACK) TCP, but no one has yet derived the throughput equation for SACK TCP, and simulations and experiments suggest that the differences between the two equations would be relatively minor [FF99] (Appendix B).
現在TFRCために必要なスループット方程式は[PFTK98]からリノTCPのスループット方程式のやや簡略化バージョンです。理想的には、我々は選択的確認応答（SACK）TCPに基づいてスループット方程式を好むだろうが、誰もまだSACK TCPのスループット方程式を導出していないと、シミュレーションと実験は、二つの式の違いは比較的マイナー[FF99]であることを示唆しています（付録B）。
The throughput equation for X_Bps, TCP's average sending rate in bytes per second, is:
X_Bps、秒あたりのバイト数でのTCPの平均送信速度のスループット方程式は、次のとおりです。
s
X_Bps = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))
Where:
どこ：
X_Bps is TCP's average transmit rate in bytes per second. (X_Bps is the same as X_calc in RFC 3448.)
X_Bps 1秒あたりのバイト数TCPの平均送信レートです。 （X_BpsはRFC 3448.にX_calcと同じです）
s is the segment size in bytes (excluding IP and transport protocol headers).
Sは（IPとトランスポートプロトコルヘッダを除く）バイト単位のセグメントサイズです。
R is the round-trip time in seconds.
Rは、秒単位の往復時間です。
p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
pが送信されたパケットの数の分数として損失事象の数の0と1.0との間の損失イベント率、です。
t_RTO is the TCP retransmission timeout value in seconds.
t_RTOは、秒単位でTCPの再送タイムアウト値です。
b is the maximum number of packets acknowledged by a single TCP acknowledgement.
Bは、単一のTCP受信確認によって確認されたパケットの最大数です。
Setting the TCP retransmission timeout value t_RTO: Implementations SHOULD set t_RTO = 4*R. Implementations MAY choose to implement a more accurate calculation of t_RTO. Implementations MAY also set t_RTO to max(4*R, one second), to match the recommended minimum of one second on the RTO [RFC2988].
TCP再送タイムアウト値のt_RTOの設定：実装はt_RTO = 4 *のRを設定する必要があります。実装はt_RTOのより正確な計算を実装することを選択できます。実装はまた、RTO [RFC2988]に一つの第二の推奨最小値に一致するように、MAX（4 *のR 1秒）にt_RTOを設定してもよいです。
Setting the parameter b for delayed acknowledgements: Some current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received. However, TCP is also allowed to send an acknowledgement for every data packet. For the revised TCP congestion control mechanisms, [RFC2581bis] currently specifies that the delayed acknowledgement algorithm should be used with TCP. However, [RFC2581bis] recommends increasing the congestion window during congestion avoidance by one segment per RTT even in the face of delayed acknowledgements, consistent with a TCP throughput equation with b = 1. On an experimental basis, [RFC2581bis] allows for increases of the congestion window during slow-start that are also consistent with a TCP throughput equation with b = 1. Thus, the use of b = 1 is consistent with [RFC2581bis]. The use of b = 1 is RECOMMENDED.
遅延確認応答のためのパラメータbの設定：一部の現在のTCP接続が遅延確認応答を使用し、すべての2つのデータパケットに対する肯定応答を送信すると、受信しました。しかし、TCPはまた、すべてのデータパケットに対する肯定応答を送信することが許可されています。改訂されたTCPの輻輳制御メカニズムについては、[RFC2581bis]現在、遅延確認応答アルゴリズムはTCPで使用することを指定します。しかし、[RFC2581bis] [RFC2581bis]の増加を可能にする、実験的にB = 1とTCPスループット方程式と一致し、さらに遅延確認応答の面でRTTごとにセグメントによって輻輳回避中に輻輳ウィンドウを増加させることをお勧めしますまた、このようにB = 1とTCPスループット方程式と一致しているスロースタート時の輻輳ウィンドウは、B = 1の使用は、[RFC2581bis]と一致しています。 B = 1の使用が推奨されます。
With t_RTO=4*R and b=1, the throughput equation for X_Bps, the TCP sending rate in bytes per second, can be simplified as:
t_RTO = 4 * R及びB = 1、X_Bpsのスループットの式で、秒あたりのバイト数で速度を送信するTCPは、のように簡略化することができます。
s
X_Bps = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
In the future, updates to this document could specify different TCP equations to 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 throughput equation can also be expressed in terms of X_pps, the sending rate in packets per second, with
スループット方程式はまたと共に、X_pps、秒あたりのパケットにおける送信速度の観点で表すことができます。
X_pps = X_Bps / s .
X_pps = X_Bps /秒。
The parameters s (segment size), p (loss event rate), and R (RTT) need to be measured or calculated by a TFRC implementation. The measurement of s is specified in Section 4.1, the measurement of R is specified in Section 4.3, and the measurement of p is specified in Section 5. In the rest of this document, data rates are measured in bytes per second unless otherwise specified.
パラメータs（セグメントサイズ）、P（損失イベント率）、およびR（RTT）は、TFRC実装によって測定または計算する必要があります。特に明記しない限り複数の測定は、セクション4.1で指定され、Rの測定は、セクション4.3で指定され、そしてpの測定は、この文書の残りの部分ではセクション5で指定され、データレートは、秒あたりのバイト数で測定されます。
Before specifying the sender and receiver functionality, we describe the contents of the data packets sent by the sender and feedback packets sent by the receiver. As TFRC will be used along with a transport protocol, we do not specify packet formats, as these depend on the details of the transport protocol used.
送信者と受信者機能を指定する前に、我々は、受信機によって送信され、送信者とフィードバックパケットが送信されたデータパケットの内容を説明します。 TFRCは、トランスポートプロトコルと一緒に使用されるように、我々はこれらが使用されるトランスポートプロトコルの詳細に依存として、パケットフォーマットを指定しないでください。
Each data packet sent by the data sender contains the following information:
データ送信者によって送られた各データパケットは、次の情報が含まれます。
o A sequence number. This number MUST be 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.
シーケンス番号O。この数は、送信される各データパケットに対して1つずつインクリメントされなければなりません。フィールドには、それは同時に受信機の最近のパケット履歴にあるように、同じシーケンス番号を持つ2つの異なるパケットを引き起こしてラップしていないことを十分に大きくなければなりません。
o A timestamp indicating when the packet is sent. We denote by ts_i the timestamp of the packet with sequence number i. The resolution of the timestamp SHOULD typically be measured in milliseconds.
パケットが送信されたときを示すタイムスタンプO。私たちは、シーケンス番号iのパケットのタイムスタンプts_iによって表します。タイムスタンプの分解能は、通常、ミリ秒単位で測定されるべきです。
This timestamp is used by the receiver to determine which losses
belong to the same loss event. The timestamp is also echoed by
the receiver to enable the sender to estimate the round-trip
time, for senders that do not save timestamps of transmitted data
packets.
We note that, as an alternative to a timestamp incremented in milliseconds, a "timestamp" that increments every quarter of a round-trip time MAY be used for determining when losses belong to the same loss event, in the context of a protocol where this is understood by both sender and receiver and where the sender saves the timestamps of transmitted data packets.
私たちは、ミリ秒単位でカウントアップタイムスタンプの代替として、ラウンドトリップ時間の四半期ごとにインクリメント「タイムスタンプ」は、このプロトコルの文脈で、損失が同じ損失イベントに属している場合を決定するために使用される可能性があることに注意してください送信者が送信したデータパケットのタイムスタンプを保存し送信側と受信側との両方によって理解されています。
o The sender's current estimate of the round-trip time. The estimate reported in packet i is denoted by R_i. The round-trip time estimate is used by the receiver, along with the timestamp, to determine when multiple losses belong to the same loss event. The round-trip time estimate is also used by the receiver to determine the interval to use for calculating the receive rate and to determine when to send feedback packets.
ラウンドトリップ時間の送信者の現在の推定値O。パケットIで報告推定値はR_iとで表されます。往復時間推定は、複数の損失が同じ損失イベントに属するかを決定するために、タイムスタンプと共に、受信機によって使用されます。ラウンドトリップ時間推定値も受信速度を計算するために使用し、フィードバックパケットを送信するタイミングを決定するための間隔を決定するために受信機によって使用されます。
If the sender sends a coarse-grained "timestamp" that increments
every quarter of a round-trip time, as discussed above, then the
sender is not required to send its current estimate of the round
trip time.
Each feedback packet sent by the data receiver contains the following information:
データ受信機によって送信される各フィードバックパケットは、以下の情報が含まれています。
o The timestamp of the last data packet received. We denote this by t_recvdata. If the last packet received at the receiver has sequence number i, then t_recvdata = ts_i. This timestamp is used by the sender to estimate the round-trip time, and is only needed if the sender does not save the timestamps of transmitted data packets.
O最後のデータパケットのタイムスタンプを受信しました。私たちは、t_recvdataすることによってこれを表します。受信機で受信された最後のパケットは、シーケンス番号i、その後t_recvdata = ts_iを持っている場合。このタイムスタンプは、往復時間を推定するために送信者によって使用され、送信者が送信されたデータパケットのタイムスタンプを保存していない場合にのみ必要です。
o The amount of time elapsed between the receipt of the last data packet at the receiver and the generation of this feedback report. We denote this by t_delay.
O時間の量は、受信機における最後のデータパケットを受信し、このフィードバックレポートの生成との間の経過しました。私たちは、t_delayすることによってこれを表します。
o The rate at which the receiver estimates that data was received in the previous round-trip time. We denote this by X_recv.
O速度は、受信機は、データが前のラウンドトリップ時間内に受信されたと推定しています。私たちは、X_recvすることによってこれを表します。
o The receiver's current estimate of the loss event rate p.
損失イベント率pの受信機の現在の推定値O。
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate based on the information contained in the feedback report. If the sender does not receive a feedback report for four round-trip times, then the sender cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
データ送信側は、制御された速度でデータ受信機へのデータパケットのストリームを送信します。フィードバックパケットがデータ受信機から受信した場合、データ送信側はフィードバックレポートに含まれる情報に基づいて、その送信レートを変更します。送信者が4往復時間のためにフィードバックレポートを受信しない場合、送信者は半分にその送信レートをカット。これはNOFEEDBACKタイマーと呼ばれるタイマーによって達成されます。
We specify the sender-side protocol in the following steps:
私たちは、次の手順では、送信者側のプロトコルを指定します。
o Measurement of the mean segment size being sent.
O、平均セグメントサイズの測定は、送信されます。
o Sender initialization.
oは初期設定を送信します。
o The sender behavior when a feedback packet is received.
フィードバックパケットを受信すると、送信者の振る舞いO。
o The sender behavior when the nofeedback timer expires.
NOFEEDBACKタイマーが満了したときに、送信者の振る舞いO。
o Oscillation prevention (optional).
O発振防止（オプション）。
o Scheduling of packet transmission and allowed burstiness.
パケットの送信と許可バースト性のOスケジューリング。
The TFRC sender uses the segment size, s, in the throughput equation, in the setting of the maximum receive rate, the setting of the minimum and initial sending rates, and the setting of the nofeedback timer. The TFRC receiver MAY use the average segment size, s, in initializing the loss history after the first loss event. As specified in Section 6.3.1, if the TFRC receiver does not know the segment size, s, used by the sender, the TFRC receiver MAY instead use the arrival rate in packets per second in initializing the loss history.
TFRCの送信者は最大の設定で速度、最小の設定を受信し、送信レートを初期、及びNOFEEDBACKタイマーの設定、スループット式で、sは、セグメントサイズを使用します。 TFRC受信機は、最初の損失イベントの後ロスの履歴を初期化における平均セグメントサイズ、Sを使用することができます。 TFRC受信機が送信者によって使用されるセグメントサイズ、Sを知らない場合、セクション6.3.1で指定されているように、TFRCの受信機ではなく、損失履歴を初期化で秒あたりのパケット到着レートを使用するかもしれません。
The segment size is normally known to an application. This may not be so in two cases:
セグメントサイズは、通常、アプリケーションには知られています。これは、2つの場合にそうではないかもしれません。
1) The segment size naturally varies depending on the data. In this case, although the segment size varies, that variation is not coupled to the transmit rate. The TFRC sender can either compute the average segment size or use the maximum segment size for the segment size, s.
1）セグメントサイズは、当然データに応じて変化します。セグメントのサイズは変化するが、この場合、その変化は、送信レートに結合されていません。 TFRCの送信者は、平均セグメントサイズを計算するか、セグメントサイズ、Sの最大セグメントサイズを使用しますか。
2) The application needs to change the segment size rather than the number of segments 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 completely different way of measuring parameters.
2）アプリケーションは、輻輳制御を実行するためのセグメントサイズではなく、秒あたりのセグメント数を変更する必要があります。これは、通常、時間の一定間隔は、各パケットによって表される必要があるパケット音声アプリケーションの場合であろう。このようなアプリケーションでは、パラメータを測定する全く異なる方法を持っている必要があります。
For the first class of applications where the segment size varies depending on the data, the sender SHOULD estimate the segment size, s, as the average segment size over the last four loss intervals. The sender MAY estimate the average segment size over longer time intervals, if so desired.
セグメントのサイズは、データに依存して変化するアプリケーションの最初のクラスに対して、送信者は、最後の4回の損失間隔にわたって平均セグメントサイズとセグメントサイズ、Sを推定すべきです。所望であれば、送信者は、より長い時間間隔にわたって平均セグメントサイズを推定してもよいです。
The second class of applications are discussed separately in a separate document on TFRC-SP [RFC4828]. For the remainder of this section we assume the sender can estimate the segment size and that congestion control is performed by adjusting the number of packets sent per second.
アプリケーションの第二のクラスは、TFRC-SP [RFC4828]に別の文書に別々に議論されています。このセクションの残りの部分のために、我々は、送信側がセグメント・サイズを推定することができると仮定し、その輻輳制御は、毎秒送信されるパケットの数を調整することによって行われます。
The initial values for X (the allowed sending rate in bytes per second) and tld (the Time Last Doubled during slow-start, in seconds) are undefined until they are set as described below. If the sender is ready to send data when it does not yet have a round-trip sample, the value of X is set to s bytes per second, for segment size s, the nofeedback timer is set to expire after two seconds, and tld is set to 0 (or to -1, either one is okay). Upon receiving the first round-trip time measurement (e.g., after the first feedback packet or the SYN exchange from the connection setup, or from a previous connection [RFC2140]), tld is set to the current time, and the allowed transmit rate, X, is set to the initial_rate, specified as W_init/R, for W_init based on [RFC3390]:
後述のようにそれらが設定されるまでX（秒あたりのバイト数で許さ送信率）とTLDの初期値は、（時間最後の数秒で、スロースタート時に倍増）定義されていません。それはまだ往復のサンプルを持っていない場合、送信側がデータを送信する準備ができている場合は、Xの値がSバイトごとに設定された第2、セグメントサイズsのために、NOFEEDBACKタイマーを2秒後に期限切れになるように設定され、TLDされます0に設定する（または-1に、どちらか一方は大丈夫です）されます。 （例えば、第1のフィードバックパケット又は接続設定から、または以前の接続のSYN交換後に[RFC2140]）、TLDは、現在の時刻に設定し、許容送信レートされた最初のラウンドトリップ時間測定を受信すると、 Xは、[RFC3390]に基づいて、initial_rateに設定W_initためW_init / Rとして指定されています。
initial_rate = W_init/R; W_init = min(4*MSS, max(2*MSS, 4380)).
initial_rate = W_init / R。 W_init =分（4 * MSS、MAX（2 * MSS、4380））。
In computing W_init, instead of using Maximum Segment Size (MSS), the TFRC sender SHOULD use the maximum segment size to be used for the initial round-trip time of data, if that is known by the TFRC sender when X is initialized.
Xが初期化されるときには、TFRC送信者によって知られている場合W_initを計算する、代わりの最大セグメントサイズ（MSS）を使用して、最大セグメントサイズを使用すべきであるTFRCの送信者は、データの最初の往復時に使用されます。
For responding to the initial feedback packet, this replaces step (4) of Section 4.3 below.
初期のフィードバックパケットに対応するため、これは以下のセクション4.3のステップ（4）に置き換えられます。
Appendix B explains why the initial value of TFRC's nofeedback timer is set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer from [RFC2988].
TFRCのNOFEEDBACKタイマーの初期値は2秒に設定されている理由は、付録Bの代わりに[RFC2988]からTCPの再送信タイマーのために3秒の推奨初期値で、説明しています。
The sender knows its current allowed sending rate, X, and maintains an estimate of the current round-trip time R. The sender also maintains X_recv_set as a small set of recent X_recv values (typically only two values).
送信者は、その許容電流送信率、Xを知っており、送信者はまた、最近のX_recv値（通常は2つだけの値）の小さなセットとしてX_recv_setを維持し、現在のラウンドトリップ時間Rの推定値を維持しています。
Initialization: X_recv_set is first initialized to contain a single item, with value Infinity. (As an implementation-specific issue, X_recv_set MAY be initialized to a large number instead of to Infinity, e.g., to the largest integer that is easily representable.)
初期化：X_recv_setが第1の値インフィニティで、単一の項目を含むように初期化されます。 （実装に固有の問題として、X_recv_setを容易に表現可能である最大の整数に、例えば、多数に代えて無限大に初期化されてもよいです。）
When a feedback packet is received by the sender at time t_now, the current time in seconds, the following actions MUST be performed.
フィードバックパケットが時間t_nowで、送信者が受信すると、秒単位で現在の時刻は、次のアクションを実行しなければなりません。
1) Calculate a new round-trip sample:
1）新往復サンプルを計算します。
R_sample = (t_now - t_recvdata) - t_delay.
R_sampleは=（t_now - t_recvdata） - t_delay。
As described in Section 3.2.2, t_delay gives the elapsed time at the receiver.
セクション3.2.2で説明したように、t_delayは、受信機での経過時間を与えます。
2) Update the round-trip time estimate:
2）ラウンドトリップ時間の推定値を更新します。
If no feedback has been received before {
R = R_sample;
} Else {
R = q*R + (1-q)*R_sample;
}
TFRC is not sensitive to the precise value for the filter constant q, but a default value of 0.9 is RECOMMENDED.
TFRCはフィルタ定数qの正確な値に対して敏感ではなく、0.9のデフォルト値が推奨されます。
3) Update the timeout interval:
3）タイムアウト間隔を更新します。
RTO = max(4*R, 2*s/X)
RTO = MAX（4 * R、2 * S / X）
4) Update the allowed sending rate as follows. This procedure uses the variables t_mbi and recv_limit:
次のように4）許容送信率を更新します。この手順は、t_mbiとrecv_limit変数を使用します。
t_mbi: the maximum backoff interval of 64 seconds. recv_limit: the limit on the sending rate computed from X_recv_set.
t_mbi：64秒の最大バックオフ間隔。 recv_limit：X_recv_setから計算された送信レートの制限。
This procedure also uses the procedures Maximize X_recv_set() and Update X_recv_set(), which are defined below.
この手順はまた、以下に定義されている手順最大化X_recv_set（）と更新X_recv_set（）を使用します。
The procedure for updating the allowed sending rate:
許可される送信レートを更新するための手順：
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
} Else { // typical behavior
Update X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
If (p > 0) { // congestion avoidance phase
Calculate X_Bps using the TCP throughput equation.
X = max(min(X_Bps, recv_limit), s/t_mbi);
} Else if (t_now - tld >= R) {
// initial slow-start
X = max(min(2*X, recv_limit), initial_rate);
tld = t_now;
}
5) If oscillation reduction is used, calculate the instantaneous transmit rate, X_inst, following Section 4.5.
振動低減が使用される場合5）、セクション4.5以下の瞬間送信速度、X_instを計算します。
6) Reset the nofeedback timer to expire after RTO seconds.
6）RTO秒後に期限切れになるようにNOFEEDBACKタイマーをリセットします。
The procedure for maximizing X_recv_set keeps a single value, the largest value from X_recv_set and the new X_recv.
X_recv_setを最大化するための手順は、単一の値、X_recv_setと新しいX_recvから最大値を保持します。
Maximize X_recv_set():
Add X_recv to X_recv_set;
Delete initial value Infinity from X_recv_set,
if it is still a member.
Set the timestamp of the largest item to the current time;
Delete all other items.
The procedure for updating X_recv_set keeps a set of X_recv values with timestamps from the two most recent round-trip times.
X_recv_setを更新する手順は、最近の2つの往復時間からのタイムスタンプを持つX_recv値のセットを保持します。
Update X_recv_set(): Add X_recv to X_recv_set; Delete from X_recv_set values older than two round-trip times.
更新X_recv_set（）：X_recv_setにX_recvを追加します。 2往復時間よりも古いX_recv_set値から削除します。
Definition of a data-limited interval: We define a sender as data-limited any time it is not sending as much as it is allowed to send. We define an interval as a 'data-limited interval' if the sender was data-limited over the *entire* interval; Section 8.2.1 discusses implementation issues for a sender in determining if an interval was a data-limited interval. The term 'data-limited interval' is used in the first "if" condition in step (4), which prevents a sender from having to reduce its sending rate as a result of a feedback packet reporting the receive rate from a data-limited period.
私たちは、データが制限されたとして、送信することが許可されると多くを送信していない任意の時間に送信者を定義します。データが制限された時間間隔の定義。送信者は、*全体*間隔でデータが制限された場合、当社は、「データが制限された区間」として間隔を定義します。 8.2.1項では間隔は、データが制限された時間間隔だったかどうかを判断する際に、送信者のための実装上の問題について説明します。用語「データ限定間隔は」データ制限から受信率を報告するフィードバックパケットの結果として、その送信レートを低減することから、送信者を阻止するステップで最初の「IF」条件（4）で使用され期間。
As an example, consider a sender that is sending at its full allowed rate, except that it is sending packets in pairs, rather than sending each packet as soon as it can. Such a sender is considered data-limited part of the time, because it is not always sending packets as soon as it can. However, consider an interval that covers this sender's transmission of at least two data packets; such an interval does not meet the definition of a data-limited interval because the sender was not data-limited *over the entire interval*.
例として、それはペアでパケットを送信するのではなく、できるだけ早くそれができるように、各パケットを送信していることを除いて、その完全な許容レートで送信された送信者を検討してください。それはいつものようにすぐにそれができるようにパケットを送信していないため、このような送信者は、時間のデータが制限された一部とみなされます。しかし、少なくとも2つのデータパケットのこの送信者の送信をカバー間隔を検討します。送信者が*全区間にわたり*データが制限されなかったため、このような間隔は、データが制限された時間間隔の定義を満たしていません。
If the feedback packet reports a receive rate X_recv of zero (i.e., the first feedback packet), the sender does not consider that the entire interval covered by the feedback packet was a data-limited interval.
フィードバックパケット受信率ゼロ（すなわち、第1のフィードバックパケット）のX_recvを報告した場合、送信者はフィードバックパケットでカバー全体の間隔は、データが制限された期間であったことを考慮していません。
X_recv_set and the first feedback packet: Because X_recv_set is initialized with a single item, with value Infinity, recv_limit is set to Infinity for the first two round-trip times of the connection. As a result, the sending rate is not limited by the receive rate during that period. This avoids the problem of the sending rate being limited by the value of X_recv from the first feedback packet.
X_recv_setと第1のフィードバックパケット：X_recv_setが値インフィニティで、単一のアイテムで初期化されているので、recv_limitは、接続の最初の2往復時間のために無限大に設定されています。結果として、送信速度は、その期間中に受ける速度に限定されるものではありません。これは、第1のフィードバックパケットからX_recvの値によって制限される送信レートの問題を回避します。
The interval covered by a feedback packet: How does the sender determine the period covered by a feedback packet? This is discussed in more detail in Section 8.2. In general, the receiver will be sending a feedback packet once per round-trip time; so typically, the sender will be able to determine exactly the period covered by the current feedback packet from the previous feedback packet. However, in cases when the previous feedback packet was lost, or when the receiver sends a feedback packet early because it detected a lost or ECN-marked packet, the sender will have to estimate the interval covered by the feedback packet. As specified in Section 6.2, each feedback packet sent by the receiver covers a round-trip time, for the round-trip time estimate R_m maintained by the receiver R_m seconds before the feedback packet was sent.
フィードバックパケットでカバー間隔：どのように送信者がフィードバックパケットの対象期間を決定するのですか？これは、8.2節で詳しく説明されています。一般に、受信機は、ラウンドトリップ時間ごとに一度フィードバックパケットを送信します。そう一般的に、送信者は、正確に、以前のフィードバックパケットから現在のフィードバックパケットの対象期間を決定することができるであろう。しかし、場合によっては、以前のフィードバックパケットが失われたとき、またはそれが紛失またはECN-マークされたパケットを検出したため、受信機は、早期フィードバックパケットを送信すると、送信側はフィードバックパケットでカバー間隔を推定する必要があります。 6.2節で規定されているように、受信機によって送信される各フィードバックパケットは、フィードバックパケットが送信される前に受信R_M秒で維持され、ラウンドトリップ時間推定R_Mため、ラウンドトリップ時間をカバーしています。
The response to a loss during a data-limited interval: In TFRC, after the initial slow-start, the sender always updates the calculated transmit rate, X_Bps, after a feedback packet is received, and the allowed sending rate, X, is always limited by X_Bps. However, during a data-limited interval, when the actual sending rate is usually below X_Bps, the sending rate is still limited by recv_limit, derived from X_recv_set. If the sender is data-limited, possibly with a varying sending rate from one round-trip time to the next, and is experiencing losses, then we decrease the entry in X_recv_set in order to reduce the allowed sending rate.
TFRCでは、初期スロースタートした後、送信者は常に、算出した送信レートを更新X_Bps、フィードバックパケットが受信された後、および許容送信レート、Xは、常に：データ制限期間中の損失に応答X_Bpsによって制限されています。しかし、実際の送信レートが通常X_Bps未満であるデータ限定間隔の間、送信レートは、依然として、recv_limitによって制限されるX_recv_setに由来します。送信者は、おそらく1ラウンドトリップ時間から次へ変化送信レートと、データが制限されており、損失が発生している場合は、我々は許可され、送信速度を低下させるためにX_recv_setのエントリを減らします。
The sender can detect a loss event during a data-limited period either from explicit feedback from the receiver, or from a reported increase in the loss event rate. When the sender receives a feedback packet reporting such a loss event in a data-limited interval, the sender limits the allowed increases in the sending rate during the data-limited interval.
送信側は受信側からの明示的なフィードバックから、または損失イベント率の報告の増加のいずれかからデータが制限された期間中に損失事象を検出することができます。送信者がデータ限られた間隔でそのような損失事象を報告し、フィードバックパケットを受信すると、送信側はデータ制限間隔の間送信レートに許容増加を制限します。
The initial slow-start phase: Note that when p=0, the sender has not yet learned of any loss events, and the sender is in the initial slow-start phase. In this initial slow-start phase, the sender can approximately double the sending rate each round-trip time until a loss occurs. The initial_rate term in step (4) gives a minimum allowed sending rate during slow-start of the initial allowed sending rate.
初期スロースタートフェーズ：p = 0で、送信者はまだ損失事象を知った、としていない場合、送信者は、最初のスロースタートフェーズであることに注意してください。この最初のスロースタートフェーズでは、送信者は約2倍、送信速度各往復時間をすることができます損失が発生するまで。ステップ（4）におけるinitial_rate用語は、最小の初期のスロースタート時の送信レートがレートの送信許可許可与えます。
We note that if the sender is data-limited during slow-start, or if the connection is limited by the path bandwidth, then the sender is not necessarily able to double its sending rate each round-trip time; the sender's sending rate is limited to at most twice the past receive rate, or at most initial_rate, whichever is larger. This is similar to TCP's behavior, where the sending rate is limited by the rate of incoming acknowledgement packets as well as by the congestion window. Thus, in TCP's slow-start, for the most aggressive case of the TCP receiver acknowledging every data packet, the TCP sender's sending rate is limited to at most twice the rate of these incoming acknowledgment packets.
私たちは、送信者が、データが制限されたスロースタートの間であれば接続は、パスの帯域幅によって制限されている場合、または、送信者は必ずしもその送信レートそれぞれの往復時間を倍増することができないことに注意してください。送信者の送信速度は、せいぜい二回過去に制限されている割合、またはどちらか大きい方で最もinitial_rate、でを受けます。これは、送信速度が、着信確認応答パケットのレートによってだけでなく、輻輳ウィンドウによって制限されているTCPの動作に似ています。このように、TCPのスロースタートでは、すべてのデータパケットを認めるTCP受信機の最も積極的な場合のために、TCP送信者の送信レートは、これらの着信確認応答パケットの最大2倍の速度に制限されています。
The minimum allowed sending rate: The term s/t_mbi ensures that when p > 0, the sender is allowed to send at least one packet every 64 seconds.
最小値は、送信速度を許可：項S / t_mbiは確実P> 0、送信者が少なくとも1つのパケットごとに64秒を送信することが許可されている場合。
This section specifies the sender's response to a nofeedback timer. The nofeedback timer could expire because of an idle period or because of data or feedback packets dropped in the network.
このセクションでは、NOFEEDBACKタイマへの送信者の応答を指定します。 NOFEEDBACKタイマーがあるため、休止期間のため、またはデータまたはフィードバックパケットの有効期限が切れる可能性がネットワークに低下しました。
This section uses the variable recover_rate. If the TFRC sender has been idle ever since the nofeedback timer was set, the allowed sending rate is not reduced below the recover_rate. For this document, the recover_rate is set to the initial_rate (specified in Section 4.2). Future updates to this specification may explore other possible values for the recover_rate.
このセクションでは、変数recover_rateを使用しています。 TFRCの送信者がNOFEEDBACKタイマーが設定されて以来、アイドル状態になっている場合は、許可される送信レートはrecover_rate以下に低減されていません。この文書のために、recover_rateは（セクション4.2で指定された）initial_rateに設定されています。この仕様の今後の更新はrecover_rateのための他の可能な値を探ることがあります。
If the nofeedback timer expires, the sender MUST perform the following actions:
NOFEEDBACKタイマーが満了した場合、送信者は、次のアクションを実行する必要があります。
1) Cut the allowed sending rate in half.
1）の半分で許可され、送信レートをカットします。
If the nofeedback timer expires when the sender has had at least one RTT measurement, the allowed sending rate is reduced by modifying X_recv_set as described in the pseudocode below (including item (2)). In the general case, the sending rate is limited to at most twice X_recv. Modifying X_recv_set limits the sending rate, but still allows the sender to slow-start, doubling its sending rate each RTT, if feedback messages resume reporting no losses.
送信者が少なくとも一つのRTT測定値を持っている場合NOFEEDBACKタイマーが満了した場合、許容送信レートは、以下の擬似コードに記載されているようにX_recv_setを変更することによって低減される（アイテムを含む（2））。一般的なケースでは、送信レートは、せいぜい二回X_recvに限定されています。変更X_recv_setは、送信レートを制限し、それでも送信側はスロースタートをするために、フィードバック・メッセージは何の損失を報告しなかっ再開する場合は、その送信レート各RTTを倍増できます。
If the sender has been idle since this nofeedback timer was set and X_recv is less than the recover_rate, then the allowed sending rate is not halved, and X_recv_set is not changed. This ensures that the allowed sending rate is not reduced to less than half the recover_rate as a result of an idle period.
このNOFEEDBACKタイマーが設定されているので、送信者がアイドル状態になっているとX_recvがrecover_rate未満の場合、許さ送信レートが半分ではなく、X_recv_setは変更されません。これは許可され、送信速度がアイドル期間の結果として半分以下recover_rateに縮小されていないことを保証します。
In the general case, the allowed sending rate is halved in response to the expiration of the nofeedback timer. The details, in the pseudocode below, depend on whether the sender is in slow-start, is in congestion avoidance limited by X_recv, or is in congestion avoidance limited by the throughput equation.
一般的なケースでは、許可される送信レートはNOFEEDBACKタイマーの満了に応じて半減されます。詳細は、以下の擬似コードでは、送信側はスロースタートであるか否かに依存して、X_recvによって制限輻輳回避であるか、またはスループット方程式によって制限輻輳回避です。
X_recv = max (X_recv_set);
If (sender does not have an RTT sample,
has not received any feedback from receiver,
and has not been idle ever since the nofeedback timer
was set) {
// We do not have X_Bps or recover_rate yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (((p>0 && X_recv < recover_rate) or
(p==0 && X < 2 * recover_rate)), and
sender has been idle ever
since nofeedback timer was set) {
// Don't halve the allowed sending rate.
Do nothing;
} Else if (p==0) {
// We do not have X_Bps yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (X_Bps > 2*X_recv)) {
// 2*X_recv was already limiting the sending rate.
// Halve the allowed sending rate.
Update_Limits(X_recv;)
} Else {
// The sending rate was limited by X_Bps, not by X_recv.
// Halve the allowed sending rate.
Update_Limits(X_Bps/2);
}
The term s/t_mbi limits the backoff to one packet every 64 seconds.
用語S / t_mbiは1つのパケットごとに64秒にバックオフを制限します。
The procedure Update_Limits() uses the variable timer_limit for the limit on the sending rate computed from the expiration of the nofeedback timer, as follows:
手順Update_Limits（）次のように、NOFEEDBACKタイマーの満了から計算送信速度に制限するための可変timer_limitを使用しています。
Update_Limits(timer_limit):
If (timer_limit < s/t_mbi)
timer_limit = s/t_mbi;
Replace X_recv_set contents with the single item
timer_limit/2;
Recalculate X as in step (4) of Section 4.3;
2) Restart the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
2）（最大後4 * R、2 * S / X）秒を期限切れにするNOFEEDBACKタイマーを再起動します。
If the sender has been data-limited but not idle since the nofeedback timer was set, it is possible that the nofeedback timer expired because data or feedback packets were dropped in the network. In this case, the nofeedback timer is the backup mechanism for the sender to detect these losses, similar to the retransmit timer in TCP.
送信者は、データ限定されるものではないNOFEEDBACKタイマーが設定されて以来、アイドル状態になっている場合、データまたはフィードバックパケットがネットワークで落とされたのでNOFEEDBACKタイマーが期限切れになっている可能性があります。この場合、NOFEEDBACKタイマーは、TCPでの再送信タイマーに似たこれらの損失を検出するために、送信者のためのバックアップメカニズムです。
Note that when the sender stops sending data for a period of time, the receiver will stop sending feedback. When the sender's nofeedback timer expires, the sender could use the procedure above to limit the sending rate. If the sender subsequently starts to send again, X_recv_set will be used to limit the transmit rate, and slow-start behavior will occur until the transmit rate reaches X_Bps.
送信者が一定期間データの送信を停止した場合、受信機は、フィードバックの送信を停止することに注意してください。送信者のNOFEEDBACKタイマーが満了すると、送信者は送信レートを制限するために、上記の手順を使用することができます。送信者がその後に再び送信を開始した場合、X_recv_setは、送信レートを制限するために使用され、送信レートがX_Bpsに達するまでのスロースタート動作が発生します。
The TFRC sender's reduction of the allowed sending rate after the nofeedback timer expires is similar to TCP's reduction of the congestion window, cwnd, after each RTO seconds of an idle period, for TCP with Congestion Window Validation [RFC2861].
NOFEEDBACKタイマーが満了した後に許可される送信レートのTFRCの送信者の減少が輻輳ウィンドウ検証[RFC2861]でTCPのために、アイドル期間の各RTO秒後に、輻輳ウィンドウ、CWNDのTCPの削減に似ています。
To reduce oscillations in queueing delay and sending rate in environments with a low degree of statistical multiplexing at the congested link, it is RECOMMENDED that the sender reduce the transmit rate as the queueing delay (and hence RTT) increases. To do this, the sender maintains R_sqmean, a long-term estimate of the square root of the RTT, and modifies its sending rate depending on how the square root of R_sample, the most recent sample of the RTT, differs from the long-term estimate. The long-term estimate R_sqmean is set as follows:
遅延キューイングと輻輳リンクにおける統計的多重度の低い環境で速度を送信する際に振動を低減するためには、送信者がキューイング遅延（ひいてはRTT）が増加するように送信速度を低下させることが推奨されます。これを行うには、送信者がR_sqmean、RTTの平方根の長期的な推定値を維持し、R_sampleの平方根、RTTの最新のサンプルは、長期とどのように異なるかに応じて、その送信レートを変更します見積もり。次のように長期的な見積もりR_sqmeanが設定されます。
If no feedback has been received before {
R_sqmean = sqrt(R_sample);
} Else {
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
}
Thus, R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, the constant used in the round-trip time estimate R. A value of 0.9 as the default for q2 is RECOMMENDED.
したがって、R_sqmeanはRTTサンプルの平方根の指数加重移動平均を与えます。定数Q2は、Qと同様にQ2のデフォルトとして0.9の値が推奨されるラウンドトリップ時間推定R.で使用される定数設定されるべきです。
When sqrt(R_sample) is greater than R_sqmean, then the current round-trip time is greater than the long-term average, implying that queueing delay is probably increasing. In this case, the transmit rate is decreased to minimize oscillations in queueing delay.
SQRT（R_sample）がR_sqmeanよりも大きい場合、現在の往復時間は、キューイング遅延はおそらく増加していることを示唆し、長期的な平均よりも大きくなります。この場合、送信速度が遅延キューイングの振動を最小限にするために減少されます。
The sender obtains the base allowed transmit rate, X, as described in step (4) of Section 4.3 above. It then calculates a modified instantaneous transmit rate X_inst, as follows:
送信者は、上記セクション4.3のステップ（4）に記載のようにベース許容送信レート、Xを取得します。次のようには、次に、修飾瞬間送信速度X_instを計算します：
X_inst = X * R_sqmean / sqrt(R_sample);
If (X_inst < s/t_mbi)
X_inst = s/t_mbi;
Because we are using square roots, there is generally only a moderate difference between the instantaneous transmit rate X_inst and the allowed transmit rate X. For example, in a somewhat extreme case when the current RTT sample R_sample is twice as large as the long-term average, then sqrt(R_sample) will be roughly 1.44 times R_sqmean, and the allowed transmit rate will be reduced by a factor of roughly 0.7.
我々は平方根を使用しているため、瞬間送信速度X_inst及び例えば許容送信率Xの間の唯一の中等度の違いは、現在のRTTサンプルR_sample長期の2倍であり、多少極端な場合には、一般的に存在します平均、次いでSQRT（R_sample）はR_sqmeanおおよそ1.44倍となり、許容送信レートは、おおよそ0.7倍に減少します。
We note that this modification for reducing oscillatory behavior is not always needed, especially if the degree of statistical multiplexing in the network is high. We also note that the modification for reducing oscillatory behavior could cause problems for connections where the round-trip time is not strongly correlated with the queueing delay (e.g., in some wireless links, over paths with frequent routing changes, etc.). However, this modification SHOULD be implemented because it makes TFRC behave better in some environments with a low level of statistical multiplexing. The performance of this modification is illustrated in Section 3.1.3 of [FHPW00]. If it is not implemented, implementations SHOULD use a very low value of the weight q for the average round-trip time.
私たちは、振動挙動を低減させるため、この変更は、常にネットワークにおける統計多重度が高い場合は特に、必要とされていないことに注意してください。我々はまた、振動挙動を減少させるための修正は、往復時間が強くキューイング遅延と相関していない接続のための問題を引き起こす可能性があることに注意してください（例えば、いくつかの無線リンクでは、頻繁にルーティング変更、などとパスオーバー）。それはTFRCは、統計多重の低レベルでいくつかの環境では、より良い振る舞いなりますので、この変更が実施されるべきです。本変形例の性能は、[FHPW00]のセクション3.1.3に示されています。それが実装されていない場合、実装は平均ラウンドトリップ時間の重みqの非常に低い値を使用する必要があります。
As TFRC 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. To help maintain the correct average sending rate, the TFRC sender MAY send some packets before their nominal send time.
TFRCとして率ベースで、オペレーティング・システムは、典型的には、正確にイベントをスケジュールすることができないように、正確な平均速度は、オペレーティングシステムの粗粒又は不規則なスケジュールにもかかわらず維持されるようにデータパケットを送信約日和見する必要があります。正確な平均送信レートを維持するのを助けるために、TFRCの送信者は、その公称送信時間前にいくつかのパケットを送信することができます。
In addition, the scheduling of packet transmissions controls the allowed burstiness of senders after an idle or data-limited period. The TFRC sender MAY accumulate sending 'credits' for past unused send times; this allows the TFRC sender to send a burst of data after an idle or data-limited period. To compare with TCP, TCP may send up to a round-trip time's worth of packets in a single burst, but never more. As examples, packet bursts can be sent by TCP when an ACK arrives acknowledging a window of data, or when a data-limited sender suddenly has a window of data to send after a delay of nearly a round-trip time.
また、パケット送信のスケジューリングは、アイドルやデータが制限された期間後に送信者の許可バースト性を制御します。 TFRCの送信者は、過去の未使用の送信時間のための「クレジット」を送信し蓄積することがあります。これはTFRCの送信者がアイドル状態またはデータが制限された期間後にデータのバーストを送信することができます。 TCPと比較するために、TCPは、単一のバーストでパケットの往復時間分まで送る、決してよりも。 ACKは、データのウィンドウを認め到着、またはデータが制限された送信者が突然、ほとんどのラウンドトリップ時間の遅延後に送信するデータの窓を持っているときときの例として、パケットバーストは、TCPで送信することができます。
To limit burstiness, a TFRC implementation MUST prevent bursts of arbitrary size. This limit MUST be less than or equal to one round-trip time's worth of packets. A TFRC implementation MAY limit bursts to less than a round-trip time's worth of packets. In addition, a TFRC implementation MAY use rate-based pacing to smooth bursts.
バースト性を制限するために、TFRCの実装では、任意のサイズのバーストを防止しなければなりません。この制限は、以下のパケットの1往復時間の価値と等しくなければなりません。 TFRCの実装では、パケットの往復時間分未満にバーストを制限する可能性があります。また、TFRCの実装では、バーストを滑らかにするためにレートベースペーシングを使用するかもしれません。
As an implementation-specific example, a sending loop could calculate the correct inter-packet interval, t_ipi, as follows:
次のように実装具体的な例として、送信ループは、正しいパケット間間隔、t_ipiを計算することができます。
t_ipi = s/X_inst;
t_ipi = S / X_inst。
Let t_now be the current time and i be a natural number, i = 0, 1, ..., with t_i the nominal send time for the i-th packet. Then, the nominal send time t_(i+1) would derive recursively as:
t_nowは、現在の時刻とすると、私は自然数、I = 0、1、...、i番目のパケットのためのT_I公称送信時間となります。その後、公称送信時間T_は、（i + 1）のように再帰的に導き出します。
t_0 = t_now, t_(i+1) = t_i + t_ipi.
T_0 = t_now、T_（I + 1）= T_I + t_ipi。
For TFRC senders allowed to accumulate sending credits for unused send time over the last T seconds, the sender would be allowed to use unused nominal send times t_j for t_j < now - T, for T set to the round-trip time.
最後のT秒にわたり未使用の送信時間のためにクレジットを送信し蓄積することができTFRCの送信者の場合は、送信者は今<T_Jのため、未使用の名目送信回T_Jを使用することを許可されるだろう - TのためのTは、ラウンドトリップ時間に設定してください。
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFRC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets. We describe this process before describing the rest of the receiver protocol. If the receiver has not yet detected a lost or marked packet, then the receiver does not calculate the loss event rate, but reports a loss event rate of zero.
損失イベント率の正確で安定した測定値を得ることはTFRCのための最も重要です。損失率の測定は、到着するパケットのシーケンス番号から紛失したり、マークされたパケットの検出に基づいて、受信機で実行されます。我々は、受信プロトコルの残りの部分を説明する前に、このプロセスを説明します。受信機はまだ失われたか、マークされたパケットを検出していない場合、受信機は、損失イベント率を計算しますが、ゼロの損失イベント率を報告していません。
TFRC 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, it is REQUIRED 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.
TFRCは、すべてのパケットが送信されたパケットごとに1ずつインクリメントされるシーケンス番号が含まれていることを前提としています。本明細書の目的のために、失われたパケットが再送された場合、再送が新しいシーケンスの送信順序で最新のものである数ではなく、失われたパケットと同じシーケンス番号が付与されている必要があります。トランスポートプロトコルは、それが元のシーケンス番号を再送しなければならないという要件がある場合、トランスポートプロトコルの設計者は、再送パケットより遅れとどのように失われた再送信を検出するために、区別するために方法を見つけ出す必要があります。
The receiver maintains a data structure that keeps track of which packets have arrived and which are missing. For the purposes of this specification, we assume that the data structure consists of a list of packets that have arrived along with the receiver 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 NDUPACK packets with a higher sequence number than the lost packet, for NDUPACK set to 3. The requirement for NDUPACK subsequent packets is the same as with TCP, and is to make TFRC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after NDUPACK subsequent packets arrived) in TFRC, the late packet can fill the hole in TFRC's reception record, and the receiver can recalculate the loss event rate. Future versions of TFRC might make the requirement for NDUPACK subsequent packets adaptive based on experienced packet reordering, but such a mechanism is not part of the current specification.
パケットの損失はNDUPACKが3に設定するためのNDUPACK後続のパケットのための要件は、TCPと同様であり、よりTFRCを行うことで、失われたパケットよりも高いシーケンス番号を有する少なくともNDUPACKパケットの到着によって検出されます並べ替えの存在下で堅牢。 （NDUPACK後続のパケットが到着した後に）パケットがTFRCに遅れて到着した場合、TCPとは対照的に、後半パケットはTFRCの受信記録に穴を埋めることができ、受信機は、損失イベント率を再計算することができます。 TFRCの将来のバージョンでは、経験豊富なパケットの並べ替えに基づいてNDUPACK後続のパケットの適応のための要件を作るかもしれないが、そのようなメカニズムは、現在の仕様の一部ではありません。
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対応の接続では、マークされたパケットは、後続のパケットの到着を待たずに、できるだけ早くそれが到着すると、輻輳イベントとして検出されます。
If an ECN-marked packet is preceded by a possibly-lost packet, then the first detected congestion event begins with the lost packet. For example, if the receiver receives a data packet with sequence number n-1, followed by an unmarked data packet with sequence number n+1, and a marked data packet with sequence number n+2, then the receiver detects a congestion event when it receives the marked packet n+2. The first congestion event detected begins with the lost packet n. The guidelines in Section 5.2 below are used to determine whether the lost and marked packets belong to the same loss event or to separate loss events.
ECN-マークされたパケットが、おそらく、失われたパケットが先行する場合は、最初に検出された輻輳イベントが失われたパケットから始まります。例えば、受信機は、シーケンス番号N + 1、およびシーケンス番号N + 2とマークされたデータパケットにマークされていないデータパケットに続くシーケンス番号N-1を有するデータパケットを受信した場合、受信機は、輻輳イベントの場合を検出しますそれがマークされたパケットのn + 2を受信します。検出された最初の輻輳イベントが失われたパケットnから始まります。以下のセクション5.2のガイドラインは、失われたとマークされたパケットが同じ損失イベントにまたは別々の損失事象に属しているかどうかを決定するために使用されています。
TFRC requires that the loss fraction be robust to several consecutive packets lost or marked in 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 receiver needs to map the packet loss history into a loss event record, where a loss event is one or more packets lost or marked in an RTT. To perform this mapping, the receiver needs to know the RTT to use, and this is supplied periodically by the sender, typically as control information piggy-backed onto a data packet. TFRC is not sensitive to how the RTT measurement sent to the receiver is made, but it is RECOMMENDED to use the sender's calculated RTT, R, (see Section 4.3) for this purpose.
TFRCは、損失の割合が同じ損失イベントに失われたり、マークされ、いくつかの連続したパケットに対してロバストであることが必要です。これは、任意の単一のRTTの間に、輻輳ウィンドウの半分を実行する（典型的に）TCP、同様です。このように、受信機は、損失イベントが1つまたは複数のパケットのRTTに失われたり、マークされた損失イベント記録、にパケットロス履歴をマップする必要があります。このマッピングを行うために、受信機は、RTTを使用するかを知る必要があり、これは、制御情報がデータパケットにピギーバック典型的には、送信者によって定期的に供給されます。 TFRCは受信機に送信されたRTTの測定が行われているかに敏感ではありませんが、この目的のために、送信者の計算されたRTT、R、（4.3節を参照）を使用することをお勧めします。
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, before any packet arrivals with a sequence number above S_loss, with a sequence number below S_loss.
S_beforeはS_loss以下のシーケンス番号と、S_loss上記シーケンス番号を持つパケットの到着前に、到着する最後のパケットのシーケンス番号です。
S_after is the sequence number of the first packet to arrive after S_before with a sequence number above S_loss.
S_afterはS_loss上記シーケンス番号S_before後に到着する最初のパケットのシーケンス番号です。
S_max is the largest sequence number.
S_MAXは、最大のシーケンス番号です。
Therefore, S_before < S_loss < S_after <= S_max.
したがって、S_before <S_loss <S_after <= S_MAX。
T_loss is the nominal estimated arrival time for the lost packet.
T_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 < T_after.
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））。
To address sequence number wrapping, let S_MAX = 2^b, where b is the bit-length of sequence numbers in a given implementation. In this case, we can interpolate the arrival time T_loss as follows:
シーケンス番号ラップに対処するために、bは所与の実装におけるシーケンス番号のビット長であるS_MAX = 2 ^ bは、ましょう。この場合、以下のように、私たちは、到着時間T_lossを補間することができます：
T_loss = T_before + (T_after - T_before) * Dist(S_loss, S_before)/Dist(S_after, S_before)
T_loss = T_before +（T_after - T_before）*ディスト（S_loss、S_before）/ディスト（S_after、S_before）
where
どこ
Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX
DIST（S_A、S_B）=（S_A + S_MAX - S_B）％S_MAX
If the lost packet S_old was determined to have started the previous loss event, and 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 in a new loss event.
T_old + R> = T_new場合、S_newは、既存の損失事象の一部です。それ以外の場合は、S_newは、新たな損失事象の最初のパケットです。
After the detection of the first loss event, the receiver divides the sequence space into loss intervals. 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). Thus, loss interval A contains all of the packets transmitted by the sender starting with the first packet transmitted in loss interval A and ending with but not including the first packet transmitted in loss interval B.
最初の損失事象の検出後、受信機は、損失間隔に配列空間を分割します。損失間隔、Aは、パケットシーケンス番号S_A及び次損失間隔Bで開始したと判定された場合、パケットシーケンス番号S_Bを開始し、損失区間A内のパケット数がによって与えられる（S_B - S_A）。したがって、損失の間隔Aは、損失区間Aに送信される最初のパケットで始まりで終わるが、損失区間Bに送信される最初のパケットを含まない送信者によって送信されたパケットをすべて含みます
The current loss interval I_0 is defined as the loss interval containing the most recent loss event. If that loss event started with packet sequence number S_A, and S_C is the highest received sequence number so far, then the size of I_0 is S_C - S_A + 1. As an example, if the current loss interval consists of a single ECN-marked packet, then S_A == S_C, and the size of the loss interval is one.
電流損失間隔I_0は、最新の損失事象を含む損失間隔として定義されます。その損失事象は、パケットシーケンス番号S_Aで開始し、S_Cは、これまでの最高受信したシーケンス番号である場合には、I_0のサイズはS_Cある - S_A + 1例として、電流損失間隔は、単一のECN-マークで構成されている場合パケットは、次いで、S_A == S_C、損失間隔の大きさは1です。
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. If the receiver has not yet seen a lost or marked packet, then the receiver does not calculate the average loss interval.
損失イベント率、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 = 2 * (n-i)/(n+2);
}
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 TFRC's speed in responding to changes in the level of congestion. It is RECOMMENDED to set the value n to 8. TFRC SHOULD NOT use values of n 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 TFRC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率を計算する際に使用される損失間隔の数の値nは、輻輳のレベルの変化に応答してTFRCの速度を決定します。 TFRCはTCPとグローバルなインターネットで競争可能性があるトラフィックのために8 nより大きな値を使用するべきではありません8に値nを設定することをお勧めします。少なくとも、8よりもn個以上の値を持つ安全な操作が重いパケットロスで二つ以上の往復時間に、より厳しい対応を含めてTFRCのメカニズムにわずかな変更を必要とします。
When calculating the average loss interval, we need to decide whether to include the current loss interval. We only include the current loss interval if it is sufficiently large to increase the average loss interval.
平均損失間隔を計算するとき、我々は現在の損失間隔を含めるかどうかを決定する必要があります。平均損失間隔を長くするのに十分な大きさの場合我々は唯一の電流損失間隔が含まれます。
Let the most recent loss intervals be I_0 to I_k, where I_0 is the current loss interval. If there have been at least n loss intervals, then k is set to n; otherwise, k is the maximum number of loss intervals seen so far. We calculate the average loss interval I_mean as follows:
最も最近の損失間隔はI_0は、電流損失間隔でI_KにI_0ことしてみましょう。少なくともn個の損失間隔があった場合、KはNに設定されています。そうでない場合、kはこれまで見損失間隔の最大数です。次のように私たちは、平均損失間隔I_meanを計算します。
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to k-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to k) {
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, when there have been at least n loss intervals, the most recent loss interval is only assigned 1/(0.75*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, discussed further in [FHPW00a] and [W00], that allows the TFRC receiver 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.
総重量の少なくともn個の損失間隔、最新の損失間隔のみ割り当てられる1 /（0.75×n個）があった場合に、最新の大きさにかかわらず、平均損失間隔を計算する際に第5.4節で説明したように損失間隔。このセクションでは、[FHPW00a]およびTFRC受信機が最新のロス間隔に相対重量の濃縮、重みを調整することを可能にする[W00]、最新の損失間隔があるでさらに論じ、OPTIONAL履歴割引機構を記載しています計算された平均損失間隔の2倍以上。
To carry out history discounting, we associate a discount factor, DF_i, with each loss interval, L_i, for i > 0, 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:
歴史の割引を行うために、我々は、各割引率は、浮動小数点数であるI> 0のため、各損失間隔、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.
歴史割引もまた、一般的な割引率、DF、浮動小数点数を使用して、それはまた1.最初に初期化され、我々は、割引率は、平均損失間隔の計算に使用されている方法を示し、その後、私たちは、このセクションの後半では、記述します、どのように割引率を経時的に変更されています。
As described in Section 5.4, the average loss interval is calculated using the n previous loss intervals I_1, ..., I_n and the current loss interval I_0. 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, the 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_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 size of current loss interval. 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.25. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
THRESHOLDにゼロ以外の値が高い混雑の早い時間からの古い損失間隔は完全に割り引かれていないことを保証します。私たちは、0.25の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 TFRC to respond somewhat more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これはオプションの履歴割引メカニズムの説明を終えます。私たちは、これが唯一の目的長い電流損失間隔で表されるようにTFRCは、混雑の突然の欠如に多少迅速に対応できるようにすることですOPTIONALメカニズムであることを強調する。
The receiver periodically sends feedback messages to the sender. Feedback packets SHOULD normally be sent at least once per RTT, unless the sender is sending at a rate of less than one packet per RTT, in which case a feedback packet SHOULD be sent for every data packet received. A feedback packet SHOULD also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history.
受信機は、定期的に送信側にフィードバックメッセージを送信します。送信側はフィードバックパケットを受信したすべてのデータパケットのために送信されるべき場合にはRTTごと未満のパケットのレートで送信されていない限り、フィードバックパケットは、通常、RTTごとに少なくとも一度送信されるべきです。フィードバックパケットは、新しい損失イベントがRTTの終了を待たずに検出されるたびに送信され、アウト・オブ・オーダーデータパケットが受信されるたびに、その履歴から、損失イベントを削除するべきです。
If the sender is transmitting at a high rate (many packets per RTT), there may be some advantages to sending periodic feedback messages more than once per RTT as this allows faster response to changing RTT measurements and more resilience to feedback packet loss.
送信者が高率（RTTあたりのパケット数）で送信された場合、これはフィードバックパケット損失にRTT測定値より回復力の変化に高速応答を可能にするように複数回RTTごとに周期的なフィードバックメッセージを送信するいくつかの利点があるかもしれません。
If the receiver was sending k feedback packets per RTT, for k>1, step (4) of Section 6.2 would be modified to set the feedback timer to expire after R_m/k seconds. However, each feedback packet would still report the receiver rate over the last RTT, not over a fraction of an RTT. In this document, we do not specify the modifications that might be required for a receiver sending more than one feedback packet per RTT. We note that there is little gain from sending a large number of feedback messages per RTT.
受信機は、K> 1、セクション6.2のステップ（4）のために、RTTごとにk個のフィードバックパケットを送信した場合R_M / K秒後に期限切れになるようにフィードバックタイマーを設定するように修正されるであろう。しかし、各フィードバックパケットはまだありませんRTTの一部の上に、最後のRTTを超える受信率を報告します。この文書では、我々はRTTごとに複数のフィードバックパケットを送信し、受信するために必要となる場合があります変更を指定しないでください。私たちは、RTTごとにフィードバックメッセージを大量に送信するから少しゲインがあることに注意してください。
When a data packet is received, the receiver performs the following steps:
データパケットを受信すると、受信機は、以下のステップを実行します。
1) Add the packet to the packet history.
1）パケット履歴にパケットを追加します。
2) Check if done: If the new packet results in the detection of a new loss event, or if no feedback packet was sent when the feedback timer last expired, go to step 3. Otherwise, no action need be performed (unless the optimization in the next paragraph is used), so exit the procedure.
新しい損失事象の検出における新しいパケット結果場合、またはそれ以外の場合はステップ3に行くときのフィードバックタイマー最後の有効期限が切れ、何のフィードバックパケットが送信されなかった場合は、何もアクションは、最適化しない限り、（実行される必要はない：2で行われている場合）をチェック次の段落）を使用するには、その手順を終了します。
An OPTIONAL optimization might check to see if the arrival of the
packet caused a hole in the packet history to be filled, and
consequently, two loss intervals were merged into one. If this
is the case, the receiver might also send feedback immediately.
The effects of such an optimization are normally expected to be
small.
3) Calculate p: Let the previous value of p be p_prev. Calculate the new value of p as described in Section 5.
3）Pを計算します。Pの前の値をp_prevことしてみましょう。第5節で説明したように、pの新しい値を計算します。
4) Expire feedback timer: If p > p_prev, cause the feedback timer to expire and perform the actions described in Section 6.2.
4）フィードバックタイマー期限切れ：P> p_prev、失効し、6.2節で説明したアクションを実行するためのフィードバックタイマーを引き起こす場合。
If p <= p_prev and no feedback packet was sent when the feedback
timer last expired, cause the feedback timer to expire and
perform the actions described in Section 6.2. If p <= p_prev and
a feedback packet was sent when the feedback timer last expired,
no action need be performed.
When the feedback timer at the receiver expires, the action to be taken depends on whether data packets have been received since the last feedback was sent.
受信機でのフィードバックタイマーの期限が切れると、取るべき行動は最後のフィードバックが送信されたため、データ・パケットが受信されたかどうかによって異なります。
For the m-th expiration of the feedback timer, let the maximum sequence number of a packet at the receiver, so far, be S_m and the value of the RTT measurement included in packet S_m be R_m. As described in Section 3.2.1, R_m is the sender's most recent estimate of the round-trip time, as reported in data packets. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
フィードバックタイマーのm番目の満了のために、受信機におけるパケットの最大シーケンス番号は、これまで、S_M及びRTT測定値はR_MことS_Mパケットに含まれるとします。 3.2.1項で説明したように、R_Mは、データパケットで報告されているように、ラウンドトリップ時間の送信者の最新の推定値です。前のフィードバックを送信してからデータ・パケットを受信した場合、受信機は、以下のステップを実行します。
1) Calculate the average loss event rate using the algorithm described in Section 5.
1）第5章に記載されたアルゴリズムを用いて、平均損失イベント率を計算します。
2) Calculate the measured receive rate, X_recv, based on the packets received within the previous R_(m-1) seconds. This is performed whether the feedback timer expired at its normal time or expired early due to a new lost or marked packet (i.e., step (3) in Section 6.1).
2）測定前R_（M-1）秒以内に受信したパケットに基づいて、速度、X_recvを受け取るを計算します。フィードバックタイマーが通常時に期限切れか早い期限が切れているかどうかこれは、新しい紛失またはマークされたパケットに実行される（すなわち、ステップ（3）6.1節で）。
In the typical case, when the receiver is sending only one
feedback packet per round-trip time and the feedback timer did
not expire early due to a new lost packet, then the time interval
since the feedback timer last expired would be R_(m-1) seconds.
We note that when the feedback timer expires early due to a new lost or marked packet, the time interval since the feedback timer last expired is likely to be smaller than R_(m-1) seconds.
私たちは、フィードバックタイマーが原因新しい紛失またはマークされたパケットを早期に満了したときに、フィードバック・タイマーからの時間間隔、最後の有効期限が切れたが、R_（M-1）秒より小さくなる可能性があることに注意してください。
For ease of implementation, if the time interval since the feedback timer last expired is not R_(m-1) seconds, the receive rate MAY be calculated over a longer time interval, the time interval going back to the most recent feedback timer expiration that was at least R_(m-1) seconds ago.
実装を容易にするために、フィードバック・タイマー、最後の有効期限が切れてからの時間間隔は、受信率がより長い時間間隔で計算することができるR_（M-1）秒、ない場合には、最新のフィードバックタイマ満了に戻る時間間隔こと少なくともR_（M-1）秒前でした。
3) Prepare and send a feedback packet containing the information described in Section 3.2.2.
3）準備し、セクション3.2.2に記載された情報を含むフィードバックパケットを送信します。
4) Restart the feedback timer to expire after R_m seconds.
4）R_M秒後に期限切れになるようにフィードバックタイマーを再起動します。
Note that rule 2) above gives a minimum value for the measured receive rate X_recv of one packet per round-trip time. If the sender is limited to a sending rate of less than one packet per round-trip time, this will be due to the loss event rate, not from a limit imposed by the measured receive rate at the receiver.
上記往復時間当たり1つのパケットの受信率測定X_recvの最小値を与える）そのルール注2。送信者が往復時間当たり未満1つのパケットの送信レートに制限されている場合は、これがない測定による制限から、損失イベント率が原因となりますが、受信機において受信速度。
If no data packets have been received since the last feedback was sent, then no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds.
最後のフィードバックが送信されましたので、何のデータパケットが受信されていない場合は、何のフィードバックパケットが送信されない、とフィードバックタイマーがR_M秒後に期限切れになるように再起動されます。
The receiver is initialized by the first data packet that arrives at the receiver. Let the sequence number of this packet be i.
受信機は、受信機に到着した最初のデータパケットによって初期化されます。このパケットのシーケンス番号iとします。
When the first packet is received:
最初のパケットを受信した場合：
o Set p = 0.
O、P = 0を設定してください。
o Set X_recv = 0.
O X_recv = 0を設定してください。
o Prepare and send a feedback packet.
O準備し、フィードバックパケットを送信します。
o Set the feedback timer to expire after R_i seconds.
O R_iとの秒後に期限切れになるようにフィードバックタイマーを設定します。
If the first data packet does not contain an estimate R_i of the round-trip time, then the receiver sends a feedback packet for every arriving data packet until a data packet arrives containing an estimate of the round-trip time.
最初のデータパケットが往復時間の推定R_iとが含まれていない場合は、データパケットが往復時間の推定値を含む到着するまで、受信機は、すべて到着するデータパケットのためのフィードバックパケットを送信します。
If the sender is using a coarse-grained timestamp that increments every quarter of a round-trip time, then a feedback timer is not needed, and the following procedure from RFC 4342 is used to determine when to send feedback messages.
送信者は、ラウンドトリップ時間の四半期ごとにインクリメント粗粒のタイムスタンプを使用している場合は、フィードバックタイマは不要であり、RFC 4342からの次の手順は、フィードバックメッセージを送信するタイミングを決定するために使用されます。
o Whenever the receiver sends a feedback message, the receiver sets a local variable last_counter to the greatest received value of the window counter since the last feedback message was sent, if any data packets have been received since the last feedback message was sent.
受信機は、フィードバックメッセージを送信するたびに、最後のフィードバック・メッセージが送信されたので、任意のデータ・パケットが受信された場合、最後のフィードバックメッセージが、送信されたため、O、受信機はウインドウカウンタの最大受信値をローカル変数last_counterを設定します。
o If the receiver receives a data packet with a window counter value greater than or equal to last_counter + 4, then the receiver sends a new feedback packet. ("Greater" and "greatest" are measured in circular window counter space.)
受信機は+ 4 last_counter以上ウインドウカウンタ値とデータ・パケットを受信した場合、O、受信機は新しいフィードバックパケットを送信します。 （「大」と「最大」は円形の窓カウンタ空間で測定されます。）
This section describes the procedure that MUST be used for initializing the loss history after the first loss event.
このセクションでは、最初の損失イベントの後損失履歴を初期化するために使用しなければならない手順を説明します。
The number of packets until the first loss cannot be used to compute the allowed sending rate directly, as the sending rate changes rapidly during this time. TFRC assumes that the correct data rate after the first loss is half of the maximum sending rate before the loss occurred. TFRC approximates this target rate, X_target, by the maximum value of X_recv so far. (For slow-start, for a particular round-trip time, the sender's sending rate is generally twice the receiver's receive rate for data sent over the previous round-trip time.)
送信速度は、この時間の間に急激に変化するように、第1の損失までのパケットの数は、直接許容送信レートを計算するために使用することができません。 TFRCは、損失が発生する前に最初の損失の後に正しいデータ・レートが最大送信レートの半分であることを前提としています。 TFRCは、これまでX_recvの最大値によって、この目標レート、X_targetに近似しています。 （スロースタートのために、特定の往復時間のために、送信者の送信レートは、前のラウンドトリップ時間を介して送信されるデータのための二回、受信機の受信率が一般的です。）
After the first loss, instead of initializing the first loss interval to the number of packets sent until the first loss, the TFRC receiver calculates the loss interval that would be required to produce the data rate X_target, and uses this synthetic loss interval to seed the loss history mechanism.
最初の損失の後、代わりに最初の損失まで、送信されたパケットの数に最初の損失間隔を初期化する、TFRC受信機は、データレートX_targetを生成するために必要とされるであろう損失間隔を算出し、シードするこの合成損失間隔を使用しロス履歴メカニズム。
TFRC does this by finding some value, p, for which the throughput equation in Section 3.1 gives a sending rate within 5% of X_target, given the round-trip time R, and the first loss interval is then set to 1/p. If the receiver knows the segment size, s, used by the sender, then the receiver MAY use the throughput equation for X; otherwise, the receiver MAY measure the receive rate in packets per second instead of bytes per second for this purpose, and use the throughput equation for X_pps. (The 5% tolerance is introduced simply because the throughput equation is difficult to invert, and we want to reduce the costs of calculating p numerically.)
TFRCは、ラウンドトリップ時間R与えられた、3.1節におけるスループット方程式はX_targetの5％以内送信速度を与えるためにいくつかの値、Pを見つけることによってこれを行い、そして最初の損失間隔は、次いで1 / Pに設定されています。受信機は、送信者によって使用されるセグメントサイズ、Sを知っている場合、受信機は、Xのスループットの式を使用することができます。そうでない場合、受信機は、秒あたりのパケットの代わりに、この目的のために秒あたりのバイト数で受信率を測定し、X_ppsのスループット方程式を使用するかもしれません。 （スループット方程式が反転することは困難であり、我々は、pの数値を計算するコストを削減したいので、5％の許容差は、単純に導入されています。）
Special care is needed for initializing the first loss interval when the first data packet is lost or marked. When the first data packet is lost in TCP, the TCP sender retransmits the packet after the retransmit timer expires. If TCP's first data packet is ECN-marked, the TCP sender resets the retransmit timer, and sends a new data packet only when the retransmit timer expires [RFC3168] (Section 6.1.2). For TFRC, if the first data packet is lost or ECN-marked, then the first loss interval consists of the null interval with no data packets. In this case, the loss interval length for this (null) loss interval SHOULD be set to give a similar sending rate to that of TCP, as specified in the paragraph below.
特別な注意が最初のデータパケットが失われたり、マークされている最初の損失間隔を初期化するために必要とされます。最初のデータパケットがTCPで失われた場合、再送タイマが満了した後、TCPの送信者は、パケットを再送します。 TCPの最初のデータパケットがECN-マークされている場合、TCPの送信者は、再送信タイマーをリセットし、再送信タイマは、[RFC3168]（セクション6.1.2）を満了した唯一の新しいデータパケットを送信します。最初のデータパケットが失われたり、ECN-マークされている場合TFRCについては、その後、最初の損失間隔はなし、データパケットとヌル間隔で構成されています。以下の段落で指定され、この場合、この（ヌル）損失間隔の損失間隔の長さは、TCPと同様の送信速度を与えるように設定されるべきです。
When the first TFRC loss interval is null, meaning that the first data packet is lost or ECN-marked, in order to follow the behavior of TCP, TFRC wants the allowed sending rate to be 1 packet every two round-trip times, or equivalently, 0.5 packets per RTT. Thus, the TFRC receiver calculates the loss interval that would be required to produce the target rate X_target of 0.5/R packets per second, for the round-trip time R, and uses this synthetic loss interval for the first loss interval. The TFRC receiver uses 0.5/R packets per second as the minimum value for X_target when initializing the first loss interval.
最初TFRC損失間隔が最初のデータパケットが失われたり、ECN-マークされていることを意味し、nullの場合は、TCPの行動を追跡するためには、TFRCは許可され、送信レートが2つずつ往復時間1つのパケットになりたい、または同等に、RTTあたり0.5パケット。したがって、TFRC受信機は、ラウンドトリップ時間Rのために、毎秒0.5 / Rパケットの目標レートX_targetを生成するために必要とされるであろう損失間隔を算出し、第一損失間隔は、この合成損失間隔を使用します。最初の損失間隔を初期化するときTFRCレシーバはX_targetの最小値として、毎秒0.5 / Rパケットを使用します。
We note that even though the TFRC receiver reports a synthetic loss interval after the first loss event, the TFRC receiver still reports the measured receive rate X_recv, as specified in Section 6.2 above.
私たちは、TFRCの受信機が最初の損失イベントの後、合成損失間隔を報告するにもかかわらず、上記のセクション6.2で指定されるように、TFRCの受信機は、まだ、受信測定率X_recvを報告することに注意してください。
In a sender-based variant of TFRC, the receiver uses reliable delivery to send information about packet losses to the sender, and the sender computes the packet loss rate and the acceptable transmit rate.
TFRCのセンダベースの変形例では、受信機は、送信側にパケット損失に関する情報を送信するために信頼できる配信を使用し、送信側はパケットロス率と許容される伝送速度を計算します。
The main advantage of a sender-based variant of TFRC is that the sender does not have to trust the receiver's calculation of the packet loss rate. However, with the requirement of reliable delivery of loss information from the receiver to the sender, a sender-based TFRC would have much tighter constraints on the transport protocol in which it is embedded.
TFRCの送信元ベースの変異体の主な利点は、送信側がパケットロス率の受信側の計算を信頼する必要がないということです。しかし、受信側から送信側への損失情報の信頼できる配信の要件と、センダベースTFRCは、それが埋め込まれているトランスポートプロトコル上ではるかに厳しい制約を有するであろう。
In contrast, the receiver-based variant of TFRC specified in this document is robust to the loss of feedback packets, and therefore does not require the reliable delivery of feedback packets. It is also better suited for applications where it is desirable to offload work from the server to the client as much as possible.
対照的に、この文書で指定されたTFRCの受信機ベースの変異体は、フィードバックパケットの損失に対してロバストであるため、フィードバックパケットの信頼できる配信を必要としません。可能な限り、サーバからクライアントへの作業負荷を軽減することが望まれる用途にも適しています。
RFC 4340 and RFC 4342 together specify DCCP's CCID 3, which can be used as a sender-based variant of TFRC. In CCID 3, each feedback packet from the receiver contains a Loss Intervals option, reporting the lengths of the most recent loss intervals. Feedback packets may also include the Ack Vector option, allowing the sender to determine exactly which packets were dropped or marked and to check the information reported in the Loss Intervals options. The Ack Vector option can also include ECN Nonce Echoes, allowing the sender to verify the receiver's report of having received an unmarked data packet. The Ack Vector option allows the sender to see for itself which data packets were lost or ECN-marked, to determine loss intervals, and to calculate the loss event rate. Section 9 of RFC 4342 discusses issues in the sender verifying information reported by the receiver.
RFC 4340およびRFC 4342には、一緒にTFRCの送信元ベースのバリアントとして使用することができますDCCPのCCID 3を、指定します。 CCID 3では、受信機からの各フィードバックパケットは、最新の損失間隔の長さを報告し、損失間隔のオプションが含まれています。フィードバックパケットも、送信者が削除またはマークされた正確にどのパケットを決定するために、損失間隔オプションで報告された情報を確認することができ、Ackをベクトルオプションを含むことができます。 Ackベクトルオプションは、送信側がマークされていないデータパケットを受信した受信者のレポートを確認することができ、電子証券取引ネットワークのNonceエコーズを含めることができます。 Ackベクトルオプションは、送信側がデータパケットが失われたり、ECN-マークされ、損失間隔を決定するために、損失イベント率を計算したそれ自体を参照することができます。 RFC 4342のセクション9は、受信機によって報告された送信者検証情報に問題について説明します。
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the implementation issues.
このドキュメントは、アプリケーションおよびトランスポートプロトコルで使用するために、TFRC輻輳制御メカニズムを指定しています。このセクションでは、簡単に実装の問題のいくつかを言及しています。
For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 can be expressed as follows:
次のようにt_RTO = 4 * R及びB = 1については、セクション3.1におけるスループット方程式を表すことができます。
s
X_Bps = --------
R * f(p)
for
ために
f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)).
F（P）は= SQRT（2 * P / 3）+（12 *のSQRT（3 * P / 8）* P *（1 + 32 * P ^ 2））。
A table lookup could be used for the function f(p).
テーブルルックアップは、関数f（P）を使用することができます。
Many of the multiplications (e.g., q and 1-q for the round-trip time average, a factor of 4 for the timeout interval) are or could be by powers of two, and therefore could be implemented as simple shift operations.
乗算の多く（例えば、Qおよび往復時間平均、タイムアウト間隔の4分の1-q）があるか、または2の累乗によることができ、従って、単純なシフト演算として実現することができます。
This section discusses implementation issues for sender behavior when a feedback packet is received, from Section 4.3.
フィードバックパケットを受信したときにこのセクションでは、セクション4.3から、送信者の行動のための実装の問題について説明します。
When a feedback packet is received, the sender has to determine if the entire interval covered by that feedback packet was a data-limited period. This section discusses one possible implementation for the sender to determine if the interval covered by a feedback packet was a data-limited period.
フィードバックパケットを受信した場合、送信者はそのフィードバックパケットによって覆わ全体区間がデータ限られた期間であるかどうかを決定しなければなりません。このセクションでは、フィードバックパケットでカバー間隔はデータが制限された時代であったかどうかを判断するために、送信者のための一つの可能な実装について説明します。
If the feedback packets all report the timestamp of the last data packet received, then let t_new be the timestamp reported by this feedback packet. Because all feedback packets cover an interval of at least a round-trip time, it is sufficient for the sender to determine if there was any time in the period (t_old, t_new] when the sender was not data-limited, for R the sender's estimate of the round-trip time, and for t_old set to t_new - R. (This procedure estimates the interval covered by the feedback packet, rather than computing it exactly. This seems fine to us.)
フィードバックパケットはすべてのパケットを受信した最後のデータのタイムスタンプを報告した場合、t_newは、このフィードバックパケットによって報告されたタイムスタンプとします。すべてのフィードバックパケットは、少なくともラウンドトリップ時間の間隔をカバーするための期間（t_old内の任意の時間があった場合、送信者が決定するために、それは十分であり、t_new]送信者は、Rのために送信者のデータが制限されなかった場合往復時間の推定値、およびt_newに設定t_oldため - R.（この手順ではなく、正確にそれを計算するよりもフィードバックパケットでカバー間隔を推定し、これは私たちに罰金です。。）
The pseudocode for determining if the sender was data-limited over the entire interval covered in a feedback packet is given below. The variables NotLimited1 and NotLimited2 both represent times when the sender was *not* data-limited.
送信側はフィードバックパケットでカバー全区間にわたってデータが制限されたかどうかを決定するための擬似コードを以下に示します。変数はNotLimited1とNotLimited2の両方が、送信者が* *データ-制限されなかった回数を表しています。
Initialization:
NotLimited1 = NotLimited2 = t_new = t_next = 0;
t_now = current time;
After sending a segment:
If (sender has sent all it is allowed to send) {
// Sender is not data-limited at this instant.
If NotLimited1 <= t_new
// Goal: NotLimited1 > t_new.
NotLimited1 = t_now;
Else if (NotLimited2 <= t_next)
// Goal: NotLimited2 > t_next.
NotLimited2 = t_now;
}
When a feedback packet is received, is this interval data-limited:
t_new = timestamp reported in feedback packet.
t_old = t_new - R. // local variable
t_next = t_now;
If ((t_old < NotLimited1 <= t_new) or
(t_old < NotLimited2 <= t_new))
This was not a data-limited interval;
Else
This was a data-limited interval.
If (NotLimited1 <= t_new && NotLimited2 > t_new)
NotLimited1 = NotLimited2;
Transmission times refer to transmission of a segment or segments to the layer below.
送信時間は、以下の層にセグメントまたはセグメントの送信を指します。
Between feedback packets, (t_old, t_new] gives the transmission time interval estimated to be covered by the most recent feedback packet, and t_next gives a time at least a round-trip time greater than t_new. The next feedback packet can be expected to cover roughly the interval (t_new, t_next] (unless the receiver sends the feedback packet early because it is reporting a new loss event). The goal is for NotLimited1 to save a non-data-limited time in (t_new, t_next], if there was one, and for NotLimited2 to save a non-data-limited time after t_next.
フィードバックパケット、（t_old、t_new]の間で最も最近のフィードバックパケットに含まれることが推定送信時間間隔を与え、t_nextがt_newより少なくともラウンドトリップ時間を時間を与えます。次のフィードバックパケットをカバーするために期待することができますそれは）新しい損失事象を報告しているため、受信機は、早期フィードバックパケットを送信しない限り、そこにあればNotLimited1は、（t_new、t_next]における非データ・限られた時間を節約するためにおおよその間隔（t_new、t_next]は、（。目標はあります一つであった、とNotLimited2ためt_next後のデータ非制限時間を節約します。
When a feedback packet was received, if either NotLimited1 or NotLimited2 is in the time interval covered by the feedback packet, then the interval is not a data-limited interval; the sender was not data-limited at least once during that time interval. If neither NotLimited1 nor NotLimited2 is in the time interval covered by a feedback packet, then the sender is assumed to have been data-limited over that time interval.
フィードバックパケットを受信したときNotLimited1又はNotLimited2いずれかがフィードバックパケットによって覆われた時間間隔であれば、その後の間隔は、データ制限間隔はありません。送信者は、データが制限され、その時間間隔中に少なくとも1回はなかったです。 NotLimited1もNotLimited2でもないが、フィードバックパケットによってカバーされた時間間隔である場合、送信者は、データが制限され、その時間間隔にわたるされているものとします。
We note that this procedure is a heuristic, and in some cases the sender might not determine correctly if the sender was data-limited over the entire interval covered by the feedback packet. This heuristic does not address the possible complications of reordering.
私たちは、この手順はヒューリスティックであることに注意して、送信者がフィードバックパケットでカバー全体の間隔でデータが制限されていた場合、いくつかの例では、送信者が正しく決定しない場合があります。このヒューリスティックは、並べ替えの可能性合併症に対処していません。
That seems acceptable to us. In order to improve its accuracy in identifying if the entire interval covered by a feedback packet was a data-limited interval, the sender could save more NotLimited times.
それは私たちに許容可能なようです。全区間がフィードバックパケットによってカバーされている場合の識別にその精度を向上させるためには、送信者がより多くのNotLimited時間を節約することができ、データが制限された時間間隔でした。
In some implementations of TFRC, the sender sends coarse-grained timestamps that increment every quarter of a round-trip time, and the feedback packet reports the greatest valid sequence number received so far instead of reporting the timestamp of the last packet received. In this case, the sender can maintain per-packet state to determine t_new (the time that the acknowledged packet was sent), or the sender can estimate t_new from its estimate of the round-trip time and the elapsed time t_delay reported by the feedback packet.
TFRCのいくつかの実装では、送信者は、ラウンドトリップ時間の四半期ごとにインクリメント粒度の粗いタイムスタンプを送信し、フィードバックパケットは、最大の有効なシーケンス番号が最後に受信したパケットのタイムスタンプを報告し、これまでの代わりを受け報告します。この場合、送信側はt_new（確認応答パケットが送信された時間）を決定するためにパケットごとの状態を維持することができる、または送信者は、その往復時間の推定とフィードバックによって報告された経過時間t_delayからt_newを推定することができますパケット。
To reduce the complexity of maintaining X_recv_set, it is sufficient to limit X_recv_set to at most N=3 elements. In this case, the procedure Update X_recv_set() would be modified as follows:
X_recv_setを維持する複雑さを低減するために、ほとんどのN = 3つの要素にまでX_recv_setを制限するのに十分です。この場合、以下のように手順更新X_recv_set（）が修正されます。
Update X_recv_set(): Add X_recv to X_recv_set; Delete from X_recv_set values older than two round-trip times. Keep only the most recent N values.
更新X_recv_set（）：X_recv_setにX_recvを追加します。 2往復時間よりも古いX_recv_set値から削除します。唯一の最も最近のN値を保管してください。
Maintaining at most *two* elements in X_recv_set would be sufficient for the sender to save an old value of X_recv from before a data-limited period, and to allow the sender not to be limited by the first feedback packet after an idle period (reporting a receive rate of one packet per round-trip time). However, it is *possible* that maintaining at most two elements in X_recv_set would not give quite as good performance as maintaining at most three elements. Maintaining three elements in X_recv_set would allow X_recv_set to contain X_recv values from two successive feedback packets, plus a more recent X_recv value from a loss event.
送信者は、データが制限された期間前からX_recvの古い値を保存するために、送信者がアイドル期間の後の最初のフィードバックパケットに限定されるものではないできるようにするためにX_recv_setで最も* 2つの*の要素で維持することが十分である（報告a）のラウンドトリップ時間あたり1つのパケットの割合を受け取ります。しかし、それはX_recv_setで最も二つの要素で維持することは、ほとんどの三つの要素で維持するほど良好な性能を与えないだろうと* *可能です。 X_recv_setでの三つの要素を維持することはX_recv_setは、2つの連続したフィードバックパケット、プラス損失イベントからより多くの最近のX_recv値からX_recv値を含めることができます。
This section discusses one possible scheduling mechanism for a sender in an operating system with a coarse-grained timing granularity (from Section 4.6).
このセクション（セクション4.6）粗いタイミング粒度を有するオペレーティングシステムにおいて、送信者のための1つの可能なスケジューリング機構を論じています。
Let t_gran be the scheduling timer granularity of the operating system. Let t_ipi be the inter-packet interval, as specified in Section 4.6. If the operating system has a coarse timer granularity or otherwise cannot support short t_ipi intervals, then either the TFRC sender will be restricted to a sending rate of at most 1 packet every t_gran seconds, or the TFRC sender must be allowed to send short bursts of packets. In addition to allowing the sender to accumulate sending credits for past unused send times, it can be useful to allow the sender to send a packet before its scheduled send time, as described in the section below.
t_granは、オペレーティングシステムのスケジューリングタイマーの粒度とします。 4.6節で指定されているようt_ipiは、パケット間の間隔とします。オペレーティングシステムが粗いタイマーの粒度を持っているか、そうでない場合は、短いt_ipi間隔をサポートすることができない場合は、TFRCの送信者は、せいぜい1つのパケットの送信レートにおきt_gran秒に制限されます、またはTFRCの送信者がの短いバーストを送信することを許可しなければならないのいずれかパケット。送信者が過去の未使用の送信時間について送信クレジットを蓄積することができることに加えて、以下のセクションで説明したように、送信者は、そのスケジュールされた送信時間前にパケットを送信できるようにするために役立ちます。
A parameter, t_delta, may be used to allow a packet to be sent before its nominal send time. Consider an application that becomes idle and requests re-scheduling for time t_i = t_(i-1) + t_ipi, for t_(i-1) the send time for the previous packet. When the application is rescheduled, it checks the current time, t_now. If (t_now > t_i - t_delta), then packet i is sent. When the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - t_delta. In such a case, the packet would be sent immediately.
パラメータは、t_delta、パケットがその公称送信時間前に送信できるようにするために使用することができます。時間のための再スケジューリングアイドルや要望なっアプリケーションT_I = T_（I-1）+ T_ためt_ipi、（I-1）前回のパケットの送信時間を考えてみましょう。アプリケーションが再スケジュールされている場合、それは現在の時刻、t_nowをチェックします。 （t_now> T_I - t_delta）場合、パケットiが送信されます。 t_delta - 公称送信時間は、T_Iは、次のパケットの計算された場合、それはすでにケースt_now> T_Iかもしれません。そのような場合には、パケットがすぐに送信されます。
In order to send at most one packet before its nominal send time, and never to send a packet more than a round-trip time before its nominal send time, the parameter t_delta would be set as follows:
その公称送信時間前に最大1つのパケットを送信するためには、その名目上の送信時間前に往復時間よりも多くのパケットを送信しないように決して、次のようにパラメータt_deltaが設定されます。
t_delta = min(t_ipi, t_gran, rtt)/2;
t_delta =分（t_ipi、t_gran、RTT）/ 2。
(The scheduling granularity t_gran is 10 ms on some older Unix systems.)
（スケジューリング粒度t_granは、一部の古いUnixシステム上の10ミリ秒です。）
As an example, consider a TFRC flow with an allowed sending rate X of 10 packets per round-trip time (PPR), a round-trip time of 100 ms, a system with a scheduling granularity t_gran of 10 ms, and the ability to accumulate unused sending credits for a round-trip time. In this case, t_ipi is 1 ms. The TFRC sender would be allowed to send packets 0.5 ms before their nominal sending time, and would be allowed to save unused sending credits for 100 ms. The scheduling granularity of 10 ms would not significantly affect the performance of the connection.
一例として、ラウンドトリップ時間あたり10のパケット（PPR）、100ミリ秒の往復時間が、10ミリ秒のt_granスケジューリング粒度でシステムの許容送信率XとTFRCフロー、および能力を検討往復時間のため、未使用の送信クレジットを蓄積します。この場合、t_ipiは1ミリ秒です。 TFRCの送信者は、その公称送信時間前にパケットに0.5ミリ秒を送信することが許可されるだろう、と100ミリのために使用されていない送信クレジットを保存できます。 10ミリ秒のスケジューリング粒度が大きく、接続のパフォーマンスに影響を与えません。
As a different example, consider a TFRC flow with a scheduling granularity greater than the round-trip time, for example, with a round-trip time of 0.1 ms and a system with a scheduling granularity of 1 ms, and with the ability to accumulate unused sending credits for a round-trip time. The TFRC sender would be allowed to save unused sending credits for 0.1 ms. If the scheduling granularity *did not* affect the sender's response to an incoming feedback packet, then the TFRC sender would be able to send an RTT of data (as determined by the allowed sending rate) each RTT, in response to incoming feedback packets. In this case, the coarse scheduling granularity would not significantly reduce the sending rate, but the sending rate would be bursty, with a round-trip time of data sent in response to each feedback packet.
別例として、0.1ミリ秒の往復時間及び1ミリ秒のスケジューリング粒度を有するシステムと、および蓄積する能力を有する、例えば、往復時間よりも長いスケジューリング粒度とTFRCフローを検討往復時間のため、未使用の送信クレジット。 TFRCの送信者は0.1ミリ秒のために使用されていない送信クレジットを保存できます。スケジューリング粒度は* *、着信フィードバックパケットに送信者の応答に影響を与えなかった場合には、TFRCの送信者は、受信フィードバックパケットに応答して、データのRTT（許可され、送信速度によって決定される）各RTTを送ることができるでしょう。この場合、粗スケジューリング粒度が大きく、送信速度を低下させないだろうが、送信レートは、各フィードバックパケットに応答して送信データの往復時間で、バースト的になります。
However, performance would be different, in this case, if the operating system scheduling granularity affected the sender's response to feedback packets as well as the general scheduling of the sender. In this case, the sender's performance would be severely limited by the scheduling granularity being greater than the round-trip time, with the sender able to send an RTT of data, at the allowed sending rate, at most once every 1 ms. This restriction of the sending rate is an unavoidable consequence of allowing burstiness of at most a round-trip time of data.
オペレーティングシステムのスケジューリング粒度は、送信者のフィードバックパケットへの応答だけでなく、送信者の一般的なスケジューリングに影響を与えた場合は、パフォーマンスは、この場合には、異なるだろう。この場合、送信者のパフォーマンスが大幅にスケジューリング粒度が高々回1ミリ秒、許さ送信レートで、データのRTTを送信できる送信者に、往復時間よりも大きいことによって制限されるだろう。送信レートのこの制限は、データのほとんどのラウンドトリップ時間のバースト性を可能にする避けられない結果です。
The calculation of the average loss interval in Section 5.4 involves multiplications by the weights w_0 to w_(n-1), which for n=8 are:
5.4の平均損失間隔の計算は、重みによって乗算nに= 8である、（N-1）W_するW_0含みます。
With a minor loss of smoothness, it would be possible to use weights that were powers of two or sums of powers of two, e.g.,
滑らかさのマイナー損失と、2の累乗、または例えば2のべき乗の和であった重みを使用することも可能です
The optional history discounting mechanism described in Section 5.5 is used in the calculation of the average loss rate. The history discounting mechanism is invoked only when there has been an unusually long interval with no packet losses. For a more efficient operation, the discount factor, DF_i, could be restricted to be a power of two.
セクション5.5で説明オプション履歴割引機構は、平均損失率の計算に使用されます。なしパケット損失が異常に長い間隔があった場合にのみ、履歴割引機構が呼び出されます。より効率的な動作については、割引率、DF_iは、2の累乗に制限することができます。
This section summarizes the changes from RFC 3448. At a high level, the main change is to add mechanisms to address the case of a data-limited sender. This document also explicitly allows the TFRC sender to accumulate up to a round-trip time of unused send credits, and as a result to send a burst of packets if data arrives from the application in a burst after a data-limited period. This issue was not explicitly addressed in RFC 3448.
このセクションでは、ハイレベルのRFC 3448.からの変化をまとめたもので、主な変化は、データ制限送信者の場合に対処するための機構を追加することです。この文書は、明示的TFRCの送信者は、未使用の送信クレジットの往復時間までに蓄積することができ、かつデータはデータが制限された期間の後、バースト内のアプリケーションから到着した場合、結果として、パケットのバーストを送信します。この問題は、明示的にRFC 3448で対処されていませんでした。
This document changes RFC 3448 to incorporate TCP's higher initial sending rates from RFC 3390. This document also changes RFC 3448 to allow RFC 4342's use of a coarse-grained timestamp on data packets instead of a more fine-grained timestamp.
この文書は、この文書はまた、代わりに、よりきめの細かいタイムスタンプのデータパケットに粗粒のタイムスタンプのRFC 4342の使用を許可するようにRFC 3448に変更RFC 3390からTCPの高い初期送信レートを組み込むためにRFC 3448を変更します。
Other changes address corner cases involving slow-start, the response when the first data packet is dropped, and the like. This document also incorporates the items in the RFC 3448 Errata.
その他の変更は、スロースタート、最初のデータパケットがドロップされ、応答などを含むコーナーケースを扱います。この文書はまた、RFC 3448正誤表の項目が組み込まれています。
This section is non-normative; the normative text is in the cited sections.
このセクションでは、非規範的です。規範的なテキストは、引用のセクションです。
Section 4.1, estimating the average segment size: Section 4.1 was modified to give a specific algorithm that could be used for estimating the average segment size.
セクション4.1、平均セグメントサイズを見積もる：4.1節は、平均セグメントサイズを見積もるために使用することができる特定のアルゴリズムを与えるように変更されました。
Section 4.2, update to the initial sending rate: In RFC 3448, the initial sending rate was two packets per round-trip time. In this document, the initial sending rate can be as high as four packets per round-trip time, following RFC 3390. The initial sending rate was changed to be in terms of the segment size s, not in terms of the MSS.
4.2節では、初期送信レートを更新：RFC 3448では、初期送信レートは、ラウンドトリップ時間ごとに2つのパケットでした。この文書では、最初の送信レートは、ラウンドトリップ時間ごとに4つのパケットほど高くすることができ、RFC 3390以下の初期送信レートは、セグメントサイズsの点ではなく、MSSの点であることに変更しました。
Section 4.2 now says that tld, the Time Last Doubled during slow-start, can be initialized to either 0 or to -1. Section 4.2 was also clarified to say that RTT measurements do not only come from feedback packets; they could also come from other places, such as the SYN exchange.
4.2節は現在のTLDは、タイムラストはスロースタート時に倍増、0または-1のいずれかに初期化することができる。と言います4.2節は、RTT測定は唯一のフィードバックパケットから来ていないと言うことを明らかにしました。彼らはまた、このようなSYN交換などの他の場所から来ることができました。
Section 4.3, response to feedback packets: Section 4.3 was modified to change the way that the receive rate is used in limiting the sender's allowed sending rate, by using the set of receive rate values of the last two round-trip times, and initializing the set of receive rate values by a large value.
4.3節、フィードバックパケットへの応答：4.3節を最後に2往復時間の受信レート値のセットを使用して、初期化することによって、受信率は、送信者の許可の送信速度を制限に使用される方法を変更するように変更されました大きな値による受信レート値のセット。
The larger initial sending rate in Section 4.2 is of little use if the receiver sends a feedback packet after the first packet is received, and the sender, in response, reduces the allowed sending rate to at most two packets per RTT, which would be twice the receive rate. Because of the change in the sender's processing of the receive rate, the sender now does not reduce the allowed sending rate to twice the reported receive rate in response to the first feedback packet.
受信機は、最初のパケットを受信した後、フィードバックパケットを送信し、送信者、応答では、二回になりRTTごとに最大2つのパケットに許可される送信レートを下げた場合、セクション4.2で、より大きな初期の送信レートは、ほとんど役に立ちません受信率。そのため、受信率の送信者の処理の変更により、送信者は現在、第1のフィードバックパケットに応じて二回受信報告率に許可され、送信レートを低下させません。
During a data-limited period, the sender saves the receive rate reported from just before the data-limited period, if it is larger than the receive rate during the data-limited period. The sender also reduces the saved values in X_recv_set in response to a loss during a data-limited period. Appendix C discusses this response further.
それは、データ・限られた期間中に受信レートよりも大きい場合、データ・限られた期間中に、送信者は、単にデータが制限された期間前から報告された受信率を節約できます。送信者は、データが制限された期間中の損失に応じてX_recv_setで保存された値を低減します。付録Cには、さらにこの応答について説明します。
Section 4.4, response to an idle period: Following Section 5.1 from [RFC4342], this document specifies that when the sending rate is reduced after an idle period that covers the period since the nofeedback timer was set, the allowed sending rate is not reduced below the initial sending rate. (In Section 4.4, the variable recover_rate is set to the initial sending rate.)
4.4節、アイドル期間に対応：[RFC4342]から5.1節に続いて、この文書では、送信速度がNOFEEDBACKタイマーが設定されてからの期間をカバーしてアイドル期間の後に低下した場合、許可される送信レートを以下に削減されていないことを指定します初期送信レート。 （セクション4.4で、変数recover_rate初期送信レートに設定されています。）
Section 4.4, correction from [RFC3448Err]. RFC 3448 had contradictory text about whether the sender halved its sending rate after *two* round-trip times without receiving a feedback report, or after *four* round-trip times. This document clarifies that the sender halves its sending rate after four round-trip times without receiving a feedback report [RFC3448Err].
セクション4.4、[RFC3448Err]から補正。 RFC 3448は、送信者がフィードバックレポートを受信することなく、* 2 *往復時間後にその送信レートを半分、または4 *往復時間*の後かどうかについての矛盾したテキストを持っていました。この文書では、送信者がフィードバックレポート[RFC3448Err]を受けずに4往復時間後の送信レートを半分にすることを明確にしています。
Section 4.4, clarification for slow-start: Section 4.4 was clarified to specify that on the expiration of the nofeedback timer, if p = 0, X_Bps cannot be used, because the sender does not yet have a value for X_Bps. Section 4.4 was also clarified to check the case when the sender does not yet have an RTT sample, but has sent a packet since the nofeedback timer was set.
4.4節、スロースタートのための明確化：4.4節は、p = 0の場合、NOFEEDBACKタイマーの満了にそれを指定することが明らかになった送信者はまだX_Bpsの値を持っていないため、X_Bpsは、使用することはできません。 4.4節はまた、送信者がまだRTTのサンプルを持っていない場合を確認するために明らかになったが、NOFEEDBACKタイマーをセットしてからパケットを送信しました。
Section 4.6: credits for unused send time:
セクション4.6：未使用の送信時間のためのクレジット：
Section 4.6 has been clarified to say that the TFRC sender gets to accumulate up to an RTT of credits for unused send time. Section 4.6 was also rewritten to clarify what is specification and what is implementation.
4.6節ではTFRCの送信者は、未使用の送信時間のためのクレジットのRTTまで蓄積して取得することを言うことが明らかにされています。 4.6節でも仕様で、実装は何が何であるかを明確にするために書き直されました。
Section 5.4, clarification: Section 5.4 was modified to clarify the receiver's calculation of the average loss interval when the receiver has not yet seen n loss intervals.
セクション5.4、明確化：第5.4節は、受信機がまだ見N損失間隔ていない場合、平均損失間隔の受信機の計算を明確にするために変更されました。
Section 5.5, correction: Section 5.5 was corrected to say that the loss interval I_0 includes all transmitted packets, including lost and marked packets (as defined in Section 5.3 in the general definition of loss intervals).
5.5節、補正：5.5節は、（損失間隔の一般的な定義では、セクション5.3で定義された）損失間隔I_0が失われたとマークされたパケットを含む、すべての送信されたパケットを、含まれていることを言うことを修正しました。
Section 5.5, correction from [RFC3448Err]: A line in Section 5.5 was changed from
セクション5.5、[RFC3448Err]から補正：セクション5.5の行から変更されました
for (i = 1 to n) { DF_i = 1; }
DF_i = 1（i = 1からnまで）{ため、 }
to
と
for (i = 0 to n) { DF_i = 1; }
（nはI = 0）のための{DF_i = 1。 }
[RFC3448Err].
【RFC3448Err]。
Section 5.5, history discounting: THRESHOLD, the lower bound on the history discounting parameter DF, has been changed from 0.5 to 0.25, to allow more history discounting when the current interval is long.
5.5節、歴史割引：THRESHOLD、パラメータDFを割り引く歴史上の下限は、現在の間隔が長い場合より歴史の割引を可能にするために、0.5から0.25に変更されました。
Section 6, multiple feedback packets: Section 6 now contains more discussion of procedures if the receiver sends multiple feedback packets each round-trip time.
第6節、複数のフィードバックパケット：受信機は、各ラウンドトリップ時間、複数のフィードバックパケットを送信した場合第6節は、今の手順のより多くの議論が含まれています。
Section 6.3, initialization of the feedback timer: Section 6.3 now specifies the receiver's initialization of the feedback timer if the first data packet received does not have an estimate of the round-trip time.
6.3節では、フィードバック・タイマーの初期化：受信した最初のデータパケットが往復時間の見積もりを持っていない場合は、セクション6.3は現在、フィードバックタイマーの受信機の初期設定を指定します。
Section 6.3, a coarse-grained timestamp: Section 6.3 was modified to incorporate, as an option, a coarse-grained timestamp from the sender that increments every quarter of a round-trip time, instead of a more fine-grained timestamp. This follows RFC 4342.
6.3節、粗粒度のタイムスタンプ：6.3節ではなく、よりきめの細かいタイムスタンプの、ラウンドトリップ時間の四半期ごとにインクリメント送信者から、オプションとして、粗粒度のタイムスタンプを組み込むように修正されました。これは、RFC 4342に従います。
Section 6.3.1, after the first loss event: Section 6.3.1 now says that for initializing the loss history after the first loss event, the receiver uses the maximum receive rate so far, instead of the receive rate in the last round-trip time.
セクション6.3.1は今最初の損失イベントの後損失履歴を初期化するため、受信機は最大でこれまでに受信速度を使用していることを言い、代わりに受信率の最後の往復で：最初の損失イベントの後、セクション6.3.1、時間。
Section 6.3.1, if the first data packet is dropped: Section 6.3.1 now contains a specification for initializing the loss history if the first data packet sent is lost or ECN-marked.
セクション6.3.1、最初のデータパケットが破棄された場合：セクション6.3.1は、現在送信された最初のデータパケットが失われたり、ECN-マークされている場合の損失履歴を初期化するための仕様が含まれています。
Section 7, sender-based variants: Section 7's discussion of sender-based variants has been expanded, with reference to RFC 4342.
第7節、送信者ベースの変種：送信者ベースの変種の第7節の議論は、RFC 4342を参照して、拡張されました。
TFRC 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.
TFRCは、それ自体でトランスポートプロトコルが、トランスポート・プロトコルに関連して使用されることが意図される輻輳制御機構はありません。したがって、セキュリティは、主に特定のトランスポートプロトコルと、その認証メカニズムの文脈において考慮される必要があります。
Congestion control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus, any transport protocol that uses TFRC should take care to ensure that feedback is only accepted from the receiver of the data. The precise mechanism to achieve this will however depend on the transport protocol itself.
輻輳制御機構は、潜在的にサービス拒否を作成するために悪用される可能性があります。これは、偽装されたフィードバックにより発生する可能性があります。したがって、TFRCを使用する任意の転送プロトコルは、フィードバックは、データのみの受信機から受け入れられることを保証するために注意を払うべきです。これを達成するための正確なメカニズムは、しかし、トランスポートプロトコル自体に依存します。
In addition, congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. A receiver might do this by claiming to have received packets that, in fact, were lost due to congestion. 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.
また、輻輳制御メカニズムは、潜在的にネットワーク帯域幅のその公正な取り分より多くを受信したい貪欲受信機によって操作することができます。受信機は、実際には、輻輳のために失われた、受信したパケットを持っていると主張することによってこれを行う可能性があります。このような受信機に対する可能な防御は、通常、受信機が受信したことを証明するために、送信者にフィードバックしなければならないナンスのいくつかのフォームが含まれるであろう。しかし、そのようなナンスの詳細は、トランスポートプロトコル上で、特に、トランスポートプロトコルが信頼できるか信頼できないかどうかに依存します。
We expect that protocols incorporating ECN with TFRC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [RFC3540]. 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.
私たちは、TFRCとECNを取り入れたプロトコルはまた、ECNナンス[RFC3540]を使用して送信側に受信機からのフィードバックを取り入れたいと思うことを期待しています。 ECNのナンスは、マークされたパケットの偶発的または悪質な隠蔽から送信者を保護ECNの変形です。また、このようなナンスの詳細は、トランスポートプロトコルに依存するであろう、と本書で扱われていません。
TFRC is currently used in Congestion Control ID 3 (CCID 3) [RFC4342] of the Datagram Congestion Control Protocol (DCCP) [RFC4340]. The Security Considerations section of RFC 4340 [RFC4340] (Section 18) discusses some of the security issues of DCCP, including sequence number validity checks to protect against hijacked connections. Section 18 of RFC 4340 also discusses mechanisms in DCCP to limit the potential impact of denial-of-service attacks.
TFRCは、現在データグラム輻輳制御プロトコル（DCCP）[RFC4340]の輻輳制御ID 3（CCID 3）[RFC4342]に使用されています。 RFC 4340 [RFC4340]（セクション18）のSecurity Considerations部は、ハイジャックの接続から保護するためのシーケンス番号の有効性チェックを含むDCCPのセキュリティ問題のいくつかを説明します。 RFC 4340のセクション18は、サービス拒否攻撃の潜在的な影響を制限するためにDCCPにメカニズムを説明します。
RFC 4342 specifies the use of TFRC in CCID 3. RFC 4342 includes extensive discussions of the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used with CCID 3, the receiver returns ECN Nonce information to the sender, to allow the sender to verify information sent by the receiver. When ECN is not used, Section 9 of RFC 4342 discusses how the sender could still use various techniques that might catch the receiver in an error in reporting congestion. However, as stated in RFC 4342, this is not as robust or non-intrusive as the verification provided by the ECN Nonce.
RFC 4342は、4342で、送信者が受信機によって送信された情報を検証するために使用できる機構の広範な議論を含むCCID 3 RFCにTFRCの使用を指定します。 ECNは、CCID 3で使用した場合、受信側は、送信側が受信側によって送信された情報を確認できるようにするために、送信者にECNノンス情報を返します。 ECNを使用しない場合は、RFC 4342のセクション9は、送信者がまだ混雑を報告するには、エラーで受信機をキャッチ可能性がある様々な技術を使用することができます方法について説明します。 RFC 4342に記載されているようしかし、これは、ECNのNonceが提供する検証ほど堅牢でまたは非侵入ではありません。
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 like to thank Dado Colussi, Gorry Fairhurst, Ladan Gharai, Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian McDonald, Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit Renker, Arjuna Sathiaseelan, Vladica Stanisic, Randall Stewart, Eduardo Urzaiz, Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier versions of this document, and to thank Mark Allman for his extensive feedback from using [RFC3448] to produce a working implementation.
私たちは、フィードバックと信頼性の高いマルチキャスト研究グループ、信頼性の高いマルチキャスト交通ワーキンググループ、およびエンドツーエンドの研究グループのメンバーを含む人々の広い範囲、と方程式ベースの輻輳制御に関する議論を確認したいと思います。我々はダドColussi、Gorry Fairhurst、ラダンGharai、ヴィムHeirman、エディー・コーラー、ケン・ロフグレン、マイク・ルビー、イアン・マクドナルド、ウラジミールMoltchanov、コリンパーキンス、ミシェルR.、ゲリット・Renker、アルジュナSathiaseelan、Vladica Stanisic、ランドール・スチュワートに感謝したいと思いますこのドキュメントの以前のバージョンについてのフィードバックのために、エドゥアルドUrzaiz、スサ温家宝、そしてウェンディ・リー（lhh@zsu.edu.cn）、および作業実施を生成するために、[RFC3448]を使用してからの彼の豊富なフィードバックのためのマーク・オールマンに感謝します。
Appendix A. Terminology
付録A.用語
This document uses the following terms. Timer variables (e.g., t_now, tld) are assumed to be in seconds, with a timer resolution of at least a millisecond.
このドキュメントでは、次の用語を使用しています。タイマ変数（例えば、t_now、TLD）は、少なくともミリ秒のタイマ分解能で、数秒であると仮定されます。
data-limited interval: An interval where the sender is data-limited (not sending as much as it is allowed to send) over the entire interval (Section 4.3).
データが制限された間隔：送信者は、全区間（4.3節）を介してデータが制限された（送信することが許可されてできるだけ多くを送信していない）される区間。
DF: Discount factor for a loss interval (Section 5.5).
DF：損失間隔（5.5節）のための割引率。
initial_rate: Allowed initial sending rate.
initial_rate：可初期送信レート。
last_counter: Greatest received value of the window counter (Section 6.3).
last_counter：ウィンドウ・カウンタ（セクション6.3）の最大の受信値。
n: Number of loss intervals.
N：損失間隔の数。
NDUPACK: Number of dupacks for inferring loss (constant) (Section 5.1).
NDUPACK：損失を推定するためのdupacksの数（定数）（5.1節）。
nofeedback timer: Sender-side timer (Section 4).
NOFEEDBACK時間：送信側の時間（第4章）。
p: Estimated Loss Event Rate.
P：推定損失イベントレート。
p_prev: Previous value of p (Section 6.1).
p_prev：Pの前の値（6.1節）。
q: Filter constant for RTT (constant) (Section 4.3).
Q：RTT（定数）（4.3節）のために一定のフィルター。
q2: Filter constant for long-term RTT (constant) (Section 4.6).
Q2：長期RTT（定数）のためのフィルタ定数（4.6節）。
R: Estimated path round-trip time.
R：推定パスのラウンドトリップ時間。
R_m: A specific estimate of the path round-trip time (Sections 4.3, 6).
R_M：パスのラウンドトリップ時間の特定の推定値（セクション4.3、6）。
R_sample: Measured path RTT (Section 4.3).
R_sample：測定パスRTT（4.3節）。
R_sqmean: Long-term estimate of the square root of the RTT (Section 4.6).
R_sqmean：RTT（4.6節）の平方根の長期見積もり。
recover_rate: Allowed rate for resuming after an idle period (Section 4.4).
recover_rate：アイドル期間（4.4節）の後に再開させるための許容レート。
recv_limit; Limit on sending rate computed from X_recv_set (Section 4.3).
recv_limit; X_recv_set（4.3節）から計算された割合を送るに制限します。
s: Nominal packet size in bytes.
S：バイト単位の公称パケットサイズ。
S: Sequence number.
S：シーケンス番号。
t_delay: Reported time delay between receipt of the last packet at the receiver and the generation of the feedback packet (Section 3.2.2).
t_delay：受信機における最後のパケットの受信及びフィードバックパケット（セクション3.2.2）の世代間の報告された時間遅延。
t_delta: Parameter for flexibility in send time (Section 8.3).
t_delta：送信時間の柔軟性のためのパラメータ（8.3節）。
t_gran: Scheduling timer granularity of the operating system (constant) (Section 8.3).
t_gran：オペレーティングシステム（定数）（8.3節）のスケジュールタイマーの粒度。
t_ipi: Inter-packet interval for sending packets (Section 4.6).
t_ipi：パケット（セクション4.6）を送信するためのインターパケット間隔。
t_mbi: Maximum RTO value of TCP (constant) (Section 4.3).
t_mbi：TCPの最大RTO値（定数）（4.3節）。
t_recvdata: Timestamp of the last data packet received (Section 3.2.2).
t_recvdata：最後のデータパケットのタイムスタンプは、（3.2.2）を受けました。
timer_limit: Limit on the sending rate from the expiration of the nofeedback timer (Section 4.4).
timer_limit：NOFEEDBACKタイマー（4.4節）の満了から送信レートの制限。
tld: Time Last Doubled (Section 4.2).
TLD：時間最後の倍増（4.2節）。
t_now: Current time (Section 4.3).
t_now：現在の時間（4.3節）。
t_RTO: Estimated RTO of TCP (Section 4.3).
t_RTO：TCPの推定RTO（4.3節）。
X: Allowed transmit rate, as limited by the receive rate.
X：許容送信レート、受信レートによって制限されます。
X_Bps: Calculated sending rate in bytes per second (Section 3.1).
X_Bps：計算が第二（3.1節）あたりのバイト数でレートを送ります。
X_pps: Calculated sending rate in packets per second (Section 3.1).
X_pps：秒（3.1節）あたりのパケットで送信レート計算。
X_inst: Instantaneous allowed transmit rate (Section 4.6).
X_inst：瞬時許容送信率（4.6節）。
X_recv: Estimated receive rate at the receiver (Section 3.2.2).
X_recv：受信機（3.2.2）での受信速度を推定しました。
X_recv_set: A small set of recent X_recv values (Section 4.3).
X_recv_set：最近X_recv値（4.3節）の小さなセット。
X_target: The target sending rate after the first loss event (Section 6.3.1).
X_target：最初の損失のイベント（6.3.1項）の後にレートを送信するターゲット。
W_init: TCP initial window (constant) (Section 4.2).
W_init：TCP初期ウィンドウ（定数）（4.2節）。
Appendix B. The Initial Value of the Nofeedback Timer
付録B. NOFEEDBACKタイマーの初期値
Why is the initial value of TFRC's nofeedback timer set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer, from [RFC2988]? There is not any particular reason why TFRC's nofeedback timer should have the same initial value as TCP's retransmit timer. TCP's retransmit timer is used not only to reduce the sending rate in response to congestion, but also to retransmit a packet that is assumed to have been dropped in the network. In contrast, TFRC's nofeedback timer is only used to reduce the allowed sending rate, not to trigger the sending of a new packet. As a result, there is no danger to the network for the initial value of TFRC's nofeedback timer to be smaller than the recommended initial value for TCP's retransmit timer.
なぜTFRCのNOFEEDBACKタイマーの初期値は、[RFC2988]から、TCPの再送信タイマーの代わりに3秒の推奨初期値で、2秒に設定されていますか？ TFRCのNOFEEDBACKタイマーは、TCPの再送信タイマーと同じ初期値を持たなければならない理由は、特定の理由がありません。 TCPの再送信タイマーは混雑に応じて送信レートを減らすために、だけでなく、ネットワークにドロップされているものとするパケットを再送するだけでなく、使用されています。これとは対照的に、TFRCのNOFEEDBACKタイマーは、許可され、送信レートを下げるために、新たなパケットの送信をトリガーするために使用されていません。その結果、TCPの再送信タイマーのために推奨される初期値よりも小さくなるようにTFRCのNOFEEDBACKタイマーの初期値のためのネットワークへの危険はありません。
Further, when the nofeedback timer has not yet expired, TFRC has a more slowly responding congestion control mechanism than TCP, and TFRC's use of the receive rate for limiting the sending rate is somewhat less precise than TCP's use of windows and ack-clocking, so the nofeedback timer is a particularly important safety mechanism for TFRC. For all of these reasons, it is perfectly reasonable for TFRC's nofeedback timer to have a smaller initial value than that of TCP's retransmit timer.
NOFEEDBACKタイマーが満了していないときまた、TFRCはTCPよりもゆっくり応答輻輳制御機構を有し、かつ、送信速度を制限するための受信率のTFRCの使用はそう、やや窓やACKクロッキングのTCPの使用よりもあまり正確ですNOFEEDBACKタイマーはTFRCのために特に重要な安全機構です。これらすべての理由から、それはTCPの再送信タイマーのそれよりも小さい初期値を持っているTFRCのNOFEEDBACKタイマーのための完全に合理的です。
Appendix C. Response to Idle or Data-Limited Periods
付録C.レスポンスはアイドルやデータが制限された周期に
Future work could explore alternate responses to using the receive rate during a data-limited period, and to responding to a loss event during a data-limited period.
今後の課題は、データが制限された期間中に受信レートを使用すると、データが制限された期間中に損失事象への対応に別の回答を探ることができます。
In particular, an Experimental RFC [RFC2861] specifies Congestion Window Validation (CWV) for TCP. For this discussion, we use the term "Standard TCP" to refer to the TCP congestion control mechanisms in [RFC2581] and [RFC2581bis]. [RFC2861] specifies a different response to idle or data-limited periods than those of Standard TCP. With CWV, the TCP sender halves the congestion window after each RTO during an idle period, down to the initial window. Similarly, with CWV the TCP sender halves the congestion window half-way down to the flight size after each RTO during a data-limited period.
特に、実験RFC [RFC2861]はTCP輻輳ウィンドウ検証（CWV）を指定します。この議論のために、我々は[RFC2581bis] [RFC2581]でTCPの輻輳制御機構を参照するために用語「標準TCP」を使用して。 [RFC2861]は空転する異なる応答またはStandard TCPよりもデータ制限期間を指定します。 CWVでは、TCPの送信者は、最初のウィンドウまで、アイドル期間中に各RTO後の輻輳ウィンドウを半分にします。同様に、CWVとTCP送信側はデータが制限された期間中に各RTOの後にハーフウェイダウン飛行サイズに輻輳ウィンドウを半分にします。
This document already specifies a TFRC response to idle periods that is similar to that of TCP with Congestion Window Validation. However, this document does not specify a TFRC response to data-limited periods similar to that of CWV. Adding such a mechanism to TFRC would require a one-line change to step (4) of Section 4.3. In particular, the sender's response to a feedback packet could be changed from:
この文書では、すでに輻輳ウィンドウ検証とTCPの場合と同様である期間をアイドル状態にTFRC応答を指定します。しかし、この文書はCWVのと同様のデータが制限された期間にTFRC応答が指定されていません。 TFRCこのような機構を追加すると、セクション4.3（4）ステップ一行の変更を必要とするであろう。具体的には、フィードバックパケットに送信者の応答がから変更することができます。
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
}
to:
と：
If (the entire interval covered by the feedback packet
was a data-limited interval) {
Multiply old entries in X_recv_set by 0.85;
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Multiply new value X_recv by 0.85.
}
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
In particular, if the receive rate from before a data-limited period is saved in X_recv_set, then the change in step (4) above would multiply that receive rate by 0.85 each time that a feedback packet is received and the above code is executed. As a result, after four successive round-trip times of data-limited intervals, the receive rate from before the data-limited period would be reduced by 0.85^4 = 0.52. Thus, this one-line change to step (4) of Section 4.3 would result in the allowed sending rate being halved for each four roundtrip times in which the sender was data-limited. Because of the nature of X_recv_set, this mechanism would never reduce the allowed sending rate below twice the most recent receive rate.
データが制限された期間がX_recv_setに保存される前から速度を受信した場合、特に、ステップの変化は、上記（4）つまり0.85によってフィードバックパケットが受信されると、上記のコードが実行されるたびに料金を受け取る乗算だろう。その結果、データが制限された時間間隔の4つの連続往復時間の後、データが制限された期間前からの受信率は0.85 ^ 4 = 0.52だけ減少されるであろう。したがって、4.3節（4）の工程をこの1行の変化は、送信者がデータ限定された各4往復回半減される許容送信率をもたらすであろう。そのためX_recv_setの性質上、このメカニズムは二回、最新の受信率以下許さ送信レートを下げることはありません。
We note that in the suggested code above, with CWV-style behavior in response to data-limited intervals, we keep
我々は、データが制限された時間間隔に応じたCWVスタイルの動作と上記提案のコードで、私たちは続けることに注意してください
recv_limit = 2 * max (X_recv_set);
recv_limit = 2 * MAX（X_recv_set）。
instead of using
代わりに使用したの
recv_limit = max (X_recv_set);
recv_limit = MAX（X_recv_set）。
following loss events in data-limited intervals. This relaxed response to a loss event is allowed because the CWV-style behavior itself limits rapid fluctuations in the sending rate during data-limited periods.
データが制限された時間間隔での損失事象以下。 CWV-スタイルの動作自体はデータが制限された期間中の送信レートの急激な変動を制限するので、損失イベントにこのリラックスした応答が許可されます。
C.1. Long Idle or Data-Limited Periods
C.1。ロングアイドルやデータが制限された期間
Table 1 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to long idle or data-limited periods. For the purposes of this section, we define a long period as a period of at least an RTO.
表1は、長いアイドルまたはデータ制限期間に応じて、標準TCP [RFC2581]、輻輳ウィンドウ検証[RFC2861]、標準TFRC [RFC3448]、および改訂TFRC（本書）とTCPの応答を要約します。本項の目的のために、私たちは、少なくともRTOの期間として長い期間を定義します。
Protocol Long idle periods Long data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Window -> initial. Window increases for
each cwnd of data.
TCP with CWV: Halve window Reduce window half way (not below initial cwnd). to used window.
CWVとTCP：（ない初期のcwnd以下）ウィンドウの半分の道を削減し、ウィンドウを半減させます。使用されるウィンドウへ。
Standard TFRC: Halve rate Rate limited to (not below 2 pkts/rtt). twice receive rate. One RTT after sending pkt, rate is limited by X_recv.
標準TFRC：（ない2つのパケット数/ RTT以下）に制限率Rateを半減。 2倍の速度を受けます。ワンRTT PKTを送信した後、レートはX_recvによって制限されています。
Revised TFRC: Halve rate Rate limited to twice (not below initial rate). max (current X_recv, receive rate before data-limited period).
改訂TFRC：に二回（ない初期レート以下）レート制限速度を半減させます。最大（現在X_recv、データが制限された期間前に受信速度）。
Table 1: Response to Long Idle or Data-Limited Periods
表1：ロングアイドルへの対応や、データが制限された期間
Standard TCP after long idle periods: For Standard TCP, [RFC2581] specifies that TCP SHOULD set the congestion window to no more than the initial window after an idle period of at least an RTO. (To be precise, RFC 2581 specifies that the TCP sender should set cwnd to the initial window if the sender has not sent data in an interval exceeding the retransmission timeout.)
長いアイドル期間の後に、標準的なTCP：標準TCPの場合、[RFC2581]はTCPが少なくともRTOのアイドル期間後の最初のウィンドウを超えないように輻輳ウィンドウを設定することを指定します。 （正確には、RFC 2581は、送信者が再送タイムアウトを超える間隔でデータを送信していない場合、TCP送信者が初期画面にcwndを設定する必要があることを指定します。）
Standard TCP after long data-limited periods: Standard TCP [RFC2581] does not reduce TCP's congestion window after a data-limited period, when the congestion window is not fully used. Standard TCP in [RFC2581] uses the FlightSize, the amount of outstanding data in the network, only in setting the slow-start threshold after a retransmit timeout. Standard TCP is not limited by TCP's ack-clocking mechanism during a data-limited period.
長いデータが制限された期間の後に標準TCP：輻輳ウィンドウが完全に使用されていない場合、標準TCP [RFC2581]は、データが制限された期間の後、TCPの輻輳ウィンドウを縮小しません。 [RFC2581]で標準TCPは、再送タイムアウト後のスロースタート閾値を設定する際に、FlightSize、ネットワーク内の未処理データの量を使用します。標準TCPは、データが制限された期間中にTCPのACKクロッキングメカニズムによって限定されるものではありません。
Standard TCP's lax response to a data-limited period is quite different from its stringent response to an idle period.
データが制限された期間に標準TCPのずさんな応答がアイドル期間にその緊縮応答とは全く異なります。
TCP with Congestion Window Validation (CWV) after long idle periods: As an experimental alternative, [RFC2861] specifies a more moderate response to an idle period than that of Standard TCP, where during an idle period the TCP sender halves cwnd after each RTO, down to the initial cwnd.
長いアイドル期間の後に輻輳ウィンドウ検証（CWV）とTCP：実験代替法として、[RFC2861]は、アイドル期間中にTCP送信者の半分が各RTO後にcwndを標準TCPのよりアイドル期間に、より穏やかな応答を特定し、初期のcwndまで。
TCP with Congestion Window Validation after long data-limited periods: As an experimental alternative, [RFC2861] specifies a more stringent response to a data-limited period than that of Standard TCP, where after each RTO seconds of a data-limited period, the congestion window is reduced half way down to the window that is actually used.
長いデータ制限期間後に輻輳ウィンドウ検証とTCP：実験代替法として、[RFC2861]は、標準TCPよりもデータ限られた期間に、より厳格な応答を指定し、データ・限られた期間の各RTO秒後、輻輳ウィンドウは、途中ダウン実際に使用されているウィンドウに減少しています。
The response of TCP with CWV to an idle period is similar to its response to a data-limited period. TCP with CWV is less restrictive than Standard TCP in response to an idle period, and more restrictive than Standard TCP in response to a data-limited period.
アイドル期間にCWVとTCPの応答は、データ限られた期間に対する応答と類似しています。 CWVとTCPはアイドル期間に応答して標準TCPよりも制限、およびデータ限られた期間に応じて、標準TCPよりも限定的です。
Standard TFRC after long idle periods: For Standard TFRC, [RFC3448] specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below two packets per RTT after idle periods. After an idle period, the first feedback packet received reports a receive rate of one packet per round-trip time, and this receive rate is used to limit the sending rate. Standard TFRC effectively slow-starts up from this allowed sending rate.
標準TFRC後に長いアイドル期間：標準TFRC、[RFC3448]のためには、許容送信レートがアイドル期間の各RTO秒後に半減することを指定します。許可される送信レートは、アイドル期間の後にRTTごとに2つのパケット以下に低減されていません。アイドル期間の後、第1のフィードバックパケットは、レポートを往復時間当たり1つのパケットの受信率を受信し、この受信速度は送信速度を制限するために使用されます。これは率を送信許さから標準TFRCは、効果的にアップスローを開始します。
Standard TFRC after long data-limited periods: [RFC3448] does not distinguish between data-limited and non-data-limited periods. As a consequence, the allowed sending rate is limited to at most twice the receive rate during and after a data-limited period. This is a very restrictive response, more restrictive than that of either Standard TCP or of TCP with CWV.
長いデータ制限期間の後、標準的なTFRC：[RFC3448]は、データ制限及び非データ制限期間を区別しません。その結果、許可され、送信レートは、せいぜい2倍のデータが制限された期間中と後に受信速度に制限されています。これはCWVと標準TCPまたはTCPのいずれかのそれよりも制限が非常に制限的応答です。
Revised TFRC after long idle periods: For Revised TFRC, this document specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below the initial sending rate as the result of an idle period. The first feedback packet received after the idle period reports a receive rate of one packet per round-trip time. However, the Revised TFRC sender does not use this receive rate for limiting the sending rate. Thus, Revised TFRC differs from Standard TFRC in the lower limit used in the reduction of the sending rate, and in the better response to the first feedback packet received after the idle period.
長いアイドル期間の後にTFRCを改訂：改訂TFRCについては、このドキュメントでは許可され、送信速度がアイドル期間の各RTO秒後に半減されることを指定します。許容送信レートは、アイドル期間の結果として、初期送信レートの下に低下しません。アイドル期間後に受信した第1のフィードバックパケットが往復時間あたり1つのパケットの受信率を報告します。しかし、改訂TFRCの送信者は、送信速度を制限するために、この受信レートを使用しません。したがって、改訂TFRCは、送信レートの減少、及びアイドル期間の後に受信された第1のフィードバックパケットに良好な応答に使用される下限で標準TFRCは異なります。
Revised TFRC after long data-limited periods: For Revised TFRC, this document distinguishes between data-limited and non-data-limited periods. As specified in Section 4.3, during a data-limited period Revised TFRC remembers the receive rate before the data-limited period began, and does not reduce the allowed sending rate below twice that receive rate. This is somewhat similar to the response of Standard TCP, and is quite different from the very restrictive response of Standard TFRC to a data-limited period. However, the response of Revised TFRC is not as conservative as the response of TCP with Congestion Window Validation, where the congestion window is gradually reduced down to the window actually used during a data-limited period.
TFRCは、長いデータが制限された期間の後に改訂：改訂TFRCについては、このドキュメントでは、データが制限されたと非データ限られた期間の間で区別します。データが制限された期間中に、4.3節で指定されているように改訂TFRCは、データが制限された期間が始まる前に、受信率を記憶し、受信速度を二倍以下で許可され、送信レートを低下させません。これは、標準TCPの応答に多少類似しており、データが制限された期間に標準TFRCの非常に限定的応答とは全く異なります。しかし、改訂TFRCの応答は、輻輳ウィンドウが次第に実際にデータが制限された期間中に使用されるウィンドウにまで低減される輻輳ウィンドウ検証とTCPの応答のように保守的ではありません。
We note that for current TCP implementations, the congestion window is generally not increased during a data-limited period (when the current congestion window is not being fully used) [MAF05] (Section 5.7). We note that there is no mechanism comparable to this in Revised TFRC.
我々は現在のTCPの実装のために、輻輳ウィンドウは、一般に、データ制限期間（現在の輻輳ウィンドウが完全に使用されていない場合）[MAF05]（セクション5.7）の間に増加されていないことに注意してください。私たちは、改訂TFRCでこれに匹敵する機構がないことに注意してください。
Recovery after idle or data-limited periods: When TCP reduces the congestion window after an idle or data-utilized period, TCP can set the slow-start threshold, ssthresh, to allow the TCP sender to slow-start back up towards its old sending rate when the idle or data-limited period is over. However, in TFRC, even when the TFRC sender's sending rate is restricted by twice the previous receive rate, this results in the sender being able to double the sending rate from one round-trip time to the next, if permitted by the throughput equation. Thus, TFRC does not need a mechanism such as TCP's setting of ssthresh to allow a slow-start after an idle or data-limited period.
アイドルやデータが制限された期間の後の回復：TCPがアイドル状態またはデータ利用期間後に輻輳ウィンドウを減少させた場合、TCPはTCPの送信者が送信バックアップ古い方のスロースタートできるようにするために、SSTHRESH、スロースタートしきい値を設定することができますアイドルやデータが制限された期間を超えている割合。しかし、TFRCに、TFRCの送信者の送信速度が二回前の受信率によって制限されている場合でも、これはスループット方程式によって許可されている場合、次の1往復時間から送信レートを倍増することができるという送信者になります。このように、TFRCは、アイドルやデータが制限された期間の後にスロースタートを可能にするために、このようなSSTHRESHのTCPの設定のようなメカニズムを必要としません。
For future work, one avenue to explore would be the addition of Congestion Window Validation mechanisms for TFRC's response to data-limited periods. Currently, following Standard TCP, during data-limited periods Revised TFRC does not limit its allowed sending rate as a function of the receive rate.
将来の仕事のために、探求する一つの道は、データが制限された期間にTFRCの応答のための輻輳ウィンドウ検証メカニズムの追加になります。現在、データが制限された期間中の標準TCPを、以下の改訂TFRCは受信レートの関数としての許可送信レートを制限しません。
C.2. Short Idle or Data-Limited Periods
C.2。短いアイドルやデータが制限された期間
Table 2 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to short idle or data-limited periods. For the purposes of this section, we define a short period as a period of less than an RTT.
表2は、短いアイドルまたはデータ制限期間に応じて、標準TCP [RFC2581]、輻輳ウィンドウ検証[RFC2861]、標準TFRC [RFC3448]、および改訂TFRC（本書）とTCPの応答を要約します。本項の目的のために、私たちはRTT未満の期間として短い期間を定義します。
Protocol Short idle periods Short data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
CWVとTCP：cwndをするまでのバーストを送信します。 cwndをするまでのバーストを送信します。
Standard TFRC: ? ?
標準TFRC：？ ？
Revised TFRC: Send a burst Send a burst (up to an RTT of (up to an RTT of unused send credits). unused send credits).
TFRC改訂：バースト（未使用の送信クレジットのRTTまでのRTT（）未使用の送信クレジットまで）バーストを送るSend。
Table 2: Response to Short Idle or Data-Limited Periods
表2：ショートアイドルへの対応や、データが制限された期間
Table 2 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a short idle or data-limited period. For a short idle or data-limited period, TCP is limited only by the size of the unused congestion window, and Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
TFRCは短いアイドルまたはデータ限られた期間に、標準TCPのとCWVとTCPと同様の応答を有する改訂表2に示します。短いアイドルまたはデータ・期間限定で、TCPだけの未使用の輻輳ウィンドウのサイズによって制限され、および改訂TFRCは（RTT分まで）、未使用の送信クレジットの数によってのみ制限されます。標準TFRCの場合は、[RFC3448]は、明示的に未使用の送信クレジットに対する動作を指定しませんでした。
C.3. Moderate Idle or Data-Limited Periods
C.3。穏健派アイドルやデータが制限された期間
Table 3 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to moderate idle or data-limited periods. For the purposes of this section, we define a moderate period as a period greater than an RTT, but less than an RTO.
表3は、標準的なTCP [RFC2581]、アイドルまたはデータ制限期間を緩和するために応じて輻輳ウィンドウ検証[RFC2861]、標準TFRC [RFC3448]、および改訂TFRC（本書）とTCPの応答を要約します。本項の目的のために、私たちはRTTよりも大きいが、RTO未満の期間として、適度な期間を定義します。
Protocol Moderate idle periods Moderate data-limited periods
------------- --------------------- -------------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
CWVとTCP：cwndをするまでのバーストを送信します。 cwndをするまでのバーストを送信します。
Standard TFRC: ? Limited by X_recv.
標準TFRC：？ X_recvによって制限されます。
Revised TFRC: Send a burst Send a burst (up to an RTT of (up to an RTT of unused send credits). unused send credits).
TFRC改訂：バースト（未使用の送信クレジットのRTTまでのRTT（）未使用の送信クレジットまで）バーストを送るSend。
Table 3: Response to Moderate Idle or Data-Limited Periods
表3：アイドルまたはData-限定期間を緩和するためにレスポンス
Table 3 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a moderate idle or data-limited period. For a moderate idle or data-limited period, TCP is limited only by the size of the unused congestion window. For a moderate idle period, Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For a moderate data-limited period, Standard TFRC would be limited by X_recv from the most recent feedback packet. In contrast, Revised TFRC is not limited by the receive rate from data-limited periods that cover an entire feedback period of a round-trip time. For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
TFRCは適度アイドルまたはデータ限られた期間に、標準TCPのとCWVとTCPと同様の応答を有する改訂表3に示します。適度なアイドルやデータ・期間限定で、TCPだけの未使用の輻輳ウィンドウのサイズによって制限されます。適度なアイドル期間について、改訂TFRCは（RTT分まで）、未使用の送信クレジットの数によって制限されます。適度なデータが制限された期間について、標準TFRCは、最新のフィードバックパケットからX_recvによって制限されるだろう。対照的に、改訂されたTFRCは、ラウンドトリップ時間の全体フィードバック期間をカバーするデータ制限期間からの受信速度によって限定されるものではありません。標準TFRCの場合は、[RFC3448]は、明示的に未使用の送信クレジットに対する動作を指定しませんでした。
C.4. Losses During Data-Limited Periods
C.4。データが制限された期間中の損失
This section discusses the response to a loss during a data-limited period.
このセクションでは、データが制限された期間中の損失への応答について説明します。
Protocol Response to a loss during a data-limited period
------------- -----------------------------------------------
Standard TCP: Set ssthresh, cwnd to FlightSize/2.
TCP with CWV: Same as Standard TCP.
CWVとTCP：標準のTCPと同じ。
Standard TFRC: Calculate X_Bps, send at most 2*X_recv.
標準TFRC：最大2 * X_recvを送って、X_Bpsを計算します。
Revised TFRC: Calculate X_Bps, send at most recv_limit. In addition, modify X_recv_set.
改訂TFRC：最もrecv_limitで送る、X_Bpsを計算します。また、X_recv_setを変更します。
Table 4: Response to a Loss during a Data-Limited Period
表4：データが制限された期間中の損失への対応
In TCP [RFC2581], the response to a loss during a data-limited period is the same as the response to a loss at any other time in TCP. This response is to set the congestion window to half of the FlightSize, where the FlightSize is the actual amount of unacknowledged data. Thus, after a loss during a data-limited period, the TCP sender must halve its allowed sending rate, as it normally does in response to a loss.
TCP [RFC2581]に、データ制限期間中に損失に対する応答は、TCPの任意の他の時間での損失に対する応答と同じです。この応答はFlightSizeは未確認データの実際の量であるFlightSize、の半分に輻輳ウィンドウを設定することです。それは通常の損失に反応しないようこのように、データが制限された期間中の損失の後、TCPの送信者は、その許可の送信率を半減させる必要があります。
In Standard TFRC, the response to a loss during a data-limited period is also the same as the response to a loss at any other time in Standard TFRC. The sending rate is limited by X_Bps, from the throughput equation, and the sending rate is also limited by twice X_recv, the most recent receive rate. As a result, after a loss in a data-limited period, the sender can at most double its sending rate to twice X_recv, even if the throughput equation X_Bps would allow a sending rate much higher than that.
標準TFRCでは、データ制限期間中の損失に応答は、標準TFRCの任意の他の時間での損失に対する応答と同じです。送信レートは、スループットの式から、X_Bpsによって制限され、送信速度も二回X_recv、最新の受信速度によって制限されます。その結果、データが制限された期間の損失の後、送信者は、せいぜい二重の送信レートは二回X_recvは、スループット方程式X_Bpsはそれよりもはるかに高い送信レートを可能にすることができる場合であっても。
In Revised TFRC, there have been changes to the use of the receive rate X_recv during data-limited intervals; the sender is limited to sending at most recv_limit, where the sender can remember the receive rate X_recv from just before the data-limited period. This allows the sender to more than double its sending rate during data-limited periods, up to the receive rate from before the data-limited period (if allowed by the throughput equation as given in X_Bps). This is similar to Standard TCP's practice of not reducing the window during data-limited periods (in the absence of loss).
改訂TFRCでは、データが制限された時間間隔中に受信率X_recvの使用に変更がありました。送信者は送信者は、単にデータが制限された期間前からの受信率X_recvを思い出すことができる最もrecv_limit、で送信することに限定されています。これは、（X_Bpsで与えられるスループット方程式によって許可されている場合）データ制限期間前からの受信レートまで、データが制限された期間中にその送信レートを倍以上に送信者を可能にします。これは、（損失の不存在下で）データが制限された期間中のウィンドウを削減しない標準的なTCPの練習に似ています。
As with Standard TFRC, during a data-limited period the Revised TFRC sender is sending less than is allowed by the throughput equation X_Bps. After the loss event, the sender still might not want to be sending as much as allowed by the recalculated value of X_Bps that takes into account the new loss event. Revised TFRC adds an additional mechanism to gradually limit the sender's sending rate after losses during data-limited periods. Unlike TCP's response of setting cwnd to half the FlightSize, this additional mechanism in Revised TFRC uses TFRC's practice of using slowly-responding changes for both increases and decreases in the allowed sending rate.
標準TFRCと同様に、データが制限された期間中に改訂TFRC送信者は、スループット方程式X_Bpsによって許可されているよりも少ない送信されます。損失イベントの後、送信者はまだ考慮に入れ、新たな損失事象を取るX_Bpsの再計算値で許可されたと同じくらいを送信したくない場合があります。改訂TFRCは徐々にデータが制限された期間中の損失の後に、送信者の送信速度を制限するために追加のメカニズムが追加されます。半分FlightSizeへのcwndを設定するTCPの応答とは異なり、改訂TFRCで、この追加のメカニズムが許可され、送信率の増加と減少の両方のためにゆっくりと応答の変化を使用してのTFRCの練習を使用しています。
This is done in Revised TFRC (in step (4) of Section 4.3) by decreasing the entry in X_recv_set after a loss in a data-limited interval, and by allowing the sender to send at most max (X_recv_set), instead of at most twice max (X_recv_set), in the immediate round-trip time following the reported loss. Thus, the 'price' for allowing the sender to send more than twice the most immediately reported value of X_recv during a data-limited interval is the introduction of an additional mechanism to reduce this allowed sending rate following losses in data-limited periods.
これは、データ・限られた期間での損失の後X_recv_setのエントリを減少させることにより、送信者は最大max（X_recv_set）で送信できるようにすることにより（ステップ（4）4.3節の）改訂TFRCで行われ、代わりに高々れます二度MAX（X_recv_set）、報告された損失以下の即時往復時間インチこのように、送信側はデータが制限された期間中にX_recvの2倍以上、ほとんどすぐに報告された値を送信することを可能にするための「価格」は、これはデータが制限された期間の損失、次の率を送信許可軽減するために追加のメカニズムの導入です。
In TFRC's response to a loss in a data-limited interval, we have considered the following examples.
データが制限された区間の損失にTFRCの応答では、次の例を検討しています。
Example 1, Losses *after* a Data-Limited Period: This example shows that losses after a data-limited period has ended are addressed by the throughput equation X_Bps.
例1、損失は、データ期間限定*後*：この例では、データが制限された期間が終了した後に損失がスループット方程式X_Bpsによって対処されることを示しています。
-------------------------------------------------------------------
Stage 1: Not data-limited.
Sending 100 packets per round-trip time (PPR).
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Not data-limited.
Sending 100 PPR again, as allowed by X_Bps.
A packet loss in the first RTT of Stage 3.
X_Bps is updated,
Response of Revised TFRC: a slight reduction in the allowed sending
rate, depending on the number of packets since the last loss event.
-------------------------------------------------------------------
Table 5: Example 1, Losses after a Data-Limited Period
表5：実施例1、データ・期間限定後の損失
For example 1, when there is a packet loss in the first RTT of Stage 3, this will be reflected in a modified value of X_Bps, and future loss events would result in future reductions of the throughput equation X_Bps. In particular, following TFRC's standard use of the throughput equation [FHPW00] (Section A.2), the allowed TFRC sending rate would be halved after something like five successive round-trip times with loss.
ステージ3の最初のRTTのパケット損失がある場合、実施例1については、これはX_Bpsの修正値に反映され、将来の損失事象は、スループット方程式X_Bpsの将来の削減をもたらします。特に、スループット方程式[FHPW00]（セクションA.2）のTFRCの標準的な使用後、許可TFRC送信レートは、損失の5連続往復時間のようなものの後に半減されるだろう。
Example 2, a Mildly Data-Limited Sender: This example considers losses in a data-limited period when, during the data-limited period, the sender is sending *almost* as much as it is allowed to send.
例2、軽度のデータが制限された送信者：この例では、データが制限された期間中に、送信者は*ほとんど*送信することが許可されると多くを送信していますが、データが制限された期間の損失を考慮します。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 99 PPR.
A packet loss in Stage 2.
Response of Revised TFRC: a slight reduction in the allowed sending
rate, down to 85 PPR or less, depending on the number of packets
since the last loss event.
-------------------------------------------------------------------
Table 6: Example 2, a Mildly Data-Limited Sender
表6：実施例2、軽度データが制限された送信者
Consider a Revised TFRC connection where the sender has been sending a hundred PPR and then enters a data-limited period of sending only 99 PPR because of data limitations from the application. (That is, at every instance of time during the data-limited period, the sender could have sent one more packet.) If there are losses in the data-limited period, the allowed sending rate is reduced to min(X_Bps, recv_limit), where both the throughput equation X_Bps and the limit recv_limit force a slight reduction in the allowed sending rate.
送信者が百PPRを送信して、ため、アプリケーションからのデータの制限の唯一の99 PPRの送信データが制限された期間に入るされた改訂TFRC接続を考えてみましょう。 （つまり、データが制限された期間中の時間のすべてのインスタンスで、送信者は、1つの以上のパケットを送信した可能性があります。）データが制限された期間の損失がある場合は、許可送信レートが分に短縮された（X_Bps、recv_limit）ここで、両方のスループット方程式X_Bpsと許容送信率のわずかな減少を強制recv_limitリミット。
Example 3, a Single Packet Loss during a Data-Limited Period. This example considers the loss of a single packet during a data-limited period, after the sender has not sent a packet for two RTTs.
例3、データ、限られた期間中にシングルパケット損失。送信者が2つのRTTのためのパケットを送信していない後にこの例では、データが制限された期間中に単一のパケットの損失を考慮しています。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Data-limited, sending no data for two RTTs.
Stage 4: Data-limited, sending one packet, which is ECN-marked.
Response of Revised TFRC: a reduction in the allowed sending
rate, down to 50 PPR or less. For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved.
-------------------------------------------------------------------
Table 7: Example 3, a Single Packet Loss
表7：実施例3、シングルパケット損失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only ten PPR, and then does not send any packets for two RTTs, and then sends a single packet, which is ECN-marked. In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period
送信者が百PPRを送信した後、わずか10 PPRの送信データが制限された期間に入り、その後、2つのRTTのための任意のパケットを送信しません、その後、ECNである単一のパケットを、送信された改訂TFRC接続を考えてみましょう-マークされた。この場合、改訂TFRCと、データが制限された期間中の各損失事象のために、送信側はデータが制限された期間前からその「思い出し」X_recvを半減します
Example 4, Losses after Increasing the Sending Rate during a Data-Limited Period. This example considers losses when the sender significantly increases its sending rate during a data-limited period.
例4、データ、限られた期間中に、送信速度を増加させた後の損失。この例では、送信者が著しくデータ限られた期間の間、その送信レートを増加損失を考慮する。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 1 PPR.
Stage 3: Data-limited, sending 20 PPR.
Several packets are lost in each RTT of Stage 3.
During Stage 3, the sender would *like* to send 20 PPR.
Response of Revised TFRC: For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved, and the most
recent X_recv is reduced by 0.85.
-------------------------------------------------------------------
Table 8: Example 4, Losses after Increasing the Sending Rate
表8：実施例4、送信レートを増加させた後損失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only one PPR, and then, while still data-limited, increases its sending rate to twenty PPR, where it experiences a number of successive loss events.
まだデータが制限されたが、それは経験20 PPRにその送信レートを増加させながら、その後、送信者が百PPRを送信された改訂TFRC接続を考慮して、1つだけPPRを送信するデータが制限された期間に入り、連続した損失イベントの数。
In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period, and the most recent X_recv is reduced by 0.85.
この場合、改訂TFRCと、データが制限された期間中の各損失事象のために、送信者は、そのデータが制限された期間前からX_recvを「思い出し」、そして最新のX_recvが0.85減少さ半分。
C.5. Other Patterns
C.5。他のパターン
Other possible patterns to consider in evaluating Revised TFRC would be to compare the behavior of TCP, Standard TFRC, and Revised TFRC for connections with alternating busy and idle periods, alternating idle and data-limited periods, or with idle or data-limited periods during slow-start.
改訂TFRCを評価する際に考慮すべき他の可能なパターンが中に、忙しいとアイドル期間を交互にアイドルとデータが制限された期間を交互に、またはアイドルやデータが制限された期間とのとの接続のためにTCP、標準TFRC、および改訂TFRCの動作を比較することであろうスロースタート。
C.6. Evaluating TFRC's Response to Idle Periods
C.6。期間をIdleにTFRCの応答を評価します
In this section we focus on evaluating Revised TFRC's response to idle or data-limited periods.
このセクションでは、アイドル状態に改訂TFRCのレスポンスやデータが制限された期間の評価に焦点を当てます。
One drawback to Standard TFRC's strict response to idle or data-limited periods is that it could be seen as encouraging applications to pad their sending rate during idle or data-limited periods, by sending dummy data when there was no other data to send. Because Revised TFRC has a less strict response to data-limited periods than that of Standard TFRC, Revised TFRC also could be seen as giving applications less of an incentive to pad their sending rates during data-limited periods. Work in progress, such as Faster Restart [KFS07], can also decrease an application's incentive to pad its sending rate, by allowing faster start-up after idle periods. Further research would be useful to understand, in more detail, the interaction between TCP or TFRC's congestion control mechanisms, and an application's incentive to pad its sending rate during idle or data-limited periods.
アイドルやデータが制限された期間にする標準TFRCの厳格な応答の一つの欠点は、それが送るべき他のデータがなかったとき、ダミーデータを送信することにより、アイドルやデータが制限された期間中のパッドに自分の送信レートを、アプリケーションを奨励として見ることができるということです。改訂TFRC標準TFRCよりもデータ制限期間にあまり厳密応答を有しているため、改訂TFRCはまた、それらの送信レートは、データ制限期間中パッドにインセンティブの少ないアプリケーションを与えるように見ることができます。そのような再起動は[KFS07]、またアイドル期間の後に高速起動を可能にすることにより、パッドへの送信レートを、アプリケーションのインセンティブを減らすことができます高速化として、進行中の作業。さらなる研究は、アイドルまたはデータ制限期間中にその送信レート、より詳細には、パッドにTCPまたはTFRCの輻輳制御機構、及びアプリケーションのインセンティブとの間の相互作用を理解するのに有用であろう。
TCP Congestion Window Validation, described in Appendix C.1 above, is an Experimental standard specifying that the TCP sender slowly reduces the congestion window during an idle or data-limited period [RFC2861]. While TFRC and Revised TFRC's responses to idle periods are roughly similar to those of TCP with Congestion Window Validation, Revised TFRC's response to data-limited periods is less conservative than those of TCP with Congestion Window Validation (and Standard TFRC's response to data-limited periods was considerably *more* conservative than those of Congestion Window Validation). Future work could include modifications to this document so that the response of Revised TFRC to a data-limited period includes a slow reduction of the allowed sending rate; Section C specifies a possible mechanism for this. Such a modification would be particularly compelling if Congestion Window Validation became a Proposed Standard in the IETF for TCP.
上記付録C.1に記載のTCP輻輳ウィンドウ検証は、TCP送信者がゆっくりとアイドルまたはデータ制限期間[RFC2861]の間に輻輳ウィンドウを減少させることを指定する実験標準です。 TFRCと期間アイドルに修正TFRCの応答は、輻輳ウィンドウ検証とTCPのものとほぼ同じであるが、データが制限された期間に修正TFRCの応答は、輻輳ウィンドウ検証とTCPのものよりも保守的である（データ制限期間に標準TFRCの応答）輻輳ウィンドウ検証のものより保守的な*かなり*以上でした。データが制限された期間に改訂TFRCの応答が許可され、送信速度の遅い減少が含まれるように、今後の作業はこのドキュメントへの変更を含めることができます。セクションCは、このための可能なメカニズムを指定します。輻輳ウィンドウ検証は、TCPのためにIETFで標準化提案になった場合、このような変更は、特に魅力的だろう。
References
リファレンス
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
Informative References
参考文献
[BRS99] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated Congestion Management Architecture for Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, September 1999.
[BRS99]バラクリシュナン、H.、ラーフル、H.、およびSeshan、S.、 "インターネットホストのための統合された輻輳管理アーキテクチャ、" PROC。 ACM SIGCOMM、ケンブリッジ、MA、1999年9月。
[CCID-4] Floyd, S., and E. Kohler, "Profile for DCCP Congestion Control ID 4: the Small-Packet Variant of TFRC Congestion Control", Work in Progress, February 2008.
[CCID-4]フロイド、S.、およびE.コーラー、 "DCCP輻輳制御ID 4のプロファイル：TFRC輻輳制御の小パケット変異体"、進歩、2008年2月に働いています。
[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", August 2000, Proc SIGCOMM 2000.
【FHPW00] S.フロイド、M.ハンドレー、J. Padhye、およびJ.ウィトマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御"、2000年8月、PROCのSIGCOMM 2000。
[FHPW00a] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications: the Extended Version", ICSI tech report TR-00-03, March 2000.
[FHPW00a] S.フロイド、M.ハンドリー、J. Padhye、およびJ.ウィトマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御：拡張版"、ICSI技術レポートTR-00-03、2000年3月。
[FF99] Floyd, S., and K. Fall, Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking, August 1999.
[FF99]フロイド、S.、およびK.秋、インターネットにおけるエンドツーエンドの輻輳制御の利用促進、ネットワーキング、1999年8月にIEEE / ACM取引。
[KFS07] E. Kohler, S. Floyd, and A. Sathiaseelan, "Faster Restart for TCP Friendly Rate Control (TFRC)", Work in Progress, November 2007.
[KFS07] E.コーラー、S.フロイド、およびA. Sathiaseelan、 "TCPフレンドリーレート制御（TFRC）のためのより高速な再起動"、進歩、2007年11月に作業。
[MAF05] A. Medina, M. Allman, and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communications Review, April 2005.
[MAF05] A.メディナ、M.オールマン、およびS.フロイド、「インターネットにおけるトランスポートプロトコルの進化を測定する」、ACMコンピュータコミュニケーションレビュー、2005年4月。
[PFTK98] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
【PFTK98] Padhye、J.及びFiroiu、V.とTowsley、D.および黒瀬、J.、 "モデルTCPスループット：簡単なモデルとその実証的検証"、PROCのACM SIGCOMM 1998。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2581bis] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", Work in Progress, April 2008.
[RFC2581bis]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、進歩、2008年4月の作業。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]ハンドレー、M.、Padhye、J.、およびS.フロイド、 "TCP輻輳ウィンドウ検証"、RFC 2861、2000年6月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC3448Err] RFC 3448 Errata, <http://www.rfc-editor.org/errata_search.php?rfc=3448>.
【RFC3448Err] RFC 3448エラッタ、<http://www.rfc-editor.org/errata_search.php?rfc=3448>。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：TCPフレンドリーレート制御（TFRC）"、RFC 4342、2006年3月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]フロイド、S.、およびE.コーラー、 "TCPフレンドリーレート制御（TFRC）：小パケット（SP）バリアント"、RFC 4828、2007年4月。
[W00] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000, <http://www.icir.org/tfrc/>.
[W00]ウィドマー、J.、 "式ベースの輻輳制御"、ディプロマ論文、マンハイム大学、2000年2月、<http://www.icir.org/tfrc/>。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI 1947 Center St, Suite 600 Berkeley, CA 94708 EMail: floyd@icir.org
サリーフロイドICSI 1947センターセント、スイート600バークレー、CA 94708 Eメール：floyd@icir.org
Mark Handley, Department of Computer Science University College London Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk
マーク・ハンドリー、コンピュータサイエンス大学・カレッジロンドンガウアーストリートロンドンWC1E 6BT英国の部門電子メール：M.Handley@cs.ucl.ac.uk
Jitendra Padhye Microsoft Research EMail: padhye@microsoft.com
Jitendra PadhyeマイクロソフトリサーチEメール：padhye@microsoft.com
Joerg Widmer DoCoMo Euro-Labs Landsberger Strasse 312 80687 Munich Germany EMail: widmer@acm.org
イェルクウィドマードコモユーロ-Labsのランデスシュトラーセ312 80687ミュンヘンドイツEメール：widmer@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。