[要約] RFC 5348は、TCP Friendly Rate Control（TFRC）プロトコルの仕様を定めたものであり、インターネット上でのトラフィック制御を目的としています。TFRCは、ネットワークの適切な共有リソースの使用を確保するために、データ転送速度を制御するためのアルゴリズムを提供します。
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
TCPフレンドリーレートコントロール（TFRC）：プロトコル仕様
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は、インターネット環境で動作し、TCPトラフィックと競合するユニキャストフロー向けに設計された輻輳制御メカニズムです[FHPW00]。完全なプロトコルを指定する代わりに、このドキュメントは、DCCP（Datagram混雑制御プロトコル）[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フローと帯域幅を競うときに合理的に公平になるように設計されています。この流れは、同じ条件下でTCPフローの送信率の2倍になる場合、「合理的に公正」と呼ばれます。ただし、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よりも遅く応答することです。したがって、TFRCは、アプリケーションにスムーズなスループットの要件がある場合にのみ使用する必要があります。特に、単一のパケットドロップに応答した送信率のTCPの半分を回避することを回避する必要があります。できるだけ短い時間でできるだけ多くのデータを転送する必要があるアプリケーションの場合、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は、固定セグメントサイズを使用するアプリケーションで最高のパフォーマンスを実現するように設計されており、混雑に応じて1秒あたりのパケットの送信率を変化させます。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（Small-Packet TFRC）は、1秒あたりのパケットに固定送信率を持つアプリケーションの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.
このドキュメントはRFC3448を廃止します。トランスポートプロトコルDCCP（データグラム混雑制御プロトコル）[RFC4340]で、混雑制御IDプロファイルCCID-3 [RFC4342]およびCCID-4 [CCID-4]はどちらもRFC 34484848484844848444848 [CCID-4]を指定しています。。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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の送信率を大まかに損失イベント率、往復時間、およびセグメントサイズの関数として説明しています。損失イベントを、データのウィンドウから1つ以上の紛失またはマークされたパケットとして定義します。マークされたパケットは、明示的な輻輳通知（ECN）[RFC3168]からの混雑の表示を指します。
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のスループット方程式に供給され、結果の送信率は最大2倍の受信レートに制限され、許可された送信率xが得られます。
o The sender then adjusts its transmit rate to match the allowed transmit rate X.
o 次に、送信者は送信率を調整して、許可された送信速度xに一致します。
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の再送信タイムアウト動作を反映する必要があることに注意してください。また、損失イベント率パラメーターに関するスループット方程式に暗示される仮定は、損失率または損失イベント率が実際にどのように測定されるかと合理的な一致でなければならないことに注意してください。この一致は、以下に示すスループット方程式および損失率の測定メカニズムに最適ではありませんが、実際には、仮定は十分に近いことが判明しています。
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]のReno TCPのスループット方程式のわずかに単純化されたバージョンです。理想的には、選択的承認（SACK）TCPに基づいたスループット方程式を好むが、サックTCPのスループット方程式をまだ導き出しておらず、シミュレーションと実験は2つの方程式間の違いが比較的マイナーであることを示唆している[FF99]（FF99]（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.) s is the segment size in bytes (excluding IP and transport protocol headers).
X_BPSは、TCPの平均送信率で1秒あたりのバイトです。（X_BPSはRFC 3448のX_CALCと同じです。）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]で推奨される最低1秒に一致するように、T_RTOを最大（4*r、1秒）に設定することもできます。
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]は、b = 1とのTCPスループット方程式と一致して、遅延承認に直面しても、RTTごとに1つのセグメントごとに混雑回避中に混雑窓を増やすことを推奨しています。スロースタート中のうっ血ウィンドウは、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のスループット方程式は、1秒あたりのバイトでの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、1秒あたりのパケットの送信レートで、
X_pps = X_Bps / s .
x_pps = x_bps / s。
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実装によって測定または計算する必要があります。Sの測定値はセクション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 パケットがいつ送信されるかを示すタイムスタンプ。TS_Iによって、シーケンス番号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.
上記のように、送信者が往復時間の4分の1を増やす粗粒の「タイムスタンプ」を送信する場合、送信者は往復時間の現在の見積もりを送信する必要はありません。
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.
o 損失イベント率のレシーバーの現在の推定p。
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.
o NoFeedbackタイマーが期限切れになったときの送信者の動作。
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送信者は、スループット方程式のセグメントサイズsを、最大受信レートの設定、最小および初期送信レートの設定、およびnofeedbackタイマーの設定で使用します。TFRCレシーバーは、最初の損失イベントの後に損失履歴を初期化する際に、平均セグメントサイズsを使用する場合があります。セクション6.3.1で指定されているように、TFRCレシーバーが送信者が使用するセグメントサイズsを知らない場合、TFRCレシーバーは代わりに損失履歴を初期化する際に1秒あたりのパケットの到着率を使用できます。
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送信者は、平均セグメントサイズを計算するか、セグメントサイズの最大セグメントサイズを使用できます。
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.
アプリケーションの2番目のクラスについては、TFRC-SP [RFC4828]に関する別のドキュメントで個別に説明されています。このセクションの残りの部分では、送信者がセグメントサイズを推定できると想定し、1秒あたりのパケットの数を調整することにより、輻輳制御が実行されると想定しています。
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の初期値（許可された送信率は1秒あたり）とTLD（スロースタート中、秒単位で倍増した時間）は、以下のように設定されるまで定義されていません。送信者がまだ往復サンプルがない場合にデータを送信する準備ができている場合、xの値は毎秒sバイトに設定され、セグメントサイズsの場合、NoFeedbackタイマーは2秒後に期限切れに設定され、TLDはTLDに設定されます。0に設定されています（または-1に、どちらも大丈夫です）。最初のラウンドトリップ時間測定（例：最初のフィードバックパケットまたは接続セットアップからのSyn Exchangeの後、または以前の接続[RFC2140]からSyn Exchangeの後）を受信すると、TLDは現在の時刻に設定され、許可された送信率は設定されます。xは、[rfc3390]に基づいてw_initの場合、w_init/rとして指定されたinitial_rateに設定されています。
initial_rate = W_init/R; W_init = min(4*MSS, max(2*MSS, 4380)).
initial_rate = w_init/r;w_init = min（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.
コンピューティングW_INITでは、最大セグメントサイズ（MSS）を使用する代わりに、TFRC送信者は、Xが初期化されたときに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].
付録Bは、[RFC2988]からのTCPの再送信タイマーの3秒の推奨初期値の代わりに、TFRCのNoFeedbackタイマーの初期値が2秒に設定される理由を説明しています。
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、および現在の往復時間Rの推定値を維持することを認識しています。送信者は、X_RECV_SETを最近のX_RECV値の小さなセットとして維持します（通常2つの値のみ）。
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.) When a feedback packet is received by the sender at time t_now, the current time in seconds, the following actions MUST be performed.
初期化：X_RECV_SETは、最初に初期化されて、値の無限で単一のアイテムが含まれています。（実装固有の問題として、X_RECV_SETは、たとえば、簡単に表現できる最大の整数ではなく、無限ではなく多数に初期化される場合があります。秒、次のアクションを実行する必要があります。
1) Calculate a new round-trip sample:
1) 新しい往復サンプルを計算します。
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)
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) nofeedbackタイマーをリセットして、rtoの数秒後に期限切れになります。
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.
x_recv_set（）を最大化：x_recvをx_recv_setに追加します。X_RECV_SETから初期値のInfinityを削除します。現在の時刻に最大のアイテムのタイムスタンプを設定します。他のすべてのアイテムを削除します。
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をx_recv_setに追加します。X_RECV_SET値から2回以上の往復時間を削除します。
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は、間隔がデータ制限間隔であるかどうかを判断する際の送信者の実装の問題について説明します。「データ制限間隔」という用語は、ステップ（4）の最初の「if」条件で使用されます。これにより、送信者は、データ制限から受信率を報告するフィードバックパケットの結果として送信率を下げることができなくなります。期間。
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.
フィードバックパケットが受信レート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および最初のフィードバックパケット：x_recv_setは単一のアイテムで初期化されているため、値は無限で、recv_limitは接続の最初の2つの往復時間の無限に設定されます。その結果、送信率は、その期間中の受信率によって制限されません。これにより、送信率が最初のフィードバックパケットから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で詳しく説明します。一般に、受信者は往復時間ごとにフィードバックパケットを1回送信します。したがって、通常、送信者は、以前のフィードバックパケットから現在のフィードバックパケットでカバーされている期間を正確に決定できます。ただし、前のフィードバックパケットが紛失した場合、またはレシーバーが紛失または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_BPを更新し、許可された送信レートXは常に常にですX_BPSによって制限されています。ただし、データ制限間隔では、実際の送信率が通常X_BPSを下回る場合、送信率はX_RECV_SETから派生したRECV_LIMITによって制限されます。送信者がデータ制限されており、おそらく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.
送信者がスロースタート中にデータ制限されている場合、または接続がパス帯域幅によって制限されている場合、送信者は必ずしも各ラウンドトリップ時間の送信率を2倍にすることができないことに注意してください。送信者の送信率は、過去の受信率の最大2倍、または最大の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の場合、送信者が64秒ごとに少なくとも1つのパケットを送信できるようにします。
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を使用します。NoFeedbackタイマーが設定されて以来、TFRC送信者がアイドル状態になっている場合、許可された送信率はRecover_rateより下では低下しません。このドキュメントでは、Recover_rateはinitial_rate（セクション4.2で指定）に設定されます。この仕様の将来の更新は、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.
NoFeedbackタイマーが少なくとも1つのRTT測定を行ったときにNoFeedbackタイマーが期限切れになった場合、下の擬似コードで説明されているようにX_RECV_SETを変更することにより、送信率が低下します（アイテム（2）を含む）。一般的なケースでは、送信率は最大でX_RECVに限定されています。X_RECV_SETの変更は送信率を制限しますが、フィードバックメッセージが損失を報告しない場合、送信者が各RTTの送信率を2倍にすることを可能にします。
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という用語は、64秒ごとにバックオフを1つのパケットに制限します。
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) nofeedbackタイマーを再起動して、最大（4*r、2*s/x）秒後に期限切れになります。
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送信者による許可された送信率の削減は、IDLE期間の各RTOの後のTCPの削減、CWNDに類似しています。
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）が増加すると、送信者が送信速度を下げることをお勧めします。これを行うために、送信者はRTTの平方根の長期的な推定であるR_SQMeanを維持し、RTTの最新サンプルであるR_Sampleの平方根の平方根が長期的に異なる方法に応じて送信率を変更します見積もり。長期推定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と同様に設定する必要があります。ROUND-TRIP TIME STAMATIAM Rで使用される定数は、Q2のデフォルトとして0.9の値です。
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は1回のバーストで往復時間のパケットに送信する場合がありますが、それ以上ではありません。たとえば、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回の往復時間のパケット分が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、...、t_iを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.
未使用の送信時間の送信クレジットを過去1秒にわたって蓄積することが許可されているTFRC送信者の場合、送信者は未使用の公称送信時間t_jを使用することが許可されます。
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に設定されている場合、Lost Packetよりも高いシーケンス番号を持つ少なくともndupackパケットの到着によって検出されます。並べ替えの存在下で堅牢。TCPとは対照的に、TFRCでパケットが遅れて（NDUPACK後続のパケットが到着した後）に到着した場合、後期パケットは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 1のマークされていないデータパケットと、シーケンス番号n 2のマークされたデータパケットが続く場合、受信者は受信したときに渋滞イベントを検出します。マークされたパケット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では、同じ損失イベントで失われた、またはマークされたいくつかの連続したパケットに対して損失分率が堅牢であることが必要です。これはTCPに似ており、（通常）単一のRTTの間に混雑ウィンドウの1つの半分のみを実行します。したがって、受信者は、パケット損失履歴を損失イベントレコードにマッピングする必要があります。このイベントでは、損失イベントがRTTで紛失またはマークされている1つ以上のパケットです。このマッピングを実行するには、受信者は使用する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_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_BEFOREDおよびS_AFTERの到着時間から受信機に名目上の「到着時間」を補間することができます。したがって：
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:
シーケンス番号のラッピングに対処するには、s_max = 2^bとbとします。ここで、bは特定の実装のシーケンス番号のビット長です。この場合、到着時間t_lossを次のように補間することができます。
T_loss = T_before + (T_after - T_before)
* Dist(S_loss, S_before)/Dist(S_after, S_before)
where
ただし
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.
Lost Packet 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で開始されたと判断された場合、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のサイズは例として、現在の損失間隔が単一の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を計算するために、最初に平均損失間隔を計算します。これは、測定された損失イベントレートがスムーズに変化するように、最新の損失イベント間隔を重み付けするフィルターを使用して行われます。レシーバーがまだ紛失またはマークされたパケットを見ていない場合、レシーバーは平均損失間隔を計算しません。
Weights w_0 to w_(n-1) are calculated as:
ウェイトw_0からw_（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_0からw_7の値は次のとおりです。
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
1.0、1.0、1.0、1.0、0.8、0.6、0.4、0.2
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の速度を決定します。値nを8に設定することをお勧めします。TFRCは、TCPを使用してグローバルインターネットで競合する可能性のあるトラフィックに8を超えるnの値を使用しないでください。少なくとも、Nの値が8を超える安全な動作には、TFRCのメカニズムにわずかな変更が必要になり、パケット損失が大きい2つ以上の往復時間に対するより深刻な反応が含まれます。
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;
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.
セクション5.4で説明されているように、少なくともn損失間隔があった場合、最新の損失間隔は、最新の損失間隔の計算において、総重量の1/（0.75*n）のみが割り当てられます。損失間隔。このセクションでは、[FHPW00A]および[W00]でさらに議論されているオプションの履歴割引メカニズムについて説明します。これにより、TFRCレシーバーが重みを調整し、最新の損失間隔が最新の損失間隔でより多くの相対重量を集中させます。計算された平均損失間隔の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:
履歴割引を実行するために、各損失間隔L_IをI> 0の割引係数DF_Iに関連付けます。各割引係数は浮動小数点数です。割引アレイは、各損失間隔の割引の累積履歴を維持します。最初は、割引アレイ内のDF_Iの値が1に初期化されます。
for (i = 0 to n) {
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で説明したように、平均損失間隔は、以前の損失間隔I_1、...、I_N、および現在の損失間隔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_meanを計算しますi_1、...、i_n：
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の2倍を超える場合、新しい損失間隔は古いものよりもかなり大きく、一般的な割引係数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.
しきい値のゼロ以外の値は、高い輻輳の初期の時期からの古い損失間隔が完全に割引されないことを保証します。0.25のしきい値をお勧めします。新しいパケット到着ごとに、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_0からi_1にシフトし、損失間隔I_Iは間隔I_（I 1）にシフトし、損失間隔I_Nは忘れられます。以前の割引係数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が突然の輻輳の欠如に対してやや迅速に応答できるようにすることを唯一の目的とするオプションのメカニズムであることを強調します。
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ごとに1つのパケットのレートで送信しない限り、フィードバックパケットは通常、RTTごとに少なくとも1回送信する必要があります。この場合、受信したデータパケットごとにフィードバックパケットを送信する必要があります。また、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ごとに定期的なフィードバックメッセージを1回以上送信することには、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.
レシーバーがRTTごとにKフィードバックパケットを送信していた場合、K> 1の場合、セクション6.2のステップ（4）が変更され、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.
2) 完了したかどうかを確認します。新しいパケットが新しい損失イベントの検出を結果、またはフィードバックタイマーが最後に期限切れになったときにフィードバックパケットが送信されなかった場合、ステップ3に移動します。そうでなければ、アクションを実行する必要はありません（次の段落が使用されているため、手順を終了します。
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.
オプションの最適化により、パケットの到着がパケット履歴に穴を開けるかどうかを確認する可能性があり、その結果、2つの損失間隔が1つに統合されました。この場合、レシーバーもすぐにフィードバックを送信する場合があります。このような最適化の影響は通常、小さいと予想されます。
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.
フィードバックタイマーが最後に期限切れになったときにP <= P_PREVとフィードバックパケットが送信されなかった場合、フィードバックタイマーが期限切れになり、セクション6.2で説明されているアクションを実行します。フィードバックタイマーが最後に期限切れになったときにp <= p_prevとフィードバックパケットが送信された場合、アクションを実行する必要はありません。
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:
フィードバックタイマーのMTH有効期限の場合、レシーバーのパケットの最大シーケンス番号をこれまでのところ、S_MとパケットS_Mに含まれるRTT測定値の値をR_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を計算します。これは、フィードバックタイマーが通常の時間に期限切れになったか、新しい紛失またはマークされたパケット（つまり、セクション6.1のステップ（3））のために早期に期限切れになったかどうかにかかわらず実行されます。
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.
典型的なケースでは、レシーバーがラウンドトリップ時間ごとに1つのフィードバックパケットのみを送信し、フィードバックタイマーが新しい紛失パケットのために早期に期限切れになっていない場合、フィードバックタイマーが最後に期限切れになってからの時間間隔はR_（M-1）秒。
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.
上記のルール2）は、往復時間ごとに1つのパケットの測定受信レートX_RECVの最小値を提供することに注意してください。送信者が、往復時間ごとに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.
送信者が往復時間の四半期ごとに増加する粗粒のタイムスタンプを使用している場合、フィードバックタイマーは必要ありません。RFC4342の次の手順を使用して、フィードバックメッセージを送信するタイミングを決定します。
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.)
o 受信者がlast_counter 4以上のウィンドウカウンター値を持つデータパケットを受信した場合、受信者は新しいフィードバックパケットを送信します。（「グレート」と「最大」は、円形の窓カウンタースペースで測定されます。）
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.)
最初の損失までのパケットの数を使用して、送信速度がこの間に急速に変化するため、許可された送信率を直接計算することはできません。TFRCは、最初の損失後の正しいデータレートが、損失が発生する前の最大送信率の半分であると想定しています。TFRCは、これまでのX_RECVの最大値であるこの目標レートX_Targetを近似しています。（スロースタートの場合、特定の往復時間の場合、送信者の送信率は、通常、前の往復時間に送信されたデータの受信者の受信率の2倍です。）
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は、セクション3.1のスループット方程式がX_Targetの5％以内の送信速度を示し、ラウンドトリップ時間rを考慮して、最初の損失間隔を1/pに設定することにより、これを行います。受信者が送信者が使用するセグメントサイズsを知っている場合、レシーバーはxに対してスループット方程式を使用できます。それ以外の場合、受信機は、この目的のために毎秒バイトではなく、1秒あたりのパケットの受信率を測定し、X_PPのスループット方程式を使用できます。（5％の許容範囲は、単にスループット方程式を反転させるのが難しいという理由だけで導入されており、Pの計算コストを数値的に削減したいと考えています。）
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）。TFRCの場合、最初のデータパケットが紛失またはECNマークが付けられている場合、最初の損失間隔は、データパケットなしのヌル間隔で構成されます。この場合、以下の段落で指定されているように、この（null）損失間隔の損失間隔長を設定する必要があります。
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損失間隔がnullの場合、最初のデータパケットが失われるかECNマークが付けられている場合、TCPの動作に従うために、TFRCは許可された送信率を2つの往復時間ごとに1パケットにするか、同等に望んでいます。、RTTあたり0.5パケット。したがって、TFRCレシーバーは、往復時間rに対して、秒単位のターゲットレートx_target x_target x_targetを1秒あたり0.5/rパケットの生成に計算し、最初の損失間隔にこの合成損失間隔を使用する損失間隔を計算します。TFRCレシーバーは、最初の損失間隔を初期化するときにX_Targetの最小値として1秒あたり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レシーバーは、最初の損失イベントの後に合成損失間隔を報告しているにもかかわらず、TFRCレシーバーは、上記のセクション6.2で指定されているように、測定された受信レート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が一緒にDCCPのCCID 3を指定します。これは、TFRCの送信者ベースのバリアントとして使用できます。CCID 3では、受信機からの各フィードバックパケットには、最新の損失間隔の長さを報告する損失間隔オプションが含まれています。フィードバックパケットには、ACKベクターオプションが含まれている場合があり、送信者がどのパケットをドロップまたはマークしたかを正確に決定し、損失間隔オプションで報告された情報を確認できます。ACKベクトルオプションには、ECNノンセエコーも含めることができ、送信者はマークのないデータパケットを受け取ったというレシーバーのレポートを確認できます。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および1-Q、タイムアウト間隔の4因子）は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.
フィードバックパケットを受信すると、送信者は、そのフィードバックパケットの対象となる間隔全体がデータ制限期間であるかどうかを判断する必要があります。このセクションでは、送信者がフィードバックパケットの対象となる間隔がデータ制限期間であるかどうかを判断するための1つの可能な実装について説明します。
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）があるかどうかを判断するだけで十分です。往復時間の推定、およびt_oldの場合はt_new -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よりも往復時間が大きくなります。ほぼ間隔（t_new、t_next]（レシーバーが新しい損失イベントを報告しているためにフィードバックパケットを早期に送信しない限り）。目標は、notlimited1が（t_new、t_next）で非データ度制限時間を節約することです。1つであり、t_nextの後に非DATA制限時間を節約するためにnotlimited2でした。
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がフィードバックパケットでカバーされている時間間隔である場合、間隔はデータ制限間隔ではありません。送信者は、その時間間隔で少なくとも一度はデータ制限されていませんでした。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.
それは私たちには受け入れられるようです。フィードバックパケットでカバーされている間隔全体がデータ制限間隔であるかどうかを識別する精度を向上させるために、送信者はより明確でない時間を節約できます。
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（認められたパケットが送信された時刻）を決定することができます。パケット。
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を維持する複雑さを減らすために、X_RECV_SETを最大n = 3要素に制限するだけで十分です。この場合、手順の更新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をx_recv_setに追加します。X_RECV_SET値から2回以上の往復時間を削除します。最新の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_SETで最大で * 2 *の要素を維持するだけで、送信者がデータ制限期間の前からX_RECVの古い値を節約し、アイドル期間後に最初のフィードバックパケットによって送信者が制限されないようにするのに十分です（報告する往復時間ごとに1パケットの受信率）。ただし、X_RECV_SETの最大2つの要素を維持することで、最大3つの要素を維持するほど優れたパフォーマンスを提供することはできません。X_RECV_SETで3つの要素を維持することで、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).
このセクションでは、粗粒のタイミング粒度を備えたオペレーティングシステムの送信者の1つの可能なスケジューリングメカニズムについて説明します（セクション4.6から）。
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送信者は、T_Gran秒ごとに最大1パケットの送信率に制限されます。パケット。以下のセクションで説明されているように、送信者が過去の未使用の送信時間の送信クレジットを蓄積できるようにすることに加えて、送信者がスケジュールされた送信時間の前にパケットを送信できるようにすることが有用です。
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_IPI、T_（I-1）の場合、前のパケットの送信時間。アプリケーションが再スケジュールされると、現在の時刻t_nowをチェックします。（t_now> t_i -t_delta）の場合、パケットIが送信されます。次のパケットの名目送信時間T_Iが計算されると、既にt_now> t_i -t_deltaである場合があります。そのような場合、パケットはすぐに送信されます。
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;
(The scheduling granularity t_gran is 10 ms on some older Unix systems.)
（いくつかの古いUNIXシステムでは、スケジューリングGranularity T_Granが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パケットの送信レートx 10パケット（PPR）、100ミリ秒の往復時間、10ミリ秒のスケジューリング粒度T_Granを備えたシステム、および往復時間のために未使用の送信クレジットを蓄積します。この場合、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 msの往復時間、スケジュール粒度が1 msのシステム、および蓄積する能力を持つ、往復時間よりも大きいスケジューリングの粒度を持つTFRCフローを考えてみましょう。ラウンドトリップ時間のために未使用の送信クレジット。TFRC送信者は、未使用の送信クレジットを0.1ミリ秒保存することが許可されます。スケジューリングの粒度 *が、着信フィードバックパケットに対する送信者の応答に影響を与えなかった場合、TFRC送信者は、各RTTの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ミリ秒に1回、許可された送信率でデータを送信できるようにすることで、大幅に制限されます。送信率のこの制限は、せいぜい往復のデータの破裂を許可することの避けられない結果です。
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の平均損失間隔の計算には、W_0からW_（N-1）の重みによる乗算が含まれます。
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.
1.0、1.0、1.0、1.0、0.8、0.6、0.4、0.2。
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つのパワーの合計である重みを使用することが可能です。
1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.
1.0、1.0、1.0、1.0、0.75、0.5、0.25、0.25。
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 3448を変更して、RFC 3390からのTCPのより高い初期送信率を組み込みます。このドキュメントは、RFC 3448を変更して、RFC 4342がより繊細な粒のタイムスタンプではなく、データパケットで粗粒のタイムスタンプを使用できるようにします。
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 errataにアイテムも組み込まれています。
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つのパケットでした。このドキュメントでは、RFC 3390に続いて、初期送信率は往復時間ごとに4つのパケットと同じくらい高くなります。初期送信率は、MSSの観点からではなく、セグメントサイズSの観点から変更されました。
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では、スロースタート中に2倍になったTLDは、0または-1に初期化できると述べています。また、セクション4.2は、RTT測定がフィードバックパケットだけからではないことを明確にしました。彼らはまた、Syn Exchangeなどの他の場所から来ることができます。
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.
セクション4.2のより大きな初期送信率は、最初のパケットを受信した後に受信機がフィードバックパケットを送信し、送信者がそれに応じて、RTTごとに最大2つのパケットに許可された送信率を減らすと、2倍になると、セクション4.2のより大きな初期送信率はほとんど役に立ちません。受信料。送信者の受信率の処理が変更されているため、送信者は、最初のフィードバックパケットに応答して、報告された受信率の2倍の送信率を減らすことはありません。
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.) 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、アイドル期間への応答：[RFC4342]のセクション5.1に従うと、このドキュメントは、NoFeedbackタイマーが設定されてからの期間をカバーするアイドル期間の後に送信率が低下した場合、許可された送信率が低下しないことを指定しています。初期送信率。（セクション4.4では、変数Recover_rateは初期送信率に設定されています。）セクション4.4、[RFC3448err]からの修正。RFC 3448には、送信者がフィードバックレポートを受け取らず、または * 4 *ラウンドトリップ時間の後に * 2 *往復時間の後に送信率を半分にしたかどうかについて矛盾したテキストを持っていました。この文書は、フィードバックレポート[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は、NoFeedbackタイマーの有効期限、p = 0の場合、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を修正して、損失間隔I_0には、失われたパケットとマークされたパケットを含むすべての送信パケットが含まれていると述べました（損失間隔の一般的な定義のセクション5.3で定義されています）。
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; }
to
に
for (i = 0 to n) { 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、履歴の割引：しきい値、履歴割引パラメーター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.
ECNをTFRCに組み込むプロトコルは、ECN NonCe [RFC3540]を使用して、受信機から送信者へのフィードバックを組み込むことも期待しています。ECN Nonceは、マークされたパケットの偶発的または悪意のある隠蔽から送信者を保護する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は現在、Datagram混雑制御プロトコル（DCCP）[RFC4340]の混雑制御ID 3（CCID 3）[RFC4342]で使用されています。RFC 4340 [RFC4340]（セクション18）のセキュリティに関する考慮事項セクションでは、ハイジャックされた接続から保護するためのシーケンス番号妥当性チェックを含む、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 CCID 3でのTFRCの使用を指定します。RFC4342には、送信者が受信者から送信された情報を確認するために使用できるメカニズムの広範な議論が含まれています。ECNがCCID 3で使用される場合、受信者はECN NonCe情報を送信者に返し、送信者が受信機によって送信された情報を確認できるようにします。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.
信頼できるマルチキャスト研究グループのメンバー、信頼できるマルチキャスト輸送ワーキンググループ、エンドツーエンドの研究グループを含む幅広い人々との方程式ベースの混雑制御に関するフィードバックと議論を認めたいと思います。Dado Colussi、Gorry Fairhurst、Ladan Gharai、Wim Heirman、Eddie Kohler、Ken Lofgren、Mike Luby、Mike Luby、Ian McDonald、Vladimir Moltchanov、Colin Perkins、Michele R.、Gerrit Renker、Arjuna Sathiaseelan、vladich stanisic、、Eduardo Urzaiz、Shushan Wen、およびWendy Lee（lhh@zsu.edu.cn）は、このドキュメントの以前のバージョンに関するフィードバックについて、[RFC3448]を使用したことからの広範なフィードバックについて、実用的な実装を作成してくれたことに感謝します。
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：損失を推測するためのデュパックの数（定数）（セクション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：時間が2倍になりました（セクション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：1秒あたりのバイトでの送信レートを計算しました（セクション3.1）。
X_pps: Calculated sending rate in packets per second (Section 3.1).
X_PPS：1秒あたりのパケットの送信レートを計算しました（セクション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）。
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.
[RFC2988]からのTCPの再送信タイマーの3秒の推奨初期値の代わりに、TFRCのNoFeedbackタイマーの初期値が2秒に設定されるのはなぜですか？TFRCのNoFeedbackタイマーがTCPの再送信タイマーと同じ初期値を持つべきである理由はありません。TCPの再送信タイマーは、輻輳に応じて送信率を下げるだけでなく、ネットワークでドロップされたと想定されるパケットを再送信するためにも使用されます。対照的に、TFRCのNoFeedbackタイマーは、新しいパケットの送信をトリガーするのではなく、許可された送信率を下げるためにのみ使用されます。その結果、TFRCのNoFeedbackタイマーの初期値がTCPの再送信タイマーの推奨初期値よりも小さいように、ネットワークに危険はありません。
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が受信率を使用することは、TCPのWindowsとACK-Clockingの使用よりもやや正確ではないため、NoFeedbackタイマーは、TFRCにとって特に重要な安全メカニズムです。これらのすべての理由により、TFRCのNoFeedbackタイマーがTCPの再送信タイマーよりも初期値が小さくなることは完全に合理的です。
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）を指定します。この議論では、「標準TCP」という用語を使用して、[RFC2581]および[RFC2581BIS]のTCP輻輳制御メカニズムを参照します。[RFC2861]は、標準のTCPとは異なるアイドルまたはデータ制限期間に対する異なる応答を指定します。CWVを使用すると、TCP送信者は、アイドル期間中の各RTOの後、最初のウィンドウまでの各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）に1行の変更が必要です。特に、フィードバックパケットに対する送信者の応答は、以下から変更できます。
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の性質により、このメカニズムは、最新の受信率の2倍未満の送信率を減らすことはありません。
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);
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スタイルの動作自体がデータ制限期間中の送信率の急速な変動を制限するため、損失イベントに対するこの緩和反応が許可されています。
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 pkts/rtt未満ではありません）。2回受信レート。PKTを送信した後の1つのRTT、レートは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：半分のレートレートは2回に制限されています（初期レートを下回っていません）。MAX（現在の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は、再発タイムアウト後にスロースタートしきい値を設定する際にのみ、ネットワーク内の優れたデータの量であるフライトサイズを使用します。標準の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のLAX応答は、アイドル期間に対する厳しい応答とはまったく異なります。
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よりもアイドル期間に対するより緩やかな応答を指定します。最初の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]は、データ制限期間の各RTO秒後、標準のTCPのそれよりもデータ制限期間に対するより厳しい応答を指定します。輻輳ウィンドウは、実際に使用されているウィンドウまで途中で縮小されます。
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つのパケットの受信レポートを受信したレポートを受信し、送信率を制限するためにこの受信率が使用されます。標準の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]は、データ制限期間と非DATA制限期間を区別しません。結果として、許可された送信率は、データ制限期間中およびデータ制限期間中の受信率の最大2倍に限定されます。これは非常に制限的な応答であり、標準のTCPまたはCWVを使用した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パケットの受信率を報告しています。ただし、改訂されたTFRC送信者は、送信率を制限するためにこの受信率を使用しません。したがって、改訂されたTFRCは、送信レートの削減で使用される下限で、およびアイドル期間後に受信した最初のフィードバックパケットに対するより良い応答で標準の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の場合、このドキュメントは、データ制限された期間と非DATA制限期間を区別します。セクション4.3で指定されているように、データ制限期間中に改訂されたTFRCは、データ制限期間が始まる前に受信率を覚えており、受信率の2倍を下回る許可された送信率を減らしません。これは、標準の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はスロースタートしきい値SSThreshを設定して、TCP送信者が古い送信にスロースタートできるようにすることができますアイドルまたはデータに制限された期間が終了した場合のレート。ただし、TFRCでは、TFRC送信者の送信率が前の受信率の2倍に制限されている場合でも、これにより、送信者は、スループット方程式で許可されている場合、ある往復時間から次の往復時間に送信率を2倍にすることができます。したがって、TFRCは、TCPのSSThreshの設定などのメカニズムを必要としないため、アイドルまたはデータ制限期間の後にスロースタートを可能にします。
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.
将来の作業では、探索するための1つの手段は、データ制限期間に対するTFRCの応答のための輻輳ウィンドウ検証メカニズムの追加です。現在、標準のTCPに続いて、データ制限期間中に改訂されたTFRCは、受信率の関数としての許可された送信率を制限しません。
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まで）。未使用の送信クレジット）。
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.
表2は、改訂されたTFRCが標準のTCPおよびTCPのそれに対して同様の応答を持っていることを示しています。短いアイドルまたはデータ制限期間の場合、TCPは未使用の輻輳ウィンドウのサイズによってのみ制限され、改訂されたTFRCは未使用の送信クレジットの数（RTTの価値まで）の数によってのみ制限されます。標準のTFRCの場合、[RFC3448]は、未使用の送信クレジットに関して動作を明示的に指定しませんでした。
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（このドキュメント）の応答をまとめたものです。このセクションの目的のために、中程度の期間を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まで）。未使用の送信クレジット）。
Table 3: Response to Moderate Idle or Data-Limited Periods
表3：中程度のアイドルまたはデータ制限期間への応答
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.
表3は、改訂されたTFRCが標準のTCPおよびCWVを備えたTCPの応答と同様の応答が中程度のアイドルまたはデータ制限期間を持っていることを示しています。中程度のアイドルまたはデータ制限期間の場合、TCPは未使用の輻輳ウィンドウのサイズによってのみ制限されます。中程度のアイドル期間の場合、改訂されたTFRCは、未使用の送信クレジットの数（RTTの価値まで）の数によってのみ制限されます。中程度のデータ制限期間の場合、標準のTFRCは、最新のフィードバックパケットからX_RECVによって制限されます。対照的に、改訂されたTFRCは、往復時間のフィードバック期間全体をカバーするデータ制限期間からの受信率によって制限されません。標準のTFRCの場合、[RFC3448]は、未使用の送信クレジットに関して動作を明示的に指定しませんでした。
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：X_BPSを計算し、最大2*X_RECVで送信します。
Revised TFRC: Calculate X_Bps, send at most recv_limit. In addition, modify X_recv_set.
改訂されたTFRC：x_bpsを計算し、最大でrecv_limitで送信します。さらに、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の他の時間での損失に対する反応と同じです。この応答は、フライトサイズの半分に輻輳ウィンドウをフライトサイズの半分に設定することです。ここでは、フライトサイズは実際の概要データの量です。したがって、データ制限期間中の損失の後、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によって制限され、送信率は最新の受信率である2回X_RECVによっても制限されます。その結果、データが制限された期間での損失の後、送信者は、スループット方程式X_BPSがそれよりもはるかに高い送信率を許可する場合でも、最大2倍のX_RECVに送信率を2倍にすることができます。
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の使用に変更がありました。送信者は、最大のRecv_limitで送信することに限定されています。この場合、送信者はデータ制限期間の直前から受信レートX_RECVを覚えています。これにより、送信者は、データに制限された期間中の送信率を2倍以上に、データ制限期間前から受信率まで（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は、データ制限期間中の損失後の送信者の送信率を徐々に制限するための追加のメカニズムを追加します。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のエントリを減少させることにより、最大で最大（x_recv_set）で送信者を送信できるようにすることにより、改訂されたTFRC（セクション4.3のステップ（4））で行われます。報告された損失後の即時の往復時間で、2回最大（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にパケット損失がある場合、これはX_BPSの変更された値に反映され、将来の損失イベントはスループット方程式X_BPSの将来の削減につながります。特に、TFRCのスループット方程式[FHPW00]（セクションA.2）の標準的な使用に続いて、許可された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.
送信者が100個のPPRを送信してから、アプリケーションからのデータ制限のために99 PPRのみを送信するデータ制限期間を入力する改訂されたTFRC接続を考えてみましょう。（つまり、データに制限された期間中のすべてのインスタンスで、送信者はもう1つのパケットを送信できた可能性があります。）データ制限期間に損失がある場合、許可された送信率はmin（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 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.
送信者が100個のPPRを送信してから、10個のPPRのみを送信するデータ制限期間を入力してから、2つのRTTのパケットを送信しないでください。-マークされた。この場合、改訂されたTFRCを使用して、データ制限期間中の各損失イベントについて、送信者は、データ制限期間の例4の前から「記憶された」X_Recvを半分にします。この例では、送信者がデータ制限期間中に送信率を大幅に増加させると、損失を考慮します。
-------------------------------------------------------------------
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.
送信者が100 PPRを送信してから、1つのPPRのみを送信するデータ制限期間を入力した改訂されたTFRC接続を検討し、それでもデータ制限されている間、送信率は20 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減少します。
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の動作を比較することです。スロースタート。
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の厳格な対応に対する1つの欠点は、他のデータが送信するデータがない場合にダミーデータを送信することにより、アイドルまたはデータ制限期間中に送信率を埋めるためのアプリケーションを促進することができることです。改訂された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とIDLE期間に対するTFRCの修正された応答は、うっ血窓の検証を伴うTCPの応答とほぼ類似していますが、データ制限期間に対するTFRCの応答を改訂したことは、うっ血ウィンドウ検証（およびデータ制限期間に対する標準のTFRCの応答に対するTCPの応答よりも保守的ではありません。輻輳窓の検証のものよりもかなり *保守的でした）。将来の作業には、このドキュメントの変更が含まれる可能性があるため、データ制限期間への改訂された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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Balakrishnan、H.、Rahul、H。、およびSeshan、S。、「インターネットホスト向けの統合渋滞管理アーキテクチャ」、Proc。ACM SIGCOMM、ケンブリッジ、マサチューセッツ州、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] Floyd、S。、およびE. Kohler、「DCCP輻輳制御IDのプロファイル：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. Floyd、M。Handley、J。Padhye、およびJ. Widmer、「ユニキャストアプリケーション用の方程式ベースの混雑制御」、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. Floyd、M。Handley、J。Padhye、およびJ. Widmer、「ユニキャストアプリケーション用の方程式ベースの混雑制御：拡張バージョン」、ICSI Tech Report 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] Floyd、S。、およびK. Fallは、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. Kohler、S。Floyd、およびA. Sathiaseelan、「TCP Friendry Rate Control（TFRC）のためのより速い再起動」、2007年11月、Work in Progress。
[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. Medina、M。Allman、およびS. Floyd、「インターネットでの輸送プロトコルの進化の測定」、ACM Computer Communications Review、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。and Towsley、D。and Kurose、J。、「モデリングTCPスループット：単純なモデルとその経験的検証」、Proc ACM Sigcomm 1998。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140] Touch、J。、「TCP制御ブロック相互依存」、RFC 2140、1997年4月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[RFC2581bis] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", Work in Progress, April 2008.
[RFC2581BIS] Allman、M.、Paxson、V。、およびW. Stevens、「TCP混雑コントロール」、2008年4月、進行中の作業。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP混雑ウィンドウ検証」、RFC 2861、2000年6月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC3448Err] RFC 3448 Errata, <http://www.rfc-editor.org/errata_search.php?rfc=3448>.
[RFC3448err] RFC 3448 errata、<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] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（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] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：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] Floyd、S。およびE. Kohler、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、RFC 4828、2007年4月。
[W00] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000, <http://www.icir.org/tfrc/>.
[W00] Widmer、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
Sally Floyd Icsi 1947 Center St、Suite 600 Berkeley、CA 94708メール：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 UKメール：m.handley@cs.ucl.ac.uk
Jitendra Padhye Microsoft Research EMail: padhye@microsoft.com
Jitendra Padhye Microsoft Researchメール：padhye@microsoft.com
Joerg Widmer DoCoMo Euro-Labs Landsberger Strasse 312 80687 Munich Germany EMail: widmer@acm.org
Joerg Widmer Docomo Euro-Labs Landsberger Strasse 312 80687 Munich Germanyメール：widmer@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。