Network Working Group M. Handley
Request for Comments: 3448 S. Floyd
Category: Standards Track ICIR
J. Padhye
Microsoft
J. Widmer
University of Mannheim
January 2003
TCP Friendly Rate Control (TFRC):
Protocol Specification
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 telephony or streaming media where a relatively smooth sending rate is of importance.
このドキュメントでは、TCPフレンドリーレート制御（TFRC）を指定します。 TFRCは、ベストエフォート型のインターネット環境で動作するユニキャストフローの輻輳制御機構です。これは、帯域幅を競合するとき、TCPフローを合理的に公平であるが、そのような電話または比較的滑らかな送付レートが重要である場合、メディアストリーミングなどのアプリケーションのためにそれをより適切なものに、TCPに比べて時間をかけてスループットのはるかに低い変動を持っています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 3
3.1. TCP Throughput Equation. . . . . . . . . . . . . . 4
3.2. Packet Contents. . . . . . . . . . . . . . . . . . 6
3.2.1. Data Packets. . . . . . . . . . . . . . . . 6
3.2.2. Feedback Packets. . . . . . . . . . . . . . 7
4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7
4.1. Measuring the Packet Size. . . . . . . . . . . . . 8
4.2. Sender Initialization. . . . . . . . . . . . . . . 8
4.3. Sender behavior when a feedback packet is
received. . . . . . . . . . . . . .. . . . . . . . 8
4.4. Expiration of nofeedback timer . . . . . . . . . . 9
4.5. Preventing Oscillations. . . . . . . . . . . . . . 10
4.6. Scheduling of Packet Transmissions . . . . . . . . 11
5. Calculation of the Loss Event Rate (p). . . . . . . . . 12
5.1. Detection of Lost or Marked Packets. . . . . . . . 12
5.2. Translation from Loss History to Loss Events . . . 13
5.3. Inter-loss Event Interval. . . . . . . . . . . . . 14
5.4. Average Loss Interval. . . . . . . . . . . . . . . 14
5.5. History Discounting. . . . . . . . . . . . . . . . 15
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 17
6.1. Receiver behavior when a data packet is
received . . . . . . . . . . . . . . . . . . . . . 18
6.2. Expiration of feedback timer . . . . . . . . . . . 18
6.3. Receiver initialization. . . . . . . . . . . . . . 19
6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . 19
7. Sender-based Variants . . . . . . . . . . . . . . . . . 20
8. Implementation Issues . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . 22
12. Non-Normative References. . . . . . . . . . . . . . . . 22
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . 23
14. Full Copyright Statement. . . . . . . . . . . . . . . . 24
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 [2]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [7], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [1]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
このドキュメントでは、TCPフレンドリーレート制御（TFRC）を指定します。 TFRCは、インターネット環境で動作し、TCPトラフィックと競合ユニキャストフローのために設計された輻輳制御機構である[2]。代わりに、完全なプロトコルを指定する、本書では単に[7]、アプリケーションレベルでエンドツーエンドの輻輳制御を組み込んだアプリケーションで、またはコンテキストにRTPなどのトランスポートプロトコルで使用することができる輻輳制御メカニズムを指定しますエンドポイント輻輳管理の[1]。この文書では、パケットフォーマットや信頼性については説明しません。実装関連の問題は、第8章では、簡単にしか説明されています。
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
TFRCは、その送信レートが同じ条件の下でTCPフローの送信レートの2倍以内であれば、一般的にフローが「合理的公正」であるTCPフロー、と帯域幅を競合するとき、合理的に公平であるように設計されています。しかし、TFRCは、このような比較的滑らかな送付レートが重要である電話やストリーミングメディアなどのアプリケーションのためにそれをより適切にするTCP、と比較して時間をかけてスループットのはるかに低い変動を持っています。
The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds slower than TCP to changes in available bandwidth. Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible we recommend using TCP, or if reliability is not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) congestion control scheme with similar parameters to those used by TCP.
帯域幅を公平に競争しながら、TCPよりも滑らかなスループットを持つことのペナルティは、TFRCは、利用可能な帯域幅の変化にTCPよりも遅く応答することです。アプリケーションが単一のパケット損失に応じて送信レートのTCPの半分を避け、特に、滑らかなスループット要件を有する場合したがってTFRCにのみ使用されるべきです。単に私たちはTCPを使用して、または信頼性が要求されていない場合は、添加剤-増加に同様のパラメータを持つ、乗法-減少（AIMD）輻輳制御方式を使用することをお勧めします、できるだけ短い時間でできるだけ多くのデータを転送する必要があるアプリケーションの場合TCPによって使用されるもの。
TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document.
TFRCは、固定パケットサイズを使用するアプリケーションのために設計され、輻輳に応答して第2あたりのパケットでそれらの送信レートを変更します。一部のオーディオアプリケーションでは、パケット間の時間の一定の間隔を必要とし、そのパケットサイズの代わりに、混雑に応じて、そのパケットレートを変えます。このドキュメントの輻輳制御機構は、これらのアプリケーションで使用することはできません。 （TFRC-たPacketSize用）TFRC-PS固定送信率を有するが、混雑に応じてそれらのパケットサイズを変化させる用途のためのTFRCの変異体です。 TFRC-PSは、後に文書で指定されます。
TFRC is 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.
TFRCはなく、データ送信側でデータ受信機における輻輳制御情報（すなわち、損失イベント率）の計算と、受信機ベースの機構です。これは、送信者が多数の同時接続を処理大規模なサーバであり、受信機は、計算のために利用可能なより多くのメモリとCPUサイクルを持つアプリケーションに適しています。加えて、受信機ベースのメカニズムは、マルチキャスト輻輳制御のためのビルディングブロックとしてより適しています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant TFRC implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応TFRC実装の要求レベルを示します。
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 packet 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) [6].
その輻輳制御機構のために、TFRCは、直接損失イベント率および往復時間の関数としての許容送信レートのスループット方程式を使用します。 TCPと公平に競争するためには、TFRCは、おおよそ損失イベント率、ラウンドトリップ時間、およびパケットサイズの関数として、TCPの送信レートを記述するTCPスループット方程式を、使用しています。我々は、マークされたパケットは、明示的輻輳通知（ECN）から輻輳表示を指すデータのウィンドウから1つまたは複数の紛失またはマーキングされたパケットのような損失事象を定義する[6]。
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, giving the acceptable transmit rate.
O損失イベント率およびRTTは、その後、許容される伝送速度を与え、TFRCのスループット方程式に供給されます。
o The sender then adjusts its transmit rate to match the calculated rate.
送信者oをその伝送レートが計算された率に一致するように調整されます。
The dynamics of TFRC are sensitive to how the measurements are performed and applied. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand how the interactions between mechanisms affect the dynamics of TFRC.
TFRCのダイナミクスは、測定が行われ、どのように適用されるかに敏感です。我々は、これらの測定を実行し、適用するには、以下の特定のメカニズムをお勧めします。他のメカニズムは可能ですが、メカニズムの間の相互作用は、TFRCのダイナミクスにどのように影響するかを理解することが重要です。
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFRC. However, we note that the TCP throughput equation used must reflect TCP's retransmit timeout behavior, as this dominates TCP throughput at higher loss rates. We also note that the assumptions implicit in the throughput equation about the loss event rate parameter have to be a reasonable match to how the loss rate or loss event rate is actually measured. While this match is not perfect for the throughput equation and loss rate measurement mechanisms given below, in practice the assumptions turn out to be close enough.
損失イベント率とRTTの関数としてTCPスループットを与える任意の現実的な方程式は、TFRCでの使用に適したものでなければなりません。しかし、我々はこれがより高い損失率のTCPスループットを支配として使用するTCPスループット方程式は、TCPの再送タイムアウトの動作を反映しなければならないことに注意してください。また、損失イベント・レート・パラメータのスループット式の暗黙の前提が損失率や損失イベント率を実際に測定する方法を合理的に一致する必要があることに注意してください。この試合は、下記のスループット方程式とロス率測定メカニズムのための完璧ではないですが、実際には仮定が十分に近いことが判明します。
The throughput equation we currently recommend for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [4]. Ideally we'd prefer a throughput equation based on SACK TCP, but no one has yet derived the throughput equation for SACK TCP, and from both simulations and experiments, the differences between the two equations are relatively minor.
我々は現在、TFRCのためにお勧めのスループット方程式は、[4]からリノTCPのスループット方程式を少し単純化したバージョンです。理想的には、SACK TCPに基づいてスループット方程式を好むだろうが、誰がまだSACK TCPのスループット方程式を導出していないと、シミュレーションと実験の両方から、二つの式の違いは比較的軽微なものです。
The throughput equation is:
スループット方程式は次のとおりです。
s
X = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
Where:
どこ：
X is the transmit rate in bytes/second.
Xは、バイト/秒で伝送速度です。
s is the packet size in bytes.
Sはバイト単位のパケットサイズです。
R is the round trip time in seconds.
Rは、秒単位の往復時間です。
p is the loss event rate, between 0 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 number of packets acknowledged by a single TCP acknowledgement.
Bは、単一のTCP受信確認によって確認されたパケットの数です。
We further simplify this by setting t_RTO = 4*R. A more accurate calculation of t_RTO is possible, but experiments with the current setting have resulted in reasonable fairness with existing TCP implementations [9]. Another possibility would be to set t_RTO = max(4R, one second), to match the recommended minimum of one second on the RTO [5].
私たちは、さらにt_RTO = 4 * Rを設定することで、これを簡素化します。 t_RTOのより正確な計算が可能であるが、現在の設定を用いた実験では、既存のTCP実装[9]との合理的な公正さをもたらしています。別の可能性は、RTO [5]に一つの第二の推奨最小値を一致させるために、t_RTO = MAX（4R、1秒）を設定することであろう。
Many current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received, and thus have a sending rate modeled by b = 2. However, TCP is also allowed to send an acknowledgement for every data packet, and this would be modeled by b = 1. Because many TCP implementations do not use delayed acknowledgements, we recommend b = 1.
現在の多くのTCP接続は、すべての2つのデータパケットを受信に対する肯定応答を送信し、遅延確認応答を使用するので、B = 2によってモデル化された送信レートは、しかし、TCPはまた、すべてのデータパケットに対して確認応答を送信することが許可されている、これはモデル化されるだろうB = 1で、多くのTCP実装が遅延確認応答を使用していないので、我々は1 = Bをお勧めします。
In future, different TCP equations may be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来的には、異なるTCP方程式は、この式に代入することができます。要件は、スループット方程式は、適合TCP輻輳制御のためのTCPの送信レートの合理的な近似であることです。
The parameters s (packet size), p (loss event rate) and R (RTT) need to be measured or calculated by a TFRC implementation. The measurement of s is specified in Section 4.1, measurement of R is specified in Section 4.3, and measurement of p is specified in Section 5. In the rest of this document all data rates are measured in bytes/second.
パラメータs（パケットサイズ）、P（損失イベント率）及びR（RTT）は、TFRC実装によって測定または計算する必要があります。 Sの測定は、Rの測定は、セクション4.3で指定され、そしてpの測定はすべてのデータレートをバイト/秒で測定され、この文書の残りの部分ではセクション5で指定され、セクション4.1で指定されています。
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 is incremented by one for each data packet transmitted. The field must be sufficiently large that it does not wrap causing two different packets with the same sequence number to be in the receiver's recent packet history at the same time.
シーケンス番号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. 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 would be sufficient 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。私たちは、シーケンス番号iのパケットのタイムスタンプts_iによって表します。タイムスタンプの分解能は、通常、ミリ秒単位で測定されなければなりません。このタイムスタンプは同一の損失事象に属する損失を決定するために受信機によって使用されます。タイムスタンプはまた、送信されたデータパケットのタイムスタンプを保存しない送信者のために、ラウンドトリップ時間を推定するために、送信者を可能にするために、受信機でエコーされます。私たちは、これがあるプロトコルの文脈では、ミリ秒単位でカウントアップタイムスタンプの代替として、ラウンドトリップ時間の四半期ごとにインクリメント「タイムスタンプ」は損失が同じ損失イベントに属している場合を決定するための十分であることに注意してください送信者が送信したデータパケットのタイムスタンプを保存し送信側と受信側との両方によって理解されます。
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. If the sender sends a coarse-grained "timestamp" that increments every quarter of a round-trip time, as discussed above, then the sender does not need to send its current estimate of the round trip time.
往復時間の送信者の現在の推定値O。パケットIで報告推定値はR_iとで表されます。往復時間推定は、複数の損失が同じ損失イベントに属するかを決定するために、タイムスタンプと共に、受信機によって使用されます。送信者は上述したように、ラウンドトリップ時間の四半期ごとにインクリメント粗粒度の「タイムスタンプ」を送信すると、送信者は、ラウンドトリップ時間の現在の推定値を送信する必要はありません。
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 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 since the last feedback report was sent. We denote this by X_recv.
O速度は、受信機が最後にフィードバックレポートを送信してからデータが受信されたと推定しています。私たちは、X_recvすることによってこれを表します。
o The receiver's current estimate of the loss event rate, p.
損失イベント率の受信機の現在の推定値、P O。
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate, based on the information contained in the feedback report. If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
データ送信側は、制御された速度でデータ受信機へのデータパケットのストリームを送信します。フィードバックパケットがデータ受信機から受信した場合、データ送信側はフィードバックレポートに含まれる情報に基づいて、その送信レートを変更します。送信者が2つの往復時間のためにフィードバックレポートを受信しない場合、それは半分にその送信レートをカット。これはNOFEEDBACKタイマーと呼ばれるタイマーによって達成されます。
We specify the sender-side protocol in the following steps:
私たちは、次の手順では、送信者側のプロトコルを指定します。
o Measurement of the mean packet size being sent.
Oの平均パケットサイズの測定は、送信されています。
o The sender behavior when a feedback packet is received.
フィードバックパケットを受信すると、送信者の振る舞いO。
o The sender behavior when the nofeedback timer expires.
NOFEEDBACKタイマーが満了したときに、送信者の振る舞いO。
o Oscillation prevention (optional)
O発振防止（オプション）
o Scheduling of transmission on non-realtime operating systems.
O非リアルタイム・オペレーティング・システム上での送信のスケジューリング。
The parameter s (packet size) is normally known to an application. This may not be so in two cases:
パラメータs（パケットサイズ）は、通常、アプリケーションには知られています。これは、2つの場合にそうではないかもしれません。
o The packet size naturally varies depending on the data. In this case, although the packet size varies, that variation is not coupled to the transmit rate. It should normally be safe to use an estimate of the mean packet size for s.
Oパケットのサイズは、当然データに応じて変化します。パケットサイズが変化するが、この場合には、その変化は、送信レートに結合されていません。通常のための平均パケットサイズの推定値を使用しても安全でなければなりません。
o The application needs to change the packet size rather than the number of packets per second to perform congestion control. This would normally be the case with packet audio applications where a fixed interval of time needs to be represented by each packet. Such applications need to have a completely different way of measuring parameters.
Oアプリケーションは、輻輳制御を実行するためのパケットサイズではなく、1秒あたりのパケット数を変更する必要があります。これは、通常、時間の一定間隔は、各パケットによって表される必要があるパケット音声アプリケーションの場合であろう。このようなアプリケーションでは、パラメータを測定する全く異なる方法を持っている必要があります。
The second class of applications are discussed separately in a separate document on TFRC-PS. For the remainder of this section we assume the sender can estimate the packet size, and that congestion control is performed by adjusting the number of packets sent per second.
アプリケーションの第二のクラスは、TFRC-PS上の別の文書に別々に議論されています。このセクションの残りの部分のために、我々は、送信者がパケットサイズを推定することができると仮定し、その輻輳制御は、毎秒送信されるパケットの数を調整することによって行われます。
To initialize the sender, the value of X is set to 1 packet/second and the nofeedback timer is set to expire after 2 seconds. The initial values for R (RTT) and t_RTO are undefined until they are set as described below. The initial value of tld, for the Time Last Doubled during slow-start, is set to -1.
送信者を初期化するには、Xの値は、第1パケット/に設定され、NOFEEDBACKタイマーを2秒後に期限切れになるように設定されています。以下に説明するように、それらが設定されるまで、R（RTT）とt_RTOの初期値は不定です。最後はスロースタート時に倍増時間のためのTLDの初期値は、-1に設定されています。
The sender knows its current sending rate, X, and maintains an estimate of the current round trip time, R, and an estimate of the timeout interval, t_RTO.
送信者は、現在の送信レート、Xを知っており、現在の往復時間、R、およびタイムアウト間隔の推定値の推定値を維持し、t_RTO。
When a feedback packet is received by the sender at time t_now, the following actions should be performed:
フィードバックパケットは、時間t_nowで、送信者が受信すると、次のアクションを実行する必要があります。
1) Calculate a new round trip sample. R_sample = (t_now - t_recvdata) - t_delay.
1）新ラウンドトリップのサンプルを計算します。 R_sampleは=（t_now - t_recvdata） - 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 we recommend a default value of 0.9.
TFRCは、フィルタ定数qのための正確な値に敏感ではありませんが、我々は0.9のデフォルト値をお勧めします。
3) Update the timeout interval:
3）タイムアウト間隔を更新します。
t_RTO = 4*R.
t_RTO = 4 *のR。
4) Update the sending rate as follows:
次のように4）送信率を更新します。
If (p > 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
If (t_now - tld >= R)
X = max(min(2*X, 2*X_recv), s/R);
tld = t_now;
Note that if p == 0, then the sender is in slow-start phase, where it approximately doubles the sending rate each round-trip time until a loss occurs. The s/R term gives a minimum sending rate during slow-start of one packet per RTT. The parameter t_mbi is 64 seconds, and represents the maximum inter-packet backoff interval in the persistent absence of feedback. Thus, when p > 0 the sender sends at least one packet every 64 seconds.
P == 0ならば、送信者は損失が発生するまで、それは約送信レートをそれぞれ往復時間を倍にスロースタートフェーズ、であることに注意してください。 S / Rの用語は、RTTあたり1つのパケットのスロースタート時レートを送信する最小を与えます。パラメータt_mbiは64秒であり、フィードバックの持続的な非存在下での最大パケット間バックオフ間隔を表します。これにより、p> 0、送信者は、少なくとも1つのパケットごとに64秒を送信するとき。
5) Reset the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
5）MAX（4 *のR、2 * S / X）秒後に期限切れになるようにNOFEEDBACKタイマーをリセットします。
If the nofeedback timer expires, the sender should perform the following actions:
NOFEEDBACKタイマーが満了した場合、送信者は、次のアクションを実行する必要があります。
1) Cut the sending rate in half. If the sender has received feedback from the receiver, this is done by modifying the sender's cached copy of X_recv (the receive rate). Because the sending rate is limited to at most twice X_recv, modifying X_recv limits the current sending rate, but allows the sender to slow-start, doubling its sending rate each RTT, if feedback messages resume reporting no losses.
1）の半分で送信レートをカット。送信者が受信者からのフィードバックを受信した場合、これは（受信速度）X_recvの送信者のキャッシュされたコピーを変更することによって行われます。送信レートは、せいぜい二回X_recvに限定されているので、X_recvを変更すると、現在の送信レートを制限しますが、フィードバックメッセージは何の損失を報告しなかっ再開する場合は、その送信レート各RTTを倍増、送信者はスロースタートをすることができます。
If (X_calc > 2*X_recv)
X_recv = max(X_recv/2, s/(2*t_mbi));
Else
X_recv = X_calc/4;
The term s/(2*t_mbi) limits the backoff to one packet every 64 seconds in the case of persistent absence of feedback.
用語S /（2 * t_mbi）は、フィードバックの持続的な不在の場合には一つのパケット毎に64秒バックオフを制限します。
2) The value of X must then be recalculated as described under point (4) above.
（4）上記の点で説明したように2）Xの値は、再計算されなければなりません。
If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, then step (1) can be skipped, and the sending rate cut in half directly:
送信者がまだRTTのサンプルを有していない、まだ受信機からのフィードバックを受信していない場合NOFEEDBACKタイマーが満了する場合には、ステップ（1）はスキップすることができ、送信レートを直接半分に切断します。
X = max(X/2, s/t_mbi)
X = MAX（X / 2、S / t_mbi）
3) Restart the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
3）（最大後4 * R、2 * S / X）秒を期限切れにするNOFEEDBACKタイマーを再起動します。
Note that when the sender stops sending, the receiver will stop sending feedback. This will cause the nofeedback timer to start to expire and decrease X_recv. If the sender subsequently starts to send again, X_recv will limit the transmit rate, and a normal slowstart phase will occur until the transmit rate reaches X_calc.
送信者が送信を停止した場合、受信機は、フィードバックの送信を停止することに注意してください。これはNOFEEDBACKタイマーがX_recvを期限切れと減少し始めることになります。送信者がその後に再び送信を開始した場合、X_recvは、送信レートを制限し、伝送レートがX_calcに達するまで、通常のスロースタートフェーズが発生します。
If the sender has been idle since this nofeedback timer was set and X_recv is less than four packets per round-trip time, then X_recv should not be halved in response to the timer expiration. This ensures that the allowed sending rate is never reduced to less than two packets per round-trip time as a result of an idle period.
送信者がこのNOFEEDBACKタイマーがアイドル状態に設定されたされているためとX_recvは、ラウンドトリップ時間ごとに4つのパケット未満の場合、X_recvは、タイマ満了に応じて半減してはなりません。これは許可され、送信速度がアイドル期間の結果として往復時間あたり2つの未満のパケットに減少したことがないことを保証します。
To prevent oscillatory behavior in environments with a low degree of statistical multiplexing it is useful to modify sender's transmit rate to provide congestion avoidance behavior by reducing the transmit rate as the queuing delay (and hence RTT) increases. To do this the sender maintains an estimate of the long-term RTT and modifies its sending rate depending on how the most recent sample of the RTT differs from this value. The long-term sample is R_sqmean, and is set as follows:
統計的多重度の低い環境で振動挙動を防止することがキューイング遅延（ひいてはRTT）が増加するにつれて、送信レートを低減することにより、輻輳回避動作を提供するために、送信者の送信レートを変更するのに有用です。これを行うには、送信者は、長期的なRTTの推定値を維持し、RTTの最新のサンプルは、この値とは異なる方法に応じて送信レートを変更します。長期的なサンプルはR_sqmeanで、次のように設定されます。
If no feedback has been received before
R_sqmean = sqrt(R_sample);
Else
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
Thus R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, and we recommend a value of 0.9 as the default.
したがってR_sqmeanはRTTサンプルの平方根の指数加重移動平均を与えます。定数Q2はQと同様に設定する必要があり、我々はデフォルトとして0.9の値をお勧めします。
The sender obtains the base transmit rate, X, from the throughput function. It then calculates a modified instantaneous transmit rate X_inst, as follows:
送信者は、スループット関数から、ベース送信レート、Xを求めます。次のようには、次に、修飾瞬間送信速度X_instを計算します：
X_inst = X * R_sqmean / sqrt(R_sample);
X_inst = X * R_sqmean / SQRT（R_sample）。
When sqrt(R_sample) is greater than R_sqmean then the queue is typically increasing and so the transmit rate needs to be decreased for stable operation.
SQRT（R_sample）がR_sqmeanより大きい場合、キューは、一般的に増加しているので、送信レートは、安定動作のために減少される必要があります。
Note: This modification is not always strictly required, especially if the degree of statistical multiplexing in the network is high. However, we recommend that it is done because it does make TFRC behave better in environments with a low level of statistical multiplexing. If it is not done, we recommend using a very low value of q, such that q is close to or exactly zero.
注：この変更は、常に厳密ネットワークにおける統計多重度が高い場合は特に、必要とされていません。しかし、我々はそれがTFRCは、統計的多重化のレベルが低い環境でより良い動作させるんので、それが行われることをお勧めします。それが行われていない場合、我々はQの非常に低い値を使用することをお勧めします、その結果、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 course-grain or irregular scheduling of the operating system. Thus a typical sending loop will calculate the correct inter-packet interval, t_ipi, as follows:
TFRCとして率ベースで、オペレーティング・システムは、典型的には、正確にイベントをスケジュールすることができないように、正確な平均速度は、オペレーティングシステムのコースグレイン又は不規則なスケジュールにもかかわらず維持されるようにデータパケットを送信約日和見する必要があります。次のようにこのように、典型的な送信ループは、正しいパケット間間隔、t_ipiを計算します。
t_ipi = s/X_inst;
t_ipi = S / X_inst。
When a sender first starts sending at time t_0, it calculates t_ipi, and calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the application becomes idle, it checks the current time, t_now, and then requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, t_now, again. If (t_now > t_1 - delta) then packet 1 is sent.
送信者が初めてT_0で送信を開始すると、それはt_ipiを計算し、アプリケーションがアイドル状態になると、パケット1の公称送信時間T_1 = T_0 + t_ipiを計算し、それが現在の時刻をチェックし、t_now、その後、後の再スケジューリングを要求（t_ipi - （t_now - T_0））秒。アプリケーションが再スケジュールされると、それは再び、現在の時刻、t_nowをチェックします。 （t_now> T_1 - デルタ）の場合、パケット1が送信されます。
Now a new t_ipi may be calculated, and used to calculate a nominal send time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with each successive packet's send time being calculated from the nominal send time of the previous packet.
今、新しいt_ipiを計算し、パケット2のための名目上の送信時間T_2を計算するために使用され得る：T2 = T_1 + t_ipi。プロセスはその後、それぞれの連続したパケットの送信時刻が前のパケットの名目上の送信時間から計算された状態で、繰り返されます。
In some cases, when the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - delta. In such a case the packet should be sent immediately. Thus if the operating system has coarse timer granularity and the transmit rate is high, then TFRC may send short bursts of several packets separated by intervals of the OS timer granularity.
デルタ - いくつかのケースでは、とき公称送信時間、T_Iは、次のパケットが計算されるのではなく、すでにそのt_now> T_I場合があり得ます。そのような場合にはパケットがすぐに送信されなければなりません。オペレーティングシステムは粗いタイマー粒度を有しており、伝送速度が高い場合したがって、その後TFRCは、OSのタイマーの粒度の間隔によって分離されたいくつかのパケットの短いバーストを送信することができます。
The parameter delta is to allow a degree of flexibility in the send time of a packet. If the operating system has a scheduling timer granularity of t_gran seconds, then delta would typically be set to:
パラメータデルタは、パケットの送信時間の自由度を可能にすることです。オペレーティングシステムはt_gran秒のスケジュールタイマーの粒度を有している場合には、デルタは一般的に設定されます。
delta = min(t_ipi/2, t_gran/2);
デルタ=分（t_ipi / 2、t_gran / 2）。
t_gran is 10ms on many Unix systems. If t_gran is not known, a value of 10ms can be safely assumed.
t_granは多くのUnixシステムでは10msです。 t_granが知られていない場合は、10ミリ秒の値が安全に仮定することができます。
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.
損失イベント率の正確で安定した測定値を得ることは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, we require that if a lost packet is retransmitted, the retransmission is given a new sequence number that is the latest in the transmission sequence, and not the same sequence number as the packet that was lost. If a transport protocol has the requirement that it must retransmit with the original sequence number, then the transport protocol designer must figure out how to distinguish delayed from retransmitted packets and how to detect lost retransmissions.
TFRCは、すべてのパケットが送信されたパケットごとに1ずつインクリメントされるシーケンス番号が含まれていることを前提としています。本明細書の目的のために、私たちは失われたパケットが再送された場合、再送が失われたパケットと同じシーケンス番号送信シーケンスにおける最新の、そしてない新しいシーケンス番号が付与されていることが必要です。トランスポートプロトコルは、それが元のシーケンス番号を再送しなければならないという要件がある場合、トランスポートプロトコルの設計者は、再送パケットより遅れとどのように失われた再送信を検出するために、区別するために方法を見つけ出す必要があります。
The receiver maintains a data structure that keeps track of which packets have arrived and which are missing. For the purposes of specification, we assume that the data structure consists of a list of packets that have arrived along with the 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 three packets with a higher sequence number than the lost packet. The requirement for three 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 3 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 three subsequent packets adaptive based on experienced packet reordering, but we do not specify such a mechanism here.
パケットの損失が失われたパケットよりも高いシーケンス番号を有する少なくとも3つのパケットの到着によって検出されます。 3つの後続のパケットのための要件は、TCPと同じであり、並べ替えの存在下でのTFRCをより堅牢にすることです。 （3つの後続のパケットが到着した後に）パケットがTFRCに遅れて到着した場合、TCPとは対照的に、後半パケットはTFRCの受信記録に穴を埋めることができ、受信機は、損失イベント率を再計算することができます。 TFRCの将来のバージョンでは、経験豊富なパケットの並べ替えに基づいて3つの後続のパケットの適応のための要件を作るかもしれませんが、我々はここで、このようなメカニズムを指定しないでください。
For an ECN-capable connection, a marked packet is detected as a congestion event as soon as it arrives, without having to wait for the arrival of subsequent packets.
ECN対応の接続では、マークされたパケットは、後続のパケットの到着を待たずに、できるだけ早くそれが到着すると、輻輳イベントとして検出されます。
TFRC requires that the loss fraction be robust to several consecutive packets lost where those packets are part of the same loss event. This is similar to TCP, which (typically) only performs one halving of the congestion window during any single RTT. Thus the receiver needs to map the packet loss history into a loss event record, where a loss event is one or more packets lost 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 we recommend using the sender's calculated RTT, R, (see Section 4.3) for this purpose.
TFRCは、損失の割合は、これらのパケットが同じ損失事象の一部で失われたいくつかの連続したパケットに対してロバストであることが必要です。これは、任意の単一のRTTの間に、輻輳ウィンドウの半分を実行する（典型的に）TCP、同様です。したがって、受信機は、損失事象が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 with sequence number before S_loss.
S_beforeはS_loss前のシーケンス番号と到着する最後のパケットのシーケンス番号です。
S_after is the sequence number of the first packet to arrive with sequence number after S_loss.
S_afterはS_loss後のシーケンス番号と到着する最初のパケットのシーケンス番号です。
T_before is the reception time of S_before.
T_beforeはS_beforeの受信時刻です。
T_after is the reception time of S_after.
T_afterはS_afterの受信時刻です。
Note that T_before can either be before or after T_after due to reordering.
T_beforeは前または後にT_afterによる並べ替えにできることに注意してください。
For a lost packet S_loss, we can interpolate its nominal "arrival time" at the receiver from the arrival times of S_before and S_after. Thus:
失われたパケットS_lossのために、私たちはS_beforeとS_afterの到着時間から受信機にその公称「到着時間」を補間することができます。したがって
T_loss = T_before + ( (T_after - T_before) * (S_loss - S_before)/(S_after - S_before) );
T_loss = T_before +（（T_after - T_before）*（S_loss - S_before）/（S_after - S_before））。
Note that if the sequence space wrapped between S_before and S_after, then the sequence numbers must be modified to take this into account before performing this calculation. If the largest possible sequence number is S_max, and S_before > S_after, then modifying each sequence number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be sufficient.
S_beforeとS_afterの間で包まれたシーケンス空間場合、シーケンス番号は、この計算を実行する前に、このことを考慮するように修正しなければならないことに注意してください。可能な最大のシーケンス番号は、次にS」=（S +（S_MAX + 1）/ 2）MOD（S_MAX + 1）によって、各シーケンス番号Sを修正S_MAX、及びS_before> S_after、ある場合に通常十分であろう。
If the lost packet S_old was determined to have started the previous loss event, and we have just determined that S_new has been lost, then we interpolate the nominal arrival times of S_old and S_new, called T_old and T_new respectively.
失われたパケットS_oldは以前損失事象を開始していると判定された、と我々はちょうどS_newが失われたと判断した場合は、その後、私たちは、それぞれT_oldとT_new呼ばれ、S_oldとS_newの公称到着時間を補間します。
If T_old + R >= T_new, then S_new is part of the existing loss event. Otherwise S_new is the first packet in a new loss event.
T_old + R> = T_new場合、S_newは、既存の損失事象の一部です。そうでなければS_newは、新たな損失事象の最初のパケットです。
If a loss interval, A, is determined to have started with packet sequence number S_A and the next loss interval, B, started with packet sequence number S_B, then the number of packets in loss interval A is given by (S_B - S_A).
損失間隔、Aは、パケットシーケンス番号S_A及び次損失間隔Bで開始したと判定された場合、パケットシーケンス番号S_Bを開始し、損失区間A内のパケット数がによって与えられる（S_B - S_A）。
To calculate the loss event rate p, we first calculate the average loss interval. This is done using a filter that weights the n most recent loss event intervals in such a way that the measured loss event rate changes smoothly.
損失イベント率pを計算するためには、まず平均損失間隔を計算します。これは、測定損失イベント率が滑らかに変化するような方法で、重みnは、最新の損失事象間隔というフィルタを使用して行われます。
Weights w_0 to w_(n-1) are calculated as:
重みは、のように計算されるW_するW_0（N-1）：
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
Thus if n=8, the values of w_0 to w_7 are:
N = 8の場合したがって、w_7にW_0の値は次のとおりです。
The value n for the number of loss intervals used in calculating the loss event rate determines TFRC's speed in responding to changes in the level of congestion. As currently specified, TFRC should not be used for values of n significantly greater than 8, for traffic that might compete in the global Internet with TCP. At the very least, safe operation with values of n greater than 8 would require a slight change to TFRC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率を計算する際に使用される損失間隔の数の値nは、輻輳のレベルの変化に応答してTFRCの速度を決定します。現在指定されているように、TFRCはTCPとグローバルなインターネットで競争可能性があるトラフィックのために、8よりも有意に大きい、nの値に使用すべきではありません。少なくとも、8よりもn個以上の値を持つ安全な操作が重いパケットロスで二つ以上の往復時間に、より厳しい対応を含めてTFRCのメカニズムにわずかな変更を必要とします。
When calculating the average loss interval we need to decide whether to include the interval since the most recent packet loss event. We only do this if it is sufficiently large to increase the average loss interval.
平均損失間隔を計算するとき、私たちは、最新のパケット損失イベントからの間隔を含めるかどうかを決定する必要があります。平均損失間隔を長くするために十分に大きい場合に私たちはこれを行います。
Thus if the most recent loss intervals are I_0 to I_n, with I_0 being the interval since the most recent loss event, then we calculate the average loss interval I_mean as:
最も最近の損失間隔が値InにI_0であればこのように、I_0は、最新の損失事象以来の間隔であると、我々は、平均損失間隔I_meanを計算します。
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
The loss event rate, p is simply:
損失イベント率は、pは単純です：
p = 1 / I_mean;
P = 1 / I_mean。
As described in Section 5.4, the most recent loss interval is only assigned 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 [3] and [9], 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で説明したように、最新の損失間隔のみにかかわらず、最新の損失間隔の大きさの、平均損失間隔を計算する際に総重量の1 /（0.75 * n）を割り当てられます。このセクションでは、さらににおいて論じ、任意履歴割引機構を説明し[3]、[9]、すなわち、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をして割引率DF_iを関連付け、各割引率は、浮動小数点数がI> 0、のために。割引配列は、それぞれの損失間隔の割引の累積履歴を保持します。初めに、割引配列のDF_iの値が1に初期化されます。
for (i = 1 to n) { DF_i = 1; }
DF_i = 1（i = 1からnまで）{ため、 }
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 interval I_0 that represents the number of packets received since the last loss event. The computation of the average loss interval using the discount factors is a simple modification of the procedure in Section 5.4, as follows:
セクション5.4で説明したように平均損失間隔はn個前の損失間隔I_1、...、値In、及びパケットの数は、最後の損失イベント以降に受信表す間隔I_0を使用して計算されます。次のように割引率を用いて、平均損失間隔の計算は、セクション5.4の手順の簡単な変更です。
I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
p = min(W_tot0/I_tot0, W_tot1/I_tot1);
The general discounting factor, DF is updated on every packet arrival as follows. First, the receiver computes the weighted average I_mean of the loss intervals I_1, ..., I_n:
次のように一般的な割引率は、DFは、すべてのパケットの到着時に更新されます。まず、受信機は、損失間隔I_1の加重平均I_meanを計算...、値Inを：
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = W_tot + w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets received since the last loss event. If I_0 is greater than twice I_mean, then the new loss interval is considerably larger than the old ones, and the general discount factor DF is updated to decrease the relative weight on the older intervals, as follows:
この加重平均I_meanはI_0、最後損失イベント以降に受信したパケットの数と比較されます。 I_0がI_mean倍よりも大きい場合には、新たに損失間隔は、古いものよりもかなり大きく、次のように一般的な割引率DFは、古い間隔の相対的な重みを減少させるために更新されます。
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
A nonzero value for THRESHOLD ensures that older loss intervals from an earlier time of high congestion are not discounted entirely. We recommend a THRESHOLD of 0.5. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
THRESHOLDにゼロ以外の値が高い混雑の早い時間からの古い損失間隔は完全に割り引かれていないことを保証します。我々は0.5のTHRESHOLDをお勧めします。それぞれの新しいパケットの到着で、I_0がさらに増加し、割引率DFが更新されることに注意してください。
When a new loss event occurs, the current interval shifts from I_0 to I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval I_n is forgotten. The previous discount factor DF has to be incorporated into the discount array. Because DF_i carries the discount factor associated with loss interval I_i, the DF_i array has to be shifted as well. This is done as follows:
新しい損失イベントが発生すると、I_1にI_0から現在の間隔シフト、損失間隔I_IはI_の間隔に移行する（I + 1）、及び損失間隔値Inを忘れています。前回の割引率DFは割引配列に組み込まれることがあります。 DF_iは損失間隔I_Iに関連付けられた割引率を運ぶので、DF_iアレイも同様にシフトされなければなりません。これは以下のように行われます。
for (i = 1 to n) {
DF_i = DF * DF_i;
}
for (i = n-1 to 0 step -1) {
DF_(i+1) = DF_i;
}
I_0 = 1;
DF_0 = 1;
DF = 1;
This completes the description of the optional history discounting mechanism. We emphasize that this is an optional mechanism whose sole purpose is to allow TFRC to response 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 send for every data packet received. A feedback packet should also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history.
受信機は、定期的に送信側にフィードバックメッセージを送信します。送信者は、すべてのデータ・パケットを受信するためのフィードバックパケットを送信すべき場合にはRTTごと未満のパケットのレートで送信されていない限り、フィードバックパケットは、通常、RTTごとに少なくとも一度送信されるべきです。フィードバックパケットは、新しい損失イベントがRTTの終了を待たずに検出されるたびに送信され、アウト・オブ・オーダーデータパケットが受信されるたびに、その履歴から、損失イベントを削除しなければなりません。
If the sender is transmitting at a high rate (many packets per RTT) there may be some advantages to sending periodic feedback messages more than once per RTT as this allows faster response to changing RTT measurements, and more resilience to feedback packet loss. However, there is little gain from sending a large number of feedback messages per RTT.
送信者が高率（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) Let the previous value of p be p_prev. Calculate the new value of p as described in Section 5.
2）のpの前の値がp_prevことをしてみましょう。第5節で説明したように、pの新しい値を計算します。
3) If p > p_prev, cause the feedback timer to expire, and perform the actions described in Section 6.2
3）のp> p_prevは、フィードバック・タイマーが期限切れになる場合があり、およびセクション6.2で説明されているアクションを実行した場合
If p <= p_prev no action need be performed.
場合のp <= p_prev何もアクションを実行する必要はありません。
However an 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つの損失間隔が一つに統合された原因かどうかを確認することがあります。この場合、受信機は、すぐにフィードバックを送信することがあります。そのような最適化の効果は、通常は小さいと予想されています。
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.
受信機でのフィードバックタイマーの期限が切れると、取るべき行動は最後のフィードバックが送信されたため、データ・パケットが受信されたかどうかによって異なります。
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. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
受信機におけるパケットの最大シーケンス番号がこれまでS_Mとすると、RTT測定値はR_MことS_Mパケットに含まれます。前のフィードバックを送信してからデータ・パケットを受信した場合、受信機は、以下のステップを実行します。
1) Calculate the average loss event rate using the algorithm described above.
1）上記のアルゴリズムを用いて、平均損失イベント率を計算します。
2) Calculate the measured receive rate, X_recv, based on the packets received within the previous R_m seconds.
2）測定前R_M秒以内に受信されたパケットに基づいて、速度、X_recvを受け取るを計算します。
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秒後に期限切れになるようにフィードバックタイマーを再起動します。
If no data packets have been received since the last feedback was sent, 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 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との秒後に期限切れになるようにフィードバックタイマーを設定します。
The number of packets until the first loss can not be used to compute the 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 sending rate when the loss occurred. TFRC approximates this target rate by X_recv, the receive rate over the most recent round-trip time. 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_recv, and uses this synthetic loss interval to seed the loss history mechanism.
送信速度は、この時間の間に急激に変化するように、第1の損失までのパケットの数は、直接送信速度を計算するために使用することができません。 TFRCは、最初の損失の後に正しいデータ・レートは、損失が発生した送信レートの半分であることを前提としています。 TFRCは、最新の往復時間をかけてX_recv、受信率により、この目標レートに近似します。最初の損失の後、代わりに最初の損失まで、送信されたパケットの数に最初の損失間隔を初期化する、TFRC受信機は、データレートX_recvを生成するために必要とされるであろう損失間隔を算出し、シードするこの合成損失間隔を使用しロス履歴メカニズム。
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_recv, given the current packet size s and round-trip time R. The first loss interval is then set to 1/p. (The 5% tolerance is introduced simply because the throughput equation is difficult to invert, and we want to reduce the costs of calculating p numerically.)
TFRCはR.最初の損失間隔は、その後1 / Pに設定されている現在のパケットサイズSとの往復時間を考慮すると、3.1節におけるスループット方程式はX_recvの5％以内送信速度を与えるためのいくつかの値pを見つけることによってこれを行います。 （スループット方程式が反転することは困難であり、我々は、pの数値を計算するコストを削減したいので、5％の許容差は、単純に導入されています。）
It would be possible to implement a sender-based variant of TFRC, where 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. However, we do not specify the details of a sender-based variant in this document.
受信機が送信者にパケット損失に関する情報を送信するために信頼できる配信を使用し、送信側がパケットロス率と許容される送信レートを算出TFRCのセンダベースの変異体を実現することが可能です。しかし、私たちは、この文書の差出人ベースのバリアントの詳細を指定しないでください。
The main advantages of a sender-based variant of TFRC would be that the sender would 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 such as streaming media from web servers, where it is typically desirable to offload work from the server to the client as much as possible.
対照的に、この文書で指定されたTFRCの受信機ベースの変異体は、フィードバックパケットの損失に対してロバストであるため、フィードバックパケットの信頼できる配信を必要としません。それは、このようなことが可能な限り、サーバからクライアントへの作業負荷を軽減することが一般的に望ましいWebサーバからストリーミングメディアなどのアプリケーションにも適しています。
The sender-based and receiver-based variants also have different properties in terms of upgrades. For example, for changes in the procedure for calculating the packet loss rate, the sender would have to be upgraded in the sender-based variant, and the receiver would have to be upgraded in the receiver-based variant.
送信者ベースとレシーバベースの変異体はまた、アップグレードの面で異なる特性を持っています。例えば、パケット損失率を計算するための手順の変更のために、送信者は、送信者ベースの変異体でアップグレードしなければならず、受信機は受信機ベースの変異体でアップグレードしなければなりません。
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the few 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 = --------
R * f(p)
for
ために
f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)).
F（P）は= SQRT（2 * P / 3）+（12 *のSQRT（3 * P / 8）* P *（1 + 32 * P ^ 2））。
A table lookup could be used for the function f(p).
テーブルルックアップは、関数f（P）を使用することができます。
Many of the multiplications (e.g., q and 1-q for the round-trip time average, a factor of 4 for the timeout interval) are or could be by powers of two, and therefore could be implemented as simple shift operations.
乗算の多く（例えば、Qおよび往復時間平均、タイムアウト間隔の4分の1-q）があるか、または2の累乗によることができ、従って、単純なシフト演算として実現することができます。
We note that the optional sender mechanism for preventing oscillations described in Section 4.5 uses a square-root computation.
私たちは、4.5節で説明した振動を防止するため、オプションの送信者メカニズムは平方根の計算を使用することに注意してください。
The calculation of the average loss interval in Section 5.4 involves multiplications by the weights w_0 to w_(n-1), which for n=8 are:
5.4の平均損失間隔の計算は、重みによって乗算nに= 8である、（N-1）W_するW_0含みます。
With a minor loss of smoothness, it would be possible to use weights that were powers of two or sums of powers of two, e.g.,
滑らかさのマイナー損失と、2の累乗、または例えば2のべき乗の和であった重みを使用することも可能です
The optional history discounting mechanism described in Section 5.5 is used in the calculation of the average loss rate. The history discounting mechanism is invoked only when there has been an unusually long interval with no packet losses. For a more efficient operation, the discount factor DF_i could be restricted to be a power of two.
セクション5.5で説明オプション履歴割引機構は、平均損失率の計算に使用されます。なしパケット損失が異常に長い間隔があった場合にのみ、履歴割引機構が呼び出されます。より効率的な動作については、割引率DF_iは2の累乗に制限することができます。
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 [WES02]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol, and are not addressed in this document.
私たちは、TFRCとECNを取り入れたプロトコルはまた、ECNナンス[WES02]を使用して送信側に受信機からのフィードバックを取り入れたいと思うことを期待しています。 ECNのナンスは、マークされたパケットの偶発的または悪質な隠蔽から送信者を保護ECNの変形です。また、このようなナンスの詳細は、トランスポートプロトコルに依存するであろう、と本書で扱われていません。
There are no IANA actions required for this document.
このドキュメントのために必要な一切IANAのアクションはありません。
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 Ken Lofgren, Mike Luby, Eduardo Urzaiz, Vladica Stanisic, Randall Stewart, 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 the document to produce a working implementation.
私たちは、フィードバックと信頼性の高いマルチキャスト研究グループ、信頼性の高いマルチキャスト交通ワーキンググループ、およびエンドツーエンドの研究グループのメンバーを含む人々の広い範囲、と方程式ベースの輻輳制御に関する議論を確認したいと思います。私たちは、この文書の以前のバージョンへのフィードバックのためにケンロフグレン、マイク・ルビー、エドゥアルドUrzaiz、Vladica Stanisic、ランドール・スチュワート、スサ温家宝、そしてウェンディ・リー（lhh@zsu.edu.cn）を感謝したい、とのためにマーク・オールマンに感謝します作業の実装を生成するために文書を使用してからの彼の豊富なフィードバック。
[1] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, September 1999.
[1]バラクリシュナン、H.、ラーフル、H.、およびS. Seshan、 "インターネットホストのための統合された輻輳管理アーキテクチャ、" PROC。 ACM SIGCOMM、ケンブリッジ、MA、1999年9月。
[2] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", August 2000, Proc. ACM SIGCOMM 2000.
[2]フロイド、S.、ハンドレー、M.、Padhye、J.およびJ.ウィドマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御"、2000年8月、PROC。 ACM SIGCOMM 2000。
[3] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based Congestion Control for Unicast Applications: the Extended Version", ICSI tech report TR-00-03, March 2000.
[3]フロイド、S.、ハンドリー、M.、Padhye、J.とJ.ウィトマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御：拡張版"、ICSIの技術レポートTR-00-03、2000年3月。
[4] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc. ACM SIGCOMM 1998.
[4] Padhye、J.、Firoiu、V.、Towsley、D.およびJ.黒瀬、 "モデルTCPスループット：簡単なモデルとその実証的検証"、PROC。 ACM SIGCOMM 1998。
[5] Paxson V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[5]パクソンV.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[6]ラマクリシュナン、K.、フロイド、S.及びD.黒、 "IPに明示的輻輳通知（ECN）の添加を"、RFC 3168、2001年9月。
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[8] Wetherall, D., Ely, D., N. Spring, S. Savage, and T. Anderson, "Robust Congestion Signaling", IEEE International Conference on Network Protocols, November 2001.
[8] Wetherall、D.、エリー、D.、N.春、S.サベージ、およびT.アンダーソン、 "堅牢な輻輳シグナリング"、ネットワークプロトコル、2001年11月にIEEE国際会議。
[9] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000. URL "http://www.icir.org/tfrc/".
[9]ウィドマー、J.、「式ベースの輻輳制御」、ディプロマ論文、マンハイム大学を、2000年2月URL「http://www.icir.org/tfrc/」。
Mark Handley ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
マーク・ハンドリーICIR / ICSI 1947センターセント、スイート600バークレー、CA 94708
EMail: mjh@icir.org
メールアドレス：mjh@icir.org
Sally Floyd ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
サリーフロイドICIR / ICSI 1947センターセント、スイート600バークレー、CA 94708
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Jitendra Padhye Microsoft Research
Jitendra Padhyeマイクロソフトリサーチ
EMail: padhye@microsoft.com
メールアドレス：padhye@microsoft.com
Joerg Widmer Lehrstuhl Praktische Informatik IV Universitat Mannheim L 15, 16 - Room 415 D-68131 Mannheim Germany
イェルクウィドマー議長実践的コンピュータサイエンスIV理学部マンハイムL 15 16 - ルーム415 D-68131マンハイムドイツ
EMail: widmer@informatik.uni-mannheim.de
メールアドレス：widmer@informatik.uni-mannheim.de
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。