[要約] RFC 3649は、大きな輻輳ウィンドウに対応するためのHighSpeed TCPプロトコルに関するものです。このRFCの目的は、高速なネットワークでのパフォーマンス向上を実現するためのTCP拡張を提案することです。
Network Working Group S. Floyd
Request for Comments: 3649 ICSI
Category: Experimental December 2003
HighSpeed TCP for Large Congestion Windows
大規模な混雑ウィンドウ用の高速TCP
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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の混雑制御メカニズムの変更であるHighSpeed TCPを提案しています。現在の標準TCPの混雑制御メカニズムは、現実的な環境でTCPによって達成できる輻輳ウィンドウを制約します。たとえば、1500バイトのパケットを使用した標準のTCP接続と100ミリ秒の往復時間の場合、10 gbpsの定常状態のスループットを達成するには、83,333セグメントの平均輻輳ウィンドウと最大1つのパケットドロップレートが必要です。5,000,000,000個のパケットごとに混雑イベント（または、最大で1回2/3時間ごとに1回の混雑イベント）。これは、非現実的な制約として広く認められています。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 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.
このドキュメントでは、大規模な渋滞ウィンドウを備えたTCP接続で使用するためのTCPの混雑制御メカニズムの変更であるHighSpeed TCPを提案しています。パケット損失率pを備えた定常状態環境では、現在の標準TCPの平均輻輳ウィンドウは、約1.2/SQRT（P）セグメントです。これにより、現実的な環境でTCPが達成できる混雑ウィンドウに深刻な制約があります。たとえば、1500バイトパケットと100ミリ秒の往復時間を使用した標準のTCP接続の場合、10 gbpsの定常状態のスループットを達成するには、83,333セグメントの平均輻輳ウィンドウと最大1のパケットドロップレートが必要です。5,000,000,000個のパケットごとに混雑イベント（または、最大で1回2/3時間ごとに1回の混雑イベント）。この環境での完全なリンク利用に必要な最大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応答関数の修正は、TFRCおよび他の形式の方程式ベースの混雑制御を使用する輸送プロトコルにも影響を与えます。これらの混雑制御メカニズムはTCP応答関数[RFC3448]を直接使用するためです。
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応答関数を変更する問題から、大きな初期ウィンドウから開始する問題に対処する問題に対処することを提案するもう1つの理由です。
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).
このセクションでは、Dバイトのパケットとround-trip時間のR秒を与えられたBPの平均スループットを達成するために標準のTCPフローに必要な輻輳イベント間の往復時間の数について説明します。輻輳イベントとは、1つ以上のドロップまたは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 BPの平均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：標準のTCPの混雑イベント、1500バイトのパケット、および0.1秒の往復時間の間のRTT。
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対応環境の両方で許容できるパフォーマンス、およびドロップテールと、ルーターの赤などのアクティブキュー管理を使用することです。
* 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 gbps以上のスループットを達成したいユーザーは、通常、複数の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.
私たちの提案は、パケットドロップ率が非常に低い環境でTCP互換性のあるパフォーマンスを必要とせず、または配信していないことに注意してください。たとえば、パケット損失率は10^-5または10^-6のパケット損失率です。このドキュメントで後で説明するように、標準のTCPは、10^-6の損失率がある環境で利用可能な帯域幅を効果的に使用できないため、高速TCPがより多くを実行するために許容可能で適切であると仮定します。このような環境の標準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の関数として、MSSサイズのセグメントでTCPの平均輻輳ウィンドウWを与えます[FF98]。このTCP応答関数は、TCPの加算的増加の増加乗数増加（AIMD）メカニズムの直接的な結果であり、うっ血がない場合に往復時間ごとに約1つのセグメントを増加させ、ラウンドトリップに応答してうっ血ウィンドウを半分にすることのメカニズム混雑イベントでの時間。標準TCPのこの応答関数は、以下の表に反映されています。この提案では、最大10^-2のパケット損失率を持つ環境でのTCPパフォーマンスへの注意を制限しているため、再送信タイムアウトを使用してより混雑した環境でTCPパフォーマンスをモデル化するために必要なより複雑な応答関数を無視できます。付録Aから、Wの平均輻輳ウィンドウは、標準TCPの損失イベント間の平均2/3 Wの往復時間に対応しています（輻輳ウィンドウは2/3 Wから4/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よりも大きいときに高速応答関数を使用します。このドキュメントでは、TCPのパケットドロップレート10^-3に対応する38ミリズサイズのセグメントに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スループットを維持するために必要なウィンドウです。83000に設定されたhigh_windowの場合、10^-7のhigh_pを指定します。つまり、高速TCPで10^-7のパケットドロップレートを使用すると、高速TCP接続が83000セグメントの平均輻輳ウィンドウを実現できます。この損失率は、高速環境の達成可能なターゲットを設定すると同時に、パケットドロップレートが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 = (p/Low_P)^S Low_Window,
for Low_P the packet drop rate corresponding to Low_Window, and for S as following constant [FRS02]:
low_pの場合、low_windowに対応するパケットドロップレート、およびsの場合は定数[frs02]：
S = (log High_Window - log Low_Window)/(log High_P - log 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:
（このホワイトペーパーでは、「ログX」はログベース10を指します。たとえば、LOW_WINDOWセット38に設定されている場合、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.
標準TCPとの後方互換性の問題には、10^-1、10^-2、または10^-3の損失率の標準TCPのそれに非常に近い応答関数が必要であると考えています。しかし、このような厳しいTCP互換性は損失率が少ないためには必要ではなく、適切な応答関数は、10 gbpsの接続スループットにもっともらしいパケットドロップレートを与えるものであると考えています。これにより、パケットドロップレートの減少の関数として、損失イベント間の往復時間の数がゆっくりと増加します。
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 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:
高速応答関数を調べる別の方法は、高速TCPが最初にnが最初に1つ、nが高速TCPの輻輳ウィンドウの関数として増加するn並列TCP接続のうっ血制御応答をほぼエミュレートしていることを考慮することです。したがって、上記の式（1）の高速応答関数の場合、応答関数はn（w）並列TCP接続のそれと同等であると見なすことができます。ここで、n（w）はうっ血ウィンドウの関数として変化します。単一の標準TCP接続である平均輻輳ウィンドウは、1.2/SQRT（P）に等しくなります。n並列TCP接続の場合、n接続の集約輻輳ウィンドウはn*1.2/sqrt（p）に等しくなります。式（1）の高速応答関数と上記の関係から、以下を導き出すことができます。
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.
このドキュメントでは、100,000を超えるパケットを超える混雑ウィンドウの高速応答関数を真剣に評価しようとはしません。私たちは、何千もの数万のパケットの混雑ウィンドウを備えた高速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接続が、同じ環境で競合する単一の標準TCP接続のスループットをW_HIGHSPEED/W_STANDARD TIMEを受信しています。
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接続が800（または2530）の往復時間ごとに最大1つの混雑イベントを必要とする体制に入りました。利用可能な帯域幅を利用するため。私たちの判断は、今日、この体制で何千ものパケットの混雑の窓があるため、今日この体制で効果的に動作している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番目の列である集約ウィンドウは、最初の列で指定されたパケットドロップレートを与えられると、2つの競合するTCP接続の集約渋滞ウィンドウを示しています。表5から、高速TCP接続は、パケットドロップレートが10^-6の環境で標準TCPの帯域幅の10倍を受け取ります。これは、1つのパイプを共有する2つのフローが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フローが必要な時間を検討します。公平性への収束の最悪のケースは、新しいフローが起動しているときに発生し、高帯域幅の既存のフローと競合し、新しいフローはパケットドロップに苦しみ、ウィンドウがまだ小さい間にスロースタートを終了します。最悪の場合、新しいフローが輻輳回避段階に入ったが、そのウィンドウは1つのパケットにすぎないことを考慮してください。混雑回避の標準TCPフローは、往復時間ごとに最大1つのパケットによってウィンドウを増加させ、nラウンドトリップ時間の後、nパケットのウィンドウのみを達成しました（最初のラウンドトリップで1つのウィンドウから始まる場合時間）。対照的に、高速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.
相対的な公平性に関する古典的な論文は、ChiuとJain [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の場合、高速応答関数を加法の増加と乗法の減少パラメーターに変換する必要があります。高速応答関数は、往復時間ごとに1つのセグメントが加算され、現在の輻輳ウィンドウを半分にすることの乗算的減少を伴う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））セグメントに減少させます。 - 1つ以上の損失イベントで時間を挙げます。したがって、単一の承認に応じて、高速TCPは次のようにセグメントの輻輳ウィンドウを増加させます。
w <- w + a(w)/w.
w <-w a（w）/w。
In response to a congestion event, HighSpeed TCP decreases as follows:
輻輳イベントに応じて、高速TCPは次のように減少します。
w <- (1-b(w))w.
w < - （1-b（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の場合、a（w）= 1およびb（w）= 1/2、wの値に関係なく。高速TCPは、w <= low_windowに対してa（w）とb（w）の同じ値を使用します。このセクションでは、wのより大きな値の高速TCPのa（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:
w = high_windowの場合、high_pの損失率を指定しました。[FRS02]から、または基本計算から、これにはw = high_windowのa（w）とb（w）の間の次の関係が必要です。
a(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.
パラメーターhigh_decreaseを使用して、w = high_windowの減少パラメーターb（w）を指定し、式（2）を使用して、w = high_windowの増加パラメーターa（w）を導き出します。たとえば、high_p = 10^-7およびhigh_window = 83000に加えて、high_decrease = 0.1を指定し、b（83000）= 0.1を指定し、輻輳イベント後に10％の減少を示します。式（2）は、w = 83000の72セグメント、または往復時間内に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.
この中程度の減少は、特に、より深刻な輻輳に応じて送信率を制限する上でのTCPのACK閉鎖の役割と相まって、私たちを受け入れられると私たちを襲います[BBFS01]。より深刻な減少には、混雑なしの往復時間の間、混雑ウィンドウがより積極的に増加する必要があります。特に、標準の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 = low_windowのb（w）= 1/2の減少パラメーター、およびb（w）= high_decrease f = high_windowの場合、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,
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)),
a（w）= w^2 * p（w） * 2 * b（w）/（2-b（w））、
for p(w) the packet drop rate for congestion window w. From inverting Equation (1), we get p(w) as follows:
p（w）の場合、混雑ウィンドウのパケットドロップレートw。式（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の実験的実装では、A（W）およびB（W）を見つけるために事前に計算されたルックアップ表が使用されると想定しています。たとえば、Tom Duniganからの実装は、0.1秒ごとにA（W）およびB（W）パラメーターを調整します。付録では、low_window = 38、high_window = 83,000、high_p = 10^-7、およびhigh_decrease = 0.1のデフォルト値のこのような表を示します。これらは、NSシミュレーターのデフォルト値でもあります。NSの例のシミュレーションは、ディレクトリTCL/テストのコマンド「./Test-All-TcPhighSpeed」で実行できます。
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.
このセクションでは、特にGlenn VinnicombeとTom Kellyによって他の多くの人々によって提案されている高速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.
LOW_WINDOWの値を38 MSSサイズのセグメントとして保持し、高速応答関数が現在のTCP応答関数と違いを示すが、High_WindowおよびHigh_Pパラメーターを変更するhigh speed応答関数の上位範囲を変更する時期を示すと仮定します。特に、high_window = 380,000および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）、1/0.38、または同等に26、W> 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.
1/2の一定の減少B（W）を考えると、これによりw/low_windowのa（w）が増加し、同等に、w> low_windowについて、確認ごとに1/low_windowパケットの一定の増加が得られます。別の可能性は、スケーラブルなTCP [K03]であり、これは固定減少B（W）が1/8、0.01の確認ごとに固定増加を使用します。これにより、純粋なMIMDでは、承認が遅れたTCPの場合、0.005 WのウィンドウあたりA（W）が増加します。
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).
線形応答関数の1つの魅力は、それがスケール不変であり、確認ごとの輻輳ウィンドウが固定され、損失イベント間の固定数の往復時間があることです。私自身の仮定は、パケットドロップレートに関係なく、往復時間に渋滞エポックに固定された長さを持つことは、さまざまなキュー管理メカニズムを備えたルーターを備えた不正確で不完全な世界に適していないことです。今日一般的なドロップテールキュー管理。たとえば、往復時間に渋滞エポックに対して固定された長さの応答関数は、すべてのフローに対して固定間隔で定常状態のバックグラウンド損失を持つ環境での明確なフィードバックを提供する可能性があります（ワイヤレスリンクで発生する可能性があります。時折短いエラーが破裂し、送信率に関係なくすべてのフローの損失を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接続の集約輻輳ウィンドウを示します。表8から、線形高速TCP接続は、パケットドロップレートが10^-5の環境で標準TCPの帯域幅の15倍を受け取ります。これは、単一のパイプを共有する2つのフローが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の輻輳制御パラメーターの選択を評価するために使用できます。このセクションでの私の仮定は、w = c/p^dの応答関数の場合、定数Cおよび指数Dの場合、考慮される唯一の応答関数は1/2 <= d <= 1の応答関数であるということです。。このスペクトルの2つの端は、d = 1/2の現在のTCPで表され、上記のセクション8で説明されている線形応答関数によって表されます。= 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.
1/2未満の指数を持つ応答関数は、高い渋滞ウィンドウとの接続に対応する標準のTCPよりもさらに悪いため、考慮から排除できます。
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を超える指数を持つ応答関数は考慮から排除できます。w = c/p^dの応答関数の場合、1/pパケットごとに1つの損失イベントまたは輻輳イベントがある場合、損失イベント間の往復時間の数はw^（（1/d）-1）/cです^（1/d）。したがって、標準のTCPの場合、w。対照的に、上記のセクション8で説明されているように、線形応答関数の1つの魅力は、それが拡張不変であり、補助金ごとの輻輳ウィンドウの固定増加と、損失間の固定数の往復時間の観点からです。イベント。
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）の場合、w^（（1/d）-1）に比例します。、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）パケットで送信率を上げ、ドロップテール環境では、1回の損失イベント中に（w）ドロップされたパケットをもたらす可能性があります。標準TCPの1つの魅力は、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 WパケットのA（W）が増加します。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接続のパフォーマンスを改善するために、スロースタート中の1つのデータウィンドウの輻輳ウィンドウが増加するセグメントの数を制限します。限られたスロースタートを別のドラフトに分離しました。これは、標準または高速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".
限られたスロースタートは、2002年5月1日以降のスナップショットについて、「./test-all-tcphighspeed tcp1a」および「./test-all-tcphighspeed tcphighspeed1」で「/test-all-tcphighspeed tcp1a」に示されています。「。
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オプションの最小提案[J02]、より多くの罰金を必要とするより多くのパワーを持つ提案まで、これには多くの提案があります。 - ルーターからの調整および連続フィードバック。これらの提案はすべて、このドキュメントの高速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メカニズムを指定していません。可能なメカニズムの1つは、何らかの形のレートベースのペーシングを使用することです。もう1つの可能性は、単一の承認に応じて送信されるパケットの数を制限する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で提起された実装の問題の1つは、4MB以上の輻輳ウィンドウを使用すると、パケットがドロップされた後の連続したサックパケットの取り扱いがTCP送信者で非常に時間がかかることです[S03]。Tom KellyのスケーラブルなTCPには、この問題に対処する「Sack Fast Path」パッチが含まれています。
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シミュレーター[NS]、シミュレーション研究[SA03]、および実験レポート[ABLLS03、D02、CC03、F03]の高速TCPの経験に基づいて、高速TCPは高速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あたりのセグメントの増加a（w）を示しています。4番目の列は、そのウィンドウWの減少B（W）を示しています（TCP送信者は、損失イベントの後にWからW（1-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接続とまったく同じ動作することを示しています。一般的に55〜110のセグメントの範囲にとどまる混雑ウィンドウを考えることができ、高速TCPの動作は標準TCPの動作とまったく同じです。（輻輳ウィンドウが128以上のセグメントである場合、高速TCPは1つではなくRTTごとに2つのセグメントを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は、競合するトラフィックがない100 Mbpsリンクを超える高速TCP接続の場合、高速TCPが6つの並列TCP接続とほぼ同じように積極的に動作し、往復時間ごとに約6セグメント、および減少とともに混雑ウィンドウを増加させることを示しています。約1/3のパラメーター（損失イベントに応じて、半分ではなく、古い輻輳ウィンドウの2/3 RDに減少することに対応）。
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ミリ秒以上のレシーバーから広告されたウィンドウを持つ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]、または高速TCP [JWL03]などの高速輻輳制御のための代替実験プロトコルの展開の可能性のブロックとして役立つとは考えていません。特に、高速TCPが高速TCPの非存在下で一般的に使用されているn並列TCP接続よりも、高速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バイトパケットを使用したスケーラブルなTCP接続のパフォーマンス、100ミリ秒（平均キューイング遅延を含む）、および競合するトラフィックなしのパフォーマンスを示しています。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/2ではなく1/8番です。つまり、10 Mbpsリンクの場合、スケーラブルなTCPは標準のTCPまたは高速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.
100 Mbpsリンクを備えた環境では、スケーラブルTCPのパラメーターは、往復時間ごとに約4つのセグメントのパラメーターが増加し、同じ減少パラメーターが1/8であります。表9と10の比較は、この100 Mbpsリンクのこのシナリオで、高速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の間の相対的な公平性を表8に示しました。P <10^-3の場合、スケーラブルと高速TCPの相対的な公平性をW_Scalable/W_HighSpeedと推定できます。この相対的な公平性を以下の表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行目は、スケーラブルなTCPと100 MS RTTと10 Mbpsパイプを備えた環境で競合する高速TCPフローの場合、2つのフローが本質的に同じ帯域幅を受け取ることを示しています。次の行は、スケーラブルなTCPと100 MS RTTSと100 Mbpsパイプを備えた環境で競合する高速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でより多くの調査を必要とする質問の1つは、ドロップテールキュー管理を備えた環境の公平性への収束であることに注意してください。
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は、Sylvia RatnasamyおよびEvandro de Souza [SA03]によってシミュレーションで個別に調査されています。[SA03]のシミュレーションは、標準のTCPとリンクを共有するときに、高速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トラフィックと、Webトラフィックジェネレーターからの少量のフォワードパストラフィックとリバースパストラフィックが含まれます。これまでのシミュレーションのほとんどは、1 gbpsリンクが50 msの1 gbpsリンクを備えた単純なダンベルトポロジのパフォーマンスを調査しています。シミュレーションは、適応性のある赤とドロップテールキュー管理を備えたもので実行されています。
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の組み合わせ。レッドキュー管理を備えた[SA03]のシミュレーションの場合、標準と高速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]は、標準TCPから高速TCPによって帯域幅を調査し、リンク帯域幅N標準TCPフローの割合を調査することにより、他の標準TCPフローと競合し、これをリンク帯域幅のフラクションとn標準の帯域幅と比較することにより調査します。TCPフローは、N高速TCPフローと競合するときに受信します。長寿命のトラフィックが支配する1 GBPSシミュレーションシナリオの場合、少数の標準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.
私たちの仮定は、高速TCPがTCP SACKオプションで使用され、[RFC3390]で許可されているように、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（PATH MTU）値[M02]の提案に対して主に直交するということです。PMTUの変更とは異なり、HighSpeed TCPはネットワークまたはTCPレシーバーの変更を必要とせず、現在のインターネットでうまく機能します。私たちの仮定は、PMTUの値が大きい場合でも高速TCPが役立つということです。現在の混雑ウィンドウとは異なり、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のアプローチです[VMS、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の混雑制御メカニズムの変更であるHighSpeed TCPを提案しています。この提案をシミュレーションで検討し、他の人は実験で高速TCPを調査しました。高速TCPは現在のインターネットに展開するのが安全であると考えています。追加の分析、シミュレーション、特に実験を歓迎します。シミュレーションと実験の詳細については、高速TCP Webページ[HSTCP]から入手できます。さらなる調査のために、高速TCP [D02、F03]とスケーラブルTCP [K03]のいくつかの独立した実装があります。
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の提案は、Sylvia RatnasamyおよびScott Shenkerとの共同作業からのものです（Scott Shenkerによって開始されました）。高速TCPの追加の調査は、エヴァンドロデソウザとデブアガルワルとの共同研究でした。Linux 2.4.16 Web100カーネルでの実装と、高速TCPでの実験に感謝します。エンドツーエンドの研究グループ、輸送エリアワーキンググループのメンバー、およびフィードバックのために大規模な通信ネットワークのIPAMプログラムのメンバーに感謝しています。高速TCPのパラメーターで線形応答関数をフレーミングしてくれたGlenn Vinnicombeに感謝します。また、以下の個人からの貢献とフィードバックにも感謝しています：レス・コトレル、ミッチェル・エルブリッヒ、ジェフリー・フスー、トム・ケリー、チャック・ジャクソン、マット・マティス、ジテンドラ・パディー、アンドリュー・リーター、スタニスラフ・シャルノフ、アレックス・ソーラン、ポール・サッター、ブライアン・ティ触る。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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. Antony、J。Blom、C。DeLaat、J。Lee、および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] Deepak Bansal、Hari Balakrishnan、Sally Floyd、およびScott Shenker、「ゆっくりと応答性の混雑制御アルゴリズムの動的な動作」、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] Fabrizio CoccettiおよびLes Cottrell、「軽く搭載されたテストベッドの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. ChiuおよびR. Jain、「コンピューターネットワークにおける混雑回避のための増加および減少アルゴリズムの分析」、コンピューターネットワークおよびISDN Systems、vol。17、pp。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. CrowcroftおよびP. Oechslin、「加重比例シェアTCPを使用した差別化されたエンドツーエンドサービス」、Computer Communication Review、28（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] Tom Dunigan、「フロイドのTCPスロースタートおよびAIMD MODS」、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] Gareth Fairey、「High-Speed 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. Floyd and V. Jacobson、「パケットスイッチされたゲートウェイ、インターネットワーキング：研究と経験に関する交通段階の影響」、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] Sally Floyd、「Re：[TSVWG] Newreno（RFC 2582）を提案した標準にして」、2003年5月14日、TSVWGメーリングリストに電子メールを送ります。
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".
urls "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html"および "http://www1.ietf.org/mail-archive/working-groups/tsvwg/Current/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] Floyd、S。、およびFall、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]サリー・フロイド、シルビア・ラトナサミー、スコット・シェンカー、「高速のTCPの混雑制御の修正」、2002年5月。
[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] Panos Gevros、Fulvio Risso、Peter Kirstein、「微分TCPサービスの方法の分析」。IEEE GlobeCom'99の議事録、グローバルインターネットに関するシンポジウム、1999年12月、ブラジル、リオデジャネイロ。
[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 and H. Vin、「バイナリ調整アルゴリズムの拡張分析」、テクニカルレポートTR2002-39、2002年8月、テキサス大学コンピューターサイエンス学科、URL "http：//www.cs.utexas.edu/users/gorinsky/pubs.html "。
[HSTCP] HighSpeed TCP Web Page, URL "http://www.icir.org/floyd/hstcp.html".
[HSTCP] HighSpeed 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] Amit JainとSally Floyd、「TCPとIPのクイックスタート」、Work in Progress、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] Tom Kelly、「スケーラブル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] Dina Katabi、Mark Handley、およびCharlie Rohrs、「帯域幅遅延製品ネットワークのための混雑制御」、Sigcomm 2002。
[M02] Matt Mathis, "Raising the Internet MTU", Web Page, URL "http://www.psc.edu/~mathis/MTU/".
[M02] Matt Mathis、「Raising the Internet 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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC3390] Allman, M., Floyd, S. and C., Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。and C.、Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC3448] Handley, M., Padhye, J., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448] Handley、M.、Padhye、J.、Floyd、S。、およびJ. Widmer、「TCP Friendry Rate Control（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] Souza、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] Stanislav Shalunov、「TCP Armonk」、Work in Progress、2002、url "http://www.internet2.edu/~shalunov/tcpar/"。
[S03] Alex Solan, private communication, 2003.
[S03] Alex Solan、Private Communication、2003。
[VMSS] "Web100 at ORNL", Web Page, "http://www.csm.ornl.gov/~dunigan/netperf/web100.html".
[vmss] "web100 at ornl"、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の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/pパケットごとに最大で紛失したイベントに相当するか、最大で1/（PW）= w/1.5の往復時間ごとに1回と同等です。Wの代わりに、これは最大で（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. a（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の増加および減少パラメーターa（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
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)
Sally Floyd ICIR（ICSIセンターのインターネット研究）
Phone: +1 (510) 666-2989
EMail: floyd@acm.org
URL: http://www.icir.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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エディター機能の資金は現在、インターネット協会によって提供されています。