[要約] RFC 3448は、TCPに優しいレート制御（TFRC）プロトコルの仕様を定めたものです。その目的は、ネットワーク上でのフェアな帯域幅の共有を実現することです。
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
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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]。完全なプロトコルを指定する代わりに、このドキュメントは、RTP [7]などのトランスポートプロトコルで使用できる混雑制御メカニズム、アプリケーションレベル、またはコンテキストにエンドツーエンドの輻輳制御を組み込んだアプリケーションで単純に指定するだけです。エンドポイントの混雑管理の[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フローと帯域幅を競うときに合理的に公平になるように設計されています。この流れは、同じ条件下で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 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は、固定パケットサイズを使用するアプリケーション向けに設計されており、輻輳に応じて1秒あたりのパケットの送信率を変更します。一部のオーディオアプリケーションでは、パケット間の固定時間間隔が必要であり、混雑に応じてパケットレートではなくパケットサイズを変化させます。このドキュメントの混雑制御メカニズムは、これらのアプリケーションでは使用できません。TFRC-PS（TFRC-Packetsizeの場合）は、固定送信率を持つアプリケーションの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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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の送信率を、損失イベント率、往復時間、パケットサイズの関数として大まかに説明しています。損失イベントを、データのウィンドウから1つ以上の紛失またはマークされたパケットと定義します。マークされたパケットは、明示的な輻輳通知（ECN）からの輻輳表示を指します[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の再送信タイムアウト動作を反映する必要があることに注意してください。また、損失イベント率パラメーターに関するスループット方程式に暗示される仮定は、損失率または損失イベント率が実際にどのように測定されるかと合理的な一致でなければならないことに注意してください。この一致は、以下に示すスループット方程式および損失率の測定メカニズムに最適ではありませんが、実際には、仮定は十分に近いことが判明しています。
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]のReno TCPのスループット方程式のわずかに単純化されたバージョンです。理想的には、Sack TCPに基づくスループット方程式を好むでしょうが、Sack TCPのスループット方程式をまだ導き出していない人はいません。シミュレーションと実験の両方から、2つの方程式間の違いは比較的マイナーです。
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]。別の可能性は、T_RTO = MAX（4R、1秒）を設定して、RTO [5]で推奨される最低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実装では遅延承認を使用しないため、b = 1をお勧めします。
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の測定値はセクション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 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 パケットがいつ送信されるかを示すタイムスタンプ。TS_Iによって、シーケンス番号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.
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 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.
o NoFeedbackタイマーが期限切れになったときの送信者の動作。
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 パケットサイズは自然にデータによって異なります。この場合、パケットサイズは異なりますが、その変動は送信速度に結合されていません。通常、sの平均パケットサイズの推定値を使用することは安全である必要があります。
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 アプリケーションは、混雑制御を実行するために、毎秒パケット数ではなくパケットサイズを変更する必要があります。これは通常、各パケットで固定された時間間隔を表す必要があるパケットオーディオアプリケーションの場合です。このようなアプリケーションは、パラメーターを測定するまったく異なる方法を持つ必要があります。
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.
アプリケーションの2番目のクラスについては、TFRC-PSの別のドキュメントで個別に説明されています。このセクションの残りの部分では、送信者がパケットサイズを推定できると想定し、その混雑制御は1秒あたりのパケットの数を調整することで実行されます。
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.
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の場合、送信者はスロースタートフェーズにあり、損失が発生するまで各往復時間をほぼ2倍にすることに注意してください。S/R用語は、RTTごとに1つのパケットのスロースタート中に最小送信率を示します。パラメーターT_MBIは64秒で、フィードバックが持続しない場合の最大パケット間のバックオフ間隔を表します。したがって、p> 0の場合、送信者は64秒ごとに少なくとも1つのパケットを送信します。
5) Reset the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
5) NoFeedbackタイマーをリセットして、最大（4*r、2*s/x）秒後に期限切れになります。
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の最大2倍に制限されるため、X_RECVを変更すると現在の送信率が制限されますが、送信者がスロースタートを可能にし、フィードバックメッセージが損失を報告しない場合、各RTTの送信率を2倍にします。
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秒ごとにバックオフを1つのパケットに制限します。
2) The value of X must then be recalculated as described under point (4) above.
2) xの値は、上記の点（4）で説明されているように再計算する必要があります。
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) nofeedbackタイマーを再起動して、最大（4*r、2*s/x）秒後に期限切れになります。
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);
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_IPI-（T_NOW -T_0））秒。アプリケーションが再スケジュールされると、現在の時刻をチェックします。（t_now> t_1 -delta）の場合、パケット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：T2 = T_1 T_IPIの公称送信時間T_2の計算に使用されます。その後、プロセスが繰り返され、連続する各パケットの送信時間は、前のパケットの公称送信時間から計算されます。
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 -deltaである場合があります。そのような場合、パケットはすぐに送信する必要があります。したがって、オペレーティングシステムに粗いタイマーの粒度が高く、送信速度が高い場合、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_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が不明な場合、10msの値を安全に想定できます。
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をより堅牢にすることです。TCPとは対照的に、TFRCでパケットが遅れて（後続の3つのパケットが到着した後）に到着した場合、後期パケットは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では、これらのパケットが同じ損失イベントの一部である場合、損失分率が失われたいくつかの連続したパケットに対して堅牢であることが必要です。これは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 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_BEFOREDとS_AFTERの到着時間から受信機に名目上の「到着時間」を補間することができます。したがって：
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.
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は新しい損失イベントの最初のパケットです。
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で開始されたと判断された場合、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を計算するために、最初に平均損失間隔を計算します。これは、測定された損失イベントレートがスムーズに変化するように、最新の損失イベント間隔を重み付けするフィルターを使用して行われます。
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 = 1 - (i - (n/2 - 1))/(n/2 + 1);
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. 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の値に使用しないでください。少なくとも、Nの値が8を超える安全な動作には、TFRCのメカニズムにわずかな変更が必要になり、パケット損失が大きい2つ以上の往復時間に対するより深刻な反応が含まれます。
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:
したがって、最新の損失間隔がI_0からI_Nの場合、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;
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:
履歴割引を実行するために、割引係数DF_Iを各損失間隔l_iに関連付けます。これは、各割引係数が浮動小数点数です。割引アレイは、各損失間隔の割引の累積履歴を維持します。最初は、割引アレイ内のDF_Iの値が1に初期化されます。
for (i = 1 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 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で説明されているように、平均損失間隔は、前の損失間隔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 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が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.5. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
しきい値のゼロ以外の値は、高い輻輳の初期の時期からの古い損失間隔が完全に割引されないことを保証します。0.5のしきい値をお勧めします。新しいパケット到着ごとに、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 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ごとに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. However, there is little gain from sending a large number of feedback messages per RTT.
送信者が高いレートで送信している場合（RTTごとに多くのパケット）、RTTごとに定期的なフィードバックメッセージを1回以上送信することには、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つの損失間隔が1つにマージされました。この場合、レシーバーもすぐにフィードバックを送信する場合があります。このような最適化の影響は通常、小さいと予想されます。
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とし、パケットS_Mに含まれるRTT測定値の値をR_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.
この間、送信速度が急速に変化するため、最初の損失が送信率を直接計算するために最初の損失までのパケットの数を使用できません。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は、セクション3.1のスループット方程式が現在のパケットサイズsと往復時間Rを考慮して、X_RECVの5％以内の送信率を提供するいくつかの値Pを見つけることでこれを行います。次に、最初の損失間隔は1/pに設定されます。（5％の許容範囲は、単にスループット方程式を反転させるのが難しいという理由だけで導入されており、Pの計算コストを数値的に削減したいと考えています。）
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および1-Q、タイムアウト間隔の4因子）は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の平均損失間隔の計算には、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つのパワーに制限される可能性があります。
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.
ECNをTFRCに組み込むプロトコルは、ECN NonCe [WES02]を使用して受信機から送信者へのフィードバックを組み込むことも期待しています。ECN Nonceは、マークされたパケットの偶発的または悪意のある隠蔽から送信者を保護する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.
信頼できるマルチキャスト研究グループのメンバー、信頼できるマルチキャスト輸送ワーキンググループ、エンドツーエンドの研究グループを含む幅広い人々との方程式ベースの混雑制御に関するフィードバックと議論を認めたいと思います。Ken Lofgren、Mike Luby、Eduardo Urzaiz、Vladica Stanisic、Randall Stewart、Shushan Wen、およびWendy Lee（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] Balakrishnan、H.、Rahul、H。、およびS. Seshan、「インターネットホスト向けの統合渋滞管理アーキテクチャ」、Proc。ACM SIGCOMM、ケンブリッジ、マサチューセッツ州、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] Floyd、S.、Handley、M.、Padhye、J。and J. widmer、「ユニキャストアプリケーションの方程式ベースのうっ血制御」、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] Floyd、S.、Handley、M.、Padhye、J。and J. Widmer、「ユニキャストアプリケーションの方程式ベースの輻輳制御：拡張バージョン」、ICSI Tech Report 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. Kurose、「モデリングTCPスループット：単純なモデルとその経験的検証」、Proc。ACM SIGCOMM 1998。
[5] Paxson V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[5] Paxson V.およびM. Allman、「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] Ramakrishnan、K.、Floyd、S。and D. Black、「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.、Frederick、R。and 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.、Ely、D.、N。Spring、S。Savage、およびT. Anderson、「Robust Musemestion Signaling」、IEEE International Conference on Network Protocols、2001年11月。
[9] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000. URL "http://www.icir.org/tfrc/".
[9] Widmer、J。、「方程式ベースの混雑制御」、卒業証書、マンハイム大学、2000年2月。URL「http://www.icir.org/tfrc/」。
Mark Handley ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
Mark Handley ICIR/ICSI 1947 Center St、Suite 600 Berkeley、CA 94708
EMail: mjh@icir.org
Sally Floyd ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
Sally Floyd ICIR/ICSI 1947 Center St、Suite 600 Berkeley、CA 94708
EMail: floyd@icir.org
Jitendra Padhye Microsoft Research
Jitendra Padhye Microsoft Research
EMail: padhye@microsoft.com
Joerg Widmer Lehrstuhl Praktische Informatik IV Universitat Mannheim L 15, 16 - Room 415 D-68131 Mannheim Germany
Joerg Widmer Lehrstuhl Praktische Informatik IV Universitat Mannheim L 15、16 -Room 415 D -68131 Mannheim Germany
EMail: widmer@informatik.uni-mannheim.de
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。