Network Working Group S. Floyd
Request for Comments: 3649 ICSI
Category: Experimental December 2003
HighSpeed TCP for Large Congestion Windows
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.
この文書の提案は実験的です。彼らは現在のインターネットで展開することができるが、彼らは、これは、高速輻輳制御のための最善の方法であるというコンセンサスを表すものではありません。特に、我々は代替実験提案は今後の可能性が高い、よくこの文書の提案は、そのような代替案と対話する方法を理解されていないことに注意してください。
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.
この文書では、高速TCP、大混雑窓のTCP接続で使用するTCPの輻輳制御機構への変更を提案しています。現在の標準的なTCPの輻輳制御機構は、現実的な環境でのTCPによって達成することができる輻輳ウィンドウを制約します。例えば、1500バイトのパケットと100ミリ秒の往復時間を有する標準のTCP接続のために、10ギガビットの定常状態のスループットを達成すること83333個のセグメントの平均混雑ウィンドウを必要とし、最大1つのパケットドロップ率輻輳イベントごと5,000,000,000パケット（または同等に、最大1つの輻輳イベントごとに1 2/3時間）。これは、広く非現実的な制約として認識されています。 TCPのこの制限に対処するために、このドキュメントは、高速TCPを提案し、より広いコミュニティからの実験とのフィードバックを要求します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem Description.. . . . . . . . . . . . . . . . . . . . 3
3. Design Guidelines.. . . . . . . . . . . . . . . . . . . . . . . 4
4. Non-Goals.. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Modifying the TCP Response Function.. . . . . . . . . . . . . . 6
6. Fairness Implications of the HighSpeed Response
Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Translating the HighSpeed Response Function into
Congestion Control Parameters . . . . . . . . . . . . . . . . . 12
8. An alternate, linear response functions.. . . . . . . . . . . . 13
9. Tradeoffs for Choosing Congestion Control Parameters. . . . . . 16
9.1. The Number of Round-Trip Times between Loss Events . . . . 17
9.2. The Number of Packet Drops per Loss Event, with Drop-Tail. 17
10. Related Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Slow-Start. . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Limiting burstiness on short time scales. . . . . . . . . 19
10.3. Other limitations on window size. . . . . . . . . . . . . 19
10.4. Implementation issues.. . . . . . . . . . . . . . . . . . 19
11. Deployment issues. . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Deployment issues of HighSpeed TCP. . . . . . . . . . . . 20
11.2. Deployment issues of Scalable TCP . . . . . . . . . . . . 22
12. Related Work in HighSpeed TCP. . . . . . . . . . . . . . . . . 23
13. Relationship to other Work.. . . . . . . . . . . . . . . . . . 25
14. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . . 26
17. Informative References . . . . . . . . . . . . . . . . . . . . 26
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 28
A. TCP's Loss Event Rate in Steady-State. . . . . . . . . . . . . 29
B. A table for a(w) and b(w). . . . . . . . . . . . . . . . . . . 30
C. Exploring the time to converge to fairness . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. In a steady-state environment, with a packet loss rate p, the current Standard TCP's average congestion window is roughly 1.2/sqrt(p) segments. This places a serious constraint on the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500- byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of
この文書では、高速TCP、大混雑窓のTCP接続で使用するTCPの輻輳制御機構への変更を提案しています。定常状態の環境では、パケット損失率pと、現在の標準的なTCPの平均輻輳ウィンドウは、およそ1.2 / SQRT（P）セグメントです。これは、現実的な環境でのTCPによって達成することができる輻輳ウィンドウ上の重大な制約を課します。例えば、1500 - バイトのパケットと100ミリ秒の往復時間を有する標準のTCP接続のために、10ギガビットの定常状態のスループットを達成するの平均輻輳ウィンドウを必要とするであろう
83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). The average packet drop rate of at most 2*10^(-10) needed for full link utilization in this environment corresponds to a bit error rate of at most 2*10^(-14), and this is an unrealistic requirement for current networks.
83333個のセグメント、および最大1つの輻輳イベント毎5,000,000,000パケットのパケットドロップ率（または同等に、最大1つの輻輳イベントで毎1 2/3時間）。平均パケットドロップ率最大で2 * 10 ^（ - 10）のビット誤り率に対応し、この環境では、完全なリンク使用率のために必要な最大2 * 10 ^（ - 14）、これは現在のために非現実的な要件でありますネットワーク。
To address this fundamental limitation of TCP and of the TCP response function (the function mapping the steady-state packet drop rate to TCP's average sending rate in packets per round-trip time), this document describes a modified TCP response function for regimes with higher congestion windows. This document also solicits experimentation and feedback on HighSpeed TCP from the wider community.
TCPのこの基本的な制限に対処し、TCPの応答関数（ラウンドトリップ時間あたりのパケットにTCPの平均送信速度に定常パケットドロップ率をマッピングする機能）は、この文書が高いとレジームのため変更されたTCP応答関数を説明します輻輳ウィンドウ。この文書はまた、より広いコミュニティから高速TCP上での実験やフィードバックを要求します。
Because HighSpeed TCP's modified response function would only take effect with higher congestion windows, HighSpeed TCP does not modify TCP behavior in environments with heavy congestion, and therefore does not introduce any new dangers of congestion collapse. However, if relative fairness between HighSpeed TCP connections is to be preserved, then in our view any modification to the TCP response function should be addressed in the IETF, rather than made as ad hoc decisions by individual implementors or TCP senders. Modifications to the TCP response function would also have implications for transport protocols that use TFRC and other forms of equation-based congestion control, as these congestion control mechanisms directly use the TCP response function [RFC3448].
高速TCPの変更した応答関数が高いだけ輻輳ウィンドウで有効になりますので、高速TCPは輻輳崩壊のいずれかの新しい危険を導入しないため、混雑した環境でのTCPの動作を変更し、しません。高速TCPコネクション間の相対的な公正性が保持される場合しかし、その後、我々の見解でTCP応答関数へのいかなる変更は、個々の実装やTCPの送信者によってアドホックな決定として作られたのではなく、IETFで対処しなければなりません。 TCP応答関数の変更は、これらの輻輳制御メカニズムが直接TCP応答関数[RFC3448]を使用するように、TFRCと式ベースの輻輳制御の他の形態を使用するトランスポートプロトコルに影響を有するであろう。
This proposal for HighSpeed TCP focuses specifically on a proposed change to the TCP response function, and its implications for TCP. This document does not address what we view as a separate fundamental issue, of the mechanisms required to enable best-effort connections to *start* with large initial windows. In our view, while HighSpeed TCP proposes a somewhat fundamental change to the TCP response function, at the same time it is a relatively simple change to implement in a single TCP sender, and presents no dangers in terms of congestion collapse. In contrast, in our view, the problem of enabling connections to *start* with large initial windows is inherently more risky and structurally more difficult, requiring some form of explicit feedback from all of the routers along the path. This is another reason why we would propose addressing the problem of starting with large initial windows separately, and on a separate timetable, from the problem of modifying the TCP response function.
高速TCPのためにこの提案は、具体的に提案TCP応答関数への変更、およびTCPのためにその意味に焦点を当てています。この文書では、我々は*大きな初期ウィンドウで*開始するベストエフォート型の接続を有効にするために必要なメカニズムの別の根本的な問題として見るものを扱っていません。高速TCPはTCP応答関数に幾分根本的な変更を提案しながら、我々の見解では、同時に単一のTCP送信者に実装するための比較的単純な変化であり、輻輳崩壊の面で何の危険性を提示していません。これとは対照的に、我々の見解では、*大きな初期ウィンドウで開始*への接続を可能にする問題は、パスに沿ったルーターのすべての明示的なフィードバックのいくつかのフォームを必要とし、本質的に危険と構造的に困難です。これは、我々はTCP応答関数を変更するの問題から、別に、独立タイムテーブル上の大きな初期ウィンドウから始まるの問題に対処する提案するもう一つの理由です。
This section describes the number of round-trip times between congestion events required for a Standard TCP flow to achieve an average throughput of B bps, given packets of D bytes and a round-trip time of R seconds. A congestion event refers to a window of data with one or more dropped or ECN-marked packets (where ECN stands for Explicit Congestion Notification).
このセクションでは、BのBPS、Dバイトの所与のパケットであり、R秒の往復時間の平均スループットを達成するために、標準的なTCPフローのために必要な輻輳イベント間の往復回数を記載しています。輻輳イベントは、一つ以上のドロップまたは（ECNは、明示的輻輳通知を表す）ECN-マーキングされたパケットを用いてデータのウィンドウを指します。
From Appendix A, achieving an average TCP throughput of B bps requires a loss event at most every BR/(12D) round-trip times. This is illustrated in Table 1, for R = 0.1 seconds and D = 1500 bytes. The table also gives the average congestion window W of BR/(8D), and the steady-state packet drop rate P of 1.5/W^2.
付録AからB BPSの平均TCPスループットを達成することは、ほとんどすべてのBR /（12D）往復時間での損失イベントが必要です。これは、R = 0.1秒、D = 1500バイトのために、表1に示されています。表はまた、BR /（8D）のW平均輻輳ウィンドウを与え、定常状態のパケットドロップ率1.5 / W ^ 2のP。
TCP Throughput (Mbps) RTTs Between Losses W P
--------------------- ------------------- ---- -----
1 5.5 8.3 0.02
10 55.5 83.3 0.0002
100 555.5 833.3 0.000002
1000 5555.5 8333.3 0.00000002
10000 55555.5 83333.3 0.0000000002
Table 1: RTTs Between Congestion Events for Standard TCP, for 1500-Byte Packets and a Round-Trip Time of 0.1 Seconds.
表1：1500バイトパケットのための標準TCPのための輻輳イベント間のRTT、および0.1秒の往復時間。
This document proposes HighSpeed TCP, a minimal modification to TCP's increase and decrease parameters, for TCP connections with larger congestion windows, to allow TCP to achieve high throughput with more realistic requirements for the steady-state packet drop rate. Equivalently, HighSpeed TCP has more realistic requirements for the number of round-trip times between loss events.
このドキュメントでは、TCPは、定常状態のパケットドロップ率のためのより現実的な要件に高いスループットを達成できるようにするために、より大きな輻輳ウィンドウとのTCP接続のために、高速TCP、TCPの増減パラメータに最小限の変更を提案しています。等価的に、高速TCPは損失事象間の往復回数のより現実的な要件があります。
Our proposal for HighSpeed TCP is motivated by the following requirements:
高速TCPのために私たちの提案は、次の要件が動機とされています。
* Achieve high per-connection throughput without requiring unrealistically low packet loss rates.
*非現実的に低いパケット損失率を必要とせずに、高接続ごとのスループットを実現。
* Reach high throughput reasonably quickly when in slow-start.
*ときスロースタートで、合理的に迅速、高スループットをリーチ。
* Reach high throughput without overly long delays when recovering from multiple retransmit timeouts, or when ramping-up from a period with small congestion windows.
複数の再送タイムアウトから回復したとき、または小さな輻輳ウィンドウと期間からアップランピングとき*過度に長い遅延がなく、高いスループットをリーチ。
* No additional feedback or support required from routers:
ルータから必要な*追加のフィードバックんやサポート：
For example, the goal is for acceptable performance in both ECN-capable and non-ECN-capable environments, and with Drop-Tail as well as with Active Queue Management such as RED in the routers.
例えば、目標は、ECN-対応と非ECN対応の環境の両方で、ドロップテールと同様に、ルータにおけるREDなどアクティブキュー管理に許容可能なパフォーマンスのためです。
* No additional feedback required from TCP receivers.
* TCP受信機から不要追加のフィードバック。
* TCP-compatible performance in environments with moderate or high congestion (e.g., packet drop rates of 1% or higher):
*中程度または高い混雑の環境におけるTCP互換性能（例えば、パケットドロップ率1％以上の）：
Equivalently, the requirement is that there be no additional load on the network (in terms of increased packet drop rates) in environments with moderate or high congestion.
等価的に、要件は、（増加したパケットドロップ率の面で）ネットワーク上の追加の負荷が中程度または高い渋滞と環境には存在しないということです。
* Performance at least as good as Standard TCP in environments with moderate or high congestion.
*中等度または高渋滞と環境における標準TCPと少なくとも同程度の良好なパフォーマンス。
* Acceptable transient performance, in terms of increases in the congestion window in one round-trip time, responses to severe congestion, and convergence times to fairness.
*許容可能な過渡性能、公正性への1往復時間で輻輳ウィンドウの増加、深刻な渋滞への対応、および収束時間の点で好ましいです。
Currently, users wishing to achieve throughputs of 1 Gbps or more typically open up multiple TCP connections in parallel, or use MulTCP [CO98,GRK99], which behaves roughly like the aggregate of N virtual TCP connections. While this approach suffices for the occasional user on well-provisioned links, it leaves the parameter N to be determined by the user, and results in more aggressive performance and higher steady-state packet drop rates if used in environments with periods of moderate or high congestion. We believe that a new approach is needed that offers more flexibility, more effectively scales to a wide range of available bandwidths, and competes more fairly with Standard TCP in congested environments.
現在、ユーザは、1つのギガビットのスループットを達成することを望むか、より典型的には、並列に複数のTCP接続を開く、又はおおよそN仮想TCPコネクションの集合体のように振る舞うMulTCP [CO98、GRK99]を、使用します。このアプローチは、よくプロビジョニングリンクで時折ユーザーには十分が、それはユーザが決定するパラメータNを残して、より積極的なパフォーマンスと高い定常状態のパケットドロップ率の結果は、中程度または高の期間と環境で使用する場合混雑。私たちは、新しいアプローチがより効果的に、より多くの柔軟性を提供しています利用可能な帯域幅の広い範囲にスケーリングし、そして混雑した環境で、よりかなり標準的なTCPと競合することが必要であると考えています。
The following are explicitly *not* goals of our work:
明示されている以下の*ない*我々の仕事の目標：
* Non-goal: TCP-compatible performance in environments with very low packet drop rates.
*非目標：非常に低いパケットドロップ率を持つ環境でのTCP互換のパフォーマンス。
We note that our proposal does not require, or deliver, TCP-compatible performance in environments with very low packet drop rates, e.g., with packet loss rates of 10^-5 or 10^-6. As we discuss later in this document, we assume that Standard TCP is unable to make effective use of the available bandwidth in environments with loss rates of 10^-6 in any case, so that it is acceptable and appropriate for HighSpeed TCP to perform more aggressively than Standard TCP in such an environment.
我々は、我々の提案は、10 ^ -5または10 ^ -6パケット損失率で、例えば、必要、または非常に低いパケットドロップ率との環境では、TCPと互換性のあるパフォーマンスを提供しないことに注意してください。私たちはこのドキュメントの議論として、高速TCPが多くを実行することが許容され、適切であるように、我々は、標準TCPは10 ^ -6いかなる場合での損失率の環境で利用可能な帯域幅を有効に活用することができないことを前提としてい積極的にそのような環境では、標準TCPより。
* Non-goal: Ramping-up more quickly than allowed by slow-start.
*非目標：ランピングアップよりも迅速にスロースタートで許可されています。
It is our belief that ramping-up more quickly than allowed by slow-start would necessitate more explicit feedback from routers along the path. The proposal for HighSpeed TCP is focused on changes to TCP that could be effectively deployed in the current Internet environment.
これは、ランプアップより迅速にスロースタートで許可されているよりは、パス上にあるルータからのより多くの明示的なフィードバックを必要とするという私たちの信念です。高速TCPの提案を効果的に現在のインターネット環境に配備することができ、TCPへの変更に焦点を当てています。
* Non-goal: Avoiding oscillations in environments with only one-way, long-lived flows all with the same round-trip times.
*非目標：全て同じ往復時間との一方向のみ、長寿命の流れと環境の振動を避けます。
While we agree that attention to oscillatory behavior is useful, avoiding oscillations in aggregate throughput has not been our primary consideration, particularly for simplified environments limited to one-way, long-lived flows all with the same, large round-trip times. Our assessment is that some oscillatory behavior in these extreme environments is an acceptable price to pay for the other benefits of HighSpeed TCP.
私たちは振動挙動に注意が有用であることに同意しますが、集約スループットの回避振動は特に、すべて同じ、大型往復時間と片道、長寿命のフローに限定簡略化環境のために、私たちの主な考慮されていません。私たちの評価は、これらの極端な環境では、いくつかの振動動作が高速TCPの他の利益のために支払うために許容できる価格であるということです。
The TCP response function, w = 1.2/sqrt(p), gives TCP's average congestion window w in MSS-sized segments, as a function of the steady-state packet drop rate p [FF98]. This TCP response function is a direct consequence of TCP's Additive Increase Multiplicative Decrease (AIMD) mechanisms of increasing the congestion window by roughly one segment per round-trip time in the absence of congestion, and halving the congestion window in response to a round-trip time with a congestion event. This response function for Standard TCP is reflected in the table below. In this proposal we restrict our attention to TCP performance in environments with packet loss rates of at most 10^-2, and so we can ignore the more complex response functions that are required to model TCP performance in more congested environments with retransmit timeouts. From Appendix A, an average congestion window of W corresponds to an average of 2/3 W round-trip times between loss events for Standard TCP (with the congestion window varying from 2/3 W to 4/3 W).
TCP応答関数、W = 1.2 / SQRT（p）は、定常状態のパケットドロップ率p [FF98]の関数として、MSSサイズのセグメント中のW TCPの平均輻輳ウィンドウを与えます。このTCP応答関数は、TCPの添加増加乗算減少（AIMD）往復することに応答して、輻輳の不在下で往復時間当たり約1セグメントによって混雑ウィンドウを増加し、輻輳ウィンドウを半分の機構の直接的な結果であります輻輳イベントと時間。標準TCPに対してこの応答関数は、以下の表に反映されています。この提案では、最大で10 ^ -2のパケット損失率を持つ環境でのTCPのパフォーマンスに注目を制限し、そして私たちは再送タイムアウトをより混雑した環境でTCPのパフォーマンスをモデル化するために必要とされる、より複雑な応答関数を無視することができます。付録Aから、Wの平均混雑ウィンドウが（4/3 W 2/3にWから変化する混雑ウィンドウとの）標準TCPに対する損失事象間2/3 W往復時間の平均値に相当します。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 120 80
10^-5 379 252
10^-6 1200 800
10^-7 3795 2530
10^-8 12000 8000
10^-9 37948 25298
10^-10 120000 80000
Table 2: TCP Response Function for Standard TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表2：標準TCPのためのTCP応答関数。 MSSサイズのセグメントの平均混雑ウィンドウWは、パケットドロップ率Pの関数として与えられます
To specify a modified response function for HighSpeed TCP, we use three parameters, Low_Window, High_Window, and High_P. To ensure TCP compatibility, the HighSpeed response function uses the same response function as Standard TCP when the current congestion window is at most Low_Window, and uses the HighSpeed response function when the current congestion window is greater than Low_Window. In this document we set Low_Window to 38 MSS-sized segments, corresponding to a packet drop rate of 10^-3 for TCP.
高速TCPのために変更した応答関数を指定するために、我々は3つのパラメータ、Low_Window、High_Window、およびHigh_Pを使用しています。 TCPの互換性を確保するために、高速応答関数は、現在の輻輳ウィンドウは最もLow_Windowである場合、標準TCPと同様の応答関数を使用し、現在の輻輳ウィンドウがLow_Windowより大きい場合、高速応答関数を使用します。この文書では、^ -3 TCPのための10のパケット廃棄率に対応する、38 MSSサイズのセグメントにLow_Windowセット。
To specify the upper end of the HighSpeed response function, we specify the packet drop rate needed in the HighSpeed response function to achieve an average congestion window of 83000 segments. This is roughly the window needed to sustain 10 Gbps throughput, for a TCP connection with the default packet size and round-trip time used earlier in this document. For High_Window set to 83000, we specify High_P of 10^-7; that is, with HighSpeed TCP a packet drop rate of 10^-7 allows the HighSpeed TCP connection to achieve an average congestion window of 83000 segments. We believe that this loss rate sets an achievable target for high-speed environments, while still allowing acceptable fairness for the HighSpeed response function when competing with Standard TCP in environments with packet drop rates of 10^-4 or 10^5.
高速応答関数の上端を指定するために、我々は83000個のセグメントの平均輻輳ウィンドウを達成するために高速応答関数に必要なパケットのドロップ率を指定します。これは大体この文書で先に使用されるデフォルトのパケット・サイズと往復時間とのTCP接続のために、10 Gbpsのスループットを維持するために必要なウィンドウです。 High_Windowが83000に設定するために、我々は10 ^ -7のHigh_Pを指定します。すなわち、高速TCPと、10のパケットドロップ率^ -7 83000個のセグメントの平均混雑ウィンドウを達成するために、高速TCP接続が可能です。私たちは10 ^ -4または10 ^ 5のパケットドロップ率を持つ環境では、標準TCPと競合する場合、まだ高速応答関数のための許容可能な公平性を可能にしながら、この損失率は、高速環境のための実現可能な目標を設定することを信じています。
For simplicity, for the HighSpeed response function we maintain the property that the response function gives a straight line on a log-log scale (as does the response function for Standard TCP, for low to moderate congestion). This results in the following response function, for values of the average congestion window W greater than Low_Window:
簡単にするため、高速応答関数のために、我々は、応答関数は、（適度な混雑に低いため、標準TCPのための応答関数の場合と同様に）両対数スケール上の直線を与える性質を維持します。これはLow_Windowより大きいW平均輻輳ウィンドウの値について、以下の応答関数になります。
W = (p/Low_P)^S Low_Window,
W =（P / Low_P）^ S Low_Window、
for Low_P the packet drop rate corresponding to Low_Window, and for S as following constant [FRS02]:
【FRS02】定数以下のようLow_PためLow_Windowに対応するパケットドロップ率、およびSのために：
S = (log High_Window - log Low_Window)/(log High_P - log Low_P).
S =（High_Windowログ - Low_Windowログ）/（High_Pログ - Low_Pログ）。
(In this paper, "log x" refers to the log base 10.) For example, for Low_Window set to 38, we have Low_P of 10^-3 (for compatibility with Standard TCP). Thus, for High_Window set to 83000 and High_P set to 10^-7, we get the following response function:
38に設定Low_Windowについては、例えば、（本稿では、「ログxが」ログ・ベース10を指す）、我々はLow_Pを有する10 ^ -3（標準TCPとの互換性のため）。 High_Windowが83000に設定し、High_Pは10 ^ -7に設定するためにこのように、我々は次の応答関数を取得します：
W = 0.12/p^0.835. (1)
W = 0.12 / P ^ 0.835。 （1）
This HighSpeed response function is illustrated in Table 3 below. For HighSpeed TCP, the number of round-trip times between losses, 1/(pW), equals 12.7 W^0.2, for W > 38 segments.
この高速応答関数は、以下の表3に示されています。高速TCP、損失との間の往復回数、1 /（PW）のために、W> 38個のセグメントの12.7 W ^ 0.2に等しいです。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 263 38
10^-5 1795 57
10^-6 12279 83
10^-7 83981 123
10^-8 574356 180
10^-9 3928088 264
10^-10 26864653 388
Table 3: TCP Response Function for HighSpeed TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表3：高速TCPのTCP応答関数。 MSSサイズのセグメントの平均混雑ウィンドウWは、パケットドロップ率Pの関数として与えられます
We believe that the problem of backward compatibility with Standard TCP requires a response function that is quite close to that of Standard TCP for loss rates of 10^-1, 10^-2, or 10^-3. We believe, however, that such stringent TCP-compatibility is not required for smaller loss rates, and that an appropriate response function is one that gives a plausible packet drop rate for a connection throughput of 10 Gbps. This also gives a slowly increasing number of round-trip times between loss events as a function of a decreasing packet drop rate.
私たちは、^ 10 ^ -2、標準TCPとの後方互換性の問題は、10 ^ -1の損失率のための標準TCPのそれに非常に近い応答関数が必要であることを信じている、または10 -3。私たちは、このような厳しいTCP-互換性は小さい損失率のために必要とされていないこと、しかし、信じているし、適切な応答関数というの10Gbpsの接続のスループットのためのもっともらしいパケットドロップ率を与えるものです。また、これは減少し、パケットのドロップ率の関数としての損失事象間の往復時間のゆっくりと増えています。
Another way to look at the HighSpeed response function is to consider that HighSpeed TCP is roughly emulating the congestion control response of N parallel TCP connections, where N is initially one, and where N increases as a function of the HighSpeed TCP's congestion window. Thus for the HighSpeed response function in Equation (1) above, the response function can be viewed as equivalent to that of
高速応答関数を見て別の方法は、高速TCPは、おおよそNは、最初は1であるN個の並列TCPコネクションの輻輳制御応答をエミュレートしていることを考慮することで、どこ高速TCPの輻輳ウィンドウの関数としてのNが増加。したがって式の高速応答関数のための上記（1）、応答関数は、と同等とみなすことができます
N(W) parallel TCP connections, where N(W) varies as a function of the congestion window W. Recall that for a single standard TCP connection, the average congestion window equals 1.2/sqrt(p). For N parallel TCP connections, the aggregate congestion window for the N connections equals N*1.2/sqrt(p). From the HighSpeed response function in Equation (1) and the relationship above, we can derive the following:
N（W）は、単一の標準的なTCP接続のために、平均輻輳ウィンドウは1.2 / SQRT（P）に等しいことを輻輳ウィンドウW.リコールの関数として変化N（W）並列TCPコネクション、。 N個の並列TCP接続の場合、N接続の集約輻輳ウィンドウは、N * 1.2 / SQRT（P）に等しいです。式（1）で高速応答関数と上記の関係から、我々は次のように導き出すことができます。
N(W) = 0.23*W^(0.4)
N（W）= 0.23 * W ^（0.4）
for N(W) the number of parallel TCP connections emulated by the HighSpeed TCP response function, and for N(W) >= 1. This is shown in Table 4 below.
N（W）高速TCP応答関数によってエミュレート並列TCPコネクション数、およびN用（W）> = 1これは、以下の表4に示されています。
Congestion Window W Number N(W) of Parallel TCPs
------------------- -------------------------
1 1
10 1
100 1.4
1,000 3.6
10,000 9.2
100,000 23.0
Table 4: Number N(W) of parallel TCP connections roughly emulated by the HighSpeed TCP response function.
表4：おおよそ高速TCP応答関数によってエミュレート並列TCPコネクション数N（W）。
In this document, we do not attempt to seriously evaluate the HighSpeed response function for congestion windows greater than 100,000 packets. We believe that we will learn more about the requirements for sustaining the throughput of best-effort connections in that range as we gain more experience with HighSpeed TCP with congestion windows of thousands and tens of thousands of packets. There also might be limitations to the per-connection throughput that can be realistically achieved for best-effort traffic, in terms of congestion window of hundreds of thousands of packets or more, in the absence of additional support or feedback from the routers along the path.
この文書では、我々は真剣に10万パケットよりも大きい輻輳ウィンドウの高速応答関数を評価しようとしないでください。我々は、我々が何千人ものと数十パケットの何千もの輻輳ウィンドウと高速TCPとのより多くの経験を積むように、その範囲内のベストエフォートコネクションのスループットを維持するための要件について詳しく説明しますと信じています。また、パスに沿ったルーターからの追加支援やフィードバックが存在しない場合に、パケット以上の数十万人の輻輳ウィンドウの面で現実的にベストエフォートトラフィックのために達成することができ、接続ごとのスループットに制限が、あるかもしれません。
The Standard and Highspeed Response Functions can be used directly to infer the relative fairness between flows using the two response functions. For example, given a packet drop rate P, assume that Standard TCP has an average congestion window of W_Standard, and HighSpeed TCP has a higher average congestion window of W_HighSpeed.
標準およびハイスピード応答関数は、2つの応答関数を用いたフローとの間の相対的な公平性を推測するために直接使用することができます。例えば、パケットドロップ率Pが与えられると、標準TCPはW_Standardの平均輻輳ウィンドウを有すると仮定し、高速TCPはW_HighSpeedの高い平均輻輳ウィンドウを有しています。
In this case, a single HighSpeed TCP connection is receiving W_HighSpeed/W_Standard times the throughput of a single Standard TCP connection competing in the same environment.
この場合、単一の高速TCP接続はW_HighSpeed / W_Standard時間を同じ環境で競合する単一の標準のTCPコネクションのスループットを受信しています。
This relative fairness is illustrated below in Table 5, for the parameters used for the Highspeed response function in the section above. The second column gives the relative fairness, for the steady-state packet drop rate specified in the first column. To help calibrate, the third column gives the aggregate average congestion window for the two TCP connections, and the fourth column gives the bandwidth that would be needed by the two connections to achieve that aggregate window and packet drop rate, given 100 ms round-trip times and 1500-byte packets.
この相対的公平性は、上記のセクションで高速応答機能のために使用されるパラメータのために、以下の表5に示されています。 2列目は、最初の列で指定された定常状態のパケットドロップ率のために、相対的な公平性を与えます。校正支援するために、3列目は2つのTCP接続のための総平均輻輳ウィンドウを与え、第4列は、100ミリ秒の往復与えられ、その集約ウィンドウとパケットのドロップ率を達成するために2つの接続で必要とされるであろう帯域幅を提供します時間と1500バイトのパケット。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 2.2 383 45.9 Mbps
10^-5 4.7 2174 260.8 Mbps
10^-6 10.2 13479 1.6 Gbps
10^-7 22.1 87776 10.5 Gbps
Table 5: Relative Fairness between the HighSpeed and Standard Response Functions.
表5：高速および標準応答関数との間の相対的な公正さ。
Thus, for packet drop rates of 10^-4, a flow with the HighSpeed response function can expect to receive 2.2 times the throughput of a flow using the Standard response function, given the same round-trip times and packet sizes. With packet drop rates of 10^-6 (or 10^-7), the unfairness is more severe, and we have entered the regime where a Standard TCP connection requires at most one congestion event every 800 (or 2530) round-trip times in order to make use of the available bandwidth. Our judgement would be that there are not a lot of TCP connections effectively operating in this regime today, with congestion windows of thousands of packets, and that therefore the benefits of the HighSpeed response function would outweigh the unfairness that would be experienced by Standard TCP in this regime. However, one purpose of this document is to solicit feedback on this issue. The parameter Low_Window determines directly the point of divergence between the Standard and HighSpeed Response Functions.
したがって、10 ^ -4のパケットドロップ率のために、高速応答関数を有するフローは同じラウンドトリップ時間およびパケットサイズが与えられると、標準応答関数を用いて、流れの2.2倍のスループットを受け取ることを期待することができます。 10 ^ -6（または10 ^ -7）のパケットドロップ率で、不公平はより深刻であり、我々は標準的なTCP接続は最大で1つの輻輳のイベントで、すべて800（または2530）の往復時間を必要とする体制に入っていますために、利用可能な帯域幅を利用することができます。私たちの判断は効果的にパケットの数千人の輻輳ウィンドウと、今日のこの領域で動作してTCPコネクションの多くは存在しないということになり、したがって、高速応答関数の利点はで標準TCPによって経験されるだろう不公平を上回るだろうとこの政権。しかし、この文書の1つの目的は、この問題に関するフィードバックを求めることです。パラメータLow_Window直接標準および高速応答関数との間の分岐点を決定します。
The third column of Table 5, the Aggregate Window, gives the aggregate congestion window of the two competing TCP connections, with HighSpeed and Standard TCP, given the packet drop rate specified in the first column. From Table 5, a HighSpeed TCP connection would receive ten times the bandwidth of a Standard TCP in an environment with a packet drop rate of 10^-6. This would occur when the two flows sharing a single pipe achieved an aggregate window of 13479 packets. Given a round-trip time of 100 ms and a packet size of 1500 bytes, this would occur with an available bandwidth for the two competing flows of 1.6 Gbps.
表5の第3列は、集約ウィンドウは、最初の列で指定されたパケットドロップ率を考えると、高速および標準TCPと、2つの競合するTCPコネクションの集合輻輳ウィンドウを与えます。表5からは、高速TCPコネクションは10 ^ -6のパケットドロップ率と環境の中で、標準TCPの10倍の帯域幅を受け取ることになります。単一管を共有する二つの流れは、13479のパケットの集約ウィンドウを達成したときにこれが起こります。 100ミリ秒の往復時間と1500バイトのパケットサイズを考えると、これは1.6 Gbpsのの2つの競合する流れに利用可能な帯域幅で発生するであろう。
Next we consider the time that it takes a standard or HighSpeed TCP flow to converge to fairness against a pre-existing HighSpeed TCP flow. The worst case for convergence to fairness occurs when a new flow is starting up, competing against a high-bandwidth existing flow, and the new flow suffers a packet drop and exits slow-start while its window is still small. In the worst case, consider that the new flow has entered the congestion avoidance phase while its window is only one packet. A standard TCP flow in congestion avoidance increases its window by at most one packet per round-trip time, and after N round-trip times has only achieved a window of N packets (when starting with a window of 1 in the first round-trip time). In contrast, a HighSpeed TCP flows increases much faster than a standard TCP flow while in the congestion avoidance phase, and we can expect its convergence to fairness to be much better. This is shown in Table 6 below. The script used to generate this table is given in Appendix C.
次に我々はそれが既存の高速TCPフローに対して公平に収束し、標準または高速TCPフローにかかる時間を考慮してください。新しいフローは、高帯域幅の既存のフローと対戦、起動され、新しいフローがパケットドロップを受けると、そのウィンドウがまだ小さいながらスロースタートを終了すると、公平性への収束のための最悪のケースが発生します。最悪の場合には、そのウィンドウは一つのパケットのみである一方で、新たなフローが輻輳回避フェーズに入ったことを考えます。輻輳回避における標準TCPフローは、ラウンドトリップ時間ごとに最大1つのパケットがそのウィンドウを増加させ、第一ラウンドトリップ1の窓から始まるときN往復時間後にのみNパケット（の窓を達成しました時間）。これとは対照的に、高速TCPはしばらく輻輳回避フェーズにおける標準TCPフローよりもはるかに速く増加を流れ、我々ははるかに良いし、公平性への収束を期待することができます。これは、以下の表6に示されています。このテーブルを生成するために使用されるスクリプトは、付録Cに記載されています
RTT HS_Window Standard_TCP_Window
--- --------- -------------------
100 131 100
200 475 200
300 1131 300
400 2160 400
500 3601 500
600 5477 600
700 7799 700
800 10567 800
900 13774 900
1000 17409 1000
1100 21455 1100
1200 25893 1200
1300 30701 1300
1400 35856 1400
1500 41336 1500
1600 47115 1600
1700 53170 1700
1800 59477 1800
1900 66013 1900
2000 72754 2000
Table 6: For a HighSpeed and a Standard TCP connection, the congestion window during congestion avoidance phase (starting with a congestion window of 1 packet during RTT 1).
表6：高速および標準TCP接続の場合、輻輳回避フェーズの間に輻輳ウィンドウは、（RTT 1中の1つのパケットの輻輳ウィンドウで始まります）。
The classic paper on relative fairness is from Chiu and Jain [CJ89]. This paper shows that AIMD (Additive Increase Multiplicative Decrease) converges to fairness in an environment with synchronized congestion events. From [CJ89], it is easy to see that MIMD and AIAD do not converge to fairness in this environment. However, the results of [CJ89] do not apply to an asynchronous environment such as that of the current Internet, where the frequency of congestion feedback can be different for different flows. For example, it has been shown that MIMD converges to fair states in a model with proportional instead of synchronous feedback in terms of packet drops [GV02]. Thus, we are not concerned about abandoning a strict model of AIMD for HighSpeed TCP. However, we note that in an environment with Drop-Tail queue management, there is likely to be some synchronization of packet drops. In this environment, the model of completely synchronous feedback does not hold, but the model of completely asynchronous feedback is not accurate either. Fairness in Drop-Tail environments is discussed in more detail in Sections 9 and 12.
相対公平に古典的な紙はチウジャイナ[CJ89]からのものです。本論文では、AIMD（添加剤は、乗算減少を増やして）同期輻輳イベントと環境に公正に収束することを示しています。 [CJ89]から、MIMDとAIADはこの環境で公正に収束していないことを確認することは容易です。しかし、[CJ89]の結果は、輻輳フィードバックの周波数が異なるフローのために異なることができ、現在のインターネットのような非同期環境には適用されません。例えば、MIMD、パケットの観点比例代わりの同期フィードバックをモデルに公正な状態に収束することが示されている[GV02]下がります。したがって、我々は高速TCPのためにAIMDの厳密なモデルを放棄について心配はありません。しかし、我々はドロップテイルキュー管理と環境の中で、パケットドロップのいくつかの同期である可能性が高いがあることに注意してください。この環境では、完全に同期したフィードバックのモデルは保持しませんが、完全に非同期フィードバックのモデルはどちらか正確ではありません。ドロップテール環境における公平性セクション9及び12においてより詳細に議論されます。
7. Translating the HighSpeed Response Function into Congestion Control Parameters
7.輻輳制御パラメータへの高速応答関数の変換
For equation-based congestion control such as TFRC, the HighSpeed Response Function above could be used directly by the TFRC congestion control mechanism. However, for TCP the HighSpeed response function has to be translated into additive increase and multiplicative decrease parameters. The HighSpeed response function cannot be achieved by TCP with an additive increase of one segment per round-trip time and a multiplicative decrease of halving the current congestion window; HighSpeed TCP will have to modify either the increase or the decrease parameter, or both. We have concluded that HighSpeed TCP is most likely to achieve an acceptable compromise between moderate increases and timely decreases by modifying both the increase and the decrease parameter.
例えばTFRCとして方程式ベースの輻輳制御のために、上記高速応答関数は、TFRC輻輳制御機構によって直接使用することができます。しかし、TCPのための高速応答関数は、添加物の増加と乗算減少パラメータに変換する必要があります。高速応答関数は、ラウンドトリップ時間ごとにセグメントの添加増加および現在の輻輳ウィンドウを半分の乗法減少にTCPによって達成することができません。高速TCPは、増減パラメータのいずれか、または両方を変更する必要があります。私たちは、高速TCPが増減パラメータの両方を変更することで、適度な増加とタイムリーな減少との間に許容可能な妥協点を達成する可能性が最も高いと結論づけています。
That is, for HighSpeed TCP let the congestion window increase by a(w) segments per round-trip time in the absence of congestion, and let the congestion window decrease to w(1-b(w)) segments in response to a round-trip time with one or more loss events. Thus, in response to a single acknowledgement HighSpeed TCP increases its congestion window in segments as follows:
すなわち、高速TCPが輻輳の不在下での往復時間当たり（w）のセグメントによって輻輳ウィンドウの増加をさせるためであり、ラウンドに応じてW（1-B（W））セグメントに輻輳ウィンドウの減少をさせ一つ以上の損失事象と-trip時間。次のようにこのように、単一の肯定応答に応答して高速TCPセグメントにおけるその混雑ウィンドウを増加します：
w <- w + a(w)/w.
（W）+ w / wの - <wです。
In response to a congestion event, HighSpeed TCP decreases as follows:
次のように輻輳イベントに応答して、高速TCPは減少します：
w <- (1-b(w))w.
（1-B（W））w - <wです。
For Standard TCP, a(w) = 1 and b(w) = 1/2, regardless of the value of w. HighSpeed TCP uses the same values of a(w) and b(w) for w <= Low_Window. This section specifies a(w) and b(w) for HighSpeed TCP for larger values of w.
標準TCP、（W）= 1及びB（W）= 1/2に関係なく、Wの値。高速TCPは<= Low_Window Wの同じ（W）の値とB（W）を使用します。このセクションでは、Wの大きな値に対して高速TCP用（W）とB（W）を特定します。
For w = High_Window, we have specified a loss rate of High_P. From [FRS02], or from elementary calculations, this requires the following relationship between a(w) and b(w) for w = High_Window:
=ハイウィンドウのために、私たちはHigh_Pの損失率を指定しています。 [FRS02]から、又は基本計算から、これは、W =高窓用（W）とB（W）との間の以下の関係が必要です。
a(w) = High_Window^2 * High_P * 2 * b(w)/(2-b(w)). (2)
（W）= High_Window ^ 2 * High_P * 2 * B（W）/（2-B（W））。 （2）
We use the parameter High_Decrease to specify the decrease parameter b(w) for w = High_Window, and use Equation (2) to derive the increase parameter a(w) for w = High_Window. Along with High_P = 10^-7 and High_Window = 83000, for example, we specify High_Decrease = 0.1, specifying that b(83000) = 0.1, giving a decrease of 10% after a congestion event. Equation (2) then gives a(83000) = 72, for an increase of 72 segments, or just under 0.1%, within a round-trip time, for w = 83000.
我々は減少パラメータb（W）のためにW = High_Windowを指定し、（2）増加パラメータ（W）のためにW = High_Windowを導出するために式を使用するパラメータHigh_Decreaseを使用します。 High_Pと共に= 10 ^ -7とHigh_Window = 83000、例えば、我々が輻輳イベントの後に10％の減少を与え、そのB（83000）= 0.1を指定し、High_Decrease = 0.1を指定します。式（2）をW = 83000ため、ラウンドトリップ時間内に、72個のセグメント、またはちょうど下の0.1％の増加のために、（83000）= 72を与えます。
This moderate decrease strikes us as acceptable, particularly when coupled with the role of TCP's ACK-clocking in limiting the sending rate in response to more severe congestion [BBFS01]. A more severe decrease would require a more aggressive increase in the congestion window for a round-trip time without congestion. In particular, a decrease factor High_Decrease of 0.5, as in Standard TCP, would require an increase of 459 segments per round-trip time when w = 83000.
この緩やかな減少は、より深刻な渋滞[BBFS01]に応じて、送信レートを制限するTCPのACKクロッキングの役割と相まって場合は特に、許容できるとして私たちを打ちます。より深刻な減少は、混雑なしのラウンドトリップ時間のための輻輳ウィンドウでより積極的な増加を必要とします。具体的には、標準的なTCPのように、0.5の減少率High_Decreaseは、W = 83000往復時間当たりの459個のセグメントの増加を必要とするであろう。
Given decrease parameters of b(w) = 1/2 for w = Low_Window, and b(w) = High_Decrease for w = High_Window, we are left to specify the value of b(w) for other values of w > Low_Window. From [FRS02], we let b(w) vary linearly as the log of w, as follows:
W = High_Window用W = Low_Window、及びB（W）= High_Decrease用減少Bのパラメータ（W）= 1/2で与えられ、我々は、W> Low_Windowの他の値について、B（W）の値を指定するために残されます。 [FRS02]から、我々は次のようにB（W）は、Wのログとして直線的に変化してみましょう：
b(w) = (High_Decrease - 0.5) (log(w)-log(W)) / (log(W_1)-log(W)) + 0.5,
B（High_Decrease - 0.5）=（W）（ログ（W）-log（W））/（LOG（W_1）-log（W））+ 0.5、
for W = Low_window and W_1 = High_window. The increase parameter a(w) can then be computed as follows:
W = Low_windowとW_1 = High_windowため。次のように増加パラメータa（W）を計算することができます。
a(w) = w^2 * p(w) * 2 * b(w)/(2-b(w)),
、= W ^ 2 * P（W）* 2 * B（W）/（2-B（）W）（W）
for p(w) the packet drop rate for congestion window w. From inverting Equation (1), we get p(w) as follows:
輻輳ウィンドウWのパケットドロップ率（W）pについて。次のように式（1）を反転から、我々は、p（W）を取得します：
p(w) = 0.078/w^1.2.
P（W）= 0.078 / W ^ 1.2。
We assume that experimental implementations of HighSpeed TCP for further investigation will use a pre-computed look-up table for finding a(w) and b(w). For example, the implementation from Tom Dunigan adjusts the a(w) and b(w) parameters every 0.1 seconds. In the appendix we give such a table for our default values of Low_Window = 38, High_Window = 83,000, High_P = 10^-7, and High_Decrease = 0.1. These are also the default values in the NS simulator; example simulations in NS can be run with the command "./test-all-tcpHighspeed" in the directory tcl/test.
私たちは、さらなる調査のための高速TCPの実験的な実装は、（w）が見つけ、B（ワット）のために事前に計算されたルックアップテーブルを使用することを前提としています。例えば、トムDuniganから実装が（W）およびb（W）ごとに0.1秒パラメータ調整します。付録では、Low_Window = 38、High_Window = 83,000の私たちのデフォルト値は、High_P = ^ -7 10、およびHigh_Decrease = 0.1のために、このようなテーブルを与えます。また、これらはNSシミュレータのデフォルト値です。 NSの例のシミュレーションでは、コマンドを実行することができ、「./test-all-tcpHighspeed」ディレクトリのtcl /テスト中。
In this section we explore an alternate, linear response function for HighSpeed TCP that has been proposed by a number of other people, in particular by Glenn Vinnicombe and Tom Kelly. Similarly, it has been suggested by others that a less "ad-hoc" guideline for a response function for HighSpeed TCP would be to specify a constant value for the number of round-trip times between congestion events.
このセクションでは、グレンVinnicombeとトム・ケリーによって、特に、他の人の数によって提案された高速TCPの代替、線形応答関数を探ります。同様に、高速TCPの応答機能にはあまり「アドホック」ガイドラインが輻輳イベント間の往復回数の一定の値を指定することであろう他の人によって示唆されています。
Assume that we keep the value of Low_Window as 38 MSS-sized segments, indicating when the HighSpeed response function diverges from the current TCP response function, but that we modify the High_Window and High_P parameters that specify the upper range of the HighSpeed response function. In particular, consider the response function given by High_Window = 380,000 and High_P = 10^-7, with Low_Window = 38 and Low_P = 10^-3 as before.
我々は高速応答関数は、現在のTCP応答関数から分岐する場合を示し、38 MSSサイズのセグメントとしてLow_Windowの値を保持することを前提とし、我々は、高速応答関数の上限を指定High_WindowとHigh_Pパラメータを変更すること。特に、Low_Window = 38とLow_P = 10 ^ -3として前とHigh_Window =38万とHigh_P = 10 ^ -7で与えられる応答関数を考えます。
Using the equations in Section 5, this would give the following Linear response function, for w > Low_Window:
第5節で数式を使用すると、これはW> Low_Windowのために、以下の線形応答関数を与えるだろう。
W = 0.038/p.
W = 0.038 / P。
This Linear HighSpeed response function is illustrated in Table 7 below. For HighSpeed TCP, the number of round-trip times between losses, 1/(pW), equals 1/0.38, or equivalently, 26, for W > 38 segments.
この線形高速応答関数は、以下の表7に示されています。高速TCP、損失は、1 /（PW）との間の往復回数は、W> 38個のセグメントに対して、26、1 / 0.38、又は等価的に等しいです。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 26
10^-4 380 26
10^-5 3800 26
10^-6 38000 26
10^-7 380000 26
10^-8 3800000 26
10^-9 38000000 26
10^-10 380000000 26
Table 7: An Alternate, Linear TCP Response Function for HighSpeed TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表7：高速TCPの代替、リニアTCP応答関数。 MSSサイズのセグメントの平均混雑ウィンドウWは、パケットドロップ率Pの関数として与えられます
Given a constant decrease b(w) of 1/2, this would give an increase a(w) of w/Low_Window, or equivalently, a constant increase of 1/Low_Window packets per acknowledgement, for w > Low_Window. Another possibility is Scalable TCP [K03], which uses a fixed decrease b(w) of 1/8 and a fixed increase per acknowledgement of 0.01. This gives an increase a(w) per window of 0.005 w, for a TCP with delayed acknowledgements, for pure MIMD.
一定の減少B 1/2（W）を考えると、これは> Low_Window WのLow_Window / W、又は同等の増加（W）、肯定応答あたり1 / Low_Windowパケットの一定の増加を与えます。別の可能性は1/8の固定減少B（W）及び0.01の肯定応答あたり一定の増加を使用してスケーラブルTCP [K03]です。これは、純粋なMIMDのために、遅延確認応答とTCPのために、0.005ワットの窓あたりの増加（ワット）を提供します。
The relative fairness between the alternate Linear response function and the standard TCP response function is illustrated below in Table 8.
代替的な線形応答関数と標準TCP応答関数との間の相対的な公平性を以下の表8に示されています。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 3.2 500 60.0 Mbps
10^-5 15.1 4179 501.4 Mbps
10^-6 31.6 39200 4.7 Gbps
10^-7 100.1 383795 46.0 Gbps
Table 8: Relative Fairness between the Linear HighSpeed and Standard Response Functions.
表8：リニア高速および標準応答関数との間の相対的な公正さ。
One attraction of the linear response function is that it is scale-invariant, with a fixed increase in the congestion window per acknowledgement, and a fixed number of round-trip times between loss events. My own assumption would be that having a fixed length for the congestion epoch in round-trip times, regardless of the packet drop rate, would be a poor fit for an imprecise and imperfect world with routers with a range of queue management mechanisms, such as the Drop-Tail queue management that is common today. For example, a response function with a fixed length for the congestion epoch in round-trip times might give less clearly-differentiated feedback in an environment with steady-state background losses at fixed intervals for all flows (as might occur with a wireless link with occasional short error bursts, giving losses for all flows every N seconds regardless of their sending rate).
線形応答関数の一つの魅力は、それが承認あたりの輻輳ウィンドウ内の固定の増加、および損失事象間の往復回数の固定数で、スケール不変であるということです。私自身の仮定は、次のような、関係なく、パケットのドロップ率の、往復時間に混雑エポックのための固定長を有するキュー管理メカニズムの範囲を持つルータと不正確で不完全な世界のための嵌合不良になることだろう今日一般的ですドロップテイルキュー管理。例えば、ラウンドトリップ時間における輻輳エポックのための固定長の応答関数は、無線リンクとで発生する可能性があるように（すべてのフローのために一定間隔で定常状態背景損失と環境にあまり明確に分化したフィードバックを与えるかもしれません時折短いエラーバーストは、すべてのために損失を与えることは関係なく、自分の送信レートの）N秒ごとを流れています。
While it is not a goal to have perfect fairness in an environment with synchronized losses, it would be good to have moderately acceptable performance in this regime. This goal might argue against a response function with a constant number of round-trip times between congestion events. However, this is a question that could clearly use additional research and investigation. In addition, flows with different round-trip times would have different time durations for congestion epochs even in the model with a linear response function.
それは同期の損失と環境の中で完璧な公平性を持っている目標ではありませんが、この政権で適度に許容可能な性能を有することが良いでしょう。この目標は、輻輳イベント間の往復時間の一定の数の応答関数に対して主張するかもしれません。しかし、これは明らかに、追加の研究と調査を使用することができます質問です。また、でも線形応答関数を持つモデルで輻輳エポックごとに異なる持続時間を持つことになり異なる往復時間と流れています。
The third column of Table 8, the Aggregate Window, gives the aggregate congestion window of two competing TCP connections, one with Linear HighSpeed TCP and one with Standard TCP, given the packet drop rate specified in the first column. From Table 8, a Linear HighSpeed TCP connection would receive fifteen times the bandwidth of a Standard TCP in an environment with a packet drop rate of 10^-5. This would occur when the two flows sharing a single pipe achieved an aggregate window of 4179 packets. Given a round-trip time of 100 ms and a packet size of 1500 bytes, this would occur with an available bandwidth for the two competing flows of 501 Mbps. Thus, because the Linear HighSpeed TCP is more aggressive than the HighSpeed TCP proposed above, it also is less fair when competing with Standard TCP in a high-bandwidth environment.
表8の第3列は、集約ウィンドウは、最初の列で指定されたパケットドロップ率を考えると、2つの競合するTCP接続、リニア高速TCPを有するものとStandard TCP有するものの集合輻輳ウィンドウを与えます。表8からは、リニア高速TCPコネクションは10 ^ -5のパケットドロップ率と環境の中で、標準TCPの15倍の帯域幅を受け取ることになります。単一管を共有する二つの流れは4179のパケットの集約ウィンドウを達成したときにこれが起こります。 100ミリ秒の往復時間と1500バイトのパケットサイズを与え、これは501 Mbpsでの2つの競合するフローの利用可能な帯域幅で発生するであろう。リニア高速TCPは、高速TCPは、上記の提案よりも、より積極的であるため、高帯域幅環境で標準TCPと競合する場合このように、それはまた、あまり公平です。
A range of metrics can be used for evaluating choices for congestion control parameters for HighSpeed TCP. My assumption in this section is that for a response function of the form w = c/p^d, for constant c and exponent d, the only response functions that would be considered are response functions with 1/2 <= d <= 1. The two ends of this spectrum are represented by current TCP, with d = 1/2, and by the linear response function described in Section 8 above, with d = 1. HighSpeed TCP lies somewhere in the middle of the spectrum, with d = 0.835.
メトリックの範囲が高速TCP輻輳制御パラメータの選択肢を評価するために使用することができます。このセクションで私の仮定は、<= D <= 1 = C / P ^ D W形式の応答関数のために、定数c及び指数dために、考えられる唯一応答関数が1/2と応答関数であるということですD = 1の高速TCPをdと、スペクトルの中間のどこかにあると、このスペクトルの両端は、D = 1/2を有する、上記項8に記載の線形応答関数により、現在のTCPで表され= 0.835。
Response functions with exponents less than 1/2 can be eliminated from consideration because they would be even worse than standard TCP in accommodating connections with high congestion windows.
彼らは高い輻輳ウィンドウとの接続を受け入れるには、標準のTCPよりもさらに悪いことになるので1/2未満指数との応答関数は考慮から除外することができます。
Response functions with exponents greater than 1 can be eliminated from consideration because for these response functions, the number of round-trip times between loss events decreases as congestion decreases. For a response function of w = c/p^d, with one loss event or congestion event every 1/p packets, the number of round-trip times between loss events is w^((1/d)-1)/c^(1/d). Thus, for standard TCP the number of round-trip times between loss events is linear in w. In contrast, one attraction of the linear response function, as described in Section 8 above, is that it is scale-invariant, in terms of a fixed increase in the congestion window per acknowledgement, and a fixed number of round-trip times between loss events.
これらの応答関数のために、損失事象間の往復回数が輻輳が減少するにつれて減少するため、1より大きい指数を有する応答関数は考慮から排除することができます。 1つの損失事象又は輻輳イベントにW = C / P ^ D、毎1 / Pパケットの応答関数のために、損失事象間の往復回数は、（（1 / D）-1）^ W / Cであります^（1 / D）。このように、標準のTCPのための損失事象間の往復回数はワットで線形です。対照的に、線形応答関数の引力、上記のセクション8で説明したように、それは肯定応答あたり輻輳ウィンドウ内の固定増加と損失との往復時間の固定された数の点で、スケール不変であることですイベント。
However, for a response function with d > 1, the number of round-trip times between loss events would be proportional to w^((1/d)-1), for a negative exponent ((1/d)-1), setting smaller as w increases. This would seem undesirable.
ただし、D> 1の応答関数のために、損失事象間の往復回数は、（（1 / D）-1）負の指数のために、（）-1（1 / D）^ Wに比例するであろう、Wが増加するにつれて小さく設定します。これは望ましくないと思われます。
A TCP connection increases its sending rate by a(w) packets per round-trip time, and in a Drop-Tail environment, this is likely to result in a(w) dropped packets during a single loss event. One attraction of standard TCP is that it has a fixed increase per round-trip time of one packet, minimizing the number of packets that would be dropped in a Drop-Tail environment. For an environment with some form of Active Queue Management, and in particular for an environment that uses ECN, the number of packets dropped in a single congestion event would not be a problem. However, even in these environments, larger increases in the sending rate per round-trip time result in larger stresses on the ability of the queues in the router to absorb the fluctuations.
TCP接続が（w）は、パケットごとのラウンドトリップ時間によって、その送信レートを増加させ、ドロップテール環境で、これは（w）は、単一の損失イベントの間にパケットをドロップが発生する可能性があります。標準TCPの一つの魅力は、それがドロップテール環境で落とされることになるパケットの数を最小限に抑え、1つのパケットの往復時間あたり一定の増加を持っていることです。アクティブキュー管理のいくつかのフォームを使用する環境の場合は、特にECNを使用する環境のために、パケットの数は、単一の輻輳イベントにドロップすることは問題ではないでしょう。しかし、これらの環境では、変動を吸収するために、ルータのキューの能力に大きな応力の往復時間の結果あたりの送信レートが大きく上昇します。
HighSpeed TCP plays a middle ground between the metrics of a moderate number of round-trip times between loss events, and a moderate increase in the sending rate per round-trip time. As shown in Appendix B, for a congestion window of 83,000 packets, HighSpeed TCP increases its sending rate by 70 packets per round-trip time, resulting in at most 70 packet drops when the buffer overflows in a Drop-Tail environment. This increased aggressiveness is the price paid by HighSpeed TCP for its increased scalability. A large number of packets dropped per congestion event could result in synchronized drops from multiple flows, with a possible loss of throughput as a result.
高速TCPは、損失事象、およびラウンドトリップ時間あたりの送信レートの緩やかな増加間の往復時間の適度な数のメトリックの間で妥協点を果たしています。付録Bに示すように、83,000パケットの輻輳ウィンドウのために、高速TCPは最大70パケットで、その結果、往復時間あたり70のパケットによってその送信速度を増加させるバッファがドロップテール環境でオーバフローしたときに低下します。この増加した攻撃は、そのスケーラビリティの向上のために、高速TCPが支払う価格です。多数のパケットは、結果としてスループットの損失の可能性と、複数のフローから同期低下につながる可能性が輻輳イベントごとに低下しました。
Scalable TCP has an increase a(w) of 0.005 w packets per round-trip time. For a congestion window of 83,000 packets, this gives an increase of 415 packets per round-trip time, resulting in roughly 415 packet drops per congestion event in a Drop-Tail environment.
スケーラブルTCPは、ラウンドトリップ時間あたり0.005ワットのパケットの増加（ワット）を持っています。 83,000パケットの輻輳ウィンドウの場合、これはおよそ415パケットがドロップテール環境での輻輳イベントごとに低下し、その結果、往復時間あたり415のパケットの増加を与えます。
Thus, HighSpeed TCP and its variants place increased demands on queue management in routers, relative to Standard TCP. (This is rather similar to the increased demands on queue management that would result from using N parallel TCP connections instead of a single Standard TCP connection.)
このように、高速TCPおよびその変異体は、標準TCPに比べて、ルータにキュー管理の需要を増加させた場所です。 （これは、代わりに、単一の標準的なTCP接続のN個の並列TCP接続を使用することから生じるキュー管理上の増加要求にかなり類似しています。）
A companion internet-draft on "Limited Slow-Start for TCP with Large Congestion Windows" [F02b] proposes a modification to TCP's slow-start procedure that can significantly improve the performance of TCP connections slow-starting up to large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link.
「大規模な輻輳ウィンドウとのTCPのための限定スロースタート」のコンパニオンインターネットドラフト[F02B]はかなり遅い開始、大きな混雑窓までのTCP接続のパフォーマンスを向上させることができ、TCPのスロースタートの手順の変更を提案しています。 （MSS送信者の最大セグメントサイズ用）MSSサイズのセグメントの混雑何千ものウィンドウ（あるいは数万人）を使用することができますTCP接続の場合、現在のスロースタート手順は、セグメントの数千人によって輻輳ウィンドウの増加につながることができます1回のラウンドトリップ時間インチこのような増加は、簡単にパケットの数千人が1往復時間にドロップされる可能性があります。これは、TCPフロー自体のためにしばしば反生産的であり、混雑リンクを共有しているトラフィックの残りの部分にハードもあります。
[F02b] proposes Limited Slow-Start, limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. We have separated out Limited Slow-Start to a separate draft because it can be used both with Standard or with HighSpeed TCP.
【F02B]は、輻輳ウィンドウが大混雑ウィンドウとのTCP接続の性能を改善するために、スロースタート時のデータの一つの窓のために増加されるセグメントの数を制限する、スロースタートを制限提案します。それは、標準または高速TCPの両方で使用することができますので、私たちは別の案に限定スロースタートを分離しています。
Limited Slow-Start is illustrated in the NS simulator, for snapshots after May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib".
スロースタートは、サブディレクトリにテスト「./test-all-tcpHighspeed tcp1A」と「./test-all-tcpHighspeed tcpHighspeed1" 」TCL / libに、2002年5月1日後にスナップショットのために、NSシミュレータに例示されているリミテッド」。
In order for best-effort flows to safely start-up faster than slow-start, e.g., in future high-bandwidth networks, we believe that it would be necessary for the flow to have explicit feedback from the routers along the path. There are a number of proposals for this, ranging from a minimal proposal for an IP option that allows TCP SYN packets to collect information from routers along the path about the allowed initial sending rate [J02], to proposals with more power that require more fine-tuned and continuous feedback from routers. These proposals are all somewhat longer-term proposals than the HighSpeed TCP proposal in this document, requiring longer lead times and more coordination for deployment, and will be discussed in later documents.
ベストエフォートが安全に起動するより速く、スロースタートより流れためには、例えば、将来の高帯域幅のネットワークでは、我々は、流れがパスに沿って、ルータからの明示的なフィードバックを持つことが必要であろうと信じています。このための提案の数は、より細かい必要がより多くの電力との提案に、TCP SYNパケットが許可された初期送信レート[J02]についての経路に沿ってルータから情報を収集することを可能にするIPオプションのための最小限の提案に至るまで、ありますルータから-tunedと継続的なフィードバック。これらの提案は、すべての展開のため、やや長期的な長いリードタイムを必要とするこのドキュメントの高速TCPの提案よりも提案し、より協調され、以降の文書で説明します。
Because the congestion window achieved by a HighSpeed TCP connection could be quite large, there is a possibility for the sender to send a large burst of packets in response to a single acknowledgement. This could happen, for example, when there is congestion or reordering on the reverse path, and the sender receives an acknowledgement acknowledging hundreds or thousands of new packets. Such a burst would also result if the application was idle for a short period of time less than a round-trip time, and then suddenly had lots of data available to send. In this case, it would be useful for the HighSpeed TCP connection to have some method for limiting bursts.
高速TCPコネクションによって達成輻輳ウィンドウが非常に大きくなる可能性があるため、単一の確認応答に応じて、パケットの大バーストを送信するために、送信者のための可能性があります。リバースパス上の輻輳や並べ替えがある場合には、例えば、発生する可能性があり、送信者は、新たなパケットの数百または数千を認め肯定応答を受信します。アプリケーションは、往復時間未満の短時間のためのアイドルだった、と突然送信するために利用可能な大量のデータを持っていた場合、このようなバーストにもつながります。高速TCP接続がバーストを制限するためのいくつかの方法を持っているため、この場合には、それが有用であろう。
In this document, we do not specify TCP mechanisms for reducing the short-term burstiness. One possible mechanism is to use some form of rate-based pacing, and another possibility is to use maxburst, which limits the number of packets that are sent in response to a single acknowledgement. We would caution, however, against a permanent reduction in the congestion window as a mechanism for limiting short-term bursts. Such a mechanism has been deployed in some TCP stacks, and our view would be that using permanent reductions of the congestion window to reduce transient bursts would be a bad idea [Fl03].
この文書では、我々は短期的なバースト性を減少させるためのTCPメカニズムを指定しないでください。一つの可能なメカニズムは、レートベースのペーシングのいくつかのフォームを使用することであり、別の可能性は、単一の肯定応答に応答して送信されるパケットの数を制限する、maxburst使用することです。当社は、短期バーストを制限するための機構として、輻輳ウィンドウの恒久的削減に対して、しかし、警告します。このようなメカニズムは、いくつかのTCPスタックで展開されてきた、と私たちの見解は、過渡バーストを減らすために、輻輳ウィンドウの恒久的な削減を使用することが悪い考え[Fl03]になることでしょう。
The TCP header uses a 16-bit field to report the receive window size to the sender. Unmodified, this allows a window size of at most 2**16 = 65K bytes. With window scaling, the maximum window size is 2**30 = 1073M bytes [RFC 1323]. Given 1500-byte packets, this allows a window of up to 715,000 packets.
TCPヘッダは、送信者に受信ウィンドウサイズを報告するために16ビットのフィールドを使用します。修飾されていない、これは最大で2 ** 16 = 65Kバイトのウィンドウサイズを可能にします。ウィンドウスケーリングと、最大ウィンドウサイズは2 ** 30 = 1073Mバイト[RFC 1323]です。 1500バイトのパケットを考えると、これは最大715,000パケットのウィンドウを可能にします。
One implementation issue that has been raised with HighSpeed TCP is that with congestion windows of 4MB or more, the handling of successive SACK packets after a packet is dropped becomes very time-consuming at the TCP sender [S03]. Tom Kelly's Scalable TCP includes a "SACK Fast Path" patch that addresses this problem.
高速TCPで提起されている一つの実装の問題は、TCP送信者[S03]で非常に時間がかかるとなり4メガバイト以上の輻輳ウィンドウと、パケットの後に連続したSACKパケットの処理が削除されたということです。トム・ケリーのスケーラブルTCPは、この問題に対処する「SACKファーストパス」のパッチが含まれています。
The issues addressed in the Web100 project, the Net100 project, and related projects about the tuning necessary to achieve high bandwidth data rates with TCP apply to HighSpeed TCP as well [Net100, Web100].
問題はのWeb100プロジェクト、NET100プロジェクトで対処、およびTCPと高帯域幅のデータ・レートを達成するために必要なチューニングの関連プロジェクトは、高速TCPだけでなく、[NET100、のWeb100]に適用されます。
We do not claim that the HighSpeed TCP modification to TCP described in this paper is an optimal transport protocol for high-bandwidth environments. Based on our experiences with HighSpeed TCP in the NS simulator [NS], on simulation studies [SA03], and on experimental reports [ABLLS03,D02,CC03,F03], we believe that HighSpeed TCP improves the performance of TCP in high-bandwidth environments, and we are documenting it for the benefit of the IETF community. We encourage the use of HighSpeed TCP, and of its underlying response function, and we further encourage feedback about operational experiences with this or related modifications.
我々は、この論文で説明TCPへの高速TCPの変更は、高帯域幅環境に最適なトランスポートプロトコルであることを主張しません。高速シミュレーション研究上のNSシミュレータでTCP [NS]、[SA03]、および実験レポートの[ABLLS03、D02、CC03、F03]と私たちの経験に基づいて、我々は高速TCPは、高帯域幅でTCPのパフォーマンスが向上することを信じています環境、そして我々は、IETFコミュニティの利益のためにそれを文書化しています。私たちは、高速TCPの使用を奨励し、その基礎となる応答関数の、そして我々はさらに、このまたは関連する修正を加えた運用経験についてのフィードバックを奨励します。
We note that in environments typical of much of the current Internet, HighSpeed TCP behaves exactly as does Standard TCP today. This is the case any time the congestion window is less than 38 segments.
私たちは、現在のインターネットの多くの一般的な環境では、高速TCPは、今日の標準TCPをまったく同じように動作することに注意してください。これは、ケース輻輳ウィンドウが38個のセグメント以下である任意の時間です。
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 1 0.50
100 Mbps 833 6 0.35
1 Gbps 8333 26 0.22
10 Gbps 83333 70 0.10
Table 9: Performance of a HighSpeed TCP connection
表9：高速TCP接続のパフォーマンス
To help calibrate, Table 9 considers a TCP connection with 1500-byte packets, an RTT of 100 ms (including average queueing delay), and no competing traffic, and shows the average congestion window if that TCP connection had a pipe all to itself and fully used the link bandwidth, for a range of bandwidths for the pipe. This assumes that the TCP connection would use Table 12 in determining its increase and decrease parameters. The first column of Table 9 gives the bandwidth, and the second column gives the average congestion window w needed to utilize that bandwidth. The third column shows the increase a(w) in segments per RTT for window w. The fourth column shows the decrease b(w) for that window w (where the TCP sender decreases the congestion window from w to w(1-b(w)) segments after a loss event). When a loss occurs we note that the actual congestion window is likely to be greater than the average congestion window w in column 2, so the decrease parameter used could be slightly smaller than the one given in column 4 of Table 9.
校正を助けるために、表9は、すべての1500バイトのパケット（平均待ち行列遅延を含む）100ミリ秒のRTT、および無競合トラフィックとのTCP接続を考慮し、そのTCP接続がパイプを持っている場合、平均輻輳ウィンドウを示し、それ自体および完全にパイプのための帯域幅の範囲のために、リンク帯域幅を使用。これは、TCP接続はその増減パラメータを決定する際に、表12を使用することを想定しています。表9の最初の列は、帯域幅を与え、第2列は、その帯域幅を利用するために必要なW平均輻輳ウィンドウを与えます。第3列は、ウィンドウWのRTTごとのセグメントの増加（W）を示します。第4列は、（TCP送信者は、損失イベントの後Wに対してW（1-B（W））セグメントから輻輳ウィンドウを減少させる場合）wは、そのウィンドウの減少B（W）を示します。損失が発生した場合、我々は、実際の輻輳ウィンドウは、列2中のW平均混雑ウィンドウよりも大きい可能性があるので、使用の減少パラメータは表9のカラム4に示すものよりもわずかに小さいかもしれないことに注意してください。
Table 9 shows that a HighSpeed TCP over a 10 Mbps link behaves exactly the same as a Standard TCP connection, even in the absence of competing traffic. One can think of the congestion window staying generally in the range of 55 to 110 segments, with the HighSpeed TCP behavior being exactly the same as the behavior of Standard TCP. (If the congestion window is ever 128 segments or more, then the HighSpeed TCP increases by two segments per RTT instead of by one, and uses a decrease parameter of 0.44 instead of 0.50.)
表9は、10 Mbpsのリンクを介した高速TCPでもトラフィックの競合が存在しない場合には、正確に標準のTCP接続と同様に動作することを示しています。一つは、高速TCP挙動が標準TCPの動作と全く同じであると、55〜110セグメントの範囲で滞在輻輳ウィンドウと考えることができます。 （輻輳ウィンドウがこれまでに128セグメント以上であれば、高速TCPの代わりに一つによってRTTごとに2つのセグメントによって増大し、代わりに、0.50の0.44の減少パラメーターを使用します）。
Table 9 shows that for a HighSpeed TCP connection over a 100 Mbps link, with no competing traffic, HighSpeed TCP behaves roughly as aggressively as six parallel TCP connections, increasing its congestion window by roughly six segments per round-trip time, and with a decrease parameter of roughly 1/3 (corresponding to decreasing down to 2/3-rds of its old congestion window, rather than to half, in response to a loss event).
表9は、無競合トラフィックが100Mbpsのリンク上で高速TCP接続のために、高速TCPのラウンドトリップ時間当たりおおよそ6つのセグメントによって、その混雑ウィンドウを増加させる、おおよそとして積極的に6つの並列TCPコネクションを振る舞い、及び減少とすることを示していますおおよそ1/3（損失イベントに応答して、その古い輻輳ウィンドウ2/3 RDSにではなく、半分にまで減少に対応する）のパラメータ。
For a Standard TCP connection in this environment, the congestion window could be thought of as generally varying in the range of 550 to 1100 segments, with an average packet drop rate of 2.2 * 10^-6 (corresponding to a bit error rate of 1.8 * 10^-10), or equivalently, roughly 55 seconds between congestion events. While a Standard TCP connection could sustain such a low packet drop rate in a carefully controlled environment with minimal competing traffic, we would contend that in an uncontrolled best-effort environment with even a small amount of competing traffic, the occasional congestion events from smaller competing flows could easily be sufficient to prevent a Standard TCP flow with no lower-speed bottlenecks from fully utilizing the available bandwidth of the underutilized 100 Mbps link.
この環境で標準のTCP接続のために、輻輳ウィンドウは、平均パケット損失率と、のような一般的に550〜1100のセグメントの範囲で変化すると考えることができた2.2×10 ^ -6（1.8のビット誤り率に対応* 10 ^ -10）、又は等価的に、輻輳イベントの間に概ね55秒。標準のTCP接続は、最小限の競合トラフィックを慎重に制御された環境では、このような低いパケットドロップ率を維持することもできますが、我々はトラフィックの競合であっても、少量で制御されていないベストエフォート型の環境で、小さいから時折渋滞イベントが競合することを主張するだろうフローは、容易十分活用されていない100 Mbpsリンクの利用可能な帯域幅を利用してからの低速度のボトルネックと標準TCPフローを防止するのに十分であり得ます。
That is, we would contend that in the environment of 100 Mbps links with a significant amount of available bandwidth, Standard TCP would sometimes be unable to fully utilize the link bandwidth, and that HighSpeed TCP would be an improvement in this regard. We would further contend that in this environment, the behavior of HighSpeed TCP is sufficiently close to that of Standard TCP that HighSpeed TCP would be safe to deploy in the current Internet. We note that HighSpeed TCP can only use high congestion windows if allowed by the receiver's advertised window size. As a result, even if HighSpeed TCP was ubiquitously deployed in the Internet, the impact would be limited to those TCP connections with an advertised window from the receiver of 118 MSS or larger.
つまり、我々は、利用可能な帯域幅の大幅な量の100 Mbpsのリンクの環境では、標準のTCPは、時には完全にリンク帯域幅を利用することができないと主張し、高速TCPは、この点で改善されることでしょう。私たちは、さらにこのような環境では、高速TCPの動作が高速TCPは、現在のインターネットで展開するのが安全だろうと、標準TCPのそれに十分近いと主張するだろう。私たちは、受信機の広告ウィンドウサイズで許可されていれば、高速TCPが唯一の高輻輳ウィンドウを使用できることに注意してください。結果として、高速TCPが遍在インターネットに配備された場合でも、影響を118 MSS以上の受信機からの広告ウィンドウとそれらのTCP接続に限定されるであろう。
We do not believe that the deployment of HighSpeed TCP would serve as a block to the possible deployment of alternate experimental protocols for high-speed congestion control, such as Scalable TCP, XCP [KHR02], or FAST TCP [JWL03]. In particular, we don't expect HighSpeed TCP to interact any more poorly with alternative experimental proposals than would the N parallel TCP connections commonly used today in the absence of HighSpeed TCP.
私たちは、高速TCPの展開は、スケーラブルTCP、XCP [KHR02]、またはFAST TCP [JWL03]などの高速輻輳制御のための別の実験プロトコルの有効な配置にブロックとして役立つだろうと信じていません。特に、我々は高速TCPは、一般的に高速TCPの不存在下で、今日使用されるN並列TCPコネクションだろうよりも代替実験提案をこれ以上悪い対話することを期待しないでください。
We believe that Scalable TCP and HighSpeed TCP have sufficiently similar response functions that they could easily coexist in the Internet. However, we have not investigated Scalable TCP sufficiently to be able to claim, in this document, that Scalable TCP is safe for a widespread deployment in the current Internet.
私たちは、スケーラブルなTCPおよび高速TCPは、彼らが簡単にインターネットに共存する可能性が十分に類似した応答機能を持っていると信じています。しかし、私たちは、スケーラブルなTCPは、現在のインターネットで広く展開するための安全であることを、この文書では、十分に主張することができるようにスケーラブルなTCPを調査していません。
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 0.4 0.125
100 Mbps 833 4.1 0.125
1 Gbps 8333 41.6 0.125
10 Gbps 83333 416.5 0.125
Table 10: Performance of a Scalable TCP connection.
表10：スケーラブルなTCP接続のパフォーマンス。
Table 10 shows the performance of a Scalable TCP connection with 1500-byte packets, an RTT of 100 ms (including average queueing delay), and no competing traffic. The TCP connection is assumed to use delayed acknowledgements. The first column of Table 10 gives the bandwidth, the second column gives the average congestion window needed to utilize that bandwidth, and the third and fourth columns give the increase and decrease parameters.
表10は、1500バイトのパケット（平均待ち行列遅延を含む）100ミリ秒のRTT、および無競合トラフィックでスケーラブルTCP接続の性能を示します。 TCP接続が遅延確認応答を使用することを想定しています。表10の最初の列は、帯域幅を与え、2番目の列は、その帯域幅を利用するために必要な平均輻輳ウィンドウを与え、第3および第4の列は、増減パラメータを与えます。
Note that even in an environment with a 10 Mbps link, Scalable TCP's behavior is considerably different from that of Standard TCP. The increase parameter is smaller than that of Standard TCP, and the decrease is smaller also, 1/8-th instead of 1/2. That is, for 10 Mbps links, Scalable TCP increases less aggressively than Standard TCP or HighSpeed TCP, but decreases less aggressively as well.
でも、10 Mbpsのリンクがある環境では、スケーラブルなTCPの動作は、標準TCPのそれとは大きく異なっていることに注意してください。増加パラメータは、標準TCPのそれよりも小さく、減少は小さく、また1/8番目の代わりに1/2です。すなわち、より少ない積極的標準TCP又は高速TCPより10 Mbpsのリンク、スケーラブルTCPが増加するためであるが、あまり積極的に同様に減少します。
In an environment with a 100 Mbps link, Scalable TCP has an increase parameter of roughly four segments per round-trip time, with the same decrease parameter of 1/8-th. A comparison of Tables 9 and 10 shows that for this scenario of 100 Mbps links, HighSpeed TCP increases more aggressively than Scalable TCP.
100Mbpsのリンクがある環境では、スケーラブルなTCPは、1/8番目の同じ減少パラメータで、往復時間当たりおおよそ4つのセグメントの増加パラメータを有します。表9と10の比較は、100Mbpsのリンクの、このシナリオのために、高速TCPは、より積極的にスケーラブルなTCPよりも増加することを示します。
Next we consider the relative fairness between Standard TCP, HighSpeed TCP and Scalable TCP. The relative fairness between HighSpeed TCP and Standard TCP was shown in Table 5 earlier in this document, and the relative fairness between Scalable TCP and Standard TCP was shown in Table 8. Following the approach in Section 6, for a given packet drop rate p, for p < 10^-3, we can estimate the relative fairness between Scalable and HighSpeed TCP as W_Scalable/W_HighSpeed. This relative fairness is shown in Table 11 below. The bandwidth in the last column of Table 11 is the aggregate bandwidth of the two competing flows given 100 ms round-trip times and 1500-byte packets.
次は、標準TCP、高速TCPとスケーラブルTCPとの間の相対的な公平性を考慮してください。高速TCPおよび標準TCPとの間の相対的な公平性は、このドキュメントでは、表5に示され、そしてスケーラブルなTCPおよび標準TCPとの間の相対的な公平性は、所与のパケットドロップ率pは、第6のアプローチは以下の表8に示しました。 P <10 ^ -3ために、我々はW_Scalable / W_HighSpeedとしてスケーラブルと高速TCPとの間の相対的な公平性を推定することができます。この相対的な公平性を以下の表11に示されています。表11の最後の列の帯域幅は、100ミリ秒の往復時間と1500バイトのパケットを指定された2つの競合するフローの総帯域幅です。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 1.4 643 77.1 Mbps
10^-5 2.1 5595 671.4 Mbps
10^-6 3.1 50279 6.0 Gbps
10^-7 4.5 463981 55.7 Gbps
Table 11: Relative Fairness between the Scalable and HighSpeed Response Functions.
表11：スケーラブルかつ高速応答関数との間の相対的な公正さ。
The second row of Table 11 shows that for a Scalable TCP and a HighSpeed TCP flow competing in an environment with 100 ms RTTs and a 10 Mbps pipe, the two flows would receive essentially the same bandwidth. The next row shows that for a Scalable TCP and a HighSpeed TCP flow competing in an environment with 100 ms RTTs and a 100 Mbps pipe, the Scalable TCP flow would receive roughly 50% more bandwidth than would HighSpeed TCP. Table 11 shows the relative fairness in higher-bandwidth environments as well. This relative fairness seems sufficient that there should be no problems with Scalable TCP and HighSpeed TCP coexisting in the same environment as Experimental variants of TCP.
表11の第2行は、100ミリ秒のRTTと環境と10 Mbpsのパイプで競合スケーラブルTCPと高速TCPフローのため、二つの流れが本質的に同じ帯域幅を受信することを示しています。次の行は、100ミリ秒のRTTと環境と100 Mbpsのパイプで競合スケーラブルTCPと高速TCPフローのために、スケーラブルなTCPフローが希望高速TCPよりも約50％多くの帯域幅を受信することを示しています。表11は、同様に高帯域幅環境における相対的公平性を示しています。この相対的な公平性がTCPの実験バリアントとして同じ環境で共存スケーラブルTCPおよび高速TCPに問題があってはならないことで十分と思われます。
We note that one question that requires more investigation with Scalable TCP is that of convergence to fairness in environments with Drop-Tail queue management.
私たちは、スケーラブルなTCPとのより多くの調査が必要と一つの質問がドロップテイルキュー管理と環境における公正性への収束のものであることに注意してください。
HighSpeed TCP has been separately investigated in simulations by Sylvia Ratnasamy and by Evandro de Souza [SA03]. The simulations in [SA03] verify the fairness properties of HighSpeed TCP when sharing a link with Standard TCP.
高速TCPは別途シルビアRatnasamyによっておよびEvandro・デ・ソウザ[SA03]でシミュレーションで検討されています。標準TCPとのリンクを共有する場合、[SA03]におけるシミュレーションは、高速TCPの公平性を検証します。
These simulations explore the relative fairness of HighSpeed TCP flows when competing with Standard TCP. The simulation environment includes background forward and reverse-path TCP traffic limited by the TCP receive window, along with a small amount of forward and reverse-path traffic from the web traffic generator. Most of the simulations so far explore performance on a simple dumbbell topology with a 1 Gbps link with a propagation delay of 50 ms. Simulations have been run with Adaptive RED and with DropTail queue management.
これらのシミュレーションは、標準のTCPと競合する場合、高速TCPの相対的公正が流れ探ります。シミュレーション環境は、前方の背景が含まれており、TCPによって制限リバースパスのTCPトラフィックは、前方の少量と一緒に、ウィンドウを受け取り、ウェブトラフィックジェネレータからのトラフィックパスリバース。シミュレーションの大半は、これまでに50ミリ秒の伝播遅延で1 Gbpsのリンクを持つ単純なダンベルトポロジのパフォーマンスを探ります。シミュレーションでは、Adaptive REDとし、DropTailキュー管理を使用して実行されています。
The simulations in [SA03] explore performance with a varying number of competing flows, with the competing traffic being all standard TCP; all HighSpeed TCP; or a mix of standard and HighSpeed TCP. For the simulations in [SA03] with RED queue management, the relative fairness between standard and HighSpeed TCP is consistent with the relative fairness predicted in Table 5. For the simulations with Drop Tail queues, the relative fairness is more skewed, with the HighSpeed TCP flows receiving an even larger share of the link bandwidth. This is not surprising; with Active Queue Management at the congested link, the fraction of packet drops received by each flow should be roughly proportional to that flow's share of the link bandwidth, while this property no longer holds with Drop Tail queue management. We also note that relative fairness in simulations with Drop Tail queue management can sometimes depend on small details of the simulation scenario, and that Drop Tail simulations need special care to avoid phase effects [F92].
[SA03]におけるシミュレーションは、競合するトラフィックはすべて、標準TCPであることで、競合するフローの様々な数とパフォーマンスを探ります。すべての高速TCP。または標準および高速TCPの組み合わせ。 REDキュー管理と[SA03]におけるシミュレーションのため、標準及び高速TCPとの間の相対的な公平性は、相対的な公平性が高速TCPで、よりスキューあるドロップテールキューにシミュレーションに表5に予測相対公平性と一致していますリンク帯域幅のより大きなシェアを受けて流れています。これは驚くべきことではありません。このプロパティは、もはやドロップテイルキュー管理を保持しながら、混雑したリンクでのアクティブキュー管理と、各フローが受信したパケットドロップの割合は、リンク帯域幅のその流れのシェアにほぼ比例あってはなりません。また、ドロップテイルキュー管理とシミュレーションの相対的な公正さが時々シミュレーションシナリオの細部に依存し、ドロップテールシミュレーションは、位相効果[F92]を避けるために、特別なケアを必要とすることができることを注意してください。
[SA03] explores the bandwidth `stolen' by HighSpeed TCP from standard TCP by exploring the fraction of the link bandwidth N standard TCP flows receive when competing against N other standard TCP flows, and comparing this to the fraction of the link bandwidth the N standard TCP flows receive when competing against N HighSpeed TCP flows. For the 1 Gbps simulation scenarios dominated by long-lived traffic, a small number of standard TCP flows are able to achieve high link utilization, and the HighSpeed TCP flows can be viewed as stealing bandwidth from the competing standard TCP flows, as predicted in Section 6 on the Fairness Implications of the HighSpeed Response Function. However, [SA03] shows that when even a small fraction of the link bandwidth is used by more bursty, short TCP connections, the standard TCP flows are unable to achieve high link utilization, and the HighSpeed TCP flows in this case are not `stealing' bandwidth from the standard TCP flows, but instead are using bandwidth that otherwise would not be utilized.
[SA03]は `リンク帯域幅の割合を模索N Nその他の標準的なTCPフローと対戦するときの標準的なTCPフローが受信し、リンク帯域幅N標準の一部にこれを比較することにより、標準のTCPから高速TCPによって」盗まれた帯域幅を探りますTCPフローはN高速TCPと対戦するときに流れる受け取ります。長寿命のトラフィックによって支配1つのGbpsのシミュレーションシナリオでは、標準のTCPフローの数が少ない、高リンク利用率を達成することができ、かつ節で予測されるように高速TCPフローは、競合する標準のTCPフローからの帯域幅を盗むとみなすことができます高速応答関数の公平性影響について6。ただし、[SA03]はリンク帯域幅の小さな画分は、よりバースト性、短いTCP接続で使用されている場合、標準のTCPフローが高いリンク利用率を達成することができないことを示しており、高速TCPは `盗んされていない。この場合に流れます「標準TCPからの帯域幅が流れますが、代わりにその他の方法で利用されない帯域幅を使用しています。
The conclusions of [SA03] are that "HighSpeed TCP behaved as forseen by its response function, and appears to be a real and viable option for use on high-speed wide area TCP connections."
[SA03]の結論は、「高速TCPは、その応答関数によって予見として挙動し、高速広域TCP接続で使用するための現実と現実的な選択肢であるように思われる。」ということです
Future work that could be explored in more detail includes convergence times after new flows start-up; recovery time after a transient outage; the response to sudden severe congestion, and investigations of the potential for oscillations. We invite contributions from others in this work.
新しいフローがアップを開始した後に、より詳細に検討される可能性が今後の作業は、コンバージェンス時間を含んでいます。過渡停電後の回復時間。突然の激しい混雑に応じて、振動のための可能性の調査。私たちは、この作品では他の人からの貢献を招待します。
Our assumption is that HighSpeed TCP will be used with the TCP SACK option, and also with the increased Initial Window of three or four segments, as allowed by [RFC3390]. For paths that have substantial reordering, TCP performance would be greatly improved by some of the mechanisms still in the research stages for robust performance in the presence of reordered packets.
我々の仮定は、[RFC3390]によって許容されるよう高速TCPは、TCP SACKオプションを使用して、また、3つのまたは4つのセグメントの増加初期ウィンドウと共に使用されることです。実質的な並べ替えを有するパスについて、TCPの性能が大幅に並べ替え、パケットの存在下でロバストな性能のために、まだ研究段階における機構の一部によって改善されるであろう。
Our view is that HighSpeed TCP is largely orthogonal to proposals for higher PMTU (Path MTU) values [M02]. Unlike changes to the PMTU, HighSpeed TCP does not require any changes in the network or at the TCP receiver, and works well in the current Internet. Our assumption is that HighSpeed TCP would be useful even with larger values for the PMTU. Unlike the current congestion window, the PMTU gives no information about the bandwidth-delay product available to that particular flow.
我々の見解では、高速TCPが高いPMTUの提案（パスMTU）の値[M02]とほぼ直交しているということです。 PMTUの変更とは異なり、高速TCPは、ネットワーク内またはTCP受信機でのすべての変更を必要とせず、現在のインターネットではうまく動作します。私たちの仮定は、高速TCPがさらにPMTUのために大きな値で有用であろうということです。現在の輻輳ウィンドウとは異なり、PMTUは、その特定のフローに使用可能な帯域幅遅延積についての情報を与えません。
A related approach is that of a virtual MTU, where the actual MTU of the path might be limited [VMSS,S02]. The virtual MTU approach has not been fully investigated, and we do not explore the virtual MTU approach further in this document.
関連するアプローチは、パスの実際のMTUが限定されるかもしれない仮想MTU、[VMSS、S02]のものです。仮想MTUのアプローチは、完全には検討されていない、と私たちは、この文書では、さらに仮想MTUのアプローチを探求していません。
This document has proposed HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. We have explored this proposal in simulations, and others have explored HighSpeed TCP with experiments, and we believe HighSpeed TCP to be safe to deploy on the current Internet. We would welcome additional analysis, simulations, and particularly, experimentation. More information on simulations and experiments is available from the HighSpeed TCP Web Page [HSTCP]. There are several independent implementations of HighSpeed TCP [D02,F03] and of Scalable TCP [K03] for further investigation.
この文書では、高速TCP、大混雑窓のTCP接続で使用するTCPの輻輳制御機構への変更を提案しました。私たちは、シミュレーションでこの提案を探求してきた、他は実験で高速TCPを模索している、と我々は高速TCPは、現在のインターネット上で展開しても安全であると信じます。我々は追加の分析、シミュレーション、および特に、実験を歓迎します。シミュレーションと実験の詳細については、高速TCPのWebページ[HSTCP]から入手可能です。さらなる調査のためのスケーラブルなTCP [K03]高速TCP [D02、F03]のと、いくつかの独立した実装があります。
The HighSpeed TCP proposal is from joint work with Sylvia Ratnasamy and Scott Shenker (and was initiated by Scott Shenker). Additional investigations of HighSpeed TCP were joint work with Evandro de Souza and Deb Agarwal. We thank Tom Dunigan for the implementation in the Linux 2.4.16 Web100 kernel, and for resulting experimentation with HighSpeed TCP. We are grateful to the End-to-End Research Group, the members of the Transport Area Working Group, and to members of the IPAM program in Large Scale Communication Networks for feedback. We thank Glenn Vinnicombe for framing the Linear response function in the parameters of HighSpeed TCP. We are also grateful for contributions and feedback from the following individuals: Les Cottrell, Mitchell Erblich, Jeffrey Hsu, Tom Kelly, Chuck Jackson, Matt Mathis, Jitendra Padhye, Andrew Reiter, Stanislav Shalunov, Alex Solan, Paul Sutter, Brian Tierney, Joe Touch.
高速TCPの提案はシルビアRatnasamyとスコット・シェンカー（とスコット・シェンカーによって開始された）との共同研究からです。高速TCPの追加調査はEvandro・デ・ソウザとデブAgarwalさんとの共同作業でした。我々は、Linux 2.4.16のWeb100カーネルの実装のため、および高速TCPとの実験結果として得られるため、トムDuniganに感謝します。私たちは、エンドツーエンドの研究グループに、交通地域ワーキンググループのメンバー、およびフィードバックのための大規模通信ネットワークにおけるIPAMプログラムのメンバーに感謝しています。私たちは、高速TCPのパラメータで線形応答関数をフレーミングするためにグレンVinnicombeに感謝します。レ・コットレル、ミッチェルErblich、ジェフリー・スー、トム・ケリー、チャック・ジャクソン、マット・マシス、Jitendra Padhye、アンドリュー・ライター、スタニスラフ・シャルノブ、アレックス・ソーラン、ポール・サッター、ブライアン・ティアニー、ジョー：我々はまた、以下の個人からの寄付やフィードバックのために感謝していますタッチ。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[ABLLS03] A. Antony, J. Blom, C. de Laat, J. Lee, and W. Sjouw, "Microscopic Examination of TCP Flows over Transatlantic Links", iGrid2002 special issue, Future Generation Computer Systems, volume 19 issue 6 (2003), URL "http://www.science.uva.nl/~delaat/techrep-2003-2- tcp.pdf".
[ABLLS03] A.アントニー、J.ブロム、C.ドLAAT、J.リー、およびW. Sjouw、 "TCPの顕微鏡検査は、大西洋横断のリンク上を流れ"、iGrid2002特別号、次世代コンピュータシステム、ボリューム19問題6（ 2003年）、URL "http://www.science.uva.nl/~delaat/techrep-2003-2- tcp.pdf"。
[BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, "Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms", SIGCOMM 2001, August 2001.
[BBFS01]ディーパック・バンソール、ハリ・バラクリシュナン、サリーフロイド、とスコット・シェンカー、「ゆっくりと応答性輻輳制御アルゴリズムの動的挙動」、SIGCOMM 2001、2001年8月。
[CC03] Fabrizio Coccetti and Les Cottrell, "TCP Stack Measurements on Lightly Loaded Testbeds", 2003. URL "http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/".
[CC03]ファブリツィオCoccettiとレ・コットレル、「負荷の軽いテストベッド上のTCPスタックの測定」、2003年URL「http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/」。
[CJ89] D. Chiu and R. Jain, "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks", Computer Networks and ISDN Systems, Vol. 17, pp. 1-14, 1989.
[CJ89] D.チウとR.ジャイナ教、「増加の分析とコンピュータネットワークにおける輻輳回避のためのアルゴリズムを下げる」、コンピュータネットワークとISDNシステム、巻。 17頁。1-14、1989。
[CO98] J. Crowcroft and P. Oechslin, "Differentiated End-to-end Services using a Weighted Proportional Fair Share TCP", Computer Communication Review, 28(3):53--69, 1998.
[CO98] J.クロウクロフトとP. Oechslin、コンピュータコミュニケーションレビュー、28 "加重プロポーショナルフェアシェアTCPを使用して差別化エンドツーエンドサービス"（3）：53--69、1998。
[D02] Tom Dunigan, "Floyd's TCP slow-start and AIMD mods", URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html".
[D02]トムDunigan、 "フロイドのTCPスロースタートとAIMD改造"、URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html"。
[F03] Gareth Fairey, "High-Speed TCP", 2003. URL "http://www.hep.man.ac.uk/u/garethf/hstcp/".
[F03]ガレス・フェアリー、 "高速TCP"、2003年URL "http://www.hep.man.ac.uk/u/garethf/hstcp/"。
[F92] S. Floyd and V. Jacobson, "On Traffic Phase Effects in Packet-Switched Gateways, Internetworking: Research and Experience", V.3 N.3, September 1992, p.115-156. URL "http://www.icir.org/floyd/papers.html".
「パケット交換ゲートウェイにおける交通相の影響で、インターネットワーキング：研究と経験」[F92] S.フロイドとV.ヤコブソン、V.3 N.3、1992年9月、p.115-156。 URL "http://www.icir.org/floyd/papers.html"。
[Fl03] Sally Floyd, "Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard", Email to the tsvwg mailing list, May 14, 2003.
[Fl03]サリーフロイド、 "再：[TSVWG] NewRenoの標準化提案へ（RFC 2582）取って"、TSVWGメーリングリストへの電子メール、2003年5月14日を。
URLs "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html" and "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04087.html".
URLの「http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html」と「http://www1.ietf.org/mail-archive/working-groups/tsvwg/現在/ msg04087.html」。
[FF98] Floyd, S., and Fall, K., "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF98]フロイド、S.、および秋、K.、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進」、ネットワーキング、1999年8月にIEEE / ACM取引。
[FRS02] Sally Floyd, Sylvia Ratnasamy, and Scott Shenker, "Modifying TCP's Congestion Control for High Speeds", May 2002. URL "http://www.icir.org/floyd/notes.html".
[FRS02]サリー・フロイド、シルビアRatnasamy、とスコット・シェンカー、「高速のための変更TCPの輻輳制御」、2002年5月URL「http://www.icir.org/floyd/notes.html」。
[GRK99] Panos Gevros, Fulvio Risso and Peter Kirstein, "Analysis of a Method for Differential TCP Service". In Proceedings of the IEEE GLOBECOM'99, Symposium on Global Internet , December 1999, Rio de Janeiro, Brazil.
[GRK99]パノスGevros、フルビオRissoとピーター・カースティン、「差動TCPサービスのための方法の分析」。グローバル・インターネット、1999年12月、リオ・デ・ジャネイロ、ブラジルのIEEE GLOBECOM'99、シンポジウムで。
[GV02] S. Gorinsky and H. Vin, "Extended Analysis of Binary Adjustment Algorithms", Technical Report TR2002-39, Department of Computer Sciences, The University of Texas at Austin, August 2002. URL "http://www.cs.utexas.edu/users/gorinsky/pubs.html".
[GV02] S. GorinskyとH.ヴィン、「バイナリ調整アルゴリズムの拡張分析」、技術報告書TR2002-39、コンピュータ科学科、テキサス大学オースティン校、2002年8月URLは「http：//www.cs .utexas.edu /ユーザー/ gorinsky / pubs.html」。
[HSTCP] HighSpeed TCP Web Page, URL "http://www.icir.org/floyd/hstcp.html".
[HSTCP]高速TCP Webページ、URL "http://www.icir.org/floyd/hstcp.html"。
[J02] Amit Jain and Sally Floyd, "Quick-Start for TCP and IP", Work in Progress, 2002.
[J02]アミットジャイナ教とサリーフロイド、「TCPとIPのためのクイックスタート」、進歩、2002年の作品。
[JWL03] Cheng Jin, David X. Wei and Steven H. Low, "FAST TCP for High-speed Long-distance Networks", Work in Progress, June 2003.
[JWL03]チェンジン、デビッドX.魏とスティーブンH.ロー、「高速長距離ネットワークの高速TCP」、進歩、2003年6月での作業。
[K03] Tom Kelly, "Scalable TCP: Improving Performance in HighSpeed Wide Area Networks", February 2003. URL "http://www-lce.eng.cam.ac.uk/~ctk21/scalable/".
[K03]トム・ケリー、「スケーラブルTCP：高速広域ネットワークにおけるパフォーマンスの向上」、2003年2月URL「http://www-lce.eng.cam.ac.uk/~ctk21/scalable/」。
[KHR02] Dina Katabi, Mark Handley, and Charlie Rohrs, "Congestion Control for High Bandwidth-Delay Product Networks", SIGCOMM 2002.
[KHR02]ダイナ・カタビ、マーク・ハンドリー、とチャーリーRohrs、「高帯域遅延製品のネットワークの輻輳制御」、SIGCOMM 2002。
[M02] Matt Mathis, "Raising the Internet MTU", Web Page, URL "http://www.psc.edu/~mathis/MTU/".
[M02]マット・マシス、 "インターネットMTUを上げる"、Webページ、URL "http://www.psc.edu/~mathis/MTU/"。
[Net100] The DOE/MICS Net100 project. URL "http://www.csm.ornl.gov/~dunigan/net100/".
[NET100] DOE / MICS NET100プロジェクト。 URL "http://www.csm.ornl.gov/~dunigan/net100/"。
[NS] The NS Simulator, "http://www.isi.edu/nsnam/ns/".
[NS] NSシミュレータ、 "http://www.isi.edu/nsnam/ns/"。
[RFC 1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC 1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC3390] Allman, M., Floyd, S. and C., Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.とC.、ヤマウズラ、RFC 3390、2002年10月 "TCPの初期ウィンドウを増やします"。
[RFC3448] Handley, M., Padhye, J., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、Padhye、J.、フロイド、S.およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[SA03] Souza, E. and D.A., Agarwal, "A HighSpeed TCP Study: Characteristics and Deployment Issues", LBNL Technical Report LBNL-53215. URL "http://www.icir.org/floyd/hstcp.html".
[SA03]ソウザ、E.およびD.A.、Agarwalさん、 "高速TCP研究：特性およびデプロイの問題"、LBNLテクニカルレポートLBNL-53215。 URL "http://www.icir.org/floyd/hstcp.html"。
[S02] Stanislav Shalunov, "TCP Armonk", Work in Progress, 2002, URL "http://www.internet2.edu/~shalunov/tcpar/".
[S02]スタニスラフ・シャルノブ、 "TCPアーモンク"、進歩、2002年の作品、URL "http://www.internet2.edu/~shalunov/tcpar/"。
[S03] Alex Solan, private communication, 2003.
[S03]アレックスソーラン、民間の通信、2003年。
[VMSS] "Web100 at ORNL", Web Page, "http://www.csm.ornl.gov/~dunigan/netperf/web100.html".
[VMSS] "ORNLでのWeb100"、Webページ、 "http://www.csm.ornl.gov/~dunigan/netperf/web100.html"。
[Web100] The Web100 project. URL "http://www.web100.org/".
[のWeb100]のWeb100プロジェクト。 URL "http://www.web100.org/"。
This proposal makes no changes to the underlying security of TCP.
この提案は、TCPの基本的なセキュリティを変更しません。
There are no IANA considerations regarding this document.
この文書に関する一切IANAの考慮事項はありません。
A. TCP's Loss Event Rate in Steady-State
定常状態におけるA. TCPのロスイベントレート
This section gives the number of round-trip times between congestion events for a TCP flow with D-byte packets, for D=1500, as a function of the connection's average throughput B in bps. To achieve this average throughput B, a TCP connection with round-trip time R in seconds requires an average congestion window w of BR/(8D) segments.
このセクションでは、BPSに接続の平均スループットBの関数として、D = 1500、D-バイトパケットでTCPフローの輻輳イベント間の往復回数を与えます。この平均スループットBを達成するために、秒単位のラウンドトリップ時間RとのTCP接続がBR /（8D）セグメントwの平均輻輳ウィンドウを必要とします。
In steady-state, TCP's average congestion window w is roughly 1.2/sqrt(p) segments. This is equivalent to a lost event at most once every 1/p packets, or at most once every 1/(pw) = w/1.5 round-trip times. Substituting for w, this is a loss event at most every (BR)/12D)round-trip times.
定常状態では、TCPの平均輻輳ウィンドウwはおおよそ1.2 / SQRT（P）セグメントです。これは= 1.5 / wの往復時間で、最高1回ごとに1 / Pパケット、または最大で1回ごとに1 /（PW）失われたイベントに相当します。ワットの代わりに、これはほとんどすべての（BR）/ 12D）往復時間での損失イベントです。
An an example, for R = 0.1 seconds and D = 1500 bytes, this gives B/180000 round-trip times between loss events.
例では、R = 0.1秒、D = 1500バイトの場合、これは損失事象間のB / 180000往復時間を与えます。
B. A table for a(w) and b(w).
B.（W）のためのテーブルおよびB（W）。
This section gives a table for the increase and decrease parameters a(w) and b(w) for HighSpeed TCP, for the default values of Low_Window = 38, High_Window = 83000, High_P = 10^-7, and High_Decrease = 0.1.
このセクションでは、増減デフォルトLow_Window = 38、High_Window = 83000、High_P = 10の値^ -7、およびHigh_Decrease = 0.1ため、高速TCPため（W）およびb（W）のパラメータの表を与えます。
w a(w) b(w)
---- ---- ----
38 1 0.50
118 2 0.44
221 3 0.41
347 4 0.38
495 5 0.37
663 6 0.35
851 7 0.34
1058 8 0.33
1284 9 0.32
1529 10 0.31
1793 11 0.30
2076 12 0.29
2378 13 0.28
2699 14 0.28
3039 15 0.27
3399 16 0.27
3778 17 0.26
4177 18 0.26
4596 19 0.25
5036 20 0.25
5497 21 0.24
5979 22 0.24
6483 23 0.23
7009 24 0.23
7558 25 0.22
8130 26 0.22
8726 27 0.22
9346 28 0.21
9991 29 0.21
10661 30 0.21
11358 31 0.20
12082 32 0.20
12834 33 0.20
13614 34 0.19
14424 35 0.19
15265 36 0.19
16137 37 0.19
17042 38 0.18
17981 39 0.18
18955 40 0.18
19965 41 0.17 21013 42 0.17 22101 43 0.17 23230 44 0.17 24402 45 0.16 25618 46 0.16 26881 47 0.16 28193 48 0.16 29557 49 0.15 30975 50 0.15 32450 51 0.15 33986 52 0.15 35586 53 0.14 37253 54 0.14 38992 55 0.14 40808 56 0.14 42707 57 0.13 44694 58 0.13 46776 59 0.13 48961 60 0.13 51258 61 0.13 53677 62 0.12 56230 63 0.12 58932 64 0.12 61799 65 0.12 64851 66 0.11 68113 67 0.11 71617 68 0.11 75401 69 0.10 79517 70 0.10 84035 71 0.10 89053 72 0.10 94717 73 0.09
19965 41 0.17 21013 42 0.17 22101 43 0.17 23230 44 0.17 24402 45 0.16 25618 46 0.16 26881 47 0.16 28193 48 0.16 29557 49 0.15 30975 50 0.15 32450 51 0.15 33986 52 0.15 35586 53 0.14 37253 54 0.14 38992 55 0.14 40808 56 0.14 42707 57 0.13 44694 58 0.13 46776 59 0.13 48961 60 0.13 51258 61 0.13 53677 62 0.12 56230 63 0.12 58932 64 0.12 61799 65 0.12 64851 66 0.11 68113 67 0.11 71617 68 0.11 75401 69 0.10 79517 70 0.10 84035 71 0.10 89053 72 0.10 94717 73 0.09
Table 12: Parameters for HighSpeed TCP.
表12：高速TCPのパラメータ。
This table was computed with the following Perl program:
このテーブルは、次のPerlプログラムで計算しました：
$top = 100000;
$num = 38;
if ($num == 38) {
print " w a(w) b(w)\n";
print " ---- ---- ----\n";
print " 38 1 0.50\n";
$oldb = 0.50;
$olda = 1;
}
while ($num < $top) {
$bw = (0.1 -0.5)*(log($num)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($num**2*2.0*$bw) / ((2.0-$bw)*$num**1.2*12.8);
if ($aw > $olda + 1) {
printf "%6d %5d %3.2f0, $num, $aw, $bw;
$olda = $aw;
}
$num ++;
}
Table 13: Perl Program for computing parameters for HighSpeed TCP.
表13：高速TCPのパラメータを計算するためのPerlプログラム。
C. Exploring the time to converge to fairness.
C.は、公平性に収束する時間を探ります。
This section gives the Perl program used to compute the congestion window growth during congestion avoidance.
このセクションでは、輻輳回避時の輻輳ウィンドウの成長を計算するために使用されるPerlプログラムを提供します。
$top = 2001;
$hswin = 1;
$regwin = 1;
$rtt = 1;
$lastrtt = 0;
$rttstep = 100;
if ($hswin == 1) {
print " RTT HS_Window Standard_TCP_Window0;
print " --- --------- -------------------0;
}
while ($rtt < $top) {
$bw = (0.1 -0.5)*(log($hswin)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($hswin**2*2.0*$bw) / ((2.0-$bw)*$hswin**1.2*12.8);
if ($aw < 1) {
$aw = 1;
}
if ($rtt >= $lastrtt + $rttstep) {
printf "%5d %9d %10d0, $rtt, $hswin, $regwin;
$lastrtt = $rtt;
}
$hswin += $aw;
$regwin += 1;
$rtt ++;
}
Table 14: Perl Program for computing the window in congestion avoidance.
表14：輻輳回避に窓を計算するためのPerlプログラム。
Author's Address
著者のアドレス
Sally Floyd ICIR (ICSI Center for Internet Research)
サリーフロイドICIR（インターネットリサーチのためのICSIセンター）
Phone: +1 (510) 666-2989 EMail: floyd@acm.org URL: http://www.icir.org/floyd/
電話：+1（510）666-2989 Eメール：floyd@acm.org URL：http://www.icir.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。