RFC5348 日本語訳
5348 TCP Friendly Rate Control (TFRC): Protocol Specification. S.Floyd, M. Handley, J. Padhye, J. Widmer. September 2008. (Format: TXT=133185 bytes) (Obsoletes RFC3448) (Updates RFC4342) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Floyd
Request for Comments: 5348 ICIR
Obsoletes: 3448 M. Handley
Updates: 4342 University College London
J. Padhye
Microsoft
J. Widmer
DoCoMo
September 2008
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 5348ICIRは以下を時代遅れにします。 3448のM.ハンドレーアップデート: 4342 ユニバーシティ・カレッジロンドンJ.PadhyeマイクロソフトJ.ウィトマーDoCoMo2008年9月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.
このドキュメントはTCP Friendly Rate Control(TFRC)を指定します。 TFRCは最も良い取り組みインターネット環境で作動するユニキャスト流れのための混雑制御機構です。 それで、TCP流れで帯域幅を競争するとき、合理的に公正ですが、時間がたつにつれてスループットのはるかに低い変化をTCPと比較します、それを比較的滑らかな送付レートが重要であるストリーミング・メディアなどのアプリケーションにより適するようにして。
This document obsoletes RFC 3448 and updates RFC 4342.
このドキュメントは、RFC3448を時代遅れにして、RFC4342をアップデートします。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Protocol Mechanism ..............................................4
3.1. TCP Throughput Equation ....................................5
3.2. Packet Contents ............................................7
3.2.1. Data Packets ........................................7
3.2.2. Feedback Packets ....................................8
4. Data Sender Protocol ............................................8
4.1. Measuring the Segment Size .................................9
4.2. Sender Initialization .....................................10
4.3. Sender Behavior When a Feedback Packet Is Received ........10
4.4. Expiration of Nofeedback Timer ............................15
4.5. Reducing Oscillations .....................................17
1. 序論…3 2. コンベンション…4 3. メカニズムについて議定書の中で述べてください…4 3.1. TCPスループット方程式…5 3.2. パケットコンテンツ…7 3.2.1. データパケット…7 3.2.2. フィードバックパケット…8 4. データ送付者は議定書を作ります…8 4.1. セグメントサイズを測定します…9 4.2. 送付者初期設定…10 4.3. フィードバックパケットであるときに、送付者の振舞いは受け取られています…10 4.4. Nofeedbackタイマの満了…15 4.5. 振動を抑えます…17
Floyd, et al. Standards Track [Page 1] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[1ページ]: プロトコル仕様2008年9月
4.6. Scheduling of Packet Transmissions ........................18
5. Calculation of the Loss Event Rate (p) .........................19
5.1. Detection of Lost or Marked Packets .......................19
5.2. Translation from Loss History to Loss Events ..............20
5.3. The Size of a Loss Interval ...............................22
5.4. Average Loss Interval .....................................22
5.5. History Discounting .......................................24
6. Data Receiver Protocol .........................................26
6.1. Receiver Behavior When a Data Packet Is Received ..........27
6.2. Expiration of Feedback Timer ..............................27
6.3. Receiver Initialization ...................................28
6.3.1. Initializing the Loss History after the
First Loss Event ...................................29
7. Sender-Based Variants ..........................................30
8. Implementation Issues ..........................................31
8.1. Computing the Throughput Equation .........................31
8.2. Sender Behavior When a Feedback Packet Is Received ........32
8.2.1. Determining If an Interval Was a
Data-Limited Interval ..............................32
8.2.2. Maintaining X_recv_set .............................34
8.3. Sending Packets before Their Nominal Send Time ............34
8.4. Calculation of the Average Loss Interval ..................36
8.5. The Optional History Discounting Mechanism ................36
9. Changes from RFC 3448 ..........................................36
9.1. Overview of Changes .......................................36
9.2. Changes in Each Section ...................................37
10. Security Considerations .......................................39
10.1. Security Considerations for TFRC in DCCP .................40
11. Acknowledgments ...............................................40
Appendix A. Terminology ...........................................41
Appendix B. The Initial Value of the Nofeedback Timer .............43
Appendix C. Response to Idle or Data-Limited Periods ..............44
C.1. Long Idle or Data-Limited Periods ........................45
C.2. Short Idle or Data-Limited Periods .......................48
C.3. Moderate Idle or Data-Limited Periods ....................49
C.4. Losses During Data-Limited Periods .......................50
C.5. Other Patterns ...........................................53
C.6. Evaluating TFRC's Response to Idle Periods ...............53
References ........................................................54
Normative References ...........................................54
Informative References .........................................54
4.6. パケット伝送のスケジューリング…18 5. 損失イベントレート(p)の計算…19 5.1. 無くなっているか著しいパケットの検出…19 5.2. 損失歴史から損失イベントまでの翻訳…20 5.3. 損失間隔のサイズ…22 5.4. 損失間隔を平均してください…22 5.5. 歴史の値段をひくこと…24 6. データ受信機は議定書を作ります…26 6.1. データ・パケットであるときに、受信機の振舞いは受け取られています…27 6.2. フィードバックタイマの満了…27 6.3. 受信機初期設定…28 6.3.1. 最初の損失イベントの後に損失歴史を初期化します…29 7. 送付者ベースの異形…30 8. 実装問題…31 8.1. スループット方程式を計算します…31 8.2. フィードバックパケットであるときに、送付者の振舞いは受け取られています…32 8.2.1. 確認して、間隔はデータ株式会社間隔でした…32 8.2.2. X_recv_を維持するのはセットしました…34 8.3. 以前パケットを送る、それら、名目上、時間を送ってください…34 8.4. 海損間隔の計算…36 8.5. 任意の歴史値段をひくメカニズム…36 9. RFC3448からの変化…36 9.1. 変化の概要…36 9.2. 各セクションにおける変化…37 10. セキュリティ問題…39 10.1. DCCPのTFRCのためのセキュリティ問題…40 11. 承認…40 付録A.用語…41 初期が評価するNofeedbackタイマの付録B.…空費する43付録C.応答かデータ限定期間…44 C.1。 長い活動していないかデータ限定期間…45 C.2。 短い活動していないかデータ限定期間…48 C.3。 活動していないかデータ限定期間を加減してください…49 C.4。 データ限定期間の間の損失…50 C.5。 他のパターン…53 C.6。 活動していない期間へのTFRCの応答を評価します…53の参照箇所…54 標準の参照…54 有益な参照…54
Floyd, et al. Standards Track [Page 2] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[2ページ]: プロトコル仕様2008年9月
1. Introduction
1. 序論
This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [FHPW00]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as DCCP (Datagram Congestion Control Protocol) [RFC4340], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [BRS99]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
このドキュメントはTCP Friendly Rate Control(TFRC)を指定します。 TFRCはインターネット環境で作動するユニキャスト流れとTCPトラフィック[FHPW00]と競争するように設計された混雑制御機構です。 完全なプロトコルを指定することの代わりに、このドキュメントは単に、DCCP(データグラムCongestion Controlプロトコル)[RFC4340]などのトランスポート・プロトコルに使用できた混雑制御機構を指定します、アプリケーションレベルにおいて、または、終点ふくそう管理の文脈に終わりからエンドへの輻輳制御を取り入れるアプリケーションで[BRS99]。 このドキュメントはパケット・フォーマットか信頼性について議論しません。 セクション8で簡潔にだけ実施問題について議論します。
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where we call a flow "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
TCP流れを伴う帯域幅(一般にTCP流動の2つの送付速度の要素の中に送付レートが同じ状態であるなら、私たちは、流れが「合理的に公正である」と言う)を競争するとき、TFRCは、合理的に公正になるように設計されます。 しかしながら、TFRCは時間がたつにつれて、スループットのはるかに低い変化をTCPと比較させます。(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より遅く利用可能な帯域幅の変化に応じるということです。 したがって、1パケット滴に対応してアプリケーションにTCPを特に避けると半分にされる送付レートの滑らかなスループットのための要件があると、TFRCは使用されるだけであるべきです。 Additive-増加、Multiplicative-減少(AIMD)輻輳制御を使用して、可能であることで、私たちが、TCPを使用することを勧める時、または信頼性は必要でないなら単に可能であるとしての短いのと同じくらい多くのデータを移す必要があるアプリケーションをTCPによって使用されたものに同様のパラメタで計画してください。
TFRC is designed for best performance with applications that use a fixed segment size, and vary their sending rate in packets per second in response to congestion. TFRC can also be used, perhaps with less optimal performance, with applications that do not have a fixed segment size, but where the segment size varies according to the needs of the application (e.g., video applications).
TFRCは最も良い性能のために固定セグメントサイズを使用して、1秒あたりのパケットで混雑に対応してそれらの送付レートを変えるアプリケーションで設計されています。 また、TFRCを使用できます、恐らくそれほど最適でない性能で、固定セグメントサイズを持っていませんが、アプリケーションの必要性に従ってセグメントサイズが異なるアプリケーション(例えば、ビデオ・アプリケーション)で。
Some applications (e.g., some audio applications) require a fixed interval of time between packets and vary their segment size instead of their packet rate in response to congestion. The congestion control mechanism in this document is not designed for those applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for applications that have a fixed sending rate in packets per second but either use small packets or vary their packet size in response to congestion. TFRC-SP is specified in a separate document [RFC4828].
いくつかのアプリケーション(例えばいくつかのオーディオアプリケーション)が、パケットの間の時間の固定間隔を必要として、混雑に対応したそれらのパケットレートの代わりにそれらのセグメントサイズを変えます。 混雑制御機構はそれらのアプリケーションのために本書では設計されていません。 TFRC-SP(小さいパケットTFRC)は1秒あたりのパケットに固定送付レートを持っていますが、小型小包を使用するか、または混雑に対応してそれらのパケットサイズを変えるアプリケーションのためのTFRCの異形です。 TFRC-SPは別々のドキュメント[RFC4828]で指定されます。
Floyd, et al. Standards Track [Page 3] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[3ページ]: プロトコル仕様2008年9月
This document specifies TFRC as a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control. However, it is also possible to implement TFRC in sender-based variants, as allowed in DCCP's Congestion Control ID 3 (CCID 3) [RFC4342].
このドキュメントは受信機ベースのメカニズムとしてTFRCを指定します、混雑制御情報(すなわち、損失イベント率)の計算がむしろデータ送付者のデータ受信装置にある状態で。 これは送付者が多くの同時接続を扱う大きいサーバであり、受信機が計算に利用可能なより多くの記憶力とCPUサイクルを過すアプリケーションに十分合っています。 さらに、受信機ベースのメカニズムはマルチキャスト輻輳制御のためのブロックとして、より適当です。 しかしながら、また、送付者ベースの異形でTFRCを実装するのも可能です、DCCPのCongestion Control ID3(CCID3)[RFC4342]で許容されているように。
This document obsoletes RFC 3448. In the transport protocol DCCP (Datagram Congestion Control Protocol) [RFC4340], the Congestion Control ID Profiles CCID-3 [RFC4342] and CCID-4 [CCID-4] both specify the use of TFRC from RFC 3448. CCID-3 and CCID-4 implementations SHOULD use this document instead of RFC 3448 for the specification of TFRC.
このドキュメントはRFC3448を時代遅れにします。 トランスポート・プロトコルDCCP(データグラムCongestion Controlプロトコル)[RFC4340]では、Congestion Control ID Profiles CCID-3[RFC4342]とCCID-4[CCID-4]はRFC3448からTFRCの使用をともに指定します。 CCID-3とCCID-4実装SHOULDはRFC3448の代わりにTFRCの仕様のためのこのドキュメントを使用します。
The normative specification of TFRC is in Sections 3-6. Section 7 discusses sender-based variants, Section 8 discusses implementation issues, and Section 9 gives a non-normative overview of differences with RFC 3448.
TFRCの標準の仕様がセクション3-6にあります。 セクション7が論ずる、送付者ベース、異形、セクション8は導入問題について議論して、セクション9はRFC3448がある違いの非標準の概要を与えます。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Appendix A gives a list of technical terms used in this document.
付録Aは本書では使用される専門用語のリストを与えます。
3. Protocol Mechanism
3. プロトコルメカニズム
For its congestion control mechanism, TFRC directly uses a throughput equation for the allowed sending rate as a function of the loss event rate and round-trip time. In order to compete fairly with TCP, TFRC uses the TCP throughput equation, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time, and segment size. We define a loss event as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [RFC3168].
混雑制御機構のために、TFRCは損失イベント率と往復の現代の関数として直接許容送付レートのためのスループット方程式を使用します。 TCPと公正に競争するために、TFRCはTCPスループット方程式を使用します。(およそ、それは、損失イベント率、往復の時間、およびセグメントサイズの関数としてTCPの送付レートを記述します)。 私たちが損失イベントを1つと定義するか、または以上は、データの窓からパケットを失ったか、マークしました(電子証券取引ネットワーク)[RFC3168]。(そこでは、著しいパケットがExplicit Congestion Notificationから混雑指示について言及します)。
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 受信機は、損失イベント率を測定して、この情報を送付者に提供して戻します。
Floyd, et al. Standards Track [Page 4] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[4ページ]: プロトコル仕様2008年9月
o The sender also uses these feedback messages to measure the
round-trip time (RTT).
o また、送付者は往復の時間(RTT)を測定するこれらのフィードバックメッセージを使用します。
o The loss event rate and RTT are then fed into TFRC's throughput
equation, and the resulting sending rate is limited to at most
twice the receive rate to give the allowed transmit rate X.
o レートを受け取ってください。次に、損失イベント率とRTTをTFRCのスループット方程式に入れて、結果として起こる送付レートを高々二度制限する、許容を与えるのはレートXを伝えます。
o The sender then adjusts its transmit rate to match the allowed
transmit rate X.
o 合うようにレートを伝えてください。次に、送付者が適応する、それ、許容はレートXを伝えます。
The dynamics of TFRC are sensitive to how the measurements are performed and applied. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand how the interactions between mechanisms affect the dynamics of TFRC.
TFRCの力学は測定がどう実行されて、適用されるかに敏感です。 私たちは、以下の特定のメカニズムがこれらの測定を実行して、当てはまることを勧めます。 他のメカニズムは可能ですが、メカニズムの間の相互作用がどのようにTFRCの力学に影響するかを理解しているのは重要です。
3.1. TCP Throughput Equation
3.1. TCPスループット方程式
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFRC. However, we note that the TCP throughput equation used must reflect TCP's retransmit timeout behavior, as this dominates TCP throughput at higher loss rates. We also note that the assumptions implicit in the throughput equation about the loss event rate parameter have to be a reasonable match to how the loss rate or loss event rate is actually measured. While this match is not perfect for the throughput equation and loss rate measurement mechanisms given below, in practice the assumptions turn out to be close enough.
損失のイベント率とRTTの機能としてスループットをTCPに与えるどんな現実的な方程式もTFRCにおける使用に適しているべきです。 しかしながら、私たちは、使用されるTCPスループット方程式が反射しなければならないことに注意します。TCPのものはタイムアウトの振舞いを再送します、これが、より高い損失率でTCPスループットを支配するとき。 また、私たちは、損失イベントレートパラメタに関するスループット方程式による暗黙の仮定が損失率か損失イベント率が実際にどう測定されるかへの妥当なマッチでなければならないことに注意します。 スループット方程式と以下に与えられた損失レート測定メカニズムには、このマッチが完全でない間、実際には、仮定は、十分近くにあるように判明します。
The throughput equation currently REQUIRED for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [PFTK98]. Ideally, we would prefer a throughput equation based on selective acknowledgment (SACK) TCP, but no one has yet derived the throughput equation for SACK TCP, and simulations and experiments suggest that the differences between the two equations would be relatively minor [FF99] (Appendix B).
TFRCのための現在のスループット方程式REQUIREDは[PFTK98]からのリノTCPのためのスループット方程式のわずかに簡易型のバージョンです。 だれもSACK TCPのためにまだスループット方程式を引き出していません、そして、理想的に、私たちは選択している承認(SACK)TCPに基づくスループット方程式を好むでしょうが、シミュレーションと実験は2つの方程式の違いが比較的小さい方の[FF99](付録B)であると示唆します。
The throughput equation for X_Bps, TCP's average sending rate in bytes per second, is:
X_Bpsのためのスループット方程式(1秒あたりのバイトで表現されるTCPの平均した送付レート)は以下の通りです。
s
X_Bps = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))
s X_bps=---------------------------------------------------------- R*sqrt(2*b*p/3)+(t_RTO*(3*sqrt(3*b*p/8)*p*(1+32*p^2)))
Where:
どこ:
X_Bps is TCP's average transmit rate in bytes per second. (X_Bps
is the same as X_calc in RFC 3448.)
X_ビーピーエスはTCPの平均が1秒あたりのバイトで表現されるレートを伝えるということです。 (X_ビーピーエスはRFC3448でX_電卓と同じです。)
Floyd, et al. Standards Track [Page 5] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[5ページ]: プロトコル仕様2008年9月
s is the segment size in bytes (excluding IP and transport
protocol headers).
sはバイト(IPとトランスポート・プロトコルヘッダーを除いた)で表現されるセグメントサイズです。
R is the round-trip time in seconds.
Rは秒の往復の時間です。
p is the loss event rate, between 0 and 1.0, of the number of loss
events as a fraction of the number of packets transmitted.
パケットの数の部分が伝わったように、pは、損失イベント率、0〜損失イベントの1.0の数です。
t_RTO is the TCP retransmission timeout value in seconds.
t_RTOは秒のTCP再送タイムアウト価値です。
b is the maximum number of packets acknowledged by a single TCP
acknowledgement.
bはただ一つのTCP承認で承認されたパケットの最大数です。
Setting the TCP retransmission timeout value t_RTO: Implementations SHOULD set t_RTO = 4*R. Implementations MAY choose to implement a more accurate calculation of t_RTO. Implementations MAY also set t_RTO to max(4*R, one second), to match the recommended minimum of one second on the RTO [RFC2988].
TCP再送タイムアウトを設定して、t_RTOを評価してください: 実装SHOULDはt_RTO=4*Rを設定します。 実装は、t_RTOの、より正確な計算を実装するのを選ぶかもしれません。 また、実装は、RTO[RFC2988]の上の1秒のお勧めの最小限を合わせるためにt_RTOに最大限にする(4*R、1秒)ように設定するかもしれません。
Setting the parameter b for delayed acknowledgements: Some current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received. However, TCP is also allowed to send an acknowledgement for every data packet. For the revised TCP congestion control mechanisms, [RFC2581bis] currently specifies that the delayed acknowledgement algorithm should be used with TCP. However, [RFC2581bis] recommends increasing the congestion window during congestion avoidance by one segment per RTT even in the face of delayed acknowledgements, consistent with a TCP throughput equation with b = 1. On an experimental basis, [RFC2581bis] allows for increases of the congestion window during slow-start that are also consistent with a TCP throughput equation with b = 1. Thus, the use of b = 1 is consistent with [RFC2581bis]. The use of b = 1 is RECOMMENDED.
遅れた承認のためのパラメタbを設定します: パケットが受け取った2つのデータ毎のための承認を送って、何らかの現在のTCP接続使用が承認を遅らせました。 しかしながら、また、TCPはあらゆるデータ・パケットのための承認を送ることができます。 改訂されたTCP混雑制御機構として、[RFC2581bis]は、現在、遅れた承認アルゴリズムがTCPと共に使用されるべきであると指定します。 しかしながら、[RFC2581bis]は、遅れた承認に直面してさえ輻輳回避の間、1RTTあたり1つのセグメントで混雑ウィンドウを増強することを勧めます、b=1でTCPスループット方程式と一致しています。 実験的に、[RFC2581bis]は遅れた出発の間の混雑ウィンドウのまた、b=1でTCPスループット方程式と一致した増加を考慮します。 したがって、b=1の使用は[RFC2581bis]と一致しています。 b=1の使用はRECOMMENDEDです。
With t_RTO=4*R and b=1, the throughput equation for X_Bps, the TCP sending rate in bytes per second, can be simplified as:
t_RTO=4*Rとb=1と共に、以下としてX_Bpsのためのスループット方程式(1秒あたりのバイトで表現されるTCP送付レート)を簡素化できます。
s
X_Bps = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
s X_bps=----------------------------------------------- R*(sqrt(2*p/3)+12*sqrt(3*p/8)*p*(1+32*p^2))
In the future, updates to this document could specify different TCP equations to be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来、このドキュメントへのアップデートは、この方程式に代入するために異なったTCP方程式を指定するかもしれません。 要件はスループット方程式がconformant TCP輻輳制御のためのTCPの送付レートの合理的な近似であるということです。
Floyd, et al. Standards Track [Page 6] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[6ページ]: プロトコル仕様2008年9月
The throughput equation can also be expressed in terms of X_pps, the sending rate in packets per second, with
また、X_pps、1秒あたりのパケットの送付レートでスループット方程式を言い表すことができます。
X_pps = X_Bps / s .
X_pps=X_bps/s。
The parameters s (segment size), p (loss event rate), and R (RTT) need to be measured or calculated by a TFRC implementation. The measurement of s is specified in Section 4.1, the measurement of R is specified in Section 4.3, and the measurement of p is specified in Section 5. In the rest of this document, data rates are measured in bytes per second unless otherwise specified.
パラメタs(セグメントサイズ)、p(損失イベント率)、およびR(RTT)は、TFRC実装によって測定されるか、または計算される必要があります。 sの測定はセクション4.1で指定されます、そして、Rの測定はセクション4.3で指定されます、そして、pの測定はセクション5で指定されます。 このドキュメントの残りでは、別の方法で指定されない場合、データ信号速度は1秒あたりのバイトで測定されます。
3.2. Packet Contents
3.2. パケットコンテンツ
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がトランスポート・プロトコルと共に使用されるとき、私たちはパケット・フォーマットを指定しません、これらが使用されるトランスポート・プロトコルの詳細によるとき。
3.2.1. Data Packets
3.2.1. データ・パケット
Each data packet sent by the data sender contains the following information:
データ送付者によって送られた各データ・パケットは以下の情報を含んでいます:
o A sequence number. This number MUST be incremented by one for
each data packet transmitted. The field must be sufficiently
large that it does not wrap causing two different packets with
the same sequence number to be in the receiver's recent packet
history at the same time.
o 一連番号。 この数を伝えられた各データ・パケットあたり1つ増加しなければなりません。 分野はそれがする多、が同じ一連番号で2つの引き起こすことの異なった荷を同時に、受信機の最近のパケット歴史にあるくらいには包装しないということであるに違いありません。
o A timestamp indicating when the packet is sent. We denote by
ts_i the timestamp of the packet with sequence number i. The
resolution of the timestamp SHOULD typically be measured in
milliseconds.
o パケットがいつ送られるかを示すタイムスタンプ。 私たちはt_iで一連番号iがあるパケットに関するタイムスタンプを指示します。 解決、タイムスタンプSHOULDでは、ミリセカンドで通常測定されてください。
This timestamp is used by the receiver to determine which losses
belong to the same loss event. The timestamp is also echoed by
the receiver to enable the sender to estimate the round-trip
time, for senders that do not save timestamps of transmitted data
packets.
このタイムスタンプは受信機によって使用されて、どの損失が同じ損失イベントに属すかを決定します。 また、タイムスタンプは受信機によって反映されて、送付者が往復の時間を見積もっているのを可能にします、伝えられたデータ・パケットに関するタイムスタンプを保存しない送付者のために。
We note that, as an alternative to a timestamp incremented in
milliseconds, a "timestamp" that increments every quarter of a
round-trip time MAY be used for determining when losses belong to
the same loss event, in the context of a protocol where this is
understood by both sender and receiver and where the sender saves
the timestamps of transmitted data packets.
私たちは、往復の時間のあらゆる4分の1を増加する「タイムスタンプ」は損失がいつ同じ損失イベントに属すかを決定するのに使用されるかもしれません、ミリセカンドで増加されたタイムスタンプに代わる手段としてこれが送付者と受信機の両方に解釈されて、送付者が伝えられたデータ・パケットに関するタイムスタンプを保存するプロトコルの文脈で注意します。
Floyd, et al. Standards Track [Page 7] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[7ページ]: プロトコル仕様2008年9月
o The sender's current estimate of the round-trip time. The
estimate reported in packet i is denoted by R_i. The round-trip
time estimate is used by the receiver, along with the timestamp,
to determine when multiple losses belong to the same loss event.
The round-trip time estimate is also used by the receiver to
determine the interval to use for calculating the receive rate
and to determine when to send feedback packets.
o 送付者の往復の現代の現状見積金額。 パケットiで報告された見積りはR_iによって指示されます。 往復の時間見積りはタイムスタンプに伴う受信機によって使用されて、複数の損失がいつ同じ損失イベントに属すかを決定します。 そして、また、往復の時間見積りが間隔が計算するのに使用することを決定する受信機によって使用される、レートを受け取ってください、いつフィードバックパケットを送るかを決定するために。
If the sender sends a coarse-grained "timestamp" that increments
every quarter of a round-trip time, as discussed above, then the
sender is not required to send its current estimate of the round
trip time.
送付者が上で議論するように往復の時間のあらゆる4分の1を増加する下品な「タイムスタンプ」を送るなら、送付者は周遊旅行時間の現状見積金額を送る必要はありません。
3.2.2. Feedback Packets
3.2.2. フィードバックパケット
Each feedback packet sent by the data receiver contains the following information:
データ受信装置によって送られたそれぞれのフィードバックパケットは以下の情報を含んでいます:
o The timestamp of the last data packet received. We denote this by
t_recvdata. If the last packet received at the receiver has
sequence number i, then t_recvdata = ts_i. This timestamp is
used by the sender to estimate the round-trip time, and is only
needed if the sender does not save the timestamps of transmitted
data packets.
o 最後のデータ・パケットに関するタイムスタンプは受信されました。 私たちはt_recvdataでこれを指示します。 受信機に受け取られた最後のパケットが一連番号iを持っているなら、t_recvdataはt_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_遅れでこれを指示します。
o The rate at which the receiver estimates that data was received
in the previous round-trip time. We denote this by X_recv.
o 前の往復の時間で受信機がそのデータを見積もっているレートを受け取りました。 私たちはX_recvでこれを指示します。
o The receiver's current estimate of the loss event rate p.
o 受信機の損失イベント率pの現状見積金額。
4. Data Sender Protocol
4. データ送付者プロトコル
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate based on the information contained in the feedback report. If the sender does not receive a feedback report for four round-trip times, then the sender cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
データ送付者は統制相場でデータ・パケットの流れをデータ受信装置に送ります。 データ受信装置からフィードバックパケットを受け取るとき、フィードバックで含まれた情報に基づく送付レートのデータ送付者変化は報告します。 送付者が往復の4倍フィードバックレポートを受け取らないなら、送付者は送付レートを半分に切ります。 これはnofeedbackタイマと呼ばれるタイマによって達成されます。
Floyd, et al. Standards Track [Page 8] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[8ページ]: プロトコル仕様2008年9月
We specify the sender-side protocol in the following steps:
私たちは以下のステップにおける送付者サイドプロトコルを指定します:
o Measurement of the mean segment size being sent.
o 送られる平均であるセグメントサイズの測定。
o Sender initialization.
o 送付者初期化。
o The sender behavior when a feedback packet is received.
o フィードバックパケットであるときに、送付者の振舞いは受け取られています。
o The sender behavior when the nofeedback timer expires.
o nofeedbackタイマであるときに、送付者の振舞いは期限が切れます。
o Oscillation prevention (optional).
o 振動防止(任意の)。
o Scheduling of packet transmission and allowed burstiness.
o パケット伝送と許容burstinessのスケジューリング。
4.1. Measuring the Segment Size
4.1. セグメントサイズを測定します。
The TFRC sender uses the segment size, s, in the throughput equation, in the setting of the maximum receive rate, the setting of the minimum and initial sending rates, and the setting of the nofeedback timer. The TFRC receiver MAY use the average segment size, s, in initializing the loss history after the first loss event. As specified in Section 6.3.1, if the TFRC receiver does not know the segment size, s, used by the sender, the TFRC receiver MAY instead use the arrival rate in packets per second in initializing the loss history.
スループット方程式におけるTFRC送付者用途セグメントサイズ、sは、最大の設定でレート、最小限の設定を受けて、レートを送って、nofeedbackタイマの設定に頭文字をつけます。 TFRC受信機は最初の損失イベントの後に損失歴史を初期化する際に平均したセグメントサイズ、sを使用するかもしれません。 セクション6.3.1で指定されるように、TFRC受信機が、セグメントサイズ(s)が送付者で使用したのを知らないなら、TFRC受信機は代わりに1秒あたりのパケットで損失歴史を初期化する際に到着率を使用するかもしれません。
The segment size is normally known to an application. This may not be so in two cases:
通常、セグメントサイズはアプリケーションに知られています。 したがって、コネtwoは、これがそうでなく、以下をケースに入れます。
1) The segment size naturally varies depending on the data. In this
case, although the segment size varies, that variation is not
coupled to the transmit rate. The TFRC sender can either compute
the average segment size or use the maximum segment size for the
segment size, s.
1) データによって、セグメントサイズは自然に異なります。 セグメントサイズが異なりますが、この場合その変化と結合されない、レートを伝えてください。 TFRC送付者は、セグメントサイズ(s)に平均したセグメントサイズを計算するか、または最大のセグメントサイズを使用できます。
2) The application needs to change the segment size rather than the
number of segments per second to perform congestion control.
This would normally be the case with packet audio applications
where a fixed interval of time needs to be represented by each
packet. Such applications need to have a completely different
way of measuring parameters.
2) アプリケーションは、輻輳制御を実行するために1秒あたりのセグメントの数よりむしろセグメントサイズを変える必要があります。 通常、これは時間の固定間隔が各パケットによって表される必要があるパケットオーディオアプリケーションでのそうでしょう。 そのようなアプリケーションはパラメタを測定する完全に異なった方法を必要とします。
For the first class of applications where the segment size varies depending on the data, the sender SHOULD estimate the segment size, s, as the average segment size over the last four loss intervals. The sender MAY estimate the average segment size over longer time intervals, if so desired.
データによって、セグメントサイズが異なるアプリケーションの一流のために、送付者SHOULDはセグメントサイズを見積もっています、s、ここ4回の損失間隔の間の平均したセグメントサイズとして。 そう望まれているなら、送付者は、より長い時間間隔にわたって平均したセグメントがサイズであると見積もるかもしれません。
Floyd, et al. Standards Track [Page 9] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[9ページ]: プロトコル仕様2008年9月
The second class of applications are discussed separately in a separate document on TFRC-SP [RFC4828]. For the remainder of this section we assume the sender can estimate the segment size and that congestion control is performed by adjusting the number of packets sent per second.
別々にTFRC-SP[RFC4828]の上の別々のドキュメントでアプリケーションの二等について議論します。 このセクションの残りのために、私たちは、送付者が、セグメントサイズとその輻輳制御が1秒単位で送られたパケットの数を調整することによって実行されると見積もることができると思います。
4.2. Sender Initialization
4.2. 送付者初期設定
The initial values for X (the allowed sending rate in bytes per second) and tld (the Time Last Doubled during slow-start, in seconds) are undefined until they are set as described below. If the sender is ready to send data when it does not yet have a round-trip sample, the value of X is set to s bytes per second, for segment size s, the nofeedback timer is set to expire after two seconds, and tld is set to 0 (or to -1, either one is okay). Upon receiving the first round-trip time measurement (e.g., after the first feedback packet or the SYN exchange from the connection setup, or from a previous connection [RFC2140]), tld is set to the current time, and the allowed transmit rate, X, is set to the initial_rate, specified as W_init/R, for W_init based on [RFC3390]:
それらが以下で説明されるように設定されるまで、X(1秒あたりのバイトで表現される許容送付レート)とtld(秒の遅れた出発の間のTime Last Doubled)のための初期の値は未定義です。 それに往復のサンプルがまだないとき、送付者がデータを送る準備ができているなら、Xの値は1秒あたりのsバイトに設定されます、そして、セグメントサイズsにおいて、nofeedbackタイマが2秒以降期限が切れるように設定されて、tldは0に用意ができています(-1に、どちらかがオーケーです)。 往復の1回目に測定(例えば、最初のフィードバックパケットかSYNが接続設定か、前の接続から[RFC2140]を交換した後に)を受けると、tldは現在の時間に用意ができています、そして、許容はレート、初期の_レートに設定されて、W_イニット/Rとして指定されたXを伝えます、[RFC3390]に基づくW_イニットのために:
initial_rate = W_init/R; W_init = min(4*MSS, max(2*MSS, 4380)).
_レート=W_イニット/Rに頭文字をつけてください。 W_イニット=分(4*MSS、(2*MSS、4380)に最大限にしてください)。
In computing W_init, instead of using Maximum Segment Size (MSS), the TFRC sender SHOULD use the maximum segment size to be used for the initial round-trip time of data, if that is known by the TFRC sender when X is initialized.
W_イニットを計算する際に、Maximum Segment Size(MSS)を使用することの代わりにTFRC送付者SHOULDはデータの初期の往復の時間に使用されるのに最大のセグメントサイズを使用します、Xが初期化されるとき、それがTFRC送付者によって知られているなら。
For responding to the initial feedback packet, this replaces step (4) of Section 4.3 below.
初期のフィードバックパケットに応じるために、これは以下のセクション4.3のステップ(4)を置き換えます。
Appendix B explains why the initial value of TFRC's nofeedback timer is set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer from [RFC2988].
付録BでTFRCのnofeedbackタイマの初期の値がなぜ2秒に設定されるかがわかります、[RFC2988]からのTCPの再送信タイマのための3秒のお勧めの初期の値の代わりに。
4.3. Sender Behavior When a Feedback Packet Is Received
4.3. フィードバックパケットが受け取られているときの送付者の振舞い
The sender knows its current allowed sending rate, X, and maintains an estimate of the current round-trip time R. The sender also maintains X_recv_set as a small set of recent X_recv values (typically only two values).
送付者は、現在の許容送付レート、Xを知って、また、送付者が、X_recv_が最近の小さいX_recv値(通常2つの値だけ)としてセットしたと主張すると現在の往復の時間R.の見積りに主張します。
Initialization: X_recv_set is first initialized to contain a single item, with value Infinity. (As an implementation-specific issue, X_recv_set MAY be initialized to a large number instead of to Infinity, e.g., to the largest integer that is easily representable.)
初期設定: _が設定したX_recvは、最初に、1つの項目を含むように値のInfinityと共に初期化されます。 (実現特有の問題として、_が設定したX_recvはInfinityの代わりに多くに初期化されるかもしれません、例えば、容易に「表-可能」な最も大きい整数に。)
Floyd, et al. Standards Track [Page 10] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[10ページ]: プロトコル仕様2008年9月
When a feedback packet is received by the sender at time t_now, the current time in seconds, the following actions MUST be performed.
フィードバックパケットが秒の現在の時間に_現在時tに送付者によって受け取られるとき、以下の動作を実行しなければなりません。
1) Calculate a new round-trip sample:
1) 新しい往復のサンプルについて計算してください:
R_sample = (t_now - t_recvdata) - t_delay.
R_は=(_現在のt--t_recvdata)を抽出します--t_遅れ。
As described in Section 3.2.2, t_delay gives the elapsed time at the receiver.
セクション3.2.2で説明されるように、t_遅れは受信機で経過時間を与えます。
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;
}
以前フィードバックを全く受け取ったことがない、R_が抽出するR=;、ほかR_が抽出するq*R+(1-q)R=*。
TFRC is not sensitive to the precise value for the filter constant q, but a default value of 0.9 is RECOMMENDED.
フィルタ定数qには、TFRCは正確な値に敏感ではありませんが、0.9のデフォルト値はRECOMMENDEDです。
3) Update the timeout interval:
3) タイムアウト間隔をアップデートしてください:
RTO = max(4*R, 2*s/X)
RTO=最大(4*R、2*s/X)
4) Update the allowed sending rate as follows. This procedure uses
the variables t_mbi and recv_limit:
4) 以下の許容送付レートをアップデートしてください。 この手順は変数t_mbiとrecv_限界を使用します:
t_mbi: the maximum backoff interval of 64 seconds.
recv_limit: the limit on the sending rate computed from
X_recv_set.
_t mbi: 64秒recv_限界の最大のbackoff間隔: X_recv_から計算された送付レートにおける限界はセットしました。
This procedure also uses the procedures Maximize X_recv_set() and Update X_recv_set(), which are defined below.
また、この手順は手順Maximize X_recv_セット()とUpdate X_recv_セット()を使用します。(それは、以下で定義されます)。
Floyd, et al. Standards Track [Page 11] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[11ページ]: プロトコル仕様2008年9月
The procedure for updating the allowed sending rate:
許容送付レートをアップデートするための手順:
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
} Else { // typical behavior
Update X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
If (p > 0) { // congestion avoidance phase
Calculate X_Bps using the TCP throughput equation.
X = max(min(X_Bps, recv_limit), s/t_mbi);
} Else if (t_now - tld >= R) {
// initial slow-start
X = max(min(2*X, recv_limit), initial_rate);
tld = t_now;
}
全体..間隔..覆う..フィードバック..パケット..データ..制限..間隔..フィードバック..パケット..レポート..新しい..損失..出来事..増加..損失..出来事..評定..半分に..エントリー..設定..等しい..最大にする..セット..限界..等しい..最大..セット..ほかに..最大にする..セット..限界..最大..セット..ほかに..典型的..振舞い..設定..限界..最大..セット{ TCPスループット方程式を使用する//輻輳回避フェーズCalculate X_Bps。 Xは最大(_分(X_Bps、recv_限界)、s/t mbi)と等しいです。 } ほか、(_現在のt--tld>=R)です。初期の//遅れた出発Xは最大(分(2*X、recv_限界)、初期の_レート)と等しいです; _現在のtld=t
5) If oscillation reduction is used, calculate the instantaneous
transmit rate, X_inst, following Section 4.5.
5) 振動減少が使用されているなら、セクション4.5に続いて、瞬時に起こるのがレート、X_instを伝えると見込んでください。
6) Reset the nofeedback timer to expire after RTO seconds.
6) RTO秒以降期限が切れるためにnofeedbackタイマをリセットしてください。
The procedure for maximizing X_recv_set keeps a single value, the largest value from X_recv_set and the new X_recv.
_が設定したX_recvを最大にするための手順はただ一つの値、_が設定したX_recvからの最も大きい値、および新しいX_recvを保ちます。
Maximize X_recv_set():
Add X_recv to X_recv_set;
Delete initial value Infinity from X_recv_set,
if it is still a member.
Set the timestamp of the largest item to the current time;
Delete all other items.
X_recv_セット()を最大にしてください: X_recv_へのX_recvがセットしたと言い足してください。 それでも、それがメンバーであるなら用意ができているX_recv_から初期の値のInfinityを削除してください。 最も大きい項目に関するタイムスタンプを現在の時間に設定してください。 他のすべての項目を削除してください。
Floyd, et al. Standards Track [Page 12] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[12ページ]: プロトコル仕様2008年9月
The procedure for updating X_recv_set keeps a set of X_recv values with timestamps from the two most recent round-trip times.
_が設定したX_recvをアップデートするための手順は2最新の往復の時間からのタイムスタンプで1セットのX_recv値を保ちます。
Update X_recv_set():
Add X_recv to X_recv_set;
Delete from X_recv_set values older than
two round-trip times.
X_recv_セット()をアップデートしてください: X_recv_へのX_recvがセットしたと言い足してください。 Xから、_往復の2回より古いrecv_設定値を削除してください。
Definition of a data-limited interval: We define a sender as data-limited any time it is not sending as much as it is allowed to send. We define an interval as a 'data-limited interval' if the sender was data-limited over the *entire* interval; Section 8.2.1 discusses implementation issues for a sender in determining if an interval was a data-limited interval. The term 'data-limited interval' is used in the first "if" condition in step (4), which prevents a sender from having to reduce its sending rate as a result of a feedback packet reporting the receive rate from a data-limited period.
データで限られた間隔の定義: 私たちはそれが発信できるくらいには発信しない何時でもデータで制限されると送付者を定義します。 送付者が*全体の*間隔にわたってデータによって限られたなら、私たちは'データで限られた間隔'と間隔を定義します。 セクション8.2 .1 間隔がデータで限られた間隔であったかどうか決定する際に送付者のために導入問題について議論します。 'データで限られた間隔'という用語が送付者がフィードバックパケット報告の結果、送付レートを低下させることができなくなければならないステップ(4)における最初の“if"状態で使用される、データ限定期間からレートを受け取ってください。
As an example, consider a sender that is sending at its full allowed rate, except that it is sending packets in pairs, rather than sending each packet as soon as it can. Such a sender is considered data- limited part of the time, because it is not always sending packets as soon as it can. However, consider an interval that covers this sender's transmission of at least two data packets; such an interval does not meet the definition of a data-limited interval because the sender was not data-limited *over the entire interval*.
例として、それの次第各パケットを送るよりパケットを対になってむしろ送るのを除いて、完全な許容レートで発信する送付者がそうすることができると考えてください。 そのような送付者はデータ現代の局所であると考えられます、できるだけすぐいつもパケットを送るというわけではないので。 しかしながら、この送付者の少なくとも2つのデータ・パケットのトランスミッションをカバーする間隔を考えてください。 全体の間隔*にわたって送付者がデータで有限な*でなかったので、そのような間隔はデータで限られた間隔の定義を満たしません。
If the feedback packet reports a receive rate X_recv of zero (i.e., the first feedback packet), the sender does not consider that the entire interval covered by the feedback packet was a data-limited interval.
フィードバックパケットレポートaがゼロ(すなわち、最初のフィードバックパケット)のレートX_recvを受けるなら、送付者は、フィードバックパケットで覆われた全体の間隔がデータで限られた間隔であったと考えません。
X_recv_set and the first feedback packet: Because X_recv_set is initialized with a single item, with value Infinity, recv_limit is set to Infinity for the first two round-trip times of the connection. As a result, the sending rate is not limited by the receive rate during that period. This avoids the problem of the sending rate being limited by the value of X_recv from the first feedback packet.
recv_が設定したX_と最初のフィードバックパケット: _が設定したX_recvが1つの項目、値のInfinityと共に初期化されるので、recv_限界は接続の往復の最初の2倍のためにInfinityに設定されます。 その結果、送付レートが制限されない、その期間、レートを受け取ってください。 これはX_recvの値によって最初のフィードバックパケットから制限される送付レートの問題を避けます。
The interval covered by a feedback packet: How does the sender determine the period covered by a feedback packet? This is discussed in more detail in Section 8.2. In general, the receiver will be sending a feedback packet once per round-trip time; so typically, the sender will be able to determine exactly the period covered by the current feedback packet from the previous feedback packet. However, in cases when the previous
フィードバックパケットで覆われた間隔: 送付者はどのようにフィードバックパケットでカバーされた期間を決定しますか? さらに詳細にセクション8.2でこれについて議論します。 一般に、受信機は往復の時間に一度フィードバックパケットを送るでしょう。 あまりに通常、送付者はまさに電流帰還パケットで前のフィードバックパケットからカバーされた期間を決定できるでしょう。 しかしながら、前であるときに、コネはケースに入れます。
Floyd, et al. Standards Track [Page 13] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[13ページ]: プロトコル仕様2008年9月
feedback packet was lost, or when the receiver sends a feedback packet early because it detected a lost or ECN-marked packet, the sender will have to estimate the interval covered by the feedback packet. As specified in Section 6.2, each feedback packet sent by the receiver covers a round-trip time, for the round-trip time estimate R_m maintained by the receiver R_m seconds before the feedback packet was sent.
それが無くなっているか電子証券取引ネットワークが著しいパケットを検出したので受信機が早くフィードバックパケットを送るとき、フィードバックパケットが失われたか、または送付者はフィードバックパケットで覆われた間隔を見積もらなければならないでしょう。 セクション6.2で指定されるように、受信機によって送られたそれぞれのフィードバックパケットは往復の時間をカバーしています、R_mがフィードバックパケットを送る秒前の受信機R_mで維持した往復の時間見積りのために。
The response to a loss during a data-limited interval: In TFRC, after the initial slow-start, the sender always updates the calculated transmit rate, X_Bps, after a feedback packet is received, and the allowed sending rate, X, is always limited by X_Bps. However, during a data-limited interval, when the actual sending rate is usually below X_Bps, the sending rate is still limited by recv_limit, derived from X_recv_set. If the sender is data-limited, possibly with a varying sending rate from one round-trip time to the next, and is experiencing losses, then we decrease the entry in X_recv_set in order to reduce the allowed sending rate.
データで限られた間隔の間の損失への応答: 初期の遅れた出発の後に送付者のTFRCでは、いつも計算が伝えるアップデートは評価します、X_Bps、フィードバックパケットが受け取られていて、許容送付レート(X)がいつもX_Bpsによって制限された後に。 しかしながら、データで限られた間隔の間、送付レートは_が設定したX_recvから得られたrecv_限界でまだ制限されています。(その時、通常X_Bpsの下に実際の送付レートがあります)。 送付者が損失をことによると往復の1回から次の回までの異なった送付レートでデータで制限して、経験しているなら、私たちは許容送付レートを低下させるために用意ができているX_recv_でエントリーを減少させます。
The sender can detect a loss event during a data-limited period either from explicit feedback from the receiver, or from a reported increase in the loss event rate. When the sender receives a feedback packet reporting such a loss event in a data-limited interval, the sender limits the allowed increases in the sending rate during the data-limited interval.
送付者は受信機からの明白なフィードバック、または、損失イベント率の報告された増加からのデータ限定期間の間、損失出来事を検出できます。 送付者がデータで限られた間隔のそのような損失出来事を報告するフィードバックパケットを受けるとき、送付者はデータで限られた間隔の間、送付レートの許容増加を制限します。
The initial slow-start phase: Note that when p=0, the sender has not yet learned of any loss events, and the sender is in the initial slow-start phase. In this initial slow-start phase, the sender can approximately double the sending rate each round-trip time until a loss occurs. The initial_rate term in step (4) gives a minimum allowed sending rate during slow-start of the initial allowed sending rate.
初期の遅れた出発フェーズ: p=0であるときに、送付者がまだどんな損失出来事も知っていなくて、送付者が初期の遅れた出発フェーズにいることに注意してください。 この初期の遅れた出発フェーズでは、損失が発生するまで、送付者は往復の毎回に周囲で送付レートを倍にすることができます。 ステップ(4)における初期の_レート用語は初期の許容送付レートの遅れた出発の間、最小の許容送付レートを与えます。
We note that if the sender is data-limited during slow-start, or if the connection is limited by the path bandwidth, then the sender is not necessarily able to double its sending rate each round-trip time; the sender's sending rate is limited to at most twice the past receive rate, or at most initial_rate, whichever is larger. This is similar to TCP's behavior, where the sending rate is limited by the rate of incoming acknowledgement packets as well as by the congestion window. Thus, in TCP's slow-start, for the most aggressive case of the TCP receiver acknowledging every data packet, the TCP sender's sending rate is limited to at most twice the rate of these incoming acknowledgment packets.
送付者がデータによって限られるなら、私たちは遅れた出発の間、それに注意するというわけではありませんか、または接続が経路帯域幅によって制限されるなら、送付者は往復の毎回に必ず送付レートを倍にすることができるというわけではありません。 制限された送付者の送付レートは高々過去の2倍までレート、または高々初期の_レートを受け取ります、どれがさらに大きいかなら。 これはTCPの振舞い、送付レートが入って来る確認応答パケットのレートによって制限されるところ、および混雑ウィンドウのそばで同様です。 したがって、TCPの遅れた出発では、TCP受信機の最も攻撃的なケースにおいて、あらゆるデータ・パケットを承認して、TCP送付者の送付レートは高々これらの入って来る確認応答パケットのレートの2倍に制限されます。
Floyd, et al. Standards Track [Page 14] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[14ページ]: プロトコル仕様2008年9月
The minimum allowed sending rate: The term s/t_mbi ensures that when p > 0, the sender is allowed to send at least one packet every 64 seconds.
最小限で、レートを送りました: mbiという用語s/t_は、p>0であるときに、送付者が少なくとも1つのパケットに64秒毎を送ることができるのを確実にします。
4.4. Expiration of Nofeedback Timer
4.4. Nofeedbackタイマの満了
This section specifies the sender's response to a nofeedback timer. The nofeedback timer could expire because of an idle period or because of data or feedback packets dropped in the network.
このセクションはnofeedbackタイマへの送付者の応答を指定します。 nofeedbackタイマが活動していない期間のためデータので期限が切れることができましたか、またはフィードバックパケットはネットワークをちょっと立ち寄らせました。
This section uses the variable recover_rate. If the TFRC sender has been idle ever since the nofeedback timer was set, the allowed sending rate is not reduced below the recover_rate. For this document, the recover_rate is set to the initial_rate (specified in Section 4.2). Future updates to this specification may explore other possible values for the recover_rate.
このセクションは変数を使用します。_レートを回復してください。 nofeedbackタイマが設定されて以来TFRC送付者が活動していないなら、許容送付レートが以下で低下しない、_レートを回復してください。 _レートを回復してください。このドキュメントのために設定する、初期の_レート(セクション4.2では、指定される)に設定されます。 この仕様への将来のアップデートが他の可能な値について調査するかもしれない、_レートを回復してください。
If the nofeedback timer expires, the sender MUST perform the following actions:
nofeedbackタイマが期限が切れるなら、送付者は以下の動作を実行しなければなりません:
1) Cut the allowed sending rate in half.
1) 許容送付レートを半分に切ってください。
If the nofeedback timer expires when the sender has had at least
one RTT measurement, the allowed sending rate is reduced by
modifying X_recv_set as described in the pseudocode below
(including item (2)). In the general case, the sending rate is
limited to at most twice X_recv. Modifying X_recv_set limits the
sending rate, but still allows the sender to slow-start, doubling
its sending rate each RTT, if feedback messages resume reporting
no losses.
送付者に少なくとも1つのRTT測定があったとき、nofeedbackタイマが期限が切れるなら、許容送付レートは、_が以下の擬似コードで説明されるように設定するX_recvを変更することによって、低下します。(項目(2))を含んでいます。 一般的な場合では、送付レートは_高々2倍X recvに制限されます。 _が設定したX_recvを変更すると、送付レートが制限されますが、送付者はまだそれぞれ送付レートを倍にする遅れた出発RTTに許容されています、フィードバックメッセージが、損失を全く報告するのを再開しないなら。
If the sender has been idle since this nofeedback timer was set
and X_recv is less than the recover_rate, then the allowed sending
rate is not halved, and X_recv_set is not changed. This ensures
that the allowed sending rate is not reduced to less than half the
recover_rate as a result of an idle period.
このnofeedbackタイマが設定されて、X_recvが、より少ないので送付者が活動していない、_レートを回復してください、そして、次に、許容送付レートは半分にされないで、また_が設定したX_recvは変えられません。 これが、許容送付レートが半分未満まで低下しないのを確実にする、活動していない期間の結果、_レートを回復してください。
In the general case, the allowed sending rate is halved in
response to the expiration of the nofeedback timer. The details,
in the pseudocode below, depend on whether the sender is in slow-
start, is in congestion avoidance limited by X_recv, or is in
congestion avoidance limited by the throughput equation.
一般的な場合では、nofeedbackタイマの満了に対応して許容送付レートは半分にされます。 以下の擬似コードでは、詳細は送付者が遅い始めにいるか、X_recvによって制限された輻輳回避でいるか、またはスループット方程式で制限された輻輳回避中であるかによります。
Floyd, et al. Standards Track [Page 15] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[15ページ]: プロトコル仕様2008年9月
X_recv = max (X_recv_set);
If (sender does not have an RTT sample,
has not received any feedback from receiver,
and has not been idle ever since the nofeedback timer
was set) {
// We do not have X_Bps or recover_rate yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (((p>0 && X_recv < recover_rate) or
(p==0 && X < 2 * recover_rate)), and
sender has been idle ever
since nofeedback timer was set) {
// Don't halve the allowed sending rate.
Do nothing;
} Else if (p==0) {
// We do not have X_Bps yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (X_Bps > 2*X_recv)) {
// 2*X_recv was already limiting the sending rate.
// Halve the allowed sending rate.
Update_Limits(X_recv;)
} Else {
// The sending rate was limited by X_Bps, not by X_recv.
// Halve the allowed sending rate.
Update_Limits(X_Bps/2);
}
X_recvは最大と等しいです(X_recv_はセットしました)。 (送付者は、RTTのサンプルを持たないで、また受信機からフィードバックをまだ受けていなくて、またnofeedbackタイマが設定する時から、活動していなくはありません){ 私たちがする//は、X_Bpsを持ってもいませんし、まだ_レートを回復もしていません。 //は許容送付レートを半分にします。 Xは最大と等しいです(_X/2、s/t mbi)。 } ほか、(p>0、X_recv<が_レートを回復する、)、(p==0、X<2*が_レートを回復する、)、nofeedbackタイマが設定されて以来送付者が活動していない、){ //は許容送付レートを半分にしません。 何もしないでください。 } ほか、(p==0)です。{ 私たちがする//はまだX_Bpsを持っていません。 //は許容送付レートを半分にします。 Xは最大と等しいです(_X/2、s/t mbi)。 } ほかにもかかわらず、(X_ビーピーエス>2*X_recv)です。 { //2*X_recvは既に送付レートを制限していました。 //は許容送付レートを半分にします。 アップデート_は(X_recv)を制限します。} ほか{ 発信が評定する//は__X recvではなく、X Bpsによって制限されました。 //は許容送付レートを半分にします。 _限界(X_bps/2)をアップデートしてください。 }
The term s/t_mbi limits the backoff to one packet every 64
seconds.
mbiという用語s/t_はbackoffを64秒毎の1つのパケットに制限します。
The procedure Update_Limits() uses the variable timer_limit for
the limit on the sending rate computed from the expiration of the
nofeedback timer, as follows:
手順Update_Limits()はnofeedbackタイマの満了から計算された送付レートにおける限界に可変タイマ_限界を使用します、以下の通りです:
Update_Limits(timer_limit):
If (timer_limit < s/t_mbi)
timer_limit = s/t_mbi;
Replace X_recv_set contents with the single item
timer_limit/2;
Recalculate X as in step (4) of Section 4.3;
_限界(タイマ_限界)をアップデートしてください: (タイマ_限界<s/t_mbi)タイマ_限界が_s/t mbiと等しいなら。 X_recv_セットコンテンツをただ一つの項目タイマ_限界/2に取り替えてください。 Recalculate Xはセクション4.3の(4)を同じくらい中に踏みます。
2) Restart the nofeedback timer to expire after max(4*R, 2*s/X)
seconds.
2) 最大(4*R、2*s/X)秒以降期限が切れるためにnofeedbackタイマを再開してください。
If the sender has been data-limited but not idle since the nofeedback timer was set, it is possible that the nofeedback timer expired because data or feedback packets were dropped in the network. In
nofeedbackタイマが設定されて以来、送付者がデータによって制限されていますが、活動していなくないなら、データかフィードバックパケットがネットワークで落とされたのでnofeedbackタイマが期限が切れたのは、可能です。 コネ
Floyd, et al. Standards Track [Page 16] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[16ページ]: プロトコル仕様2008年9月
this case, the nofeedback timer is the backup mechanism for the sender to detect these losses, similar to the retransmit timer in TCP.
本件、nofeedbackタイマは送付者がこれらの損失を検出するバックアップメカニズムです、TCPの再送信タイマと同様です。
Note that when the sender stops sending data for a period of time, the receiver will stop sending feedback. When the sender's nofeedback timer expires, the sender could use the procedure above to limit the sending rate. If the sender subsequently starts to send again, X_recv_set will be used to limit the transmit rate, and slow- start behavior will occur until the transmit rate reaches X_Bps.
送付者が、しばらくデータを送るのを止めると、受信機が、フィードバックを送るのを止めることに注意してください。 送付者のnofeedbackタイマが期限が切れると、送付者は送付レートを制限するためには上の手順を用いるかもしれません。 送付者が次に再び発信し始めると、_が設定したX_recvが制限するのにおいて使用する、レートを伝えてください。そうすれば、遅いスタートの振舞いが起こる、レート範囲X_Bpsを伝えてください。
The TFRC sender's reduction of the allowed sending rate after the nofeedback timer expires is similar to TCP's reduction of the congestion window, cwnd, after each RTO seconds of an idle period, for TCP with Congestion Window Validation [RFC2861].
nofeedbackタイマが期限が切れた後にTFRC送付者の許容送付レートの減少は活動していない期間のcwndに後それぞれのRTO秒単位でTCPの混雑ウィンドウの減少と同様です、Congestion Window Validation[RFC2861]とTCPのために。
4.5. Reducing Oscillations
4.5. 振動を抑えます。
To reduce oscillations in queueing delay and sending rate in environments with a low degree of statistical multiplexing at the congested link, it is RECOMMENDED that the sender reduce the transmit rate as the queueing delay (and hence RTT) increases. To do this, the sender maintains R_sqmean, a long-term estimate of the square root of the RTT, and modifies its sending rate depending on how the square root of R_sample, the most recent sample of the RTT, differs from the long-term estimate. The long-term estimate R_sqmean is set as follows:
送付者が減少するのが、低度の統計的多重化が混雑しているリンクにある状態で待ち行列遅れと環境でレートを送る際に振動を抑えるためには、RECOMMENDEDである、待ち行列遅れ(そして、したがって、RTT)が増加するのに従って、レートを伝えてください。 送付者は、これをするように、R_がsqmean、RTTの平方根の長期の見積りであることを支持して、R_サンプルの平方根(RTTの最新のサンプル)がどう長期の見積りと異なっているかに依存する送付レートを変更します。 _sqmeanが以下の通り用意ができているという長期の見積りR:
If no feedback has been received before {
R_sqmean = sqrt(R_sample);
} Else {
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
}
以前フィードバックを全く受け取ったことがない、R_sqmean=sqrt(R_サンプル);、ほかq2*R_sqmean+(1-q2)R_sqmean=*sqrt(R_サンプル)。
Thus, R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, the constant used in the round-trip time estimate R. A value of 0.9 as the default for q2 is RECOMMENDED.
したがって、R_sqmeanはRTTのサンプルの平方根の指数加重移動平均を与えます。 q2のためのデフォルトがRECOMMENDEDであるので、一定のq2は同様にqに用意ができるべきであり、定数は往復の時間見積りR.に0.9のA値を使用しました。
When sqrt(R_sample) is greater than R_sqmean, then the current round-trip time is greater than the long-term average, implying that queueing delay is probably increasing. In this case, the transmit rate is decreased to minimize oscillations in queueing delay.
sqrt(R_サンプル)がR_sqmeanよりすばらしいと、現在の往復の時間は長期の平均より大きいです、待ち行列遅れがたぶん増加しているのを含意して。 レートを伝えてください。この場合、待ち行列遅れにおける振動を最小にするために、減少します。
The sender obtains the base allowed transmit rate, X, as described in step (4) of Section 4.3 above. It then calculates a modified instantaneous transmit rate X_inst, as follows:
許容されて、送付者はベースを得ます。上でセクション4.3のステップ(4)で説明されるようにレート、Xを伝えてください。 次に、それは、瞬時に起こった状態で変更されたaが_instに、以下の通りレートXを伝えると見込みます:
Floyd, et al. Standards Track [Page 17] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[17ページ]: プロトコル仕様2008年9月
X_inst = X * R_sqmean / sqrt(R_sample);
If (X_inst < s/t_mbi)
X_inst = s/t_mbi;
_X_inst=X*R sqmean / sqrt(R_サンプル)。 (_X_inst<s/t mbi)X_instが_s/t mbiと等しいなら。
Because we are using square roots, there is generally only a moderate difference between the instantaneous transmit rate X_inst and the allowed transmit rate X. For example, in a somewhat extreme case when the current RTT sample R_sample is twice as large as the long- term average, then sqrt(R_sample) will be roughly 1.44 times R_sqmean, and the allowed transmit rate will be reduced by a factor of roughly 0.7.
私たちが平方根を使用しているので、瞬時に起こることの間には、一般に、適度の違いしかありません。レートX_instを伝えてください。そうすれば、許容はレートX.Forの例を伝えます、現在のRTTサンプルのR_サンプルが平均、次に、(R_サンプル)がおよそ1.44回がR_sqmeanであったならそうするsqrt、および許容がレートを伝える長い期間はおよそ0.7の要素によって減少させられるより2倍大きくいくらか極端な場合で。
We note that this modification for reducing oscillatory behavior is not always needed, especially if the degree of statistical multiplexing in the network is high. We also note that the modification for reducing oscillatory behavior could cause problems for connections where the round-trip time is not strongly correlated with the queueing delay (e.g., in some wireless links, over paths with frequent routing changes, etc.). However, this modification SHOULD be implemented because it makes TFRC behave better in some environments with a low level of statistical multiplexing. The performance of this modification is illustrated in Section 3.1.3 of [FHPW00]. If it is not implemented, implementations SHOULD use a very low value of the weight q for the average round-trip time.
私たちは、振動性の振舞いを抑えるためのこの変更がいつも必要であるというわけではないことに注意します、特にネットワークにおける、統計的多重化の学位が高であるなら。 また、私たちは、振動性の振舞いを抑えるための変更が接続のための往復の時間が待ち行列遅れ(例えば、頻繁なルーティング変化などを伴う経路の上のいくつかの無線のリンクの)で強く関連しない問題を引き起こす場合があったことに注意します。 しかしながら、この変更SHOULD、TFRCがそれで低レベルの統計的多重化でいくつかの環境でもっと行儀よくするので、実行されてください。 この変更の性能は.3セクション3.1[FHPW00]で例証されます。 それが実行されないなら、実現SHOULDは重さqの非常に低い値を平均した往復の時間に使用します。
4.6. Scheduling of Packet Transmissions
4.6. パケット伝送のスケジューリング
As TFRC is rate-based, and as operating systems typically cannot schedule events precisely, it is necessary to be opportunistic about sending data packets so that the correct average rate is maintained despite the coarse-grain or irregular scheduling of the operating system. To help maintain the correct average sending rate, the TFRC sender MAY send some packets before their nominal send time.
TFRCがレートベースであり、オペレーティングシステムが通常正確に出来事の計画をすることができないので、送付データ・パケットに関して便宜主義的であるのが必要であるので、オペレーティングシステムの粗粉か不規則なスケジューリングにもかかわらず、適度の平均相場は維持されます。 適度の平均した送付レートを維持するのを助けるために、TFRC送付者が以前いくつかのパケットを送るかもしれない、それら、名目上、時間を送ってください。
In addition, the scheduling of packet transmissions controls the allowed burstiness of senders after an idle or data-limited period. The TFRC sender MAY accumulate sending 'credits' for past unused send times; this allows the TFRC sender to send a burst of data after an idle or data-limited period. To compare with TCP, TCP may send up to a round-trip time's worth of packets in a single burst, but never more. As examples, packet bursts can be sent by TCP when an ACK arrives acknowledging a window of data, or when a data-limited sender suddenly has a window of data to send after a delay of nearly a round-trip time.
さらに、パケット伝送のスケジューリングは活動していないかデータ限定期間の後に送付者の許容burstinessを制御します。 未使用で過去の'クレジット'を送る送付者が蓄積するかもしれないTFRCは回を送ります。 これで、TFRC送付者は活動していないかデータ限定期間の後にデータの炸裂を送ることができます。 TCPと比較するために、TCPはしかしさらに決して押し破かれなかったシングルで往復の時間のパケットの価値まで発信するかもしれません。 例として、ACKがデータの窓を承認しながら到着するか、またはデータで限られた送付者が突然ほとんど往復の時間の遅れの後に送るデータの窓を持っていると、TCPはパケット炸裂を送ることができます。
Floyd, et al. Standards Track [Page 18] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[18ページ]: プロトコル仕様2008年9月
To limit burstiness, a TFRC implementation MUST prevent bursts of arbitrary size. This limit MUST be less than or equal to one round- trip time's worth of packets. A TFRC implementation MAY limit bursts to less than a round-trip time's worth of packets. In addition, a TFRC implementation MAY use rate-based pacing to smooth bursts.
burstinessを制限するために、TFRC実現は任意のサイズの炸裂を防がなければなりません。 この限界は、よりあるラウンド旅行時間のパケットの価値であるに違いありません。 TFRC実現は往復の時間のパケットの価値より炸裂を以下に制限するかもしれません。 さらに、TFRC実現は、炸裂を整えるのにレートベースのペースを使用するかもしれません。
As an implementation-specific example, a sending loop could calculate the correct inter-packet interval, t_ipi, as follows:
実現特有の例として、送付輪は以下の通り正しい相互パケット間隔、t_ipiについて計算するかもしれません:
t_ipi = s/X_inst;
t_ipiは_s/X instと等しいです。
Let t_now be the current time and i be a natural number, i = 0, 1, ..., with t_i the nominal send time for the i-th packet. Then, the nominal send time t_(i+1) would derive recursively as:
電流が0、自然数、i=1であったなら_今、tをさせてください…, 名目上が時間を送るt_i、i、-、第パケット。 そして、名目上は以下として(i+1)が再帰的に引き出す時間t_を送ります。
t_0 = t_now,
t_(i+1) = t_i + t_ipi.
t_0は__現在のt t_(i+1)=t_i+t ipiと等しいです。
For TFRC senders allowed to accumulate sending credits for unused send time over the last T seconds, the sender would be allowed to use unused nominal send times t_j for t_j < now - T, for T set to the round-trip time.
許容された未使用で送付クレジットを蓄積するTFRC送付者に関して最後のT秒にタイム・オーバーを送ってください、そして、送付者はそうでしょう。使用未使用に名目上で許容されて、現在のt_j<--Tのために回t_jを送ってください、往復の時間に設定されたTのために。
5. Calculation of the Loss Event Rate (p)
5. 損失イベント率の計算(p)
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFRC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets. We describe this process before describing the rest of the receiver protocol. If the receiver has not yet detected a lost or marked packet, then the receiver does not calculate the loss event rate, but reports a loss event rate of zero.
損失イベント率の正確で安定した測定を得るのはTFRCのために第一に重要です。 損失レート測定は受信機で実行されます、到着パケットの一連番号からの無くなっているか著しいパケットの検出に基づいて。 受信機プロトコルの残りについて説明する前に、私たちはこの過程について説明します。 受信機がまだ無くなっているか著しいパケットを検出していないなら、受信機は、損失イベント率について計算しませんが、ゼロの損失イベント率を報告します。
5.1. Detection of Lost or Marked Packets
5.1. 無くなっているか著しいパケットの検出
TFRC assumes that all packets contain a sequence number that is incremented by one for each packet that is sent. For the purposes of this specification, it is REQUIRED that if a lost packet is retransmitted, the retransmission is given a new sequence number that is the latest in the transmission sequence, and not the same sequence number as the packet that was lost. If a transport protocol has the requirement that it must retransmit with the original sequence number, then the transport protocol designer must figure out how to distinguish delayed from retransmitted packets and how to detect lost retransmissions.
TFRCは、すべてのパケットが送られる各パケットあたり1つ増加される一連番号を含むと仮定します。 この仕様の目的のために、無くなっているパケットを再送するなら、失われたパケットと同じ一連番号ではなく、トランスミッション系列で最新のものである新しい一連番号を「再-トランスミッション」に与えるのは、REQUIREDです。 トランスポート・プロトコルに元の一連番号で再送しなければならないという要件があるなら、トランスポート・プロトコルデザイナーは、どう区別するかが再送されたパケットとどう無くなっている「再-トランスミッション」を検出するかから延着したのを理解しなければなりません。
Floyd, et al. Standards Track [Page 19] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[19ページ]: プロトコル仕様2008年9月
The receiver maintains a data structure that keeps track of which packets have arrived and which are missing. For the purposes of this specification, we assume that the data structure consists of a list of packets that have arrived along with the receiver timestamp when each packet was received. In practice, this data structure will normally be stored in a more compact representation, but this is implementation-specific.
受信機は動向をおさえるデータ構造を維持します(パケットが到着して、なくなっています)。 この仕様の目的のために、私たちは、データ構造が各パケットを受け取ったとき受信機タイムスタンプと共に到着したパケットのリストから成ると思います。 実際には、このデータ構造は、よりコンパクトな表現に通常格納されるでしょうが、これは実現特有です。
The loss of a packet is detected by the arrival of at least NDUPACK packets with a higher sequence number than the lost packet, for NDUPACK set to 3. The requirement for NDUPACK subsequent packets is the same as with TCP, and is to make TFRC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after NDUPACK subsequent packets arrived) in TFRC, the late packet can fill the hole in TFRC's reception record, and the receiver can recalculate the loss event rate. Future versions of TFRC might make the requirement for NDUPACK subsequent packets adaptive based on experienced packet reordering, but such a mechanism is not part of the current specification.
パケットの損失は少なくとも無くなっているパケットより高い一連番号があるNDUPACKパケットの到着で検出されます、3に用意ができているNDUPACKのために。 NDUPACKのその後のパケットのための要件は、TCPと同じであり、TFRCを再命令の面前でより強健にすることです。 パケットが遅さに(NDUPACKのその後のパケットが到着した後に)TFRCに到着するなら、遅いパケットはTFRCのレセプション記録の穴をふさぐことができます、そして、TCPと対照して、受信機は損失出来事が評定するrecalculateをふさぐことができます。 TFRCの将来のバージョンはNDUPACKのための要件を経験豊富なパケット再命令に基づいて適応型のその後のパケットにするかもしれませんが、そのようなメカニズムは現在の仕様の一部ではありません。
For an ECN-capable connection, a marked packet is detected as a congestion event as soon as it arrives, without having to wait for the arrival of subsequent packets.
それの次第混雑出来事が到着するとき、電子証券取引ネットワーク有能な接続において、著しいパケットは検出されます、その後のパケットの到着を待つ必要はなくて。
If an ECN-marked packet is preceded by a possibly-lost packet, then the first detected congestion event begins with the lost packet. For example, if the receiver receives a data packet with sequence number n-1, followed by an unmarked data packet with sequence number n+1, and a marked data packet with sequence number n+2, then the receiver detects a congestion event when it receives the marked packet n+2. The first congestion event detected begins with the lost packet n. The guidelines in Section 5.2 below are used to determine whether the lost and marked packets belong to the same loss event or to separate loss events.
ことによると無くなっているパケットが電子証券取引ネットワークが著しいパケットに先行するなら、最初の検出された混雑出来事は無くなっているパケットと共に始まります。 それが著しいパケットn+2を受けるとき、例えば、受信機が一連番号n+2で一連番号n+1がある無印のデータ・パケットがあとに続いた一連番号n-1があるデータ・パケットと著しいデータ・パケットを受けるなら、受信機は混雑出来事を検出します。 検出された最初の混雑出来事は無くなっているパケットnと共に始まります。 以下のセクション5.2のガイドラインは、無くなっていて著しいパケットが同じ損失出来事に属すかどうか決定するか、または損失出来事を切り離すのに使用されます。
5.2. Translation from Loss History to Loss Events
5.2. 損失歴史から損失出来事までの翻訳
TFRC requires that the loss fraction be robust to several consecutive packets lost or marked in the same loss event. This is similar to TCP, which (typically) only performs one halving of the congestion window during any single RTT. Thus, the receiver needs to map the packet loss history into a loss event record, where a loss event is one or more packets lost or marked in an RTT. To perform this mapping, the receiver needs to know the RTT to use, and this is supplied periodically by the sender, typically as control information
TFRCは、損失断片が同じ損失出来事で失われたか、またはマークされたいくつかの連続したパケットに強健であることを必要とします。 これはTCPと同様です。(TCPはどんな独身のRTTの間も、混雑ウィンドウのある半分にを(通常)実行するだけです)。 したがって、受信機は、損失イベント記録にパケット損失歴史を写像する必要があります。(そこでは、損失出来事がRTTで失われたか、またはマークされた1つ以上のパケットです)。 このマッピング、RTTが使用するのを知る受信機の必要性、およびこれを実行するのは定期的に送付者によって供給されます、通常制御情報として
Floyd, et al. Standards Track [Page 20] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[20ページ]: プロトコル仕様2008年9月
piggy-backed onto a data packet. TFRC is not sensitive to how the RTT measurement sent to the receiver is made, but it is RECOMMENDED to use the sender's calculated RTT, R, (see Section 4.3) for this purpose.
データ・パケットに背負われます。 TFRCは受信機に送られたRTT測定をしますが、それがどうこのために送付者の計算されたRTT、Rを使用する(セクション4.3を見ます)RECOMMENDEDであるかに敏感ではありません。
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_に新しいです、直接T_新しいレセプション時間に注意できます。 無くなっているパケットに関しては、私たちは、名目上の「到着時間」を推論するのを補間できます。 仮定します:
S_loss is the sequence number of a lost packet.
S_損失は無くなっているパケットの一連番号です。
S_before is the sequence number of the last packet to arrive,
before any packet arrivals with a sequence number above S_loss,
with a sequence number below S_loss.
S、_以前、到着する最後のパケットの一連番号があります、S_損失の上に一連番号があるどんなパケット到着の前にも、S_損失の下に一連番号がある状態で。
S_after is the sequence number of the first packet to arrive after
S_before with a sequence number above S_loss.
S_は後にS_損失の上に一連番号がある状態で_以前Sの後に到着する最初のパケットの一連番号です。
S_max is the largest sequence number.
S_最大は最も大きい一連番号です。
Therefore, S_before < S_loss < S_after <= S_max.
したがって、<の後の<のS_損失<S_がS_と等しい前にS_は最大限にします。
T_loss is the nominal estimated arrival time for the lost packet.
T_損失は無くなっているパケットのための名目上のおよそ到着時間です。
T_before is the reception time of S_before.
_以前、Sのレセプション時間があります。T、_以前。
T_after is the reception time of S_after.
T_は後に_後のSのレセプション時間です。
Note that T_before < T_after.
_後の<Tの前でそのT_に注意してください。
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_の損失によって、私たちは_Sの何倍も以前、到着から受信機への名目上の「到着時間」を補間できます。そして、_後のS。 このようにして:
T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) );
T_損失が+の前にT_と等しい、(__後のT--T以前、)、*、(S_の損失--、S、_以前)、/、(__後のS--S以前、)、。
To address sequence number wrapping, let S_MAX = 2^b, where b is the bit-length of sequence numbers in a given implementation. In this case, we can interpolate the arrival time T_loss as follows:
一連番号ラッピングを記述するために、S_MAXに2^bと等しくしいさせてください。(そこでは、bが与えられた実現で、一連番号のビット-長さです)。 この場合、私たちは以下の到着時間のT_損失を補間できます:
Floyd, et al. Standards Track [Page 21] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[21ページ]: プロトコル仕様2008年9月
T_loss = T_before + (T_after - T_before)
* Dist(S_loss, S_before)/Dist(S_after, S_before)
T_損失が+の前にT_と等しい、(__後のT--T以前、)、*Dist、(Sの_の損失、S_以前、)、/Dist(_後のS、S、_以前)
where
どこ
Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX
Dist(S、S_B)=(S+S_最大--S_B)%S_は最大限にします。
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_老人が前の損失出来事を出発させたと決心していて、無くなって、次に、私たちが新しい状態でS_老人とS_の名目上の到着時間を補間するということであり、_新しく、それぞれT_老人とTと呼ばれて、私たちがちょうどそのSを_新しく決心したところであるなら。
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_の古い+R>がT_と新しい状態で等しいなら、S_新しいのは、既存の損失出来事の一部です。 さもなければ、S_新しいのは、新しい損失出来事で最初のパケットです。
5.3. The Size of a Loss Interval
5.3. 損失間隔のサイズ
After the detection of the first loss event, the receiver divides the sequence space into loss intervals. If a loss interval, A, is determined to have started with packet sequence number S_A and the next loss interval, B, started with packet sequence number S_B, then the number of packets in loss interval A is given by (S_B - S_A). Thus, loss interval A contains all of the packets transmitted by the sender starting with the first packet transmitted in loss interval A and ending with but not including the first packet transmitted in loss interval B.
最初の損失出来事の検出の後に、受信機は系列スペースを損失間隔に分割します。 損失間隔(A)がパケット一連番号Sから始まったと決心していて、次の損失間隔(B)がパケット一連番号S_Bから始まったなら、(S_B--S)は損失間隔Aのパケットの数を与えます。 したがって、損失間隔Aは損失間隔Aで伝えられた最初のパケットから始まって、終わりますが、損失間隔Bに伝えられた最初のパケットを含まない送付者によって伝えられたパケットのすべてを含んでいます。
The current loss interval I_0 is defined as the loss interval containing the most recent loss event. If that loss event started with packet sequence number S_A, and S_C is the highest received sequence number so far, then the size of I_0 is S_C - S_A + 1. As an example, if the current loss interval consists of a single ECN- marked packet, then S_A == S_C, and the size of the loss interval is one.
当期損失間隔I_0は損失間隔含有最新の損失出来事と定義されます。 その損失出来事がパケット一連番号Sから始まって、今までのところS_Cが最も高い容認された一連番号であるなら、I_0のサイズはS_Cです--S+1。 例として、当期損失間隔がシングル電子証券取引ネットワークから成るなら、損失間隔のパケットと、S_Cと、次に、S=サイズであるとマークされているのは、1です。
5.4. Average Loss Interval
5.4. 海損間隔
To calculate the loss event rate, p, we first calculate the average loss interval. This is done using a filter that weights the n most recent loss event intervals in such a way that the measured loss event rate changes smoothly. If the receiver has not yet seen a lost or marked packet, then the receiver does not calculate the average loss interval.
損失イベント率、pについて計算するために、私たちは最初に、海損間隔について計算します。 これは測定損失イベント率がスムーズに変化するような方法でn最新の損失イベント間隔に重みを加えるフィルタを使用し終わっています。 受信機がまだ無くなっているか著しいパケットを見ていないなら、受信機は海損間隔について計算しません。
Floyd, et al. Standards Track [Page 22] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[22ページ]: プロトコル仕様2008年9月
Weights w_0 to w_(n-1) are calculated as:
w_(n-1)への重りw_0は以下として計算されます。
If (i < n/2) {
w_i = 1;
} Else {
w_i = 2 * (n-i)/(n+2);
}
(i<n/2)である、w_i=1;、ほかw_i=2*(n-i)/(n+2)。
Thus, if n=8, the values of w_0 to w_7 are:
したがって、n=8であるなら、0対w_7のw_値は以下の通りです。
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
The value n for the number of loss intervals used in calculating the loss event rate determines TFRC's speed in responding to changes in the level of congestion. It is RECOMMENDED to set the value n to 8. TFRC SHOULD NOT use values of n greater than 8 for traffic that might compete in the global Internet with TCP. At the very least, safe operation with values of n greater than 8 would require a slight change to TFRC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
損失イベント率について計算する際に費やされた損失間隔の数のための値nは混雑のレベルにおける変化に応じる際にTFRCの速度を測定します。 それはnから8に値を設定するRECOMMENDEDです。 TFRC SHOULD NOTはTCPと共に世界的なインターネットに参加するかもしれない交通にnより多くの8の値を使用します。 少なくとも、nより多くの8の値がある安全操業は、重いパケット損失に伴う往復の2回以上への、より厳しい応答を含むようにTFRCのメカニズムへの小変化を必要とするでしょう。
When calculating the average loss interval, we need to decide whether to include the current loss interval. We only include the current loss interval if it is sufficiently large to increase the average loss interval.
海損間隔について計算するとき、私たちは、当期損失間隔を含んでいるかどうか決める必要があります。 海損間隔を増加させるのが十分大きい場合にだけ、私たちは当期損失間隔を入れます。
Let the most recent loss intervals be I_0 to I_k, where I_0 is the current loss interval. If there have been at least n loss intervals, then k is set to n; otherwise, k is the maximum number of loss intervals seen so far. We calculate the average loss interval I_mean as follows:
最新の損失間隔がI_0であることをI_kにさせてください。そこでは、I_0が当期損失間隔です。 少なくともn損失間隔があったなら、kはnに設定されます。 さもなければ、kは今までのところ見られている損失間隔の最大数です。 私たちは以下のI_が意味する海損間隔について計算します:
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to k-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to k) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0=0。 I_tot1=0。 W_は=0を加えます。 iは(kへのi=1)のためにk-1) I_tot0=I_tot0+(I_i*w_i)(W_幼児=W_幼児+w_i)への0と等しいです。(I_tot1=I_tot1+(I_i*w_(i-1)); I_は=最大(__I tot0、I tot1)を加えます。 I_は、= I_幼児/W_が合計を意味します。
The loss event rate, p is simply:
損失イベント率、pは単に以下の通りです。
p = 1 / I_mean;
1/I_p=平均。
Floyd, et al. Standards Track [Page 23] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[23ページ]: プロトコル仕様2008年9月
5.5. History Discounting
5.5. 歴史の値段をひくこと
As described in Section 5.4, when there have been at least n loss intervals, the most recent loss interval is only assigned 1/(0.75*n) of the total weight in calculating the average loss interval, regardless of the size of the most recent loss interval. This section describes an OPTIONAL history discounting mechanism, discussed further in [FHPW00a] and [W00], that allows the TFRC receiver to adjust the weights, concentrating more of the relative weight on the most recent loss interval, when the most recent loss interval is more than twice as large as the computed average loss interval.
少なくともn損失間隔があったときだけ、セクション5.4で説明されるように、全重量の1/(0.75*n)は海損間隔について計算する際に最新の損失間隔に割り当てられます、最新の損失間隔のサイズにかかわらず。 このセクションはTFRC受信機が重りを調整できる[FHPW00a]と[W00]で、より詳しく議論したOPTIONAL歴史値段をひくメカニズムについて説明します、最新の損失間隔に一層の相対重量を集結して。(その時、最新の損失間隔は計算された海損間隔の2倍以上大きいです)。
To carry out history discounting, we associate a discount factor, DF_i, with each loss interval, L_i, for i > 0, where each discount factor is a floating point number. The discount array maintains the cumulative history of discounting for each loss interval. At the beginning, the values of DF_i in the discount array are initialized to 1:
歴史の値段をひくことを行うために、私たちは割引係数を関連づけます、DF_i、それぞれの損失間隔に、L_i、i>0のために。そこでは、各割引係数が浮動小数点です。 割り引きアレイはそれぞれの損失間隔の間、値段をひく累積している歴史を維持します。 始めに、割り引きアレイのDF_iの値は1に初期化されます:
for (i = 0 to n) {
DF_i = 1;
}
(0〜i=n)のためにDF_i=1。
History discounting also uses a general discount factor, DF, also a floating point number, that is also initialized to 1. First, we show how the discount factors are used in calculating the average loss interval, and then we describe, later in this section, how the discount factors are modified over time.
また、歴史の値段をひくのは一般的な割引係数、DF、また、浮動小数点を使用します、また、それが1に初期化されます。 まず最初に、私たちは割引係数が海損間隔について計算する際にどう使用されるかを示しています、そして、次に、このセクションで、より遅く、割引係数が時間がたつにつれてどう変更されるかを説明します。
As described in Section 5.4, the average loss interval is calculated using the n previous loss intervals I_1, ..., I_n and the current loss interval I_0. The computation of the average loss interval using the discount factors is a simple modification of the procedure in Section 5.4, as follows:
セクション5.4で説明されるように、海損間隔は前のn損失間隔I_1、…を費やすことで計算されます。, Iと当期損失間隔I_0。 割引係数を使用する海損間隔の計算はセクション5.4で、手順の簡単な変更です、以下の通りです:
Floyd, et al. Standards Track [Page 24] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[24ページ]: プロトコル仕様2008年9月
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);
I_tot0はI_0*w_0と等しいです。 I_tot1=0。 W_tot0はw_0と等しいです。 W_tot1=0。 等しい..分
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_が意味する損失間隔I_1の加重平均を計算します…, I:
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;
I_は=0を加えます。 W_は=0を加えます。 W_は=W_幼児+w_(i-1)*DF_iを加えます; (1〜i=n)に関してはI_幼児=I_幼児+(I_i*w_(i-1)*DF_i)、I_は、= I_幼児/W_が合計を意味します。
This weighted average I_mean is compared to I_0, the size of current loss interval. If I_0 is greater than twice I_mean, then the new loss interval is considerably larger than the old ones, and the general discount factor, DF, is updated to decrease the relative weight on the older intervals, as follows:
I_が意味するこの加重平均はI_0、当期損失間隔のサイズにたとえられます。 I_0がI_が意味する2倍より古い方より大きいなら、新しい損失間隔はかなり大きいです、そして、より古い間隔に相対重量を減少させるために、一般的な割引係数(DF)をアップデートします、以下の通りです:
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD) {
DF = THRESHOLD;
}
} else {
DF = 1;
}
(I_0>2*I_意地悪)、DFが(DF<THRESHOLD)であるなら2*I_平均/I_0と等しい、DF=THRESHOLD;、ほかDF=1。
A nonzero value for THRESHOLD ensures that older loss intervals from an earlier time of high congestion are not discounted entirely. We recommend a THRESHOLD of 0.25. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
THRESHOLDのための非ゼロ値は、高い混雑の以前の時間からの、より古い損失間隔が完全に割り引かれないのを確実にします。 私たちは0.25のTHRESHOLDを推薦します。 それぞれの新しいパケット到着に従って、I_0がさらに増加して、割引係数DFをアップデートすることに注意してください。
Floyd, et al. Standards Track [Page 25] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[25ページ]: プロトコル仕様2008年9月
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は忘れられています。 前の割引係数DFは割り引きアレイに組み入れられなければなりません。 DF_私が損失間隔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;
(1〜i=n)、DF*DF DF_i=_i;、(iは0ステップ-1へのn-1と等しいです) DF_(i+1)=DF_i; I_0 = 1。 DF_0 = 1。 DF=1。
This completes the description of the optional history discounting mechanism. We emphasize that this is an OPTIONAL mechanism whose sole purpose is to allow TFRC to respond somewhat more quickly to the sudden absence of congestion, as represented by a long current loss interval.
これは、メカニズムを無視しながら、任意の歴史の記述を終了します。 私たちは、これがTFRCがいくらかすばやく混雑の突然の欠如に応じるのを許容する唯一の目的がことであるOPTIONALメカニズムであると強調します、長い当期損失間隔のそばに表されるように。
6. Data Receiver Protocol
6. データ受信装置プロトコル
The receiver periodically sends feedback messages to the sender. Feedback packets SHOULD normally be sent at least once per RTT, unless the sender is sending at a rate of less than one packet per RTT, in which case a feedback packet SHOULD be sent for every data packet received. A feedback packet SHOULD also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history.
受信機は定期的にフィードバックメッセージを送付者に送ります。 送付者が1RTTあたり1つ未満のパケットのレートで発信しない場合通常、RTT単位でフィードバックパケットSHOULDを少なくとも一度送って、どれがフィードバックパケットSHOULDをケースに入れるかでパケットが受け取ったあらゆるデータのために送ってください。 フィードバックパケットSHOULD、また、新しい損失出来事が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.
送付者が高価で(多くの1RTTあたりのパケット)を伝えているなら、これが、より速くRTT測定を変えることへの応答と、より多くの弾力をフィードバックパケット損失に許容するので、1RTTあたりの一度より多くの送付周期的なフィードバックメッセージのいくつかの利点があるかもしれません。
If the receiver was sending k feedback packets per RTT, for k>1, step (4) of Section 6.2 would be modified to set the feedback timer to expire after R_m/k seconds. However, each feedback packet would still report the receiver rate over the last RTT, not over a fraction of an RTT. In this document, we do not specify the modifications that might be required for a receiver sending more than one feedback packet per RTT. We note that there is little gain from sending a large number of feedback messages per RTT.
受信機が1RTTあたりのkフィードバックパケットを送るなら、k>1に関して、セクション6.2のステップ(4)は、フィードバックタイマにR_m/k秒以降期限が切れるように設定するように変更されるでしょうに。 しかしながら、それぞれのフィードバックパケットはRTTの部分の上で報告するのではなく、最後のRTTの上でまだ受信機レートを報告しているでしょう。 本書では、私たちは1RTTあたり1つ以上のフィードバックパケットを送る受信機に必要であるかもしれない変更を指定しません。 私たちは、多くの1RTTあたりのフィードバックメッセージを送るのからの利得がほとんどないことに注意します。
Floyd, et al. Standards Track [Page 26] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[26ページ]: プロトコル仕様2008年9月
6.1. Receiver Behavior When a Data Packet Is Received
6.1. データ・パケットが受け取られているときの受信機の振舞い
When a data packet is received, the receiver performs the following steps:
データ・パケットが受け取られているとき、受信機は以下のステップを実行します:
1) Add the packet to the packet history.
1) パケット歴史にパケットを追加してください。
2) Check if done: If the new packet results in the detection of a
new loss event, or if no feedback packet was sent when the
feedback timer last expired, go to step 3. Otherwise, no action
need be performed (unless the optimization in the next paragraph
is used), so exit the procedure.
2) するなら、チェックしてください: フィードバックタイマが最後に期限が切れたとき、新しいパケットが新しい損失出来事の検出をもたらすか、またはフィードバックパケットを全く送らなかったなら、ステップ3に行ってください。 さもなければ、動作が全く実行される必要はないので(次のパラグラフにおける最適化が使用されていない場合)、手順を出てください。
An OPTIONAL optimization might check to see if the arrival of the
packet caused a hole in the packet history to be filled, and
consequently, two loss intervals were merged into one. If this
is the case, the receiver might also send feedback immediately.
The effects of such an optimization are normally expected to be
small.
OPTIONAL最適化はいっぱいにされるためにパケット歴史でパケットの到着が穴を引き起こしたかどうか確認するためにチェックしたかもしれません、そして、その結果、2回の損失間隔が1つに合併されました。 また、これがそうであるなら、受信機はすぐに、フィードバックを送るかもしれません。 通常、そのような最適化の効果が小さいと予想されます。
3) Calculate p: Let the previous value of p be p_prev. Calculate
the new value of p as described in Section 5.
3) pについて計算してください: pの前の値がp_prevであることをさせてください。 セクション5で説明されるようにpの新しい値について計算してください。
4) Expire feedback timer: If p > p_prev, cause the feedback timer to
expire and perform the actions described in Section 6.2.
4) フィードバックタイマを吐き出してください: p>p_prevであるなら、フィードバックタイマがセクション6.2で説明された動作を吐き出して、実行することを引き起こしてください。
If p <= p_prev and no feedback packet was sent when the feedback
timer last expired, cause the feedback timer to expire and
perform the actions described in Section 6.2. If p <= p_prev and
a feedback packet was sent when the feedback timer last expired,
no action need be performed.
p<=p_prevを送りましたが、フィードバックタイマが最後に期限が切れたときどんなフィードバックパケットも送らなかったなら、フィードバックタイマがセクション6.2で説明された動作を吐き出して、実行することを引き起こしてください。 フィードバックタイマが最後に期限が切れたとき、p<=p_prevとフィードバックパケットを送ったなら、動作を全く実行する必要はありません。
6.2. Expiration of Feedback Timer
6.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.
受信機のフィードバックタイマが期限が切れるとき、取られるべき動作は最後のフィードバックを送って以来データ・パケットを受け取っているかどうかによります。
For the m-th expiration of the feedback timer, let the maximum sequence number of a packet at the receiver, so far, be S_m and the value of the RTT measurement included in packet S_m be R_m. As described in Section 3.2.1, R_m is the sender's most recent estimate of the round-trip time, as reported in data packets. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
m、-、フィードバックタイマの第満了今までのところ受信機のパケットの最大の一連番号がS_mであることをさせて、R_がmであったならパケットS_mにRTT測定の値を含んでいて。 セクション3.2.1で説明されるように、R_mは送付者の往復の現代の最新の見積りです、データ・パケットで報告されるように。 前のフィードバックを送って以来データ・パケットを受け取っているなら、受信機は以下のステップを実行します:
1) Calculate the average loss event rate using the algorithm
described in Section 5.
1) セクション5で説明されたアルゴリズムを使用して、海損イベント率について計算してください。
Floyd, et al. Standards Track [Page 27] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[27ページ]: プロトコル仕様2008年9月
2) Calculate the measured receive rate, X_recv, based on the packets
received within the previous R_(m-1) seconds. This is performed
whether the feedback timer expired at its normal time or expired
early due to a new lost or marked packet (i.e., step (3) in
Section 6.1).
2) 測定が前のR_(m-1)秒以内に受け取られたパケットに基づいてレート、X_recvを受けると見込んでください。 これは、新しい無くなっているか著しいパケット(すなわち、セクション6.1のステップ(3))のためフィードバックタイマが正常な時に期限が切れたか否かに関係なく、実行されるか、または早く吐き出されます。
In the typical case, when the receiver is sending only one
feedback packet per round-trip time and the feedback timer did
not expire early due to a new lost packet, then the time interval
since the feedback timer last expired would be R_(m-1) seconds.
受信機が往復の時間あたり1つのフィードバックパケットだけを送って、フィードバックタイマが新しい無くなっているパケットのため早く期限が切れなかったときの典型的な場合では、フィードバックタイマが最後に期限が切れたので、次に、時間間隔はR_(m-1)秒でしょう。
We note that when the feedback timer expires early due to a new
lost or marked packet, the time interval since the feedback timer
last expired is likely to be smaller than R_(m-1) seconds.
私たちは、フィードバックタイマが新しい無くなっているか著しいパケットのため早く期限が切れるとき、フィードバックタイマが最後に期限が切れたので、時間間隔がR_(m-1)秒より小さい傾向があることに注意します。
For ease of implementation, if the time interval since the
feedback timer last expired is not R_(m-1) seconds, the receive
rate MAY be calculated over a longer time interval, the time
interval going back to the most recent feedback timer expiration
that was at least R_(m-1) seconds ago.
フィードバックタイマ以来の時間間隔が最後に期限が切れたならR_(m-1)が実現の容易さのための秒でない、受信、レートは、より長い時間間隔にわたって計算されるかもしれません、時間間隔が少なくともR_(m-1)秒であった最新のフィードバックタイマ満了に戻って前
3) Prepare and send a feedback packet containing the information
described in Section 3.2.2.
3) セクション3.2.2で説明された情報を含むフィードバックパケットを、準備して、送ってください。
4) Restart the feedback timer to expire after R_m seconds.
4) フィードバックタイマを再開して、R_m後に秒を吐き出してください。
Note that rule 2) above gives a minimum value for the measured receive rate X_recv of one packet per round-trip time. If the sender is limited to a sending rate of less than one packet per round-trip time, this will be due to the loss event rate, not from a limit imposed by the measured receive rate at the receiver.
上の2が)測定のために最小値を与える規則が往復の時間あたり1つのパケットのレートX_recvを受けることに注意してください。 送付者が往復の時間あたり1つ未満のパケットの送付レートに制限されると、これは測定によって課された限界によって受け取るのではなく、損失イベント率のため受信機にレートを受け取るためにことになるでしょう。
If no data packets have been received since the last feedback was sent, then no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds.
最後のフィードバックを送って以来データ・パケットを全く受け取っていないなら、フィードバックパケットを全く送りません、そして、R_m後に秒を吐き出すためにフィードバックタイマを再開します。
6.3. Receiver Initialization
6.3. 受信機初期設定
The receiver is initialized by the first data packet that arrives at the receiver. Let the sequence number of this packet be i.
受信機は受信機に到着する最初のデータ・パケットによって初期化されます。このパケットの一連番号がiであることをさせてください。
When the first packet is received:
最初のパケットが受け取られているとき:
o Set p = 0.
o p=0を設定してください。
o Set X_recv = 0.
o X_recv=0を設定してください。
o Prepare and send a feedback packet.
o フィードバックパケットを準備して、送ってください。
Floyd, et al. Standards Track [Page 28] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[28ページ]: プロトコル仕様2008年9月
o Set the feedback timer to expire after R_i seconds.
o フィードバックタイマにR_i秒以降期限が切れるように設定してください。
If the first data packet does not contain an estimate R_i of the round-trip time, then the receiver sends a feedback packet for every arriving data packet until a data packet arrives containing an estimate of the round-trip time.
最初のデータ・パケットが往復の現代の見積りR_iを含んでいないなら、往復の現代の見積りを含んでいて、データ・パケットが到着するまで、受信機はあらゆる到着データ・パケットのためにフィードバックパケットを送ります。
If the sender is using a coarse-grained timestamp that increments every quarter of a round-trip time, then a feedback timer is not needed, and the following procedure from RFC 4342 is used to determine when to send feedback messages.
送付者が往復の時間のあらゆる4分の1を増加する下品なタイムスタンプを使用しているなら、フィードバックタイマは必要ではありません、そして、RFC4342からの以下の手順は、いつフィードバックメッセージを送るかを決定するのに用いられます。
o Whenever the receiver sends a feedback message, the receiver sets
a local variable last_counter to the greatest received value of
the window counter since the last feedback message was sent, if
any data packets have been received since the last feedback
message was sent.
o フィードバックメッセージを送るときはいつも、受信機は最後のフィードバックメッセージを送って以来のウィンドウカウンタの最も大きい容認された値に局所変数最終_カウンタを設定します、最後のフィードバックメッセージを送って以来何かデータ・パケットを受け取っているなら。
o If the receiver receives a data packet with a window counter
value greater than or equal to last_counter + 4, then the
receiver sends a new feedback packet. ("Greater" and "greatest"
are measured in circular window counter space.)
o 受信機が受信されるなら、窓の対価があるデータパケットは_カウンタ+4をより持続して、次に、受信機は新しいフィードバックパケットを送ります。 (「大」で「最もすばらしいこと」は円形の窓のカウンタのスペースで測定されます。)
6.3.1. Initializing the Loss History after the First Loss Event
6.3.1. 最初の損失出来事の後に損失歴史を初期化します。
This section describes the procedure that MUST be used for initializing the loss history after the first loss event.
このセクションは最初の損失出来事の後に損失歴史を初期化するのに用いなければならない手順について説明します。
The number of packets until the first loss cannot be used to compute the allowed sending rate directly, as the sending rate changes rapidly during this time. TFRC assumes that the correct data rate after the first loss is half of the maximum sending rate before the loss occurred. TFRC approximates this target rate, X_target, by the maximum value of X_recv so far. (For slow-start, for a particular round-trip time, the sender's sending rate is generally twice the receiver's receive rate for data sent over the previous round-trip time.)
直接許容送付レートを計算するのに最初の損失までのパケットの数を使用できません、送付レートがこの間に急速に変化するとき。 TFRCは、損失が発生する前に最初の損失の後の正しいデータ信号速度が最大の送付レートの半分であると仮定します。 TFRCはこの目標金利に近似して、X_は今までのところ、Xの最大値で_recvを狙います。 (遅れた出発、特定の往復の時間、送付者の送付レートは一般に受信機のものの2倍が前の往復の時間送られたデータのレートを受け取るということです。)
After the first loss, instead of initializing the first loss interval to the number of packets sent until the first loss, the TFRC receiver calculates the loss interval that would be required to produce the data rate X_target, and uses this synthetic loss interval to seed the loss history mechanism.
最初の損失の後に、最初の損失まで送られたパケットの数に最初の損失間隔を初期化することの代わりに、TFRC受信機は、データ信号速度X_目標を生産するのに必要である損失間隔について計算して、損失歴史メカニズムに種を蒔くためにこの合成の損失間隔を費やします。
TFRC does this by finding some value, p, for which the throughput equation in Section 3.1 gives a sending rate within 5% of X_target, given the round-trip time R, and the first loss interval is then set to 1/p. If the receiver knows the segment size, s, used by the
TFRCは何らかの値を見つけることによって、これをします、そして、p(往復の時間R、および最初の損失間隔を考えて、セクション3.1のスループット方程式はX_目標の5%以内で送付レートを与える)は1/pへのセットです。 受信機はサイズ(s)が使用したセグメントを知っています。
Floyd, et al. Standards Track [Page 29] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[29ページ]: プロトコル仕様2008年9月
sender, then the receiver MAY use the throughput equation for X; otherwise, the receiver MAY measure the receive rate in packets per second instead of bytes per second for this purpose, and use the throughput equation for X_pps. (The 5% tolerance is introduced simply because the throughput equation is difficult to invert, and we want to reduce the costs of calculating p numerically.)
送付者、次に、受信機はXにスループット方程式を使用するかもしれません。 さもなければ、受信機が測定するかもしれない、1秒あたりのバイトの代わりに1秒あたりのパケットにこのためにレートを受け取ってください、そして、X_ppsにスループット方程式を使用してください。 (単にスループット方程式は逆にするのが難しいので、5%の寛容を導入して、数の上で計算のpのコストを削減したいと思います。)
Special care is needed for initializing the first loss interval when the first data packet is lost or marked. When the first data packet is lost in TCP, the TCP sender retransmits the packet after the retransmit timer expires. If TCP's first data packet is ECN-marked, the TCP sender resets the retransmit timer, and sends a new data packet only when the retransmit timer expires [RFC3168] (Section 6.1.2). For TFRC, if the first data packet is lost or ECN-marked, then the first loss interval consists of the null interval with no data packets. In this case, the loss interval length for this (null) loss interval SHOULD be set to give a similar sending rate to that of TCP, as specified in the paragraph below.
特別な注意が最初のデータ・パケットが失われているか、またはマークされる最初の損失間隔を初期化するのに必要です。 最初のデータ・パケットがTCPで失われているとき、再送信タイマが期限が切れた後にTCP送付者はパケットを再送します。 TCPの最初のデータ・パケットが電子証券取引ネットワークが著しいなら、TCP送付者は、再送信タイマをリセットして、再送信タイマが[RFC3168](セクション6.1.2)を吐き出すときだけ、新しいデータ・パケットを送ります。 TFRCに関しては、最初のデータ・パケットが無くなるか、または電子証券取引ネットワークが著しいなら、最初の損失間隔はデータ・パケットなしでヌル間隔から成ります。 この場合損失間隔の長さ、この(ヌル)の損失間隔SHOULDの間、同様の送付レートをTCPのものに与えるように設定されてください、以下のパラグラフで指定されるように。
When the first TFRC loss interval is null, meaning that the first data packet is lost or ECN-marked, in order to follow the behavior of TCP, TFRC wants the allowed sending rate to be 1 packet every two round-trip times, or equivalently, 0.5 packets per RTT. Thus, the TFRC receiver calculates the loss interval that would be required to produce the target rate X_target of 0.5/R packets per second, for the round-trip time R, and uses this synthetic loss interval for the first loss interval. The TFRC receiver uses 0.5/R packets per second as the minimum value for X_target when initializing the first loss interval.
最初のデータ・パケットが無くなるか、または電子証券取引ネットワークが著しいことを意味して、最初のTFRC損失間隔がヌルであるときに、TFRCは、TCPの動きに続くように許容送付レートに往復の2回毎、または同等に1つのパケットになって欲しいです、1RTTあたり0.5のパケット。 したがって、TFRC受信機は、往復の時Rに1秒あたり0.5/Rパケットの目標金利X_目標を生産するのに必要である損失間隔について計算して、最初の損失間隔の間、この合成の損失間隔を費やします。 最初の損失間隔を初期化するとき、TFRC受信機はX_目標に最小値として1秒あたり0.5/Rパケットを使用します。
We note that even though the TFRC receiver reports a synthetic loss interval after the first loss event, the TFRC receiver still reports the measured receive rate X_recv, as specified in Section 6.2 above.
最初の損失出来事の後の合成の損失間隔、TFRC受信機がまだ測定を報告しているというTFRC受信機レポートはレートX_recvを受けますが、私たちはそれに注意します、上のセクション6.2で指定されるように。
7. Sender-Based Variants
7. 送付者ベースの異形
In a sender-based variant of TFRC, the receiver uses reliable delivery to send information about packet losses to the sender, and the sender computes the packet loss rate and the acceptable transmit rate.
TFRCの送付者ベースの異形では、受信機はパケット損失の情報を送付者に送るのに信頼できる配信を使用します、そして、送付者はパケット損失率を計算します、そして、許容できるのはレートを伝えます。
The main advantage of a sender-based variant of TFRC is that the sender does not have to trust the receiver's calculation of the packet loss rate. However, with the requirement of reliable delivery of loss information from the receiver to the sender, a sender-based TFRC would have much tighter constraints on the transport protocol in which it is embedded.
TFRCの送付者ベースの異形の主な利点は送付者が受信機のパケット損失率の計算を信じる必要はないということです。 しかしながら、損失情報の受信機から送付者までの信頼できる配信の要件によって、送付者ベースのTFRCはそれが埋め込まれているトランスポート・プロトコルにはるかにきつい規制を持っているでしょう。
Floyd, et al. Standards Track [Page 30] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[30ページ]: プロトコル仕様2008年9月
In contrast, the receiver-based variant of TFRC specified in this document is robust to the loss of feedback packets, and therefore does not require the reliable delivery of feedback packets. It is also better suited for applications where it is desirable to offload work from the server to the client as much as possible.
対照的に、本書では指定されたTFRCの受信機ベースの異形は、フィードバックパケットの損失に強健であり、したがって、フィードバックパケットの信頼できる配信を必要としません。 また、それはサーバからクライアントまでの仕事をできるだけ積み下ろすのが望ましいアプリケーションに合うほうがよいです。
RFC 4340 and RFC 4342 together specify DCCP's CCID 3, which can be used as a sender-based variant of TFRC. In CCID 3, each feedback packet from the receiver contains a Loss Intervals option, reporting the lengths of the most recent loss intervals. Feedback packets may also include the Ack Vector option, allowing the sender to determine exactly which packets were dropped or marked and to check the information reported in the Loss Intervals options. The Ack Vector option can also include ECN Nonce Echoes, allowing the sender to verify the receiver's report of having received an unmarked data packet. The Ack Vector option allows the sender to see for itself which data packets were lost or ECN-marked, to determine loss intervals, and to calculate the loss event rate. Section 9 of RFC 4342 discusses issues in the sender verifying information reported by the receiver.
一緒にRFC4340とRFC4342はDCCPのCCID3を指定します。(TFRCの送付者ベースの異形としてCCIDを使用できます)。 CCID3では、受信機からのそれぞれのフィードバックパケットはLoss Intervalsオプションを含んでいます、最新の損失間隔の長さを報告して。 また、フィードバックパケットはAck Vectorオプションを含むかもしれません、送付者がどのパケットが落とされたか、またはマークされたかをまさに決心して、Loss Intervalsオプションで報告された情報をチェックするのを許容して。 また、Ack Vectorオプションは電子証券取引ネットワークNonceエコーズを含むことができます、送付者が受信機の無印のデータ・パケットを受けたレポートについて確かめるのを許容して。 Ack Vectorオプションで、送付者は、どのデータ・パケットが無くなるか、または電子証券取引ネットワークが著しかったかを自分の目で確かめて、損失間隔を決定して、損失イベント率を見込みます。 RFC4342のセクション9は受信機によって報告された情報について確かめる送付者で問題について論じます。
8. Implementation Issues
8. 導入問題
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the implementation issues.
このドキュメントはアプリケーションとトランスポート・プロトコルでTFRC混雑制御機構を使用に指定しました。 このセクションは簡潔に導入問題のいくつかについて言及します。
8.1. Computing the Throughput Equation
8.1. スループット方程式を計算します。
For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 can be expressed as follows:
t_RTO=4*Rとb=1に関しては、以下の通りセクション3.1のスループット方程式を言い表すことができます:
s
X_Bps = --------
R * f(p)
s X_bps=-------- R*f(p)
for
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.
掛け算(往復の時間平均、タイムアウト間隔の間の4の要素のための例えば、qと1-q)の多くは、あるか、または2人の強国であるかもしれなくて、したがって、簡単な交替制として実行できました。
Floyd, et al. Standards Track [Page 31] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[31ページ]: プロトコル仕様2008年9月
8.2. Sender Behavior When a Feedback Packet Is Received
8.2. フィードバックパケットが受け取られているときの送付者の振舞い
This section discusses implementation issues for sender behavior when a feedback packet is received, from Section 4.3.
セクション4.3からフィードバックパケットを受け取るとき、このセクションは送付者の振舞いのために導入問題について論じます。
8.2.1. Determining If an Interval Was a Data-Limited Interval
8.2.1. 間隔がデータ株式会社間隔であったかどうか決定します。
When a feedback packet is received, the sender has to determine if the entire interval covered by that feedback packet was a data- limited period. This section discusses one possible implementation for the sender to determine if the interval covered by a feedback packet was a data-limited period.
フィードバックパケットが受け取られているとき、送付者は、そのフィードバックパケットで覆われた全体の間隔がデータ限定期間であったかどうかと決心しなければなりません。 送付者が、フィードバックパケットで覆われた間隔がデータ限定期間であったかどうかと決心するように、このセクションは1つの可能な実現について論じます。
If the feedback packets all report the timestamp of the last data packet received, then let t_new be the timestamp reported by this feedback packet. Because all feedback packets cover an interval of at least a round-trip time, it is sufficient for the sender to determine if there was any time in the period (t_old, t_new] when the sender was not data-limited, for R the sender's estimate of the round-trip time, and for t_old set to t_new - R. (This procedure estimates the interval covered by the feedback packet, rather than computing it exactly. This seems fine to us.)
_フィードバックパケットが最後のデータ・パケットに関するタイムスタンプが受信されたとすべて報告して、次に、tをさせるなら、新しいのは、このフィードバックパケットによって報告されたタイムスタンプです。 すべてのフィードバックパケットが少なくとも往復の時間の間隔を覆っているので、送付者が、新しい_が送付者がtへの送付者の往復の現代の見積りの、そして、t_に、古いRのためにデータで限られたセットでなかった時代(古い_t t_新しい]にいつでもあったかを決心しているのは、十分です--R。(この手順はまさにそれを計算するよりフィードバックパケットでむしろ覆われた間隔を見積もっています。 これは私たちにとって大丈夫に見えます。)
The pseudocode for determining if the sender was data-limited over the entire interval covered in a feedback packet is given below. The variables NotLimited1 and NotLimited2 both represent times when the sender was *not* data-limited.
送付者がフィードバックパケットで覆われた全体の間隔にわたってデータによって限られたかどうか決定するための擬似コードを以下に与えます。 変数のNotLimited1とNotLimited2はともに、データによって制限されていた状態で送付者が*ではなく、*であった回を表します。
Initialization:
NotLimited1 = NotLimited2 = t_new = t_next = 0;
t_now = current time;
初期設定: _次のNotLimited2NotLimited1==t新しい=t_=0。 t_は現在、現在の時間と等しいです。
After sending a segment:
If (sender has sent all it is allowed to send) {
// Sender is not data-limited at this instant.
If NotLimited1 <= t_new
// Goal: NotLimited1 > t_new.
NotLimited1 = t_now;
Else if (NotLimited2 <= t_next)
// Goal: NotLimited2 > t_next.
NotLimited2 = t_now;
}
セグメントを送った後に: (送付者はそれが送ることができるすべてを送りました){ //送付者はこの瞬間にデータによって限られません。 NotLimited1=t_新しい<//目標であるなら: NotLimited1>t_新しいです。 NotLimited1は_現在、tと等しいです。 ほか、(NotLimited2<=t_次)//目標であるなら: 次のNotLimited2>t_。 NotLimited2は_現在、tと等しいです。 }
Floyd, et al. Standards Track [Page 32] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[32ページ]: プロトコル仕様2008年9月
When a feedback packet is received, is this interval data-limited:
t_new = timestamp reported in feedback packet.
t_old = t_new - R. // local variable
t_next = t_now;
If ((t_old < NotLimited1 <= t_new) or
(t_old < NotLimited2 <= t_new))
This was not a data-limited interval;
Else
This was a data-limited interval.
If (NotLimited1 <= t_new && NotLimited2 > t_new)
NotLimited1 = NotLimited2;
フィードバックパケットが受け取られているとき、この間隔はデータで有限です: t_新しい=タイムスタンプは、フィードバックパケットtで_古い=t_が新しいと報告しました--_現在の次のR.//局所変数t=t_ ((古いt<NotLimited1<=t__新しい)か(古いt<NotLimited2<=t__新しい))であるなら、これはデータで限られた間隔ではありませんでした。 ほかに、Thisはデータで限られた間隔でした。 (NotLimited1<がt_と新しい状態で等しい、NotLimited2>t_新しい、)、NotLimited1はNotLimited2と等しいです。
Transmission times refer to transmission of a segment or segments to the layer below.
トランスミッション時間はセグメントかセグメントの送信を以下の層と呼びます。
Between feedback packets, (t_old, t_new] gives the transmission time interval estimated to be covered by the most recent feedback packet, and t_next gives a time at least a round-trip time greater than t_new. The next feedback packet can be expected to cover roughly the interval (t_new, t_next] (unless the receiver sends the feedback packet early because it is reporting a new loss event). The goal is for NotLimited1 to save a non-data-limited time in (t_new, t_next], if there was one, and for NotLimited2 to save a non-data-limited time after t_next.
トランスミッション時間間隔は最新のフィードバックパケットで覆われているために見積もっていました、そして、次のt_は少なくともt_より大きい往復の時間を時間に新しい状態で与えます。次のフィードバックパケットがおよそ間隔を覆うと予想できます。目標はNotLimited1が中で制限された非データ時間を節約することです。フィードバックパケットの間で(古い_t t_新しい、付与、(新しいt_t_次(それが新しい損失出来事を報告しているので受信機が早くフィードバックパケットを送らない場合)、(次の新しい_t t_; 1つがあって、_次にtの後に制限された非データ時間を節約するNotLimited2のために。
When a feedback packet was received, if either NotLimited1 or NotLimited2 is in the time interval covered by the feedback packet, then the interval is not a data-limited interval; the sender was not data-limited at least once during that time interval. If neither NotLimited1 nor NotLimited2 is in the time interval covered by a feedback packet, then the sender is assumed to have been data-limited over that time interval.
フィードバックパケットを受け取ったとき、NotLimited1かNotLimited2のどちらかがフィードバックパケットで覆われた時間間隔にあるなら、間隔はデータで限られた間隔ではありません。 送付者はデータで少なくとも一度限られたその時の間、間隔ではありませんでした。 NotLimited1もNotLimited2もフィードバックパケットで覆われた時間間隔にないなら、送付者はデータで限られたその時の間、間隔であったと思われます。
We note that this procedure is a heuristic, and in some cases the sender might not determine correctly if the sender was data-limited over the entire interval covered by the feedback packet. This heuristic does not address the possible complications of reordering.
私たちは、この手順がヒューリスティックであることに注意します、そして、いくつかの場合、送付者は送付者がフィードバックパケットで覆われた全体の間隔にわたってデータによって限られたかどうかと正しく決心しないかもしれません。 このヒューリスティックは再命令の可能な複雑さを記述しません。
That seems acceptable to us. In order to improve its accuracy in identifying if the entire interval covered by a feedback packet was a data-limited interval, the sender could save more NotLimited times.
それは私たちにとって許容できるように思えます。 フィードバックパケットで覆われた全体の間隔がデータで限られた間隔であったかどうか特定する際に精度を改良するために、送付者は、より多くのNotLimited回を貯蓄できました。
In some implementations of TFRC, the sender sends coarse-grained timestamps that increment every quarter of a round-trip time, and the feedback packet reports the greatest valid sequence number received so far instead of reporting the timestamp of the last packet received. In this case, the sender can maintain per-packet state to
TFRCのいくつかの実現では、送付者は往復の時間のあらゆる4分の1を増加する下品なタイムスタンプ、および最大級の有効な一連番号が報告の代わりにあまりに遠くに最後のパケットに関するタイムスタンプが受信されたほど受け取ったフィードバックパケットレポートを送ります。 この場合缶が1パケットあたりの状態を維持する送付者
Floyd, et al. Standards Track [Page 33] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[33ページ]: プロトコル仕様2008年9月
determine t_new (the time that the acknowledged packet was sent), or the sender can estimate t_new from its estimate of the round-trip time and the elapsed time t_delay reported by the feedback packet.
(承認されたパケットを送った時間)のときに新しいt_を決心してください。さもないと、送付者は、tがフィードバックパケットによって報告された往復の時間と経過時間t_遅れの見積りのために新しい_であると見積もることができます。
8.2.2. Maintaining X_recv_set
8.2.2. X_recv_がセットしたと主張します。
To reduce the complexity of maintaining X_recv_set, it is sufficient to limit X_recv_set to at most N=3 elements. In this case, the procedure Update X_recv_set() would be modified as follows:
X_recv_がセットしたと主張する複雑さを減少させるために、高々N=3要素に用意ができているX_recv_を制限するのは十分です。 この場合、手順Update X_recv_セット()は以下の通り変更されるでしょう:
Update X_recv_set():
Add X_recv to X_recv_set;
Delete from X_recv_set values older than
two round-trip times.
Keep only the most recent N values.
X_recv_セット()をアップデートしてください: X_recv_へのX_recvがセットしたと言い足してください。 Xから、_往復の2回より古いrecv_設定値を削除してください。 最新の唯一のNが値であることを保ってください。
Maintaining at most *two* elements in X_recv_set would be sufficient for the sender to save an old value of X_recv from before a data- limited period, and to allow the sender not to be limited by the first feedback packet after an idle period (reporting a receive rate of one packet per round-trip time). However, it is *possible* that maintaining at most two elements in X_recv_set would not give quite as good performance as maintaining at most three elements. Maintaining three elements in X_recv_set would allow X_recv_set to contain X_recv values from two successive feedback packets, plus a more recent X_recv value from a loss event.
*X_recv_の2*要素がセットしたと高々主張するのは、X_の古い値を除いて、送付者が以前からデータ限定期間をrecvして、送付者が活動していない期間(aが、ある往復の時間あたりのパケットのレートを受け取ると報告する)の後に最初のフィードバックパケットによって制限されないのを許容するために十分でしょう。 しかしながら、それは*Xのほとんどの2つの要素で_recv_がセットしたと主張するのが維持しているのと全く同じくらい良いほとんどの3つの要素での性能を与えないのが可能な*です。 X_recv_の3つの要素がセットしたと主張するのは、2つの連続したフィードバックパケットから_がX_recv値を含むように設定したX_recvを許容して、損失出来事から、より最近のX_recv値を許容するでしょう。
8.3. Sending Packets before Their Nominal Send Time
8.3. 以前パケットを送る、それら、名目上、時間を送ってください。
This section discusses one possible scheduling mechanism for a sender in an operating system with a coarse-grained timing granularity (from Section 4.6).
このセクションは送付者のためにオペレーティングシステムで下品なタイミング粒状(セクション4.6からの)に1つの可能なスケジューリングメカニズムについて論じます。
Let t_gran be the scheduling timer granularity of the operating system. Let t_ipi be the inter-packet interval, as specified in Section 4.6. If the operating system has a coarse timer granularity or otherwise cannot support short t_ipi intervals, then either the TFRC sender will be restricted to a sending rate of at most 1 packet every t_gran seconds, or the TFRC sender must be allowed to send short bursts of packets. In addition to allowing the sender to accumulate sending credits for past unused send times, it can be useful to allow the sender to send a packet before its scheduled send time, as described in the section below.
t_おばあちゃんがオペレーティングシステムのスケジューリングタイマ粒状であることをさせてください。 t_ipiがセクション4.6で指定されるように相互パケット間隔であることをさせてください。 オペレーティングシステムが粗いタイマ粒状を持つことができませんし、そうでなければ、短いt_ipi間隔を支持できないと、TFRC送付者はほとんどの1つのパケットのおばあちゃんの秒、またはTFRC送付者にパケットの短い炸裂を送らせなければならないあらゆるt_の送付レートに制限されるでしょう。 送付者が蓄積するのを許容すること過去の未使用の送付クレジットが回を送るに加えて、送付者が発信するのを許容するのは役に立つ場合があります。それが予定される前にパケットは時間を送ります、下のセクションで説明されるように。
A parameter, t_delta, may be used to allow a packet to be sent before its nominal send time. Consider an application that becomes idle and requests re-scheduling for time t_i = t_(i-1) + t_ipi, for t_(i-1) the send time for the previous packet. When the application is
パラメタ(t_デルタ)は、名目上になる前にパケットが送られるのを許容するのに使用されるかもしれません。時間を送ってください。 t_(i-1)+t活動していなくなるアプリケーションと時tに_iの時期変更する要求=_がipiであると考えてください、t_(i-1)のために前のパケットのための時間を送ってください。 アプリケーションはいつですか。
Floyd, et al. Standards Track [Page 34] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[34ページ]: プロトコル仕様2008年9月
rescheduled, it checks the current time, t_now. If (t_now > t_i - t_delta), then packet i is sent. When the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - t_delta. In such a case, the packet would be sent immediately.
時期変更されていて、それは現在、現在の時間、t_をチェックします。 (_現在のt>t_i--t_デルタ)、そして、パケットiを送ります。 名目上であるときには時間を送ってください、そして、次のパケットのt_iは計算されて、それはケースが_現在のそのtであったなら既にそうしてもよいです。>t_i--t_デルタ。 このような場合には、すぐに、パケットを送るでしょう。
In order to send at most one packet before its nominal send time, and never to send a packet more than a round-trip time before its nominal send time, the parameter t_delta would be set as follows:
名目上になる前に1つのパケットを高々送るために時間を送って、名目上になる前にパケットを決して送らないように、往復の時間以上は時間を送ります、そして、パラメタt_デルタは以下の通り設定されるでしょう:
t_delta = min(t_ipi, t_gran, rtt)/2;
t_デルタは分(t_ipi、t_おばあちゃん、rtt)/2と等しいです。
(The scheduling granularity t_gran is 10 ms on some older Unix systems.)
(スケジューリング粒状のt_おばあちゃんはいくつかの、より古いUnixシステムの上の10msです。)
As an example, consider a TFRC flow with an allowed sending rate X of 10 packets per round-trip time (PPR), a round-trip time of 100 ms, a system with a scheduling granularity t_gran of 10 ms, and the ability to accumulate unused sending credits for a round-trip time. In this case, t_ipi is 1 ms. The TFRC sender would be allowed to send packets 0.5 ms before their nominal sending time, and would be allowed to save unused sending credits for 100 ms. The scheduling granularity of 10 ms would not significantly affect the performance of the connection.
例として、往復の時間あたり10のパケットの許容送付レートXに従ったTFRC流動が(PPR)と、100msの往復の時間と、10msのスケジューリング粒状のt_おばあちゃんとのシステムと、往復の時間未使用の送付クレジットを蓄積する能力であると考えてください。 この場合、t_ipiは100原稿のためのTFRC送付者がそうする原稿が彼らの名目上の送付時の前に0.5msをパケットに送るのが許容されていて、未使用の送付クレジットを救うことができる1です。10msのスケジューリング粒状は接続に関する実績にかなり影響しないでしょう。
As a different example, consider a TFRC flow with a scheduling granularity greater than the round-trip time, for example, with a round-trip time of 0.1 ms and a system with a scheduling granularity of 1 ms, and with the ability to accumulate unused sending credits for a round-trip time. The TFRC sender would be allowed to save unused sending credits for 0.1 ms. If the scheduling granularity *did not* affect the sender's response to an incoming feedback packet, then the TFRC sender would be able to send an RTT of data (as determined by the allowed sending rate) each RTT, in response to incoming feedback packets. In this case, the coarse scheduling granularity would not significantly reduce the sending rate, but the sending rate would be bursty, with a round-trip time of data sent in response to each feedback packet.
異なった例と、例えば0.1msの往復の時間がある往復の時間と1msのスケジューリング粒状があるシステムより長いスケジューリング粒状、および往復の時間未使用の送付クレジットを蓄積する能力に従ったTFRC流動を考えてください。 TFRC送付者は0.1原稿のために未使用の送付クレジットを貯蓄できるでしょう。スケジューリング粒状*が*でないのをしたIfは入って来るフィードバックパケットへの送付者の応答に影響します、次に、TFRC送付者がデータ(許容送付レートで決定するように)のRTTに各RTTを送ることができるでしょう、入って来るフィードバックパケットに対応して。 この場合、粗いスケジューリング粒状は送付レートをかなり低下させないでしょうが、送付レートはburstyでしょう、データの往復の時間をそれぞれのフィードバックパケットに対応した送付で。
However, performance would be different, in this case, if the operating system scheduling granularity affected the sender's response to feedback packets as well as the general scheduling of the sender. In this case, the sender's performance would be severely limited by the scheduling granularity being greater than the round- trip time, with the sender able to send an RTT of data, at the allowed sending rate, at most once every 1 ms. This restriction of the sending rate is an unavoidable consequence of allowing burstiness of at most a round-trip time of data.
しかしながら、性能は異なっているでしょう、この場合、オペレーティングシステムスケジューリング粒状が送付者の一般的なスケジューリングと同様にフィードバックパケットへの送付者の応答に影響したなら。 この場合、送付者の実績は送付者が許容送付レート、大部分でデータのRTTを送ることができる丸い旅行時間より送付レートのあらゆる1つの原稿This制限がいったん高々データの往復の時間のburstinessを許容する避けられない結果になるとすばらしいスケジューリング粒状によって厳しく制限されるでしょう。
Floyd, et al. Standards Track [Page 35] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[35ページ]: プロトコル仕様2008年9月
8.4. Calculation of the Average Loss Interval
8.4. 海損間隔の計算
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_(n-1)への重りw_0への掛け算にかかわります。(n=8であるときに、掛け算は以下の通りです)。
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.
8.5. The Optional History Discounting Mechanism
8.5. 任意の歴史値段をひくメカニズム
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のパワーになるように制限されるかもしれません。
9. Changes from RFC 3448
9. RFC3448からの変化
9.1. Overview of Changes
9.1. 変化の概観
This section summarizes the changes from RFC 3448. At a high level, the main change is to add mechanisms to address the case of a data- limited sender. This document also explicitly allows the TFRC sender to accumulate up to a round-trip time of unused send credits, and as a result to send a burst of packets if data arrives from the application in a burst after a data-limited period. This issue was not explicitly addressed in RFC 3448.
このセクションはRFC3448から変化をまとめます。 高いレベルでは、主な変化は、データの限られた送付者のケースを記述するためにメカニズムを加えることになっています。 また、このドキュメントは明らかに未使用では、クレジットを送ってください。そうすれば、その結果、発信するために、パケットの炸裂がデータであるならデータ限定期間の後にアプリケーションから炸裂に到着する往復の時代に蓄積するTFRC送付者を許容します。 この問題はRFC3448に明らかに記述されませんでした。
This document changes RFC 3448 to incorporate TCP's higher initial sending rates from RFC 3390. This document also changes RFC 3448 to allow RFC 4342's use of a coarse-grained timestamp on data packets instead of a more fine-grained timestamp.
このドキュメントは、RFC3390からTCPの、より高い初期の送付レートを取り入れるためにRFC3448を変えます。 また、このドキュメントは、きめ細かにより粒状のタイムスタンプの代わりにデータ・パケットにおける下品なタイムスタンプのRFC4342の使用を許すためにRFC3448を変えます。
Other changes address corner cases involving slow-start, the response when the first data packet is dropped, and the like. This document also incorporates the items in the RFC 3448 Errata.
他の変化は遅れた出発、最初のデータ・パケットが落とされるときの応答にかかわる角のケースと同様のものを記述します。 また、このドキュメントはRFC3448Errataの項目を組み込みます。
This section is non-normative; the normative text is in the cited sections.
このセクションは非規範的です。 標準のテキストが引用されたセクションにあります。
Floyd, et al. Standards Track [Page 36] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[36ページ]: プロトコル仕様2008年9月
9.2. Changes in Each Section
9.2. 各セクションにおける変化
Section 4.1, estimating the average segment size: Section 4.1 was modified to give a specific algorithm that could be used for estimating the average segment size.
平均したセグメントがサイズであると見積もっているセクション4.1: セクション4.1は、平均したセグメントがサイズであると見積もるのに使用できた特定のアルゴリズムを与えるように変更されました。
Section 4.2, update to the initial sending rate: In RFC 3448, the initial sending rate was two packets per round-trip time. In this document, the initial sending rate can be as high as four packets per round-trip time, following RFC 3390. The initial sending rate was changed to be in terms of the segment size s, not in terms of the MSS.
セクション4.2 初期の送付レートに以下をアップデートしてください。 RFC3448では、往復の時間あたり初期の送付レートは2つのパケットでした。 RFC3390に続いて、本書では、初期の送付レートは往復の時間あたり4つのパケットと同じくらい高いことができます。 セグメントサイズsに関してMSSに関してあるのではなく、あるように初期の送付レートを変えました。
Section 4.2 now says that tld, the Time Last Doubled during slow- start, can be initialized to either 0 or to -1. Section 4.2 was also clarified to say that RTT measurements do not only come from feedback packets; they could also come from other places, such as the SYN exchange.
セクション4.2は、現在、tld(遅い始めの間のTime Last Doubled)を0、または、-1に初期化できると言います。 また、セクション4.2はRTT測定値がフィードバックパケットから来るだけではないと言うためにはっきりさせられました。 また、彼らはSYN交換などの他の場所から来るかもしれません。
Section 4.3, response to feedback packets: Section 4.3 was modified to change the way that the receive rate is used in limiting the sender's allowed sending rate, by using the set of receive rate values of the last two round-trip times, and initializing the set of receive rate values by a large value.
セクション4.3、フィードバックパケットへの応答: 送付者が最後の往復の2回のレート値を受けて、セットを初期化するセットを使用するのによるレートを送らせた制限で使用されるレートを受け取ってください。セクション4.3が道を変えるように変更された、それ、大きい値でレート値を受けてください。
The larger initial sending rate in Section 4.2 is of little use if the receiver sends a feedback packet after the first packet is received, and the sender, in response, reduces the allowed sending rate to at most two packets per RTT, which would be twice the receive rate. Because of the change in the sender's processing of the receive rate, the sender now does not reduce the allowed sending rate to twice the reported receive rate in response to the first feedback packet.
最初のパケットが受け取られていた後に受信機がフィードバックパケットを送って、応答における送付者が許容送付レートを高々2つのパケットまで低下させるならセクション4.2における、より大きい初期の送付レートがRTT単位でほとんど役に立たない、レートを受け取ってください。二度RTTはそうでしょう。 送付者の処理における変化、レートを受け取ってください、そして、送付者は、今、最初のフィードバックパケットに対応して二度への報告が受け取るレートにレートを送りながら、許容を減少させません。
During a data-limited period, the sender saves the receive rate reported from just before the data-limited period, if it is larger than the receive rate during the data-limited period. The sender also reduces the saved values in X_recv_set in response to a loss during a data-limited period. Appendix C discusses this response further.
データ限定期間の間、送付者が節約する、データ限定期間の少し前に報告されたレートを受け取ってください、それが、より大きいならデータ限定期間の間、レートを受け取ってください。 また、送付者はデータ限定期間の間の損失に対応して用意ができているX_recv_で救われた値を減少させます。 付録Cはさらにこの応答について議論します。
Section 4.4, response to an idle period: Following Section 5.1 from [RFC4342], this document specifies that when the sending rate is reduced after an idle period that covers the period since the nofeedback timer was set, the allowed sending rate is not reduced below the initial sending rate. (In Section 4.4, the variable recover_rate is set to the initial sending rate.)
セクション4.4、活動していない期間への応答: [RFC4342]からセクション5.1に続いて、このドキュメントは、送付レートがnofeedbackタイマが設定されて以来の期間をカバーする活動していない期間の後に低下するとき、許容送付レートが初期の送付速度より下で低下しないと指定します。 (4.4に、変数が回復するセクションでは、_レートは初期の送付レートに設定されます。)
Floyd, et al. Standards Track [Page 37] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[37ページ]: プロトコル仕様2008年9月
Section 4.4, correction from [RFC3448Err]. RFC 3448 had contradictory text about whether the sender halved its sending rate after *two* round-trip times without receiving a feedback report, or after *four* round-trip times. This document clarifies that the sender halves its sending rate after four round-trip times without receiving a feedback report [RFC3448Err].
[RFC3448Err]からのセクション4.4、修正。 RFC3448は回フィードバックレポートを受け取ることなしで、または*の後に往復の4*回送付者が*two*の後に送付レートを半分にしたかどうかに関する相容れないテキストを往復にしました。 このドキュメントは送付者がフィードバックレポート[RFC3448Err]を受け取りながら往復の4回の後の送付レートを半分にするはっきりさせられます。
Section 4.4, clarification for slow-start: Section 4.4 was clarified to specify that on the expiration of the nofeedback timer, if p = 0, X_Bps cannot be used, because the sender does not yet have a value for X_Bps. Section 4.4 was also clarified to check the case when the sender does not yet have an RTT sample, but has sent a packet since the nofeedback timer was set.
セクション4.4、遅れた出発のための明確化: セクション4.4はnofeedbackタイマの満了のときにp=0であるなら、X_Bpsを使用できないと指定するためにはっきりさせられました、送付者にはX_Bpsのための値がまだないので。 セクション4.4は、また、送付者にRTTのサンプルがまだないとケースをチェックするためにはっきりさせられましたが、nofeedbackタイマが設定されて以来、パケットを送ります。
Section 4.6: credits for unused send time:
セクション4.6: クレジット、未使用、時間を送ってください:
Section 4.6 has been clarified to say that the TFRC sender gets to accumulate up to an RTT of credits for unused send time. Section 4.6 was also rewritten to clarify what is specification and what is implementation.
クレジットのRTTに蓄積するTFRC送付者が、始めるセクション4.6が言うのがはっきりさせられた、未使用、時間を送ってください。 また、セクション4.6は、何が仕様であるか、そして、何が実現であるかをはっきりさせるために書き直されました。
Section 5.4, clarification: Section 5.4 was modified to clarify the receiver's calculation of the average loss interval when the receiver has not yet seen n loss intervals.
セクション5.4、明確化: セクション5.4 受信機の受信機がそうしていない海損間隔の計算をはっきりさせるように変更されましたが、n損失間隔を見ます。
Section 5.5, correction: Section 5.5 was corrected to say that the loss interval I_0 includes all transmitted packets, including lost and marked packets (as defined in Section 5.3 in the general definition of loss intervals).
セクション5.5、修正: セクション5.5はI_0がすべてを含む損失間隔がパケットを伝えたと言うために修正されました、無くなっていて著しいパケットを含んでいて(損失間隔の一般的な定義でセクション5.3で定義されるように)。
Section 5.5, correction from [RFC3448Err]: A line in Section 5.5 was changed from
[RFC3448Err]からのセクション5.5、修正: セクション5.5の線から、変えました。
for (i = 1 to n) { DF_i = 1; }
(1〜i=n)のためにDF_i=1。
to
to
for (i = 0 to n) { DF_i = 1; }
(0〜i=n)のためにDF_i=1。
[RFC3448Err].
[RFC3448Err。]
Section 5.5, history discounting: THRESHOLD, the lower bound on the history discounting parameter DF, has been changed from 0.5 to 0.25, to allow more history discounting when the current interval is long.
セクション5.5、歴史の値段をひくこと: THRESHOLD(歴史値段をひくパラメタDFにおける下界)は、現在の間隔が長いときに、より多くの歴史の値段をひくことを許すために0.5〜0.25に変わりました。
Section 6, multiple feedback packets: Section 6 now contains more discussion of procedures if the receiver sends multiple feedback packets each round-trip time.
セクション6、複数のフィードバックパケット: 受信機が往復の毎回複数のフィードバックパケットを送るなら、セクション6は現在、手順の、より多くの議論を含みます。
Floyd, et al. Standards Track [Page 38] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[38ページ]: プロトコル仕様2008年9月
Section 6.3, initialization of the feedback timer: Section 6.3 now specifies the receiver's initialization of the feedback timer if the first data packet received does not have an estimate of the round- trip time.
セクション6.3、フィードバックタイマの初期化: パケットが受け取った最初のデータが丸い旅行時間の見積りを持っていないなら、セクション6.3は現在、受信機のフィードバックタイマの初期化を指定します。
Section 6.3, a coarse-grained timestamp: Section 6.3 was modified to incorporate, as an option, a coarse-grained timestamp from the sender that increments every quarter of a round-trip time, instead of a more fine-grained timestamp. This follows RFC 4342.
セクション6.3、下品なタイムスタンプ: セクション6.3は盛込むように変更されました、オプションとして、往復の時間のあらゆる4分の1を増加する送付者からの下品なタイムスタンプ、きめ細かにより粒状のタイムスタンプの代わりに。 これはRFC4342に続きます。
Section 6.3.1, after the first loss event: Section 6.3.1 now says that for initializing the loss history after the first loss event, the receiver uses the maximum receive rate so far, instead of the receive rate in the last round-trip time.
最初の損失出来事の後のセクション6.3.1: の代わりにする、現在が最初の損失出来事、受信機が最大を使用した後に損失歴史を初期化しながらそれを言うセクション6.3.1が今までのところレートを受け取る、最後の往復の時間でレートを受け取ってください。
Section 6.3.1, if the first data packet is dropped: Section 6.3.1 now contains a specification for initializing the loss history if the first data packet sent is lost or ECN-marked.
セクション6.3 .1 最初のデータ・パケットが落とされるなら: セクション6.3 .1 現在、パケットが送った最初のデータが無くなるか、または電子証券取引ネットワークが著しいなら損失歴史を初期化するための仕様を含みます。
Section 7, sender-based variants: Section 7's discussion of sender- based variants has been expanded, with reference to RFC 4342.
セクション7、送付者ベースの異形: RFC4342に関してセクション7の送付者ベースの異形の議論を広げてあります。
10. Security Considerations
10. セキュリティ問題
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.
さらに、混雑制御機構はそれがネットワーク回線容量の正当な分け前より受信したがっている貪欲な受信機によって潜在的に操作されるかもしれません。 事実上、混雑のため失われたパケットを受けたと主張することによって、受信機はこれをするかもしれません。 通常、そのような受信機に対する可能なディフェンスは受信機が領収書を立証するために送付者にフィードバックしなければならない何らかのフォームの一回だけを含んでいるでしょう。 しかしながら、そのような一回だけの詳細はトランスポート・プロトコルと、特に、トランスポート・プロトコルが信頼できますかそれとも頼り無いかよるでしょう。
Floyd, et al. Standards Track [Page 39] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[39ページ]: プロトコル仕様2008年9月
We expect that protocols incorporating ECN with TFRC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [RFC3540]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol, and are not addressed in this document.
私たちは、また、TFRCと共に電子証券取引ネットワークを法人組織にするプロトコルが電子証券取引ネットワーク一回だけ[RFC3540]を使用することで受信機から送付者までフィードバックを取り入れたくなると予想します。 電子証券取引ネットワーク一回だけは著しいパケットの偶然の、または、悪意がある隠すことから送付者を保護する電子証券取引ネットワークへの変更です。 一方、そのような一回だけの詳細は、トランスポート・プロトコルによって、本書では記述されません。
10.1. Security Considerations for TFRC in DCCP
10.1. DCCPのTFRCのためのセキュリティ問題
TFRC is currently used in Congestion Control ID 3 (CCID 3) [RFC4342] of the Datagram Congestion Control Protocol (DCCP) [RFC4340]. The Security Considerations section of RFC 4340 [RFC4340] (Section 18) discusses some of the security issues of DCCP, including sequence number validity checks to protect against hijacked connections. Section 18 of RFC 4340 also discusses mechanisms in DCCP to limit the potential impact of denial-of-service attacks.
TFRCは現在、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]のCongestion Control ID3(CCID3)[RFC4342]に使用されます。 RFC4340[RFC4340](セクション18)のSecurity Considerations部はDCCPの安全保障問題のいくつかについて論じます、ハイジャックされた接続から守るために一連番号バリディティチェックを含んでいて。 また、RFC4340のセクション18は、サービス不能攻撃の可能性のある衝撃を制限するためにDCCPのメカニズムについて論じます。
RFC 4342 specifies the use of TFRC in CCID 3. RFC 4342 includes extensive discussions of the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used with CCID 3, the receiver returns ECN Nonce information to the sender, to allow the sender to verify information sent by the receiver. When ECN is not used, Section 9 of RFC 4342 discusses how the sender could still use various techniques that might catch the receiver in an error in reporting congestion. However, as stated in RFC 4342, this is not as robust or non-intrusive as the verification provided by the ECN Nonce.
RFC4342はCCID3におけるTFRCの使用を指定します。 RFC4342は送付者が受信機によって送られた情報について確かめるのに使用できるメカニズムの大規模な議論を含めます。電子証券取引ネットワークがCCID3と共に使用されるとき、受信機は、送付者が受信機によって送られた情報について確かめるのを許容するために電子証券取引ネットワークNonce情報を送付者に返します。電子証券取引ネットワークが使用されていないとき、RFC4342のセクション9は送付者がどうまだ混雑を報告しながら誤りにおける受信機に引っかかるかもしれない様々なテクニックを使用できたかについて議論します。 しかしながら、RFC4342に述べられているように、これは、電子証券取引ネットワークNonceによって提供された検証ほど、強健でもなくて、また非押しつけがましくもありません。
11. Acknowledgments
11. 承認
We would like to acknowledge feedback and discussions on equation- based congestion control with a wide range of people, including members of the Reliable Multicast Research Group, the Reliable Multicast Transport Working Group, and the End-to-End Research Group. We would like to thank Dado Colussi, Gorry Fairhurst, Ladan Gharai, Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian McDonald, Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit Renker, Arjuna Sathiaseelan, Vladica Stanisic, Randall Stewart, Eduardo Urzaiz, Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier versions of this document, and to thank Mark Allman for his extensive feedback from using [RFC3448] to produce a working implementation.
方程式についてのフィードバックと議論がさまざまな人々との輻輳制御を基礎づけたと認めたいと思います、Reliable Multicast Research Group、Reliable Multicast Transport作業部会、およびEndから終わりへのResearch Groupのメンバーを含んでいて。 [RFC3448]を使用するのからの彼の大規模なフィードバックが働く実現を起こすように、Dado Colussi、ゴーリーFairhurst、Ladan Gharai、ヴィムHeirman、エディ・コーラー、ケン・レーフグレン、マイクLuby、イアン・マクドナルド、ウラジミールMoltchanov、コリン・パーキンス、ミシェルR.、ゲリットRenker、アルジュナSathiaseelan、Vladica Stanisic、ランドル・スチュワート、エドゥアルドUrzaiz、Shushan Wen、およびウェンディー・リー( lhh@zsu.edu.cn )がこのドキュメントの以前のバージョンのフィードバック、マーク・オールマンに感謝するのを感謝申し上げます。
Floyd, et al. Standards Track [Page 40] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[40ページ]: プロトコル仕様2008年9月
Appendix A. Terminology
付録A.用語
This document uses the following terms. Timer variables (e.g., t_now, tld) are assumed to be in seconds, with a timer resolution of at least a millisecond.
このドキュメントは次の用語を使用します。秒に、タイマ変数(_現在の例えば、t tld)があると思われます、少なくとも1ミリセカンドのタイマ解決で。
data-limited interval:
An interval where the sender is data-limited (not sending as much
as it is allowed to send) over the entire interval (Section 4.3).
間隔をデータで制限します: 送付者が全体の間隔(セクション4.3)にわたってデータによって限られる(送ることができるのと同じくらい多くを送りません)間隔。
DF: Discount factor for a loss interval (Section 5.5).
DF: 損失間隔(セクション5.5)の間、要素を無視してください。
initial_rate:
Allowed initial sending rate.
_レートに頭文字をつけてください: 初期の送付レートを許容しました。
last_counter:
Greatest received value of the window counter (Section 6.3).
最後の_カウンタ: ウィンドウカウンタ(セクション6.3)の最も大きい容認された値。
n: Number of loss intervals.
n: 損失間隔の数。
NDUPACK:
Number of dupacks for inferring loss (constant) (Section 5.1).
NDUPACK: 損失(一定の)(セクション5.1)を推論するためのdupacksの数。
nofeedback timer:
Sender-side timer (Section 4).
nofeedbackタイマ: 送付者サイドタイマ(セクション4)。
p: Estimated Loss Event Rate.
p: 損失見積額イベント率。
p_prev:
Previous value of p (Section 6.1).
_p prev: p(セクション6.1)の前の値。
q: Filter constant for RTT (constant) (Section 4.3).
q: RTT(一定の)(セクション4.3)のために定数をフィルターにかけてください。
q2: Filter constant for long-term RTT (constant) (Section 4.6).
q2: 長期のRTT(一定の)(セクション4.6)のために定数をフィルターにかけてください。
R: Estimated path round-trip time.
R: およそ経路往復の時間。
R_m:
A specific estimate of the path round-trip time (Sections 4.3, 6).
R_m: 経路の往復の現代(セクション4.3、6)の特定の見積り。
R_sample:
Measured path RTT (Section 4.3).
R_は以下を抽出します。 経路RTT(セクション4.3)を測定しました。
R_sqmean:
Long-term estimate of the square root of the RTT (Section 4.6).
_R sqmean: RTT(セクション4.6)の平方根の長期の見積り。
recover_rate:
Allowed rate for resuming after an idle period (Section 4.4).
_レートを回復してください: 活動していない期間(セクション4.4)の後に再開するレートを許容しました。
Floyd, et al. Standards Track [Page 41] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[41ページ]: プロトコル仕様2008年9月
recv_limit;
Limit on sending rate computed from X_recv_set (Section 4.3).
recv_限界。 Xから計算されたレートを送るとき、__が設定したrecv(セクション4.3)を制限してください。
s: Nominal packet size in bytes.
s: バイトで表現される名目上のパケットサイズ。
S: Sequence number.
S: 一連番号。
t_delay:
Reported time delay between receipt of the last packet at the
receiver and the generation of the feedback packet (Section
3.2.2).
t_遅れ: 受信機の最後のパケットの領収書とフィードバックパケット(セクション3.2.2)の世代の間で時間遅れを報告しました。
t_delta:
Parameter for flexibility in send time (Section 8.3).
t_デルタ: 柔軟性のためのパラメタは中で(セクション8.3)を時間に送ります。
t_gran:
Scheduling timer granularity of the operating system (constant)
(Section 8.3).
t_のおばあちゃん: オペレーティングシステム(一定の)(セクション8.3)のタイマ粒状の計画をします。
t_ipi:
Inter-packet interval for sending packets (Section 4.6).
_t ipi: 送付パケット(セクション4.6)のための相互パケット間隔。
t_mbi:
Maximum RTO value of TCP (constant) (Section 4.3).
_t mbi: TCP(一定の)(セクション4.3)の最大のRTO値。
t_recvdata:
Timestamp of the last data packet received (Section 3.2.2).
_t recvdata: 最後のデータ・パケットに関するタイムスタンプは(セクション3.2.2)を受けました。
timer_limit:
Limit on the sending rate from the expiration of the nofeedback
timer (Section 4.4).
タイマ_限界: 送付レートでnofeedbackタイマの満了から(セクション4.4)を制限してください。
tld:
Time Last Doubled (Section 4.2).
tld: 時間は最後に(セクション4.2)を倍にしました。
t_now:
Current time (Section 4.3).
現在のt_: 現在の時間(セクション4.3)。
t_RTO:
Estimated RTO of TCP (Section 4.3).
_t RTO: TCP(セクション4.3)のおよそRTO。
X: Allowed transmit rate, as limited by the receive rate.
X: 許容されて、制限されるようにレートを伝えてください、レートを受け取ってください。
X_Bps:
Calculated sending rate in bytes per second (Section 3.1).
X_ビーピーエス: 秒(セクション3.1)あたりのバイトで表現される計算された送付レート。
X_pps:
Calculated sending rate in packets per second (Section 3.1).
_X pps: 秒(セクション3.1)あたりのパケットの計算された送付レート。
Floyd, et al. Standards Track [Page 42] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[42ページ]: プロトコル仕様2008年9月
X_inst:
Instantaneous allowed transmit rate (Section 4.6).
_X inst: 瞬時に起こる、許容されて、レート(セクション4.6)を伝えてください。
X_recv:
Estimated receive rate at the receiver (Section 3.2.2).
_X recv: 受信機(セクション3.2.2)にレートを受け取るように見積もっていました。
X_recv_set:
A small set of recent X_recv values (Section 4.3).
X_recv_はセットしました: 最近のX_recvの小さいセットは(セクション4.3)を評価します。
X_target:
The target sending rate after the first loss event (Section
6.3.1).
X_は以下を狙います。 最初の損失出来事(セクション6.3.1)の後の目標送付レート。
W_init:
TCP initial window (constant) (Section 4.2).
W_イニット: TCPは窓(定数)(セクション4.2)に頭文字をつけます。
Appendix B. The Initial Value of the Nofeedback Timer
初期が評価するNofeedbackタイマの付録B.
Why is the initial value of TFRC's nofeedback timer set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer, from [RFC2988]? There is not any particular reason why TFRC's nofeedback timer should have the same initial value as TCP's retransmit timer. TCP's retransmit timer is used not only to reduce the sending rate in response to congestion, but also to retransmit a packet that is assumed to have been dropped in the network. In contrast, TFRC's nofeedback timer is only used to reduce the allowed sending rate, not to trigger the sending of a new packet. As a result, there is no danger to the network for the initial value of TFRC's nofeedback timer to be smaller than the recommended initial value for TCP's retransmit timer.
TFRCのnofeedbackタイマの初期の値はなぜ3秒のお勧めの初期の値の代わりにTCPの再送信タイマのために[RFC2988]から2秒に設定されますか? TFRCのnofeedbackタイマにはTCPの再送信タイマと同じ初期の値があるはずである少しの特定の理由もありません。 TCPの再送信タイマは混雑に対応して送付レートを単に低下させるのではなく、ネットワークで落とされたと思われるパケットを再送もするのにおいて使用されています。 対照的に、TFRCのnofeedbackタイマは、新しいパケットの発信の引き金となるのではなく、許容送付レートを低下させるのに使用されるだけです。 その結果、TCPの再送信タイマには、TFRCのnofeedbackタイマの初期の値がお勧めの初期の値より小さいように、ネットワークへの危険は全くありません。
Further, when the nofeedback timer has not yet expired, TFRC has a more slowly responding congestion control mechanism than TCP, and TFRC's use of the receive rate for limiting the sending rate is somewhat less precise than TCP's use of windows and ack-clocking, so the nofeedback timer is a particularly important safety mechanism for TFRC. For all of these reasons, it is perfectly reasonable for TFRC's nofeedback timer to have a smaller initial value than that of TCP's retransmit timer.
nofeedbackタイマがまだ期限が切れていないときさらに、TFRCにはTCPよりゆっくり応じている混雑制御機構、および送付レートを制限するのが窓のTCPの使用よりいくらか正確でないのでレートを受け取って、ack時間を計ることのTFRCの使用があるので、nofeedbackタイマはTFRCには、特に重要な安全メカニズムです。 これらの理由のすべてに関しては、TFRCのnofeedbackタイマにはTCPの再送信タイマのものより小さい初期の値があるのは、完全に妥当です。
Floyd, et al. Standards Track [Page 43] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[43ページ]: プロトコル仕様2008年9月
Appendix C. Response to Idle or Data-Limited Periods
空費する付録C.応答かデータ限定期間
Future work could explore alternate responses to using the receive rate during a data-limited period, and to responding to a loss event during a data-limited period.
今後の活動が使用への交互の応答について調査するかもしれない、データ限定期間と、データ限定期間の間、損失出来事に応じることにレートを受け取ってください。
In particular, an Experimental RFC [RFC2861] specifies Congestion Window Validation (CWV) for TCP. For this discussion, we use the term "Standard TCP" to refer to the TCP congestion control mechanisms in [RFC2581] and [RFC2581bis]. [RFC2861] specifies a different response to idle or data-limited periods than those of Standard TCP. With CWV, the TCP sender halves the congestion window after each RTO during an idle period, down to the initial window. Similarly, with CWV the TCP sender halves the congestion window half-way down to the flight size after each RTO during a data-limited period.
特に、Experimental RFC[RFC2861]はCongestion Window Validation(CWV)をTCPに指定します。 この議論に、私たちは「標準のTCP」という示す用語を使用します。[RFC2581]と[RFC2581bis]のTCP混雑制御機構。 [RFC2861]はStandard TCPのものより空費する異なった応答かデータ限定期間を指定します。 CWVと共に、TCP送付者は活動していない期間の各RTOの後に混雑ウィンドウを半分にします、初期の窓まで。 同様に、CWVと共に、TCP送付者はデータ限定期間の間の各RTOの後に混雑窓のハーフウェイを飛行サイズまで半分にします。
This document already specifies a TFRC response to idle periods that is similar to that of TCP with Congestion Window Validation. However, this document does not specify a TFRC response to data- limited periods similar to that of CWV. Adding such a mechanism to TFRC would require a one-line change to step (4) of Section 4.3. In particular, the sender's response to a feedback packet could be changed from:
このドキュメントはCongestion Window Validationと共に活動していない期間へのTCPのものと同様のTFRC応答を既に指定します。 しかしながら、このドキュメントはCWVのものと同様のデータ限定期間へのTFRC応答を指定しません。 そのようなメカニズムをTFRCに加えるのは、セクション4.3の(4)を踏むために1線の変化を必要とするでしょう。 特に、以下からフィードバックパケットへの送付者の応答を変えることができました。
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
}
(覆われて、フィードバックパケットがデータで限られた間隔であった全体の間隔)です。X_recv_セット()を最大にしてください; recv_限界=2*最大(X_recv_はセットした)(新しい損失出来事か損失出来事の増加がpであると評定するフィードバックパケットレポート)がほかにX_recvは_0.85*X recvと等しいです; X_recv_セット()を最大にしてください; recv_限界が最大と等しいという(X_recv_はセットしました)_が設定したX_recvでエントリーを半分にするなら
Floyd, et al. Standards Track [Page 44] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[44ページ]: プロトコル仕様2008年9月
to:
to:
If (the entire interval covered by the feedback packet
was a data-limited interval) {
Multiply old entries in X_recv_set by 0.85;
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Multiply new value X_recv by 0.85.
}
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
(覆われて、フィードバックパケットがデータで限られた間隔であった全体の間隔)です。0.85用意ができているX_recv_で古いエントリーを掛けてください; (新しい損失出来事か損失出来事の増加がpであると評定するフィードバックパケットレポート)が新しい値のX_recvを0.85に掛けるなら、X_recv_セット()を最大にしてください; recv_限界=2*最大(X_recv_はセットしました)
In particular, if the receive rate from before a data-limited period is saved in X_recv_set, then the change in step (4) above would multiply that receive rate by 0.85 each time that a feedback packet is received and the above code is executed. As a result, after four successive round-trip times of data-limited intervals, the receive rate from before the data-limited period would be reduced by 0.85^4 = 0.52. Thus, this one-line change to step (4) of Section 4.3 would result in the allowed sending rate being halved for each four roundtrip times in which the sender was data-limited. Because of the nature of X_recv_set, this mechanism would never reduce the allowed sending rate below twice the most recent receive rate.
以前からレートを受け取ってください。特に、データ限定期間は_が設定したX_recvで節約されて、次に、上の(4)が掛けるステップにおけるフィードバックパケットが受け取られていることの時間レートをそれぞれ0.85受け取る変化と上のコードは実行されます。 以前からレートを受け取ってください。データで限られた間隔の連続した往復の4回の後の結果として短縮する、データ限定期間は0.85^4 = 0.52によって短縮されるでしょう。 したがって、セクション4.3の(4)を踏むこの1線の変化は送付者がデータによって限られた往復の各4回のために半分にされる許容送付レートをもたらすでしょう。 _が設定するX_recvの自然のために、このメカニズムは許容を決して減少させません。二度下で最新の送付レートはレートを受け取ります。
We note that in the suggested code above, with CWV-style behavior in response to data-limited intervals, we keep
私たちは、CWV-スタイルの振舞いによるデータで限られた間隔に対応した上の提案されたコードでは、保つことに注意します。
recv_limit = 2 * max (X_recv_set);
recv_限界は2*最大と等しいです(X_recv_はセットしました)。
instead of using
使用の代わりに
recv_limit = max (X_recv_set);
recv_限界は最大と等しいです(X_recv_はセットしました)。
following loss events in data-limited intervals. This relaxed response to a loss event is allowed because the CWV-style behavior itself limits rapid fluctuations in the sending rate during data- limited periods.
データで限られた間隔の損失出来事に続きます。 CWV-スタイルの振舞い自体がデータ限定期間の間、送付レートにおける急速な変動を制限するので、損失出来事へのこの伸びやかな応答は許容されています。
C.1. Long Idle or Data-Limited Periods
C.1。 長い活動していないかデータ限定期間
Table 1 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to long idle or data-limited periods. For the purposes of this section, we define a long period as a period of at least an RTO.
テーブル1はStandard TCP[RFC2581]の応答、Congestion Window Validation[RFC2861]、Standard TFRC[RFC3448]、および長く活動していないことに対応したRevised TFRC(このドキュメント)とTCPまたはデータ限定期間をまとめます。 このセクションの目的のために、私たちは少なくともRTOの期間と長期を定義します。
Floyd, et al. Standards Track [Page 45] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[45ページ]: プロトコル仕様2008年9月
Protocol Long idle periods Long data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Window -> initial. Window increases for
each cwnd of data.
プロトコルLongは期間のLongデータ限定期間を空費します。-------------- -------------------- ---------------------- 標準のTCP: ウィンドウ->初期です。 窓はデータの各cwndのために増加します。
TCP with CWV: Halve window Reduce window half way
(not below initial cwnd). to used window.
CWVとTCP: 窓を半分にしてください。Reduce窓のハーフウェイ(初期のcwndの下の)中古の窓に。
Standard TFRC: Halve rate Rate limited to
(not below 2 pkts/rtt). twice receive rate.
One RTT after sending pkt,
rate is limited by X_recv.
標準のTFRC: (2未満pkts/rttでない)に制限されたレートRateを半分にしてください。二度レートを受け取ってください。 pktを送った後の1RTT、レートはX_recvによって制限されます。
Revised TFRC: Halve rate Rate limited to twice
(not below initial rate). max (current X_recv,
receive rate before
data-limited period).
改訂されたTFRC: 二度制限されたレートRate(以下の初期のレートでない)を半分にしてください。最大限にしてください(現在のX_recv、データ限定期間の前にレートを受け取ってください)。
Table 1: Response to Long Idle or Data-Limited Periods
テーブル1: 長い間空費する応答かデータ限定期間
Standard TCP after long idle periods: For Standard TCP, [RFC2581] specifies that TCP SHOULD set the congestion window to no more than the initial window after an idle period of at least an RTO. (To be precise, RFC 2581 specifies that the TCP sender should set cwnd to the initial window if the sender has not sent data in an interval exceeding the retransmission timeout.)
長い活動していない期間の後の標準のTCP: Standard TCPとして、[RFC2581]は、TCP SHOULDが少なくともRTOの活動していない期間の後に初期の窓だけに混雑ウィンドウを設定すると指定します。 (正確に言うと、RFC2581は、送付者がデータに再送タイムアウトを合間に超えさせていないならTCP送付者が初期の窓にcwndを設定するべきであると指定します。)
Standard TCP after long data-limited periods: Standard TCP [RFC2581] does not reduce TCP's congestion window after a data-limited period, when the congestion window is not fully used. Standard TCP in [RFC2581] uses the FlightSize, the amount of outstanding data in the network, only in setting the slow-start threshold after a retransmit timeout. Standard TCP is not limited by TCP's ack-clocking mechanism during a data-limited period.
長いデータ限定期間の後の標準のTCP: 標準のTCP[RFC2581]はデータ限定期間の後にTCPの混雑ウィンドウを減少させません。その時、混雑ウィンドウは完全に使用されるというわけではありません。 [RFC2581]用途による標準のTCP FlightSize、ネットワークにおける、単に遅れた出発敷居後aを設定することにおける、傑出しているデータの量はタイムアウトを再送します。 標準のTCPはデータ限定期間の間、自分のack-時計メカニズムによって制限されません。
Standard TCP's lax response to a data-limited period is quite different from its stringent response to an idle period.
データ限定期間への標準のTCPの手緩い応答は緊縮応答から活動していない期間まで全く異なっています。
TCP with Congestion Window Validation (CWV) after long idle periods: As an experimental alternative, [RFC2861] specifies a more moderate response to an idle period than that of Standard TCP, where during an idle period the TCP sender halves cwnd after each RTO, down to the initial cwnd.
長い活動していない期間の後のCongestion Window Validation(CWV)とTCP: 実験代替手段として、[RFC2861]は活動していない期間への活動していない期間、TCP送付者が各RTOの後にcwndを半分にするStandard TCPのものより適度の応答を指定します、初期のcwndまで。
TCP with Congestion Window Validation after long data-limited periods: As an experimental alternative, [RFC2861] specifies a more stringent response to a data-limited period than that of Standard TCP, where after each RTO seconds of a data-limited period, the
長いデータ限定期間の後のCongestion Window ValidationとTCP: 実験代替手段として、[RFC2861]はデータ限定期間へのStandard TCPのものより厳しい応答を指定します、データ限定期間の後それぞれのRTO秒のどこ
Floyd, et al. Standards Track [Page 46] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[46ページ]: プロトコル仕様2008年9月
congestion window is reduced half way down to the window that is actually used.
実際に使用される窓まで混雑ウィンドウは減少しているハーフウェイです。
The response of TCP with CWV to an idle period is similar to its response to a data-limited period. TCP with CWV is less restrictive than Standard TCP in response to an idle period, and more restrictive than Standard TCP in response to a data-limited period.
活動していない期間までのCWVとのTCPの応答はデータ限定期間への応答と同様です。 CWVとTCPは活動していない期間に対応して制限していなくて、Standard TCPよりデータ限定期間に対応してStandard TCPより制限しています。
Standard TFRC after long idle periods: For Standard TFRC, [RFC3448] specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below two packets per RTT after idle periods. After an idle period, the first feedback packet received reports a receive rate of one packet per round-trip time, and this receive rate is used to limit the sending rate. Standard TFRC effectively slow-starts up from this allowed sending rate.
長い活動していない期間の後の標準のTFRC: Standard TFRCとして、[RFC3448]は、許容送付レートがRTOが後援するそれぞれ後に活動していない期間について半分にされると指定します。 許容送付レートは活動していない期間の後に1RTTあたり2つ未満のパケットまで低下しません。 後に、活動していない期間、容認されたレポートaが、あるパケットの往復の時間あたりのレートに受ける最初のフィードバックパケット、およびこれは、送付レートを制限するために使用されるレートを受け取ります。 事実上、発信が許されたこれからの遅い始めの標準のTFRCは評価します。
Standard TFRC after long data-limited periods: [RFC3448] does not distinguish between data-limited and non-data-limited periods. As a consequence, the allowed sending rate is limited to at most twice the receive rate during and after a data-limited period. This is a very restrictive response, more restrictive than that of either Standard TCP or of TCP with CWV.
長いデータ限定期間の後の標準のTFRC: [RFC3448]はデータで制限されるのとデータの非限定期間を見分けません。 結果として、許容送付レートが高々二度制限される、限定期間とデータ限定期間の後にレートを受け取ってください。 これはStandard TCPかCWVとTCPのものより制限している非常に制限している応答です。
Revised TFRC after long idle periods: For Revised TFRC, this document specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below the initial sending rate as the result of an idle period. The first feedback packet received after the idle period reports a receive rate of one packet per round-trip time. However, the Revised TFRC sender does not use this receive rate for limiting the sending rate. Thus, Revised TFRC differs from Standard TFRC in the lower limit used in the reduction of the sending rate, and in the better response to the first feedback packet received after the idle period.
長い活動していない期間の後の改訂されたTFRC: Revised TFRCとして、このドキュメントは、許容送付レートがRTOが後援するそれぞれ後に活動していない期間について半分にされると指定します。 許容送付レートは活動していない期間の結果として初期の送付速度より下で低下しません。 活動していない期間のレポートaが、ある往復の時間あたりのパケットのレートを受け取った後に最初のフィードバックパケットは受信されました。 しかしながら、これが受ける使用ではなく、送付者がするRevised TFRCが、送付レートを制限するために評価します。 したがって、Revised TFRCは送付レートの減少に使用される下限、および活動していない期間の後に受け取られた最初のフィードバックパケットへの、より良い応答においてStandard TFRCと異なっています。
Revised TFRC after long data-limited periods: For Revised TFRC, this document distinguishes between data-limited and non-data-limited periods. As specified in Section 4.3, during a data-limited period Revised TFRC remembers the receive rate before the data-limited period began, and does not reduce the allowed sending rate below twice that receive rate. This is somewhat similar to the response of Standard TCP, and is quite different from the very restrictive response of Standard TFRC to a data-limited period. However, the response of Revised TFRC is not as conservative as the response of TCP with Congestion Window Validation, where the congestion window is gradually reduced down to the window actually used during a data- limited period.
長いデータ限定期間の後の改訂されたTFRC: Revised TFRCに関しては、このドキュメントはデータで制限されるのとデータの非限定期間を見分けます。 セクション4.3で指定されるデータ限定期間の間、Revised TFRCが覚えている、データで有限な期間が二度下のレートを受け取る許容送付レートを始めて、低下させない前にレートを受け取ってください。 これは、Standard TCPの応答といくらか同様であり、Standard TFRCの非常に制限している応答とデータ限定期間に全く異なっています。 しかしながら、Revised TFRCの応答はCongestion Window ValidationでのTCPの応答ほど保守的ではありません。(そこでは、混雑ウィンドウが徐々に実際にデータ限定期間の間に使用される窓まで減少します)。
Floyd, et al. Standards Track [Page 47] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[47ページ]: プロトコル仕様2008年9月
We note that for current TCP implementations, the congestion window is generally not increased during a data-limited period (when the current congestion window is not being fully used) [MAF05] (Section 5.7). We note that there is no mechanism comparable to this in Revised TFRC.
私たちは、現在のTCP実現において、一般に、混雑ウィンドウがデータ限定期間(現在の混雑ウィンドウが完全に使用されているというわけではないとき)[MAF05](セクション5.7)の間増加しないことに注意します。 私たちは、Revised TFRCでこれに匹敵するどんなメカニズムもないことに注意します。
Recovery after idle or data-limited periods: When TCP reduces the congestion window after an idle or data-utilized period, TCP can set the slow-start threshold, ssthresh, to allow the TCP sender to slow- start back up towards its old sending rate when the idle or data- limited period is over. However, in TFRC, even when the TFRC sender's sending rate is restricted by twice the previous receive rate, this results in the sender being able to double the sending rate from one round-trip time to the next, if permitted by the throughput equation. Thus, TFRC does not need a mechanism such as TCP's setting of ssthresh to allow a slow-start after an idle or data-limited period.
活動していなかった後に回復かデータ限定期間: TCPが活動していないかデータに利用された期間の後に混雑ウィンドウを減少させると、TCPは、遅れた出発敷居、ssthreshに活動していないかデータ限定期間が終わっているときにはTCP送付者に古い送付レートに向かって上がっているスタート後部を遅くさせるように設定できます。しかしながら、TFRC送付者の送付レートが前の2倍によって制限さえされたらTFRCでは、レートを受け取ってください、往復の1回から次の回まで送付レートを倍にすることができる送付者のこの結果、スループット方程式で受入れられるなら。 したがって、TFRCは、活動していないかデータ限定期間の後に遅れた出発を許容するためにTCPのssthreshの設定などのようにメカニズムを必要としません。
For future work, one avenue to explore would be the addition of Congestion Window Validation mechanisms for TFRC's response to data- limited periods. Currently, following Standard TCP, during data- limited periods Revised TFRC does not limit its allowed sending rate as a function of the receive rate.
今後の活動のために、探検する1つの大通りはデータ限定期間へのTFRCの応答のためのCongestion Window Validationメカニズムの添加でしょう。 現在有限な期間のRevised TFRCが機能としての許容送付レートを制限しないデータの間、Standard TCPに続く、レートを受け取ってください。
C.2. Short Idle or Data-Limited Periods
C.2。 短い活動していないかデータ限定期間
Table 2 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to short idle or data- limited periods. For the purposes of this section, we define a short period as a period of less than an RTT.
テーブル2は短い活動していないかデータ限定期間に対応してStandard TCP[RFC2581]、Congestion Window ValidationとTCP[RFC2861]、Standard TFRC[RFC3448]、およびRevised TFRC(このドキュメント)の応答をまとめます。 このセクションの目的のために、私たちはRTT以下の期間と短期を定義します。
Protocol Short idle periods Short data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
プロトコルShortは期間のShortデータ限定期間を空費します。-------------- -------------------- ---------------------- 標準のTCP: 炸裂をcwndまで送ってください。 炸裂をcwndまで送ってください。
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
CWVとTCP: 炸裂をcwndまで送ってください。 炸裂をcwndまで送ってください。
Standard TFRC: ? ?
標準のTFRC: ? ?
Revised TFRC: Send a burst Send a burst
(up to an RTT of (up to an RTT of
unused send credits). unused send credits).
改訂されたTFRC: 炸裂Sendに炸裂を送ってください、(RTTへ上昇する、(未使用のRTTまで、クレジットを送ってください)、未使用、発信、クレジット)
Table 2: Response to Short Idle or Data-Limited Periods
テーブル2: 短い活動していないかデータ限定期間への応答
Table 2 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a short idle or data-limited
テーブル2は、Revised TFRCが同様の応答をショートへのCWVがあるStandard TCPとTCPのものに活動していないかデータによって制限されるようにするのを示します。
Floyd, et al. Standards Track [Page 48] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[48ページ]: プロトコル仕様2008年9月
period. For a short idle or data-limited period, TCP is limited only by the size of the unused congestion window, and Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
以上。 短い活動していないかデータ限定期間の間、TCPは未使用の混雑ウィンドウのサイズだけによって制限されます、そして、単に未使用の数に応じて、制限されたRevised TFRCはクレジット(RTTの価値までの)を送ります。 Standard TFRCとして、[RFC3448]は未使用に関して明らかに振舞いを指定しませんでした。クレジットを送ってください。
C.3. Moderate Idle or Data-Limited Periods
C.3。 適度の活動していないかデータ限定期間
Table 3 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to moderate idle or data- limited periods. For the purposes of this section, we define a moderate period as a period greater than an RTT, but less than an RTO.
テーブル3は適度の活動していないかデータ限定期間に対応してStandard TCP[RFC2581]、Congestion Window ValidationとTCP[RFC2861]、Standard TFRC[RFC3448]、およびRevised TFRC(このドキュメント)の応答をまとめます。 このセクションの目的のために、私たちはRTTよりすばらしい、しかし、RTOより少ない期間と適度の期間を定義します。
Protocol Moderate idle periods Moderate data-limited periods
------------- --------------------- -------------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
プロトコルModerateは期間のModerateデータ限定期間を空費します。------------- --------------------- ------------------------- 標準のTCP: 炸裂をcwndまで送ってください。 炸裂をcwndまで送ってください。
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
CWVとTCP: 炸裂をcwndまで送ってください。 炸裂をcwndまで送ってください。
Standard TFRC: ? Limited by X_recv.
標準のTFRC: ? X_recvによって制限されます。
Revised TFRC: Send a burst Send a burst
(up to an RTT of (up to an RTT of
unused send credits). unused send credits).
改訂されたTFRC: 炸裂Sendに炸裂を送ってください、(RTTへ上昇する、(未使用のRTTまで、クレジットを送ってください)、未使用、発信、クレジット)
Table 3: Response to Moderate Idle or Data-Limited Periods
テーブル3: 活動していない状態で加減する応答かデータ限定期間
Table 3 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a moderate idle or data-limited period. For a moderate idle or data-limited period, TCP is limited only by the size of the unused congestion window. For a moderate idle period, Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For a moderate data-limited period, Standard TFRC would be limited by X_recv from the most recent feedback packet. In contrast, Revised TFRC is not limited by the receive rate from data-limited periods that cover an entire feedback period of a round-trip time. For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
テーブル3は、Revised TFRCがCWVと共にStandard TCPとTCPのものに同様の応答を適度の活動していないかデータ限定期間まで持っているのを示します。 適度の活動していないかデータ限定期間の間、TCPは未使用の混雑ウィンドウのサイズだけによって制限されます。 適度の活動していない期間、単に未使用の数に応じて、制限されたRevised TFRCはクレジット(RTTの価値までの)を送ります。 適度のデータ限定期間の間、Standard TFRCはX_recvによって最新のフィードバックパケットから制限されるでしょう。 対照的に、Revised TFRCが制限されない、往復の時間の全体のフィードバックの期間をカバーするデータ限定期間からレートを受け取ってください。 Standard TFRCとして、[RFC3448]は未使用に関して明らかに振舞いを指定しませんでした。クレジットを送ってください。
Floyd, et al. Standards Track [Page 49] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[49ページ]: プロトコル仕様2008年9月
C.4. Losses During Data-Limited Periods
C.4。 データ限定期間の間の損失
This section discusses the response to a loss during a data-limited period.
このセクションはデータ限定期間の間、損失への応答について論じます。
Protocol Response to a loss during a data-limited period
------------- -----------------------------------------------
Standard TCP: Set ssthresh, cwnd to FlightSize/2.
データ限定期間の間の損失へのプロトコルResponse------------- ----------------------------------------------- 標準のTCP: ssthresh、cwndをFlightSize/2に設定してください。
TCP with CWV: Same as Standard TCP.
CWVとTCP: 標準のTCPと同じです。
Standard TFRC: Calculate X_Bps, send at most 2*X_recv.
標準のTFRC: X_Bpsについて計算してください、そして、_2*X recvを高々送ってください。
Revised TFRC: Calculate X_Bps, send at most recv_limit.
In addition, modify X_recv_set.
改訂されたTFRC: X_Bpsについて計算してください、そして、recv_限界を高々送ってください。 さらに、_が設定したX_recvを変更してください。
Table 4: Response to a Loss during a Data-Limited Period
テーブル4: データ限定期間の間の損失への応答
In TCP [RFC2581], the response to a loss during a data-limited period is the same as the response to a loss at any other time in TCP. This response is to set the congestion window to half of the FlightSize, where the FlightSize is the actual amount of unacknowledged data. Thus, after a loss during a data-limited period, the TCP sender must halve its allowed sending rate, as it normally does in response to a loss.
TCP[RFC2581]では、データ限定期間の間の損失への応答はTCPで他の時ならいつでも損失への応答と同じです。 この応答は半分のFlightSizeに混雑ウィンドウを設定することです。そこでは、FlightSizeが実際の量の不承認のデータです。 したがって、データ限定期間の間の損失の後にTCP送付者は許容送付レートを半分にしなければなりません、通常、損失に対応してするように。
In Standard TFRC, the response to a loss during a data-limited period is also the same as the response to a loss at any other time in Standard TFRC. The sending rate is limited by X_Bps, from the throughput equation, and the sending rate is also limited by twice X_recv, the most recent receive rate. As a result, after a loss in a data-limited period, the sender can at most double its sending rate to twice X_recv, even if the throughput equation X_Bps would allow a sending rate much higher than that.
また、Standard TFRCでは、データ限定期間の間の損失への応答もStandard TFRCで他の時ならいつでも損失への応答と同じです。 送付レートはそうであり、送付レートはX_Bpsによってスループット方程式から制限されて、また、二度でX_recvで、最新の状態で制限されて、レートを受け取ってください。 その結果、データ限定期間の損失の後に送付者は送付レートを_2倍X recvまで高々倍にすることができます、スループット方程式X_Bpsがそれよりはるかに高い送付レートを許容しても。
In Revised TFRC, there have been changes to the use of the receive rate X_recv during data-limited intervals; the sender is limited to sending at most recv_limit, where the sender can remember the receive rate X_recv from just before the data-limited period. This allows the sender to more than double its sending rate during data-limited periods, up to the receive rate from before the data-limited period (if allowed by the throughput equation as given in X_Bps). This is similar to Standard TCP's practice of not reducing the window during data-limited periods (in the absence of loss).
使用への変化がRevised TFRCに、あった、データで限られた間隔の間、レートX_recvを受けてください。 送付者が送付者が思い出すことができるrecv_限界を高々送るのに制限される、データ限定期間の少し前に_recvにレートXを受け取ってください。 以前からレートを受け取ってください。送付者がデータ限定期間の間、これで送付レートを倍以上に増やすことができて、密かに企ててください、データ限定期間(X_Bpsで与えるようにスループット方程式で許容されているなら)。 これはStandard TCPのデータ限定期間(損失が不在のとき)の間、窓を減少させない習慣と同様です。
As with Standard TFRC, during a data-limited period the Revised TFRC sender is sending less than is allowed by the throughput equation X_Bps. After the loss event, the sender still might not want to be
Standard TFRC、データ限定期間の間、Revised TFRC送付者はスループット方程式X_Bpsによって許容されているほど発信しません。 損失出来事の後に、送付者はまだそうしていたがっていないかもしれません。
Floyd, et al. Standards Track [Page 50] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[50ページ]: プロトコル仕様2008年9月
sending as much as allowed by the recalculated value of X_Bps that takes into account the new loss event. Revised TFRC adds an additional mechanism to gradually limit the sender's sending rate after losses during data-limited periods. Unlike TCP's response of setting cwnd to half the FlightSize, this additional mechanism in Revised TFRC uses TFRC's practice of using slowly-responding changes for both increases and decreases in the allowed sending rate.
_BpsにそれをXの再計算された値によって許容されているのと同じくらいたくさん送ると、新しい損失出来事は考慮に入れられます。 改訂されたTFRCは、データ限定期間の間の損失の後に徐々に送付者の送付レートを制限するために追加メカニズムを加えます。 TCPのFlightSizeの半分にcwndを設定する応答と異なって、Revised TFRCのこの追加メカニズムは、TFRCの両方の増加にゆっくり応じている変化を使用する習慣を使用して、許容送付レートに縮小します。
This is done in Revised TFRC (in step (4) of Section 4.3) by decreasing the entry in X_recv_set after a loss in a data-limited interval, and by allowing the sender to send at most max (X_recv_set), instead of at most twice max (X_recv_set), in the immediate round-trip time following the reported loss. Thus, the 'price' for allowing the sender to send more than twice the most immediately reported value of X_recv during a data-limited interval is the introduction of an additional mechanism to reduce this allowed sending rate following losses in data-limited periods.
これは報告された損失に続く往復の時間をデータで限られた間隔の損失の後に用意ができていたX_recv_でエントリーを減少させるのによるRevised TFRC(セクション4.3のステップ(4)における)でして、送付者が大部分の代わりに最大(X_recv_はセットした)を二度高々送るのを許容する即座に最大限にする(X_recv_はセットしました)ことです。 したがって、送付者が最もすぐに二度以上発信するのを許容する'価格'は、データ限定期間に損失に続いて、この許容送付レートを低下させるためにデータで限られた間隔の間のX_recvの値が追加メカニズムの導入であると報告しました。
In TFRC's response to a loss in a data-limited interval, we have considered the following examples.
データで限られた間隔の損失へのTFRCの応答では、私たちは以下の例を考えました。
Example 1, Losses *after* a Data-Limited Period: This example shows that losses after a data-limited period has ended are addressed by the throughput equation X_Bps.
例1、*aデータ限定期間の後の損失*: この例は、データ限定期間が終わった後に損失がスループット方程式X_Bpsによって記述されるのを示します。
-------------------------------------------------------------------
Stage 1: Not data-limited.
Sending 100 packets per round-trip time (PPR).
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Not data-limited.
Sending 100 PPR again, as allowed by X_Bps.
A packet loss in the first RTT of Stage 3.
X_Bps is updated,
Response of Revised TFRC: a slight reduction in the allowed sending
rate, depending on the number of packets since the last loss event.
-------------------------------------------------------------------
------------------------------------------------------------------- ステージ1: データで、制限されていません。 往復の時間(PPR)あたりの発信100パケット。 ステージ2: データで制限されて、発信している10PPR。 ステージ3: データで、制限されていません。 X_Bpsによって許容されているように再び100PPRを送ります。 Stage3の最初のRTTのパケット損失。 Response、X_ビーピーエスをアップデートする、Revised TFRCについて: 最後の損失出来事以来パケットの数に応じた許容送付レートのわずかな減少。 -------------------------------------------------------------------
Table 5: Example 1, Losses after a Data-Limited Period
テーブル5: 例1、データ限定期間の後の損失
For example 1, when there is a packet loss in the first RTT of Stage 3, this will be reflected in a modified value of X_Bps, and future loss events would result in future reductions of the throughput equation X_Bps. In particular, following TFRC's standard use of the throughput equation [FHPW00] (Section A.2), the allowed TFRC sending rate would be halved after something like five successive round-trip times with loss.
例えば、1、パケット損失がStage3の最初のRTTにあるとき、これはX_Bpsの変更された値に反映されるでしょう、そして、将来の損失出来事はスループット方程式X_Bpsの将来の減少をもたらすでしょう。 スループット方程式[FHPW00](セクションA.2)のTFRCの標準的用法に続いて、特に、許容TFRC送付レートは何かの後に連続した往復の5回のように損失で半分にされるでしょう。
Floyd, et al. Standards Track [Page 51] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[51ページ]: プロトコル仕様2008年9月
Example 2, a Mildly Data-Limited Sender: This example considers losses in a data-limited period when, during the data-limited period, the sender is sending *almost* as much as it is allowed to send.
例2、穏やかにデータで限られた送付者: この例はデータ限定期間の間に、送付者が**ほとんど発信できるくらい発信するデータ限定期間に損失を考えます。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 99 PPR.
A packet loss in Stage 2.
Response of Revised TFRC: a slight reduction in the allowed sending
rate, down to 85 PPR or less, depending on the number of packets
since the last loss event.
-------------------------------------------------------------------
------------------------------------------------------------------- ステージ1: データで、制限されていません。 発信100PPR。 ステージ2: データで制限されて、発信している99PPR。 Stage2のパケット損失。 改訂されたTFRCの応答: 許容送付レートのわずかな減少か最小85PPRか最後の損失出来事以来パケットの数に依存する以下。 -------------------------------------------------------------------
Table 6: Example 2, a Mildly Data-Limited Sender
テーブル6: 例2、穏やかにデータで限られた送付者
Consider a Revised TFRC connection where the sender has been sending a hundred PPR and then enters a data-limited period of sending only 99 PPR because of data limitations from the application. (That is, at every instance of time during the data-limited period, the sender could have sent one more packet.) If there are losses in the data- limited period, the allowed sending rate is reduced to min(X_Bps, recv_limit), where both the throughput equation X_Bps and the limit recv_limit force a slight reduction in the allowed sending rate.
送付者がデータ制限のためにアプリケーションから99PPRだけを送りながら100PPRを送って、次にデータ限定期間に入るRevised TFRC接続を考えてください。 (すなわち、データ限定期間の間の時間のあらゆる例では、送付者はもうひとつのパケットを送ったかもしれません。) データ限定期間に損失があれば、許容送付レートは分(X_Bps、recv_限界)まで低下します、_スループット方程式X Bpsと限界recv_限界の両方が許容送付レートのわずかな減少を強制するところで。
Example 3, a Single Packet Loss during a Data-Limited Period. This example considers the loss of a single packet during a data-limited period, after the sender has not sent a packet for two RTTs.
例3、データ限定期間の間の単一のパケット損失。 この例はデータ限定期間の間、単一のパケットの損失を考えます、送付者が2RTTsのためにパケットを送らなかった後に。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Data-limited, sending no data for two RTTs.
Stage 4: Data-limited, sending one packet, which is ECN-marked.
Response of Revised TFRC: a reduction in the allowed sending
rate, down to 50 PPR or less. For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved.
-------------------------------------------------------------------
------------------------------------------------------------------- ステージ1: データで、制限されていません。 発信100PPR。 ステージ2: データで制限されて、発信している10PPR。 ステージ3: 2RTTsのためのデータを全く送らないで、データで制限します。 ステージ4: データで制限されて、発信している1つのパケット。(そのパケットは電子証券取引ネットワークは著しいです)。 改訂されたTFRCの応答: 許容送付レート、最小50PPRまたは以下での減少。 データ限定期間、X_が以前からrecvする'覚えている'の間のそれぞれの損失出来事に関しては、事実上、データ限定期間は半分にされます。 -------------------------------------------------------------------
Table 7: Example 3, a Single Packet Loss
テーブル7: 例3、単一のパケット損失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only ten PPR, and then does not send any packets for two RTTs, and then sends a single packet, which is ECN-marked. In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period
次に、送付者が100PPRを送って、10PPRだけを送るデータ限定期間に入って、次に、2RTTsのためにどんなパケットも送らないで、次に、単一のパケット(電子証券取引ネットワークは著しい)を送るところでRevised TFRC接続を考えてください。 この場合、データ限定期間、送付者半分の間のRevised TFRCがあるそれぞれの損失出来事に関して、それは、X_がデータ限定期間の前にrecvするのを'覚えていました'。
Floyd, et al. Standards Track [Page 52] RFC 5348 TFRC: Protocol Specification September 2008
フロイド、他 規格はRFC5348TFRCを追跡します[52ページ]: プロトコル仕様2008年9月
Example 4, Losses after Increasing the Sending Rate during a Data- Limited Period. This example considers losses when the sender significantly increases its sending rate during a data-limited period.
例4、データ限定期間の間、送付レートを増加させた後の損失。 送付者がデータ限定期間の間、送付レートをかなり増加させると、この例は損失を考えます。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 1 PPR.
Stage 3: Data-limited, sending 20 PPR.
Several packets are lost in each RTT of Stage 3.
During Stage 3, the sender would *like* to send 20 PPR.
Response of Revised TFRC: For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved, and the most
recent X_recv is reduced by 0.85.
-------------------------------------------------------------------
------------------------------------------------------------------- ステージ1: データで、制限されていません。 発信100PPR。 ステージ2: データで制限されて、発信している1PPR。 ステージ3: データで制限されて、発信している20PPR。 いくつかのパケットがStage3の各RTTで失われています。 Stage3の間、送付者は20PPRを送る*のように*がそうするでしょう。 改訂されたTFRCの応答: データ限定期間、X_が以前からrecvする'覚えている'の間のそれぞれの損失出来事に関しては、事実上、データ限定期間は半分にされます、そして、最新のX_recvは0.85減少します。 -------------------------------------------------------------------
Table 8: Example 4, Losses after Increasing the Sending Rate
テーブル8: 例4、送付レートを増加させた後の損失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only one PPR, and then, while still data-limited, increases its sending rate to twenty PPR, where it experiences a number of successive loss events.
送付者が100PPRを送って、次に、1PPRだけを送るデータ限定期間に入って、次に、データによってまだ制限されている間、20PPR(それは多くの連続した損失出来事を経験する)に送付レートを増加させるところでRevised TFRC接続を考えてください。
In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period, and the most recent X_recv is reduced by 0.85.
この場合、データ限定期間、送付者半分の間のRevised TFRCがあるそれぞれの損失出来事に関して、X_がデータ限定期間の前にrecvするのを'覚えていました'、そして、最新のX_recvは0.85減少します。
C.5. Other Patterns
C.5。 他のパターン
Other possible patterns to consider in evaluating Revised TFRC would be to compare the behavior of TCP, Standard TFRC, and Revised TFRC for connections with alternating busy and idle periods, alternating idle and data-limited periods, or with idle or data-limited periods during slow-start.
Revised TFRCを評価する際に考える他の可能なパターンは遅れた出発の間の忙しい交替との接続、活動していない期間、活動していない状態で交替して、およびデータ限定期間、活動していないかまたはデータ限定期間にTCP、Standard TFRC、およびRevised TFRCの動きをたとえるだろうことです。
一覧
スポンサーリンク
