RFC3649 日本語訳
3649 HighSpeed TCP for Large Congestion Windows. S. Floyd. December 2003. (Format: TXT=79801 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd Request for Comments: 3649 ICSI Category: Experimental December 2003
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 3649年のICSIカテゴリ: 実験的な2003年12月
HighSpeed TCP for Large Congestion Windows
大きい混雑WindowsのためのHighSpeed TCP
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントはHighSpeed TCP(大きい混雑ウィンドウとのTCP接続による使用のためのTCPの混雑制御機構への変更)を提案します。 現在のStandard TCPの輻輳制御メカニズムはTCPが現実的な環境で達成できる混雑ウィンドウを抑制します。 1500年のバイトのパケットとのStandard TCP接続と100のmsの往復の時間例えば、10Gbpsに関する定常状態スループットを達成するのは8万3333のセグメントの平均した混雑ウィンドウを必要とするでしょう、そして、高々1回の混雑出来事のパケット低下率は50億のパケット(または、同等で、高々1 2/3時間毎の1回の混雑出来事)毎を必要とします。 これは非現実的な規制として広く承認されます。 このドキュメントは、TCPのこの限界を記述するために、より広い共同体からHighSpeed TCPを提案して、実験とフィードバックに請求します。
Floyd Experimental [Page 1] RFC 3649 HighSpeed TCP December 2003
[1ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 問題記述。 . . . . . . . . . . . . . . . . . . . 3 3. ガイドラインを設計してください。 . . . . . . . . . . . . . . . . . . . . . . 4 4. 非目標です。 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. TCPレスポンス関数を変更します。 . . . . . . . . . . . . . 6 6. HighSpeed応答の公正含意は機能します。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. 混雑管理パラメータ. . . . . . . . . . . . . . . . . 12 8にHighSpeedレスポンス関数を翻訳します。 交互の、そして、直線的な応答は機能します。 . . . . . . . . . . . 13 9. 混雑を選ぶための見返りはパラメタを制御します。 . . . . . 16 9.1. 損失出来事. . . . 17 9.2の間の往復の回の数。 パケットの数は低下テールと共に損失出来事単位で低下します。 17 10. 関連問題. . . . . . . . . . . . . . . . . . . . . . . . 18 10.1。 遅れた出発。 . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. 短い間burstinessを制限するのは比例します。 . . . . . . . . 19 10.3. ウィンドウサイズにおける他の制限。 . . . . . . . . . . . . 19 10.4. 導入問題。 . . . . . . . . . . . . . . . . . 19 11. 展開問題。 . . . . . . . . . . . . . . . . . . . . . . 20 11.1. HighSpeed TCPの展開問題。 . . . . . . . . . . . 20 11.2. Scalable TCP. . . . . . . . . . . . 22 12の展開問題。 HighSpeed TCPでの関連仕事。 . . . . . . . . . . . . . . . . 23 13. 他のWorkとの関係。 . . . . . . . . . . . . . . . . . 25 14. 結論。 . . . . . . . . . . . . . . . . . . . . . . . . . 25 15. 承認. . . . . . . . . . . . . . . . . . . . . . . 25 16。 引用規格. . . . . . . . . . . . . . . . . . . . . 26 17。 有益な参照. . . . . . . . . . . . . . . . . . . . 26 18。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 28 19. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 28 定常状態におけるA.TCPの損失イベント率。 . . . . . . . . . . . . 29 B. a(w)とb(w)のためのテーブル。 . . . . . . . . . . . . . . . . . . 30 .32AuthorのAddress. . . . . . . . . . . . . . . . . . . . . . . 33Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34を公正に一点に集める時間を探検するC.
1. Introduction
1. 序論
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
このドキュメントはHighSpeed TCP(大きい混雑ウィンドウとのTCP接続による使用のためのTCPの混雑制御機構への変更)を提案します。 定常状態環境で、パケット損失率pで、現在のStandard TCPの平均した混雑ウィンドウはおよそ1.2/sqrt(p)セグメントです。 これはTCPが現実的な環境で達成できる混雑ウィンドウに重大な規制を置きます。 1500バイトパケットとのStandard TCP接続と100のmsの往復の時間、例えば、10Gbpsに関するスループットが平均した混雑ウィンドウを必要とする定常状態を獲得します。
Floyd Experimental [Page 2] RFC 3649 HighSpeed TCP December 2003
[2ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
8万3333のセグメント、およびほとんどの1回の混雑出来事の50億のパケット(または、同等で、高々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レスポンス関数について説明します。 また、このドキュメントは、より広い共同体からHighSpeed 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].
HighSpeed TCPの変更されたレスポンス関数は、より高い混雑ウィンドウで実施するだけでしょう、HighSpeed TCPが環境における重い混雑によるTCPの振舞いを変更しないで、またしたがって、したがって、混雑崩壊の少しの新たな脅威も導入しません。 しかしながら、HighSpeed 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.
HighSpeed TCPのためのこの提案はTCPのために特にTCPレスポンス関数、およびその含意への変更案に焦点を合わせます。 このドキュメントは私たちが大きい初期の窓で*スタート*にベストエフォート型接続を可能にしなければならなかったメカニズムの別々の基本的な問題をみなすことを記述しません。 私たちの意見では、それは、同時に、HighSpeed TCPがTCPレスポンス関数へのいくらか基本的な変化を提案しますが、独身のTCP送付者で実行するのが比較的簡単である変化であり、混雑崩壊に関して危険を全く提示しません。 対照的に、大きい初期の窓で*スタート*に接続を可能にするという問題は、私たちの意見では、本来より危険であって、構造的に難しいです、経路に沿ってルータのすべてから何らかのフォームの明白なフィードバックを必要として。 これは私たちが別々に、そして、別々の時刻表の上の大きい初期の窓から始まるというその問題を訴えるよう提案する別の理由です、TCPレスポンス関数を変更するという問題から。
Floyd Experimental [Page 3] RFC 3649 HighSpeed TCP December 2003
[3ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
2. The Problem Description
2. 問題記述
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).
このセクションはStandard TCP流動がBビーピーエスの平均したスループットを実現するのに必要である混雑出来事の間の往復の回の数について説明します、DバイトとR秒の丸い旅行時間のパケットを考えて。 混雑出来事は1かさらに低下したか、電子証券取引ネットワークが著しいパケット(電子証券取引ネットワークがExplicit Congestion Notificationを表すところ)でデータの窓について言及します。
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.
Appendix Aから、Bビーピーエスの平均したTCPスループットを達成するのが高々損失出来事を必要とする、あらゆる、BR/(12D)往復の回。 これはTable1で0.1R=秒と1500D=バイト例証されます。 また、テーブルは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
損失W Pの間のTCPスループット(Mbps)RTTs--------------------- ------------------- ---- ----- 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秒の往復の時間の混雑出来事の間のRTTs。
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が定常状態パケット低下率のための、より現実的な要件で高生産性を達成するのを許容するためにHighSpeed TCPとTCPの増加への最小量の変更と、より大きい混雑ウィンドウとのTCP接続への減少パラメタを提案します。 同等に、HighSpeed TCPは損失出来事の間に往復の回の数のための、より現実的な要件を持っています。
3. Design Guidelines
3. デザインガイドライン
Our proposal for HighSpeed TCP is motivated by the following requirements:
HighSpeed TCPのための私たちの提案は以下の要件によって動機づけられています:
* Achieve high per-connection throughput without requiring
unrealistically low packet loss rates.
* 非現実的に低パケット損失率を必要としないで、1接続あたりの高いスループットを達成してください。
* 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.
* 倍数から回復するときひどく長いことのない高生産性が遅らせる範囲は斜面期間から小さい混雑ウィンドウに上がっているタイムアウト、またはいつを再送するか。
Floyd Experimental [Page 4] RFC 3649 HighSpeed TCP December 2003
[4ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
* 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.
例えば、目標はできる電子証券取引ネットワークとできる非電子証券取引ネットワーク環境の両方、Drop-テール、およびルータにおけるREDなどのActive Queue Managementとの許容性能のためのものです。
* 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):
* 環境における適度の、または、高い混雑(例えば、1%のパケット低下率)によるTCPコンパチブル性能:
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.
* 少なくとも環境におけるStandard 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.
現在、1Gbpsに関するスループットを達成したがっているユーザか以上が、N仮想のTCP接続の集合のように平行な複数のTCP接続を通常開けるか、またはMulTCP[CO98、GRK99]を使用します。(MulTCPはおよそ振る舞います)。 このアプローチはよく食糧を供給されたリンクの上の時々のユーザに十分ですが、それは、ユーザによって決定されるようにパラメタをNに残して、適度の、または、高い混雑の一区切りで環境で使用されるなら、より攻撃的な性能と、より高い定常状態パケット低下率をもたらします。 私たちは、より多くの柔軟性を提供して、より効果的にさまざまな利用可能な帯域幅に比例して、Standard TCPと混雑している環境において、より公正に競争する新しいアプローチが必要であると信じています。
4. Non-Goals
4. 非目標
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
私たちは、私たちの提案が非常に低いパケット低下率と共に環境におけるTCPコンパチブル性能を必要でない、または提供しないことに注意します、例えば、10^-5か10^-6のパケット損失率で。 中で後でこのドキュメントについて議論するとき、私たちは、Standard TCPが環境における損失を伴う利用可能な帯域幅をうまく利用することができないと思います。
Floyd Experimental [Page 5] RFC 3649 HighSpeed TCP December 2003
[5ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
HighSpeed TCPがそのような環境でStandard TCPより積極的に働くのが、許容できて適切であるためのどんな場合でも、10^-6のレート。
* 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.
それは遅い始めで許容されているよりはやく昇るのが経路に沿ったルータからのさらに明白なフィードバックを必要とするだろうという私たちの信念です。 HighSpeed 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.
私たちは、振動性の振舞いに関する注意が役に立つのに同意しますが、集合スループットにおける振動を避けるのは、私たちの第一の考慮ではありません、特に優に同じで、大きい丸い旅行時間で片道の、そして、長命の流れに制限された簡易型の環境のために。 私たちの査定はこれらの極限環境における何らかの振動性の振舞いがHighSpeed TCPの諸手当の代価を払う許容できる価格であるということです。
5. Modifying the TCP Response Function
5. 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))はMSSサイズのセグメントでTCPの平均した混雑ウィンドウwを与えます、定常状態パケット低下率p[FF98]の関数として。 このTCPレスポンス関数はTCPの混雑と、混雑出来事に伴う往復の時間に対応して混雑ウィンドウを半分にすることが不在のとき往復の時間あたりおよそ1つのセグメントで混雑ウィンドウを増加させるAdditive Increase Multiplicative Decrease(AIMD)メカニズムの直接の結果です。 Standard TCPのためのこのレスポンス関数は以下のテーブルに反映されます。 私たちが高々10^-2のパケット損失率で環境におけるTCP性能に関する私たちの留意を制限するので以上のTCP性能と環境を充血させたモデルに必要であるより複雑なレスポンス関数を無視できるというこの提案では、タイムアウトを再送してください。 Appendix Aから、Wの平均した混雑ウィンドウがStandard TCPのための損失出来事の間で往復の平均2/3W回に対応している、(Wを2/3から4/3に変える混雑ウィンドウ、W)。
Floyd Experimental [Page 6] RFC 3649 HighSpeed TCP December 2003
[6ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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
損失の間のパケット低下率Pの混雑ウィンドウW RTTs------------------ ------------------- ------------------- 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レスポンス関数。 パケット低下率Pの関数としてMSSサイズのセグメントの平均した混雑ウィンドウWを与えます。
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.
変更されたレスポンス関数をHighSpeed TCPに指定するために、私たちは3つのパラメタ、Low_Window、High_Window、およびHigh_Pを使用します。 HighSpeedレスポンス関数は、TCPに互換性を確実にするのに、現在の混雑ウィンドウが高々Low_Windowであるときに、Standard TCPと同じレスポンス関数を使用して、現在の混雑ウィンドウがLow_Windowよりすばらしいときに、HighSpeedレスポンス関数を使用します。 TCPのための10^-3のパケット低下率に対応する、本書では私たちは38のMSSサイズのセグメントにLow_Windowを設定します。
To specify the upper end of the HighSpeed response function, we specify the packet drop rate needed in the HighSpeed response function to achieve an average congestion window of 83000 segments. This is roughly the window needed to sustain 10 Gbps throughput, for a TCP connection with the default packet size and round-trip time used earlier in this document. For High_Window set to 83000, we specify High_P of 10^-7; that is, with HighSpeed TCP a packet drop rate of 10^-7 allows the HighSpeed TCP connection to achieve an average congestion window of 83000 segments. We believe that this loss rate sets an achievable target for high-speed environments, while still allowing acceptable fairness for the HighSpeed response function when competing with Standard TCP in environments with packet drop rates of 10^-4 or 10^5.
HighSpeedレスポンス関数の上側の終わりを指定するために、私たちは83000のセグメントの平均した混雑ウィンドウを達成するのにHighSpeedレスポンス関数で必要であるパケット低下率を指定します。 これはおよそ10Gbpsスループットを支えるのが必要である窓です、サイズと往復の時間が、より早く本書では使用したデフォルトパケットとのTCP接続のために。 Windowが83000に設定するHigh_として、私たちは10^-7のHigh_Pを指定します。 すなわち、HighSpeed TCPと共に、10のパケット低下率に、HighSpeed TCP接続は^-7で83000のセグメントの平均した混雑ウィンドウを実現できます。 私たちは、10^-4か10^5のパケット低下率で環境でStandard TCPと競争するとき、まだHighSpeedレスポンス関数のための許容できる公正を許容している間、この損失率が高速環境のための達成可能な目標を設定すると信じています。
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:
簡単さ、HighSpeedレスポンス関数のために、私たちはレスポンス関数がログログスケール(Standard TCP、混雑を加減する安値のためのレスポンス関数のような)の直線を与える特性を維持します。 これはLow_Windowより大きい平均した混雑ウィンドウWの値のための以下のレスポンス関数をもたらします:
W = (p/Low_P)^S Low_Window,
Wは^S低い_の窓と等しいです(p/低い_P)。
Floyd Experimental [Page 7] RFC 3649 HighSpeed TCP December 2003
[7ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
for Low_P the packet drop rate corresponding to Low_Window, and for S as following constant [FRS02]:
Low_Windowに対応するパケット低下率のLow_P、および定数[FRS02]に続くとしてのSのために:
S = (log High_Window - log Low_Window)/(log High_P - log Low_P).
Sは/(ログHigh_P--ログLow_P)と等しいです(ログHigh_Window--ログLow_Window)。
(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を示します。) 例えば、Windowが38に設定するLow_に関して、私たちには、10^-3(Standard TCPとの互換性のための)のLow_Pがあります。 したがって、Windowが83000に設定するHigh_とPが10^-7に設定したHigh_に関して、私たちは以下のレスポンス関数を得ます:
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.
このHighSpeedレスポンス関数は以下のTable3で例証されます。 HighSpeed TCPに関しては、損失の間の往復の回の数1/(pW)はW>38セグメントのために12.7W^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
損失の間のパケット低下率Pの混雑ウィンドウW RTTs------------------ ------------------- ------------------- 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: HighSpeed TCPのためのTCPレスポンス関数。 パケット低下率Pの関数としてMSSサイズのセグメントの平均した混雑ウィンドウWを与えます。
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.
私たちは、Standard TCPとの後方の互換性の問題が10 1、^-10^-2、または10^-3の損失率のために全くStandard TCPのものの近くにあるレスポンス関数を必要とすると信じています。 しかしながら、私たちはそのような厳しいTCP-互換性が、よりわずかな損失率に必要でなく、適切なレスポンス関数がもっともらしいパケット低下率に10Gbpsに関する接続スループットを支払うものであると信じています。 また、これは減少しているパケット低下率の関数としてゆっくり増加する数の往復の回を損失出来事の間に与えます。
Another way to look at the HighSpeed response function is to consider that HighSpeed TCP is roughly emulating the congestion control response of N parallel TCP connections, where N is initially one, and where N increases as a function of the HighSpeed TCP's congestion window. Thus for the HighSpeed response function in Equation (1) above, the response function can be viewed as equivalent to that of
HighSpeed TCPが乱暴にN平行なTCP接続の混雑操舵応答を見習っていると考えるために、別の方法で、HighSpeedレスポンス関数への一見には、1、およびどこが初めは、Nがあるところにあるか。HighSpeed TCPの混雑ウィンドウの機能としてのN増加。 したがって、Equation(1)のHighSpeedレスポンス関数において、上では、それに同じくらい同等な状態でレスポンス関数を見ることができます。
Floyd Experimental [Page 8] RFC 3649 HighSpeed TCP December 2003
[8ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
N(W) parallel TCP connections, where N(W) varies as a function of the congestion window W. Recall that for a single standard TCP connection, the average congestion window equals 1.2/sqrt(p). For N parallel TCP connections, the aggregate congestion window for the N connections equals N*1.2/sqrt(p). From the HighSpeed response function in Equation (1) and the relationship above, we can derive the following:
N(W)はTCP接続に沿います、N(W)が混雑ウィンドウの機能として単本位制TCP接続、平均した混雑ウィンドウのために1.2/sqrt(p)と等しいW.Recallを変えるところで。 N平行なTCP接続のために、N接続のための集合混雑ウィンドウはN*1.2/sqrt(p)と等しいです。 Equation(1)のHighSpeedレスポンス関数と関係から、上では、私たちが以下を引き出すことができます:
N(W) = 0.23*W^(0.4)
N(W)は0.23*W^と等しいです。(0.4)
for N(W) the number of parallel TCP connections emulated by the HighSpeed TCP response function, and for N(W) >= 1. This is shown in Table 4 below.
N(W)に関しては、平行なTCP接続の数はHighSpeed TCPレスポンス関数、およびN(W)>のために=1を見習いました。 これは以下のTable4に示されます。
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
平行なTCPsの混雑ウィンドウW数のN(W)------------------- ------------------------- 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: HighSpeed 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パケットのために真剣にHighSpeedレスポンス関数を評価するのを試みません。 私たちは、私たちが数千の混雑ウィンドウと何万ものパケットでHighSpeed TCPの、より多くの経験をするのに従ってその範囲のベストエフォート型接続に関するスループットを支えるための要件に関してもう少し学ぶつもりであると信じています。 また、現実的にベストエフォート型交通に達成できる1接続あたりのスループットへの制限があるかもしれません、パケットか以上の何十万の混雑ウィンドウに関して、経路に沿ったルータからの追加的支援かフィードバックがないとき。
6. Fairness Implications of the HighSpeed Response Function
6. HighSpeedレスポンス関数の公正含意
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つのレスポンス関数を使用することで流れの間の相対的な公正を推論するのに直接StandardとHighspeed Response Functionsを使用できます。 例えば、パケット低下率Pを考えて、Standard TCPにはW_Standardの平均した混雑ウィンドウがあると仮定してください。そうすれば、HighSpeed TCPはW_HighSpeedの、より高い平均した混雑ウィンドウを持っています。
Floyd Experimental [Page 9] RFC 3649 HighSpeed TCP December 2003
[9ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
この場合、単独のHighSpeed TCP接続はaに関するスループットが同じ環境に参加するStandard TCP接続を選抜するというW_HighSpeed/W_Standard回数を受けています。
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.
この相対的な公正はTable5で以下で例証されます、上のセクションのHighspeedレスポンス関数に使用されるパラメタのために。 第2コラムは最初のコラムで指定された定常状態パケット低下率のために相対的な公正を与えます。 較正するのを助けるために、第3コラムは2つのTCP接続のために総平均混雑ウィンドウを与えます、そして、第4コラムはその集合窓とパケット低下率を達成するために2つの接続によって必要とされる帯域幅を与えます、往復の100ms回と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
パケットのレートのP公正集合窓の低下帯域幅------------------ -------- ---------------- --------- 10 1.6Gbps10の45.9Mbps10の^-3 1.0 76 9.1Mbps10^-4 2.2 383^-5 4.7 2174 260.8Mbps10^-6 10.2 13479^-7 22.1 87776 10.5^-2 1.0 24 2.8Mbps10Gbps
Table 5: Relative Fairness between the HighSpeed and Standard Response Functions.
テーブル5: HighSpeedと標準の応答の間の相対的な公正は機能します。
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.
したがって、^-4、HighSpeedレスポンス関数に従った流れが受け取ると予想できる10のパケット低下率のために、Standard応答を使用する流れスループットの2.2倍は機能します、同じ往復の回とパケットサイズを考えて。 10^-6(または、10^-7)のパケット低下率に、不公平は、より厳しいです、そして、私たちはStandard TCP接続が利用可能な帯域幅を利用するために最も1つで往復の800(または、2530)回毎混雑出来事を必要とする政権に入りました。 私たちの判断は事実上、今日この政権で働いている多くのTCP接続がないということでしょう、何千ものパケットの混雑ウィンドウで、そして、したがって、HighSpeed応答の恩恵が機能するのがこの政権でStandard TCPによって経験される不公平を重いでしょう。 しかしながら、このドキュメントの1つの目的はこの問題のフィードバックに請求することです。 パラメタLow_Windowは直接StandardとHighSpeed Response Functionsの間の分岐のポイントを決定します。
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
Table5に関する第3コラム(Aggregate Window)は2つの競争しているTCP接続の集合混雑ウィンドウを与えます、HighSpeedとStandard TCPと共に、最初のコラムで指定されたパケット低下率を考えて。 Table5から、HighSpeed TCP接続は10^-6のパケット低下率で環境における、Standard TCPの帯域幅の10倍を得るでしょう。 2であるときに、これは起こるでしょう。
Floyd Experimental [Page 10] RFC 3649 HighSpeed TCP December 2003
[10ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
単一のパイプを共有する流れが13479のパケットの集合窓を実現しました。 100msの往復の時間と1500バイトのパケットサイズを考えて、これは1.6Gbpsの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.
次に、私たちは、先在のHighSpeed TCP流動に対して規格を取る時間かHighSpeed TCPが公正に一点に集める流れであると考えます。 公正への集合のための最悪の場合は、新しい流れが始動しています、高帯域存在流動に対して競争していて、新しい流れがパケット滴を受けるとき、起こって、窓はまだ小さいのですが、遅れた出発を出ます。 最悪の場合には、窓が1つのパケットにすぎませんが、新しい流れが輻輳回避フェーズに入ったと考えてください。 往復の時間、往復のN回がNパケットの窓を達成するだけであった(往復の1回目で1の窓から始まるとき)後に輻輳回避における標準のTCP流動は高々1つのパケットで窓を増加させます。 対照的に、HighSpeed TCPは輻輳回避フェーズにある間、標準のTCP流動よりはるかに速く流れます、そして、私たちは公正への集合がはるかに良いと予想できます。 これは以下のTable6に示されます。 Appendix 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
RTT HS_ウィンドウの標準の_のTCP_窓--- --------- ------------------- 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: 輻輳回避段階(RTT1の間、1つのパケットの混雑ウィンドウから始まる)の間のHighSpeedとStandard TCP接続、混雑ウィンドウに。
Floyd Experimental [Page 11] RFC 3649 HighSpeed TCP December 2003
[11ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
The classic paper on relative fairness is from Chiu and Jain [CJ89]. This paper shows that AIMD (Additive Increase Multiplicative Decrease) converges to fairness in an environment with synchronized congestion events. From [CJ89], it is easy to see that MIMD and AIAD do not converge to fairness in this environment. However, the results of [CJ89] do not apply to an asynchronous environment such as that of the current Internet, where the frequency of congestion feedback can be different for different flows. For example, it has been shown that MIMD converges to fair states in a model with proportional instead of synchronous feedback in terms of packet drops [GV02]. Thus, we are not concerned about abandoning a strict model of AIMD for HighSpeed TCP. However, we note that in an environment with Drop-Tail queue management, there is likely to be some synchronization of packet drops. In this environment, the model of completely synchronous feedback does not hold, but the model of completely asynchronous feedback is not accurate either. Fairness in Drop-Tail environments is discussed in more detail in Sections 9 and 12.
相対的な公正に関する古典的な紙はチウとジャイナ教の[CJ89]から来ています。 この論文は、AIMD(付加的なIncrease Multiplicative Decrease)が連動している混雑出来事で環境における公正に一点に集まるのを示します。 [CJ89]から、MIMDとAIADがこの環境における公正に一点に集まらないのがわかるのは簡単です。 しかしながら、[CJ89]の結果は異なった流れにおいて、混雑フィードバックの頻度が異なる場合がある現在のインターネットのものなどの非同期な環境に適用されません。 例えば、比例するのがパケット滴[GV02]に関する同期フィードバックの代わりにある状態でMIMDがモデルで公正な州に一点に集まるのが示されました。 したがって、私たちはHighSpeed TCPのためにAIMDの厳しいモデルをやめることに関して心配していません。 しかしながら、私たちは、Drop-テール待ち行列管理がある環境には、パケット滴の何らかの同期がありそうに注意します。 この環境で、完全に同期のフィードバックのモデルは成立しませんが、完全に非同期なフィードバックのモデルは正確ではありません。 さらに詳細にセクション9と12でDrop-テール環境における公正について議論します。
7. Translating the HighSpeed Response Function into Congestion Control
Parameters
7. HighSpeedレスポンス関数を混雑管理パラメータに翻訳します。
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混雑制御機構は上のHighSpeed Response Functionを使用できました。 しかしながら、TCPに関して、HighSpeedレスポンス関数は付加的な増加と乗法的な減少パラメタに翻訳されなければなりません。 TCPは丸い旅行時間あたり1つのセグメントの付加的な増加と現在の混雑ウィンドウを半分にする乗法的な減少でHighSpeedレスポンス関数を獲得できません。 HighSpeed TCPは増加か減少パラメタか両方のどちらかを変更しなければならないでしょう。 私たちは、HighSpeed 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:
すなわち、HighSpeed TCPに関して、混雑がないとき往復の時間あたりのa(w)セグメントで混雑窓の増加をさせてください、そして、混雑ウィンドウをwと減少させてください。(1回以上の損失出来事に伴う往復の時間に対応した1-b(w))セグメント。 したがって、ただ一つの承認に対応して、HighSpeed TCPは以下のセグメントで混雑ウィンドウを増加させます:
w <- w + a(w)/w.
w<w+a(w)/w。
In response to a congestion event, HighSpeed TCP decreases as follows:
混雑出来事に対応して、HighSpeed TCPは以下の通り減少します:
w <- (1-b(w))w.
w<(1-b(w))w。
Floyd Experimental [Page 12] RFC 3649 HighSpeed TCP December 2003
[12ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
Standard TCPに関しては、1とa(w)=b(w)はwの値にかかわらず1/2と等しいです。 HighSpeed TCPはa(w)の同じ値を使用します、そして、w<のためのb(w)は安値_Windowと等しいです。 このセクションはwの、より大きい値としてa(w)とb(w)をHighSpeed TCPに指定します。
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=高値_Windowとして、私たちはHigh_Pの損失率を指定しました。 [FRS02]、または、基本の計算から、これはw=高値_Windowのためにa(w)とb(w)との以下の関係を必要とします:
a(w) = High_Window^2 * High_P * 2 * b(w)/(2-b(w)). (2)
a(w)は高_Window^2*高値_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.
私たちはw=高値_Windowに減少パラメタb(w)を指定するのにパラメタHigh_Decreaseを使用します、そして、Equationを使用してください。(2) 増加を引き出すために、wのためのパラメタa(w)は高い_Windowと等しいです。 例えば、10の^-7とHigh_Window=High_P=83000と共に、私たちはHigh_Decrease=0.1を指定します、b(83000)が0.1と等しいと指定して、混雑出来事の後に10%の減少を与えて。 次に、方程式(2)はa(83000)=72を与えます、72のセグメント、またはちょうど0.1%未満の増加のために、往復の時以内に、w=83000のために。
This moderate decrease strikes us as acceptable, particularly when coupled with the role of TCP's ACK-clocking in limiting the sending rate in response to more severe congestion [BBFS01]. A more severe decrease would require a more aggressive increase in the congestion window for a round-trip time without congestion. In particular, a decrease factor High_Decrease of 0.5, as in Standard TCP, would require an increase of 459 segments per round-trip time when w = 83000.
この適度の減少は許容できると私たちに感じます、特により厳しい混雑[BBFS01]に対応して送付レートを制限することにおけるTCPのACK-時計の役割に結びつけられると。 より厳しい減少は往復の時間、混雑なしで混雑ウィンドウの、より攻撃的な増加を必要とするでしょう。 w=83000であるのに、特に、0.5の減少要素High_DecreaseはStandard TCPのように往復の時間あたり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=安値_Windowのためのb(w)=1/2の与えられた減少パラメタ、およびw=高値_Windowのためのb(w)=高値_Decrease、私たちがw>Low_Windowの他の値にb(w)の値を指定するのが残されます。 [FRS02]と、私たちは以下の通りwに関するログとしてb(w)を直線的に異ならせます:
b(w) = (High_Decrease - 0.5) (log(w)-log(W)) / (log(W_1)-log(W)) +
0.5,
b(w)が等しい、(高値_Decrease--0.5)((w)ログ(W))/を登録してください、((W_1)ログ(W))+0.5を登録してください。
for W = Low_window and W_1 = High_window. The increase parameter a(w) can then be computed as follows:
W=に関しては、低い_の窓とW_1は高い_の窓と等しいです。 パラメタa(w)缶を増加させてください、そして、次に、以下の通り計算されてください、:
a(w) = w^2 * p(w) * 2 * b(w)/(2-b(w)),
w^2*p(w)*2*b(w)a(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に評価します。 Equation(1)を逆にするのから、私たちはp(w)を以下の通りにします:
p(w) = 0.078/w^1.2.
p(w)は0.078/w^1.2と等しいです。
Floyd Experimental [Page 13] RFC 3649 HighSpeed TCP December 2003
[13ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
私たちは、さらなる調査のためのHighSpeed TCPの実験的な実現がa(w)とb(w)を見つけるのにあらかじめ計算されたルックアップテーブルを使用すると思います。 例えば、トムDuniganからの実現は0.1秒毎にa(w)とb(w)パラメタを調整します。 私たちがLow_Window=38のデフォルト値のためにそのようなテーブルを与える付録では、High_Window=8万3000、High_P=10^-7、およびHigh_Decreaseは0.1と等しいです。 また、これらはNSシミュレータのデフォルト値です。 ディレクトリtcl/テストにおける「NSでの例のシミュレーションはコマンド」 . /試しにオールtcpHighspeedとの走行であるかもしれません」。
8. An alternate, linear response functions
8. 交互の、そして、直線的な応答は機能します。
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.
このセクションでは、私たちは多くの他の人々によって提案されたHighSpeed TCPのために交互の、そして、直線的なレスポンス関数について調査します、特にグレンVinnicombeとトム・ケリー。 同様に、他のものによってHighSpeed 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.
私たちが38のMSSサイズのセグメントとしてLow_Windowの値を保つと仮定してください、私たちがHighSpeedレスポンス関数の上側の範囲を指定するHigh_WindowとHigh_Pパラメタを変更していなかったならHighSpeedレスポンス関数がいつ現在のTCPレスポンス関数からそれるかを示して。 特に、High_Window=380,000とHigh_Pによって与えられたレスポンス関数が従来と同様Low_Window=38とLow_P=10^-3で10^-7と等しいと考えてください。
Using the equations in Section 5, this would give the following Linear response function, for w > Low_Window:
セクション5の方程式を使用して、これはw>Low_Windowのために以下のLinearレスポンス関数を与えるでしょう:
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.
このLinear HighSpeedレスポンス関数は以下のTable7で例証されます。 HighSpeed TCPに関しては、損失の間の往復の回の数1/(pW)が同等に1/0.38と等しい、26 W>38セグメントのために。
Floyd Experimental [Page 14] RFC 3649 HighSpeed TCP December 2003
[14ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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
損失の間のパケット低下率Pの混雑ウィンドウW RTTs------------------ ------------------- ------------------- 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: HighSpeed TCPのための交互の、そして、直線的なTCPレスポンス関数。 パケット低下率Pの関数としてMSSサイズのセグメントの平均した混雑ウィンドウWを与えます。
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のa一定の減少b(w)を考えて、これがa(w)を増加に与えるだろう、Low_Windowと共に同等と、1/低い_Windowパケットのw>Low_Windowのための承認あたり1つの一定の増加。 別の可能性はScalable TCP[K03]です。(そのScalable TCPは1/8の固定減少b(w)と0.01の承認あたり1つの固定増加を使用します)。 これは0.005の窓あたりのa(w)に増加を与えます。遅れた承認があるTCP、純粋なMIMDのためのw。
The relative fairness between the alternate Linear response function and the standard TCP response function is illustrated below in Table 8.
交互のLinearレスポンス関数と標準のTCPレスポンス関数の間の相対的な公正はTable8で以下で例証されます。
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
パケットのレートのP公正集合窓の低下帯域幅------------------ -------- ---------------- --------- 10 60.0Mbps10の^-2 1.0 24 2.8Mbps10^-3 1.0 76 9.1Mbps10^-4 3.2 500^-5 15.1 4179 501.4Mbps10の^-6 31.6 39200 4.7Gbps10^-7 100.1 383795 46.0Gbps
Table 8: Relative Fairness between the Linear HighSpeed and Standard Response Functions.
テーブル8: 直線的なHighSpeedと標準の応答の間の相対的な公正は機能します。
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
直線的なレスポンス関数の1つのアトラクションはそれがスケール不変式であるということです、1承認あたりの混雑ウィンドウの固定増加、および損失出来事の間の往復の回の定数で。 私自身の仮定は往復の時代にパケット低下率にかかわらず混雑時代のための固定長を持つのが、さまざまな待ち行列管理メカニズムがあるルータがある不正確で不完全な世界に、貧しいフィットであるだろうということでしょう、今日一般的なDrop-テール待ち行列管理などのように。 例えば、a
Floyd Experimental [Page 15] RFC 3649 HighSpeed TCP December 2003
[15ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
response function with a fixed length for the congestion epoch in round-trip times might give less clearly-differentiated feedback in an environment with steady-state background losses at fixed intervals for all flows (as might occur with a wireless link with occasional short error bursts, giving losses for all flows every N seconds regardless of their sending rate).
往復の回による混雑時代が以下を与えるかもしれないので固定長があるレスポンス関数が明確に定期的にすべての流れることのための定常状態バックグラウンドの損失に伴う環境におけるフィードバックを微分した、(時々の短い誤り炸裂との無線のリンクで起こるかもしれないときすべてのための損失を与えるのが流れる、あらゆる、それらの送付レートにかかわらずN秒)
While it is not a goal to have perfect fairness in an environment with synchronized losses, it would be good to have moderately acceptable performance in this regime. This goal might argue against a response function with a constant number of round-trip times between congestion events. However, this is a question that could clearly use additional research and investigation. In addition, flows with different round-trip times would have different time durations for congestion epochs even in the model with a linear response function.
それは連動している損失と共に環境における完全な公正を持つ目標ではありませんが、この政権に適度に許容している性能を持っているのは良いでしょう。 混雑出来事の間には、定数の往復の倍がある状態で、この目標はレスポンス関数について反対の議論をするかもしれません。 しかしながら、これは明確に追加研究と調査を使用できた問題です。 さらに、いろいろな往復の時間がある流れは混雑時代に直線的なレスポンス関数があるモデルにさえ異なった時間持続時間を持っているでしょう。
The third column of Table 8, the Aggregate Window, gives the aggregate congestion window of two competing TCP connections, one with Linear HighSpeed TCP and one with Standard TCP, given the packet drop rate specified in the first column. From Table 8, a Linear HighSpeed TCP connection would receive fifteen times the bandwidth of a Standard TCP in an environment with a packet drop rate of 10^-5. This would occur when the two flows sharing a single pipe achieved an aggregate window of 4179 packets. Given a round-trip time of 100 ms and a packet size of 1500 bytes, this would occur with an available bandwidth for the two competing flows of 501 Mbps. Thus, because the Linear HighSpeed TCP is more aggressive than the HighSpeed TCP proposed above, it also is less fair when competing with Standard TCP in a high-bandwidth environment.
Table8に関する第3コラム(Aggregate Window)は2つの競争しているTCP接続、Linear HighSpeed TCPがある1、およびStandard TCPがある1の集合混雑ウィンドウを与えます、最初のコラムで指定されたパケット低下率を考えて。 Table8から、Linear HighSpeed TCP接続は10^-5のパケット低下率で環境における、Standard TCPの帯域幅の15倍を得るでしょう。 単一のパイプを共有する2回の流れが4179のパケットの集合窓を実現したとき、これは起こるでしょう。 100msの往復の時間と1500バイトのパケットサイズを考えて、これは501Mbpsの2回の競争している流れのための利用可能な帯域幅で起こるでしょう。 したがって、Linear HighSpeed TCPがHighSpeed TCPが上で提案したより攻撃的であるので、また、高帯域環境でStandard TCPと競争するとき、それも、より公正ではありません。
9. Tradeoffs for Choosing Congestion Control Parameters
9. 混雑管理パラメータを選ぶための見返り
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.
HighSpeed TCPのための混雑管理パラメータのための選択を評価するのにさまざまな測定基準を使用できます。 このセクションの私の仮定は考えられる唯一のレスポンス関数がc/pフォームwのレスポンス関数=^d、定数cと解説者dのための、d<1/2<==1があるレスポンス関数であるということです。 このスペクトルの2つの終わりがd=1/2がある現在のTCPとd=1による上のセクション8で説明された直線的なレスポンス関数によって表されます。 HighSpeed TCPが中央のどこかにスペクトル、d=0.835でいます。
Response functions with exponents less than 1/2 can be eliminated from consideration because they would be even worse than standard TCP in accommodating connections with high congestion windows.
彼らは標準のTCPより高い混雑ウィンドウとの接続を収容するのにおいてさらに悪いでしょう、したがって、考慮から解説者1/2があるレスポンス関数を排除できます。
Floyd Experimental [Page 16] RFC 3649 HighSpeed TCP December 2003
[16ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
9.1. The Number of Round-Trip Times between Loss Events
9.1. 損失出来事の間の往復の回の数
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を排除できるより偉大な状態で応答は機能します。 c/p w=^dのレスポンス関数、1回の損失出来事か混雑出来事によるあらゆる1/pパケットに関しては、損失出来事の間の往復の回の数はw^((1/d)-1)/c^(1/d)です。 したがって、標準のTCPに関して、損失出来事の間の往復の回の数はwで直線的です。 対照的に、上のセクション8で説明される直線的なレスポンス関数の1つのアトラクションはそれがスケール不変であるということです、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があるレスポンス関数において、損失出来事の間の丸い旅行時間の数はw^((1/d)-1)に比例しているでしょう、負の指数((1/d)-1)のために、wが増加するのに従って、より小さくセットして。 これは望ましくなく思えるでしょう。
9.2. The Number of Packet Drops per Loss Event, with Drop-Tail
9.2. 低下テールがある損失出来事あたりのパケット滴の数
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接続は往復の時間あたりのa(w)パケットで送付レートを増加させます、そして、Drop-テール環境で、これはa(w)をもたらすのが単一の損失出来事の間、パケットを落とした傾向があります。 標準のTCPの1つのアトラクションはそれには1つのパケットの往復の時間あたり1つの固定増加があるということです、Drop-テール環境で落とされるパケットの数を最小にして。 Active Queue Managementの何らかのフォームがある環境、および特に電子証券取引ネットワークを使用する環境のために、単一の混雑出来事で落とされたパケットの数は問題でないでしょう。 しかしながら、これらの環境でさえ、往復の時間あたりの送付レートの、より大きい増加は変動を吸収する待ち行列のルータにおける、能力で、より大きい圧力をもたらします。
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.
HighSpeed TCPは損失出来事の間の適度の数の往復の回の測定基準と、往復の時間あたりの送付レートの適度の増加の間の妥協点をプレーします。 Appendix Bに8万3000のパケットの混雑ウィンドウに示されるように、HighSpeed TCPは往復の時間あたり70のパケットで送付レートを増加させます、バッファがDrop-テール環境であふれると70パケット滴を高々もたらして。 この増加する攻撃性はHighSpeed TCPによって支払われた増加するスケーラビリティの価格です。 混雑出来事単位で落とされた多くのパケットが複数の流れからの連動している低下をもたらすかもしれません、その結果、スループットの可能な損失で。
Floyd Experimental [Page 17] RFC 3649 HighSpeed TCP December 2003
[17ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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)にあります。 8万3000のパケットの混雑ウィンドウに関しては、これは往復の時間あたり415のパケットの増加を与えます、Drop-テール環境で混雑出来事あたりおよそ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.)
したがって、HighSpeed TCPとその異形場所はStandard TCPに比例してルータにおける待ち行列管理で要求を増加させました。 (これはそれが生じる待ち行列管理の単独のStandard TCP接続の代わりにN平行なTCP接続を使用する需要増とかなり同様です。)
10. Related Issues
10. 関連問題
10.1. Slow-Start
10.1. 遅れた出発
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.
「大きい混雑WindowsがあるTCPのための株式会社の遅れた出発」[F02b]の仲間インターネットドラフトは大きい混雑ウィンドウまでの遅い始めのTCP接続の性能をかなり向上させることができるTCPの遅いスタート手順への変更を提案します。 MSSサイズのセグメントの数千(または、何万)の混雑ウィンドウを使用できるTCP接続、(MSS、送付者のMAXIMUM SEGMENT SIZE)、現在の遅れた出発手順はただ一つの往復の時間で何千ものセグメントで混雑ウィンドウを増加させるのに結果として生じることができます。 そのような増加は往復の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]は株式会社Slow-始めを提案します、混雑ウィンドウは遅れた出発の間にデータの1つの窓に増加させられるセグメントの数を制限して、大きい混雑ウィンドウとのTCP接続のために性能を向上させるために。 私たちは、Standardか両方の、HighSpeed TCPと共にそれを使用できるので、株式会社Slow-始めを別々の草稿に分離しました。
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".
「株式会社Slow-始めはNSシミュレータで例証されます、2002年5月1日以降スナップのために、テスト」 . /試しにオールtcpHighspeed tcp1Aで」「tcl/リブ」というサブディレクトリの」 . /試しにオールtcpHighspeed tcpHighspeed1"。
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
例えば、将来の高帯域ネットワークで安全に遅い始めより速く立ち上げるベストエフォート型流れにおいて整然とします、私たちは流れが経路に沿ってルータからの明白なフィードバックを持つのが必要であると信じています。 これのための多くの提案があります、TCP SYNパケットが経路に沿って許容初期の送付レート[J02]に関してルータから情報を集めることができるIPオプションのための最小量の提案から変化して、より多くのパワーがあるルータから、より微調整されて連続したフィードバックを必要とする提案に。 これら
Floyd Experimental [Page 18] RFC 3649 HighSpeed TCP December 2003
[18ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
提案がこのドキュメントにおけるHighSpeed TCP提案よりすべていくらかさらに長い期間の提案であり、展開のために、より長い間先行時間と、より多くのコーディネートを必要として、後のドキュメントで議論するでしょう。
10.2. Limiting burstiness on short time scales
10.2. 短いタイムスケールでburstinessを制限します。
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.
HighSpeed TCP接続によって実現された混雑ウィンドウがかなり大きいかもしれないので、送付者がただ一つの承認に対応してパケットの大きい炸裂を送る可能性があります。 混雑か再命令が逆の経路にあるとき、例えば、これは起こることができました、そして、送付者は数百か何千もの新しいパケットを承認しながら、承認を受けます。 また、アプリケーションが短期間の間、往復の時間よりそれほど活動していなく、次に、突然送るために利用可能な多くのデータを持っているなら、そのような炸裂は結果として生じるでしょうに。 この場合、HighSpeed 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].
本書では、私たちは短期的なburstinessを減少させるのにTCPメカニズムを指定しません。 別の可能性は1台の可能なメカニズムが何らかのフォームのレートベースのペースを使用することであり、maxburstを使用することです。(maxburstはただ一つの承認に対応して送られるパケットの数を制限します)。 しかしながら、私たちは短期的な炸裂を制限するためのメカニズムとして混雑ウィンドウでの永久的な減少に対して警告するでしょう。 そのようなメカニズムはいくつかのTCPスタックで配備されました、そして、私たちの視点は一時的な炸裂を減少させるのに混雑ウィンドウの永久的な減少を使用するのが、悪い考え[Fl03]であるだろうということでしょう。
10.3. Other limitations on window size
10.3. ウィンドウサイズにおける他の制限
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ビットの分野を使用します。 変更されていなくて、これは高々16 = 65 2**Kバイトのウィンドウサイズを許容します。 窓が比例して、最大のウィンドウサイズは*2*30 = 1073Mバイト[RFC1323]です。 1500年のバイトのパケットを考えて、これは最大71万5000のパケットの窓を許容します。
10.4. Implementation issues
10.4. 導入問題
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.
HighSpeed TCPと共に提起されたある導入問題はパケットが落とされた後に4MB以上の混雑ウィンドウで、連続したSACKパケットの取り扱いがTCPで送付者[S03]を消費しながらまさしくその時間になるということです。 トム・ケリーのScalable TCPはこのその問題を訴える「袋の高速経路」パッチを含んでいます。
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].
TCPと共に高帯域データ信号速度を達成するのに必要な調律に関するWeb100プロジェクトで記述された問題、Net100プロジェクト、および関連するプロジェクトはまた、HighSpeed TCP[Net100、Web100]に申請されます。
Floyd Experimental [Page 19] RFC 3649 HighSpeed TCP December 2003
[19ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
11. Deployment issues
11. 展開問題
11.1. Deployment issues of HighSpeed TCP
11.1. HighSpeed TCPの展開問題
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へのHighSpeed TCP変更が高帯域環境のための最適のトランスポート・プロトコルであると主張しません。 シミュレーション研究[SA03]の上と、そして、NSシミュレータ[NS]と、実験レポートの上のHighSpeed TCP[ABLLS03、D02、CC03、F03]の私たちの経験に基づいて、私たちは、HighSpeed TCPが高帯域環境における、TCPの性能を向上させると信じています、そして、IETF共同体の利益のためにそれを記録しています。 私たちはHighSpeed 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.
私たちは、現在のインターネットの大部分の典型の環境で、HighSpeed TCPが今日ちょうどStandard 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
帯域幅Avg Cwnd w(pkts)はa(w)減少b(w)を増加させます。--------- ----------------- ------------- ------------- 1.5 1Mbps12.5 1 0.50 10Mbps83 0.50 100Mbps833 6 0.35 1Gbps8333 26 0.22 10Gbps83333 70 0.10
Table 9: Performance of a HighSpeed TCP connection
テーブル9: HighSpeed 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.
そのTCP接続がすべてそれ自体に一服やって、リンク帯域幅を完全に使用したなら、較正するのを助けるために、Table9は、1500年のバイトのパケットとのTCP接続、競争している交通、および100ms(平均した待ち行列遅れを含んでいる)のRTTではなく、ショーが平均した混雑ウィンドウであると考えます、パイプのためのさまざまな帯域幅に。 これは、TCP接続が増加を決定する際にTable12を使用して、パラメタを減少させると仮定します。 Table9の最初のコラムは帯域幅を与えます、そして、第2コラムはwが利用する必要があった平均した混雑ウィンドウにその帯域幅を与えます。 第3コラムはセグメントの1RTTあたりのa(w)に窓wに増加を示しています。 第4コラムはその窓wに減少b(w)を示しています。(w(損失出来事の後の1-b(w))セグメント)によってTCP送付者が混雑ウィンドウを減少させるところ。 損失が発生すると私たちが、実際の混雑ウィンドウがコラム2で平均した混雑ウィンドウwよりすばらしい傾向があることに注意するので、使用される減少パラメタはTable9に関するコラム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
が不在のときテーブル9は、10Mbpsリンクの上のHighSpeed TCPがまさにStandard TCP接続として同じように振る舞うのを示します、同等である。
Floyd Experimental [Page 20] RFC 3649 HighSpeed TCP December 2003
[20ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.)
競争している交通。 人は一般に、55〜110のセグメントの範囲にいる混雑ウィンドウを考えることができます、HighSpeed TCPの振舞いがまさにStandard TCPの動きと同じ状態で。 (かつて混雑ウィンドウが128以上のセグメントであるなら、HighSpeed TCPは1の代わりに1RTTあたり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).
100Mbpsの上のHighSpeed TCP接続のために競争している交通なしでリンクされるテーブル9ショー、HighSpeed TCPはおよそ6がTCP接続に沿うのと同じくらい積極的に振る舞います、往復の時間、およびおよそ1/3(損失出来事に対応して半分にというよりむしろ古い混雑ウィンドウの2/3-rdsまで減少すると対応する)の減少パラメタによると、およそ6つのセグメントで混雑ウィンドウを増加させて。
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.
この環境におけるStandard TCP接続において、一般に、2.2*10^-6(1.8*10^-10のしばらく誤り率に対応する)の平均したパケット低下率がある550〜1100のセグメントの範囲、または同等に異なると混雑ウィンドウを考えることができました、混雑出来事の間のおよそ55秒。 Standard TCP接続がそのような低パケット低下率に最小量の競争している交通に伴う慎重に制御された環境を支持できた間、私たちは、少量の競争している交通を伴う非制御のベストエフォート型環境で、より小さい競争している流れからの時々の混雑出来事が100underutilized Mbpsの利用可能な帯域幅を完全に利用するのからの下側のスピードボトルネックリンクなしでStandard 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リンクの環境で、Standard TCPがリンク帯域幅を時々完全に利用できないで、HighSpeed TCPがこの点で改良であると主張するでしょう。 私たちは、この環境で、HighSpeed TCPの動きがStandard TCPのものの十分近くでは、そのHighSpeed TCPが現在のインターネットで展開するために安全であるだろうということであるとさらに主張するでしょう。 私たちは、受信機の広告を出しているウィンドウサイズによって許容されている場合にだけHighSpeed TCPが高い混雑ウィンドウを使用できることに注意します。 その結果、HighSpeed TCPがインターネットで遍在して配備されたとしても、衝撃は、広告を出している窓で118MSSの受信機からそれらの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.
私たちは、HighSpeed TCPの展開がブロックとして高速輻輳制御のための交互の実験プロトコルの可能な展開に機能すると信じていません、Scalable TCP、XCP[KHR02]、またはFAST TCP[JWL03]などのように。 特に、私たちは、今日HighSpeed TCPが不在のとき一般的に使用されているN平行なTCP接続を予想するだろうよりHighSpeed TCPがそれ以上代替の実験的な提案で不十分に相互作用すると予想しません。
Floyd Experimental [Page 21] RFC 3649 HighSpeed TCP December 2003
[21ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
11.2. Deployment issues of Scalable TCP
11.2. Scalable 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.
私たちは、Scalable TCPとHighSpeed TCPがインターネットにそれらが容易にそうすることができた十分同様のレスポンス関数を共存させると信じています。 しかしながら、私たちはScalable TCPを現在のインターネットでの広範囲の展開に、Scalable 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
帯域幅Avg Cwnd w(pkts)はa(w)減少b(w)を増加させます。--------- ----------------- ------------- ------------- 1.5は1 12.5 0.50 10Mbps83 0.4 0.125 100Mbps833 4.1に0.125 1Gbps8333 41.6 0.125 10のGbps83333 416.5 0.125をMbpsします。
Table 10: Performance of a Scalable TCP connection.
テーブル10: Scalable 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.
100ms(平均した待ち行列遅れを含んでいる)のRTTを示しますが、テーブル10は1500年のバイトのパケットとのScalable TCP接続に関する実績、どんな競争している交通も示していません。 使用する接続が思われるTCPは承認を遅らせました。 Table10の最初のコラムが帯域幅を与えて、第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.
10Mbpsリンクがある環境においてさえ、Scalable TCPの振舞いがStandard TCPのものとかなり異なっていることに注意してください。 パラメタはStandard TCPのものより小さいです、そして、減少は、より小さいです。増加、1/2の代わりに1/8番目も。 すなわち、10個のMbpsリンクに関しては、Scalable TCPはそれほどStandard TCPかHighSpeed TCPより積極的でなく増加しませんが、それほど積極的でなくまた、減少しません。
In an environment with a 100 Mbps link, Scalable TCP has an increase parameter of roughly four segments per round-trip time, with the same decrease parameter of 1/8-th. A comparison of Tables 9 and 10 shows that for this scenario of 100 Mbps links, HighSpeed TCP increases more aggressively than Scalable TCP.
100Mbpsリンクがある環境で、Scalable TCPはおよそ4つのセグメントの往復の時間あたりのパラメタに増加を持っています、1/8番目の同じ減少パラメタで。 Tables9と10の比較は、100個のMbpsリンクのこのシナリオのために、HighSpeed TCPがScalable 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
次に、私たちはStandard TCPと、HighSpeed TCPとScalable TCPの間の相対的な公正を考えます。 HighSpeed TCPとStandard TCPの間の相対的な公正は、より早くTable5に本書では示されました、そして、Scalable TCPとStandard TCPの間の相対的な公正はTable8に示されました。 セクション6でアプローチに続いて、与えられたパケット低下率p、p<10^3のために、私たちは_W_Scalable/W HighSpeedとしてScalableとHighSpeed TCPの間の相対的な公正を見積もることができます。 この相対的な公正は以下のTable11に示されます。 Table11に関する最後のコラムにおける帯域幅は集合です。
Floyd Experimental [Page 22] RFC 3649 HighSpeed TCP December 2003
[22ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
bandwidth of the two competing flows given 100 ms round-trip times and 1500-byte packets.
2回の競争している流れ与えられた往復の100ms回と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 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
パケットのレートのP公正集合窓の低下帯域幅------------------ -------- ---------------- --------- 10 ^-4 1.4 643 77.1Mbps10^-5 2.1 5595 671.4Mbps10^-6 3.1 50279 6.0Gbps10^-7 4.5 463981 55.7^-2 1.0 24 2.8Mbps10^-3 1.0 76 9.1Mbps10Gbps
Table 11: Relative Fairness between the Scalable and HighSpeed Response Functions.
テーブル11: スケーラブル、そして、HighSpeedレスポンス関数の間の相対的な公正。
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.
100ms RTTsと10Mbpsと共に環境に参加するScalable TCPとHighSpeed TCP流動のために運ばれる2番目の列のTable11ショー、2回の流れが本質的には同じ帯域幅を受けるでしょう。 100ms RTTsと100Mbpsと共に環境に参加するScalable TCPとHighSpeed TCP流動のために運ばれる次の列のショー、Scalable TCP流動はHighSpeed TCPを受けるだろうよりおよそ50%さらに多くの帯域幅を受けるでしょう。 テーブル11はまた、より高い帯域幅環境における相対的な公正を示しています。 この親類公正は十分に見えます。TCPのExperimental異形と同じ環境で共存しているというScalable TCPとHighSpeed 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.
私たちは、Scalable TCPとの、より多くの調査を必要とする1つの質問が環境における公正へのDrop-テール待ち行列管理による集合のものであることに注意します。
12. Related Work in HighSpeed TCP
12. HighSpeed TCPでの関連仕事
HighSpeed TCP has been separately investigated in simulations by Sylvia Ratnasamy and by Evandro de Souza [SA03]. The simulations in [SA03] verify the fairness properties of HighSpeed TCP when sharing a link with Standard TCP.
シルヴィアRatnasamyとEvandro deスザによるシミュレーション[SA03]でHighSpeed TCPは別々に調査されました。 Standard TCPとのリンクを共有するとき、[SA03]でのシミュレーションはHighSpeed 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.
Standard TCPと競争するとき、これらのシミュレーションはHighSpeed TCP流れの相対的な公正について調査します。 シミュレーション環境は前方にバックグラウンドを含んでいます、そして、TCPによって制限された逆経路TCP交通は窓を受けます、ウェブ・トラフィックジェネレータからの少量の前進の、そして、逆経路の交通と共に。 シミュレーションの大部分は今までのところ、走行である原稿Simulationsが持っている50の伝播遅延との1個のGbpsリンクでAdaptive REDとDropTail待ち行列管理で簡単なダンベルトポロジーに関する性能を探ります。
Floyd Experimental [Page 23] RFC 3649 HighSpeed TCP December 2003
[23ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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である競争している交通で。 すべてのHighSpeed TCP。 または、規格とHighSpeed TCPのミックス。 [SA03]でのRED待ち行列管理によるシミュレーションにおいて、規格とHighSpeed TCPの間の相対的な公正はTable5で予測される相対的な公正と一致しています。 Drop Tail待ち行列によるシミュレーションにおいて、相対的な公正はさらに歪曲されています、HighSpeed TCP流れがリンク帯域幅のさらに大きいシェアを受けていて。 これは驚くべきものではありません。 混雑しているリンクのActive Queue Managementと共に、各流れによって受け取られたパケット滴の部分はその流れのリンク帯域幅のシェアにおよそ比例しているべきです、この特性がもうDrop Tail待ち行列管理に賛成しませんが。 また、私たちは、Drop Tail待ち行列管理によるシミュレーションにおける相対的な公正を時々シミュレーションシナリオの小さい詳細に依存できて、Drop Tailシミュレーションがフェーズ効果[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.
他のN標準のTCP流れを競争するとき、[SA03]は標準のTCPからN標準のTCP流れが受けるリンク帯域幅の部分を探ることによって、HighSpeed TCPによって'盗まれた'帯域幅を探検します、そして、N HighSpeed TCPを競争するときN標準のTCP流れが受けるリンク帯域幅の部分とこれを比較するのは流れます。 シナリオが長命の交通で支配した1つのGbpsシミュレーションにおいて、少ない数の標準のTCP流れが高いリンク利用を達成できます、そして、競争している標準のTCPから帯域幅を盗むのが流れるとき、HighSpeed TCP流れは見ることができます、HighSpeed Response FunctionのFairness Implicationsでセクション6で予測されるように。 しかしながら、[SA03]は、リンク帯域幅のわずかな部分さえより多くのbursty、背の低いTCP接続によって使用されて、標準のTCP流れが高いリンク利用を達成できないで、この場合、HighSpeed 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]の結論は「HighSpeed TCPは、forseenとしてレスポンス関数で振る舞って、高速広い領域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.
新しい流れが始動した後に探検できた今後の活動はさらに詳細に集合時間を含んでいます。 一時的な供給停止の後の回復時間。 突然の厳しい混雑への応答、および振動の可能性の調査。 私たちは他のものからこの仕事で原稿を募ります。
Floyd Experimental [Page 24] RFC 3649 HighSpeed TCP December 2003
[24ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
13. Relationship to other Work
13. 他の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.
私たちの仮定はHighSpeed TCPがTCP SACKオプション、および3か4つのセグメントの増加するInitial Windowと共にも使用されるということです、[RFC3390]によって許容されているように。 かなりの再命令を持っている経路において、再命令されたパケットがあるとき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.
私たちの視点はHighSpeed TCPが、より高いPMTU(経路MTU)値[M02]のための提案と主に直交しているということです。 PMTUへの変化と異なって、HighSpeed TCPはネットワークかTCP受信機で少しの変化も必要としないで、現在のインターネットでうまくいきます。 私たちの仮定はHighSpeed TCPが、より大きい値があってもPMTUの役に立つだろうということです。 現在の混雑ウィンドウと異なって、PMTUは帯域幅遅れ製品の情報を全くその特定の流れに利用可能に教えません。
A related approach is that of a virtual MTU, where the actual MTU of the path might be limited [VMSS,S02]. The virtual MTU approach has not been fully investigated, and we do not explore the virtual MTU approach further in this document.
関連するアプローチは経路の実際のMTUが制限されるかもしれない[VMSS、S02]ところの仮想のMTUのものです。 仮想のMTUアプローチは完全に調査されるというわけではありませんでした、そして、私たちはさらに本書では仮想のMTUアプローチについて調査しません。
14. Conclusions
14. 結論
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.
このドキュメントはHighSpeed TCP(大きい混雑ウィンドウとのTCP接続による使用のためのTCPの混雑制御機構への変更)を提案しました。 私たちはシミュレーションにおけるこの提案を探りました、そして、他のものは実験でHighSpeed TCPを探検しました、そして、HighSpeed TCPが現在のインターネットで展開するために安全であると信じています。 私たちは追加分析、シミュレーション、および特に実験を歓迎するでしょう。 シミュレーションと実験の詳しい情報はHighSpeed TCPウェブページ[HSTCP]から利用可能です。 HighSpeed TCP[D02、F03]とさらなる調査のためのScalable TCP[K03]のいくつかの独立している実現があります。
15. Acknowledgements
15. 承認
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
HighSpeed TCP提案はシルヴィアRatnasamyとスコットShenker(そして、スコットShenkerが開始された)との共同作業から来ています。 HighSpeed TCPの追加調査はEvandro deスザとDeb Agarwalとの共同作業でした。 私たちがリナックスにおける実現についてトムDuniganに感謝する、2.4.16Web100カーネル、HighSpeed TCPとの結果として起こる実験 私たちはEndから終わりへのResearch Group、Transport Area作業部会のメンバーと、そして、フィードバックのためのLarge Scale Communication NetworksのIPAMプログラムのメンバーに感謝しています。 私たちは、HighSpeed TCPのパラメタのLinearレスポンス関数を縁どって頂いて、グレンVinnicombeに感謝します。 また、私たちも感謝しています。
Floyd Experimental [Page 25] RFC 3649 HighSpeed TCP December 2003
[25ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
以下の個人からの貢献とフィードバック: レス・コットレル、ミッチェルErblich、ジェフリー・シュー、トム・ケリー、チャック・ジャクソン、マット・マシス、Jitendra Padhye、アンドリューReiter、スタニスラフShalunov、アレックスSolan、ポールサター、ブライアン・ティアニー、ジョーは触れます。
16. Normative References
16. 引用規格
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
17. Informative References
17. 有益な参照
[ABLLS03] A. Antony, J. Blom, C. de Laat, J. Lee, and W. Sjouw,
"Microscopic Examination of TCP Flows over Transatlantic
Links", iGrid2002 special issue, Future Generation
Computer Systems, volume 19 issue 6 (2003), URL
"http://www.science.uva.nl/~delaat/techrep-2003-2-
tcp.pdf".
[ABLLS03]A.アントニウス、J.ブロム、C.de Laat、J.リー、およびW.Sjouw、「TCPの顕微鏡検査は大西洋横断のリンクの上に流れます」、iGrid2002増刊、Future Generationコンピュータシステムズ、ボリューム19号6(2003)、「 http://www.science.uva.nl/~delaat/techrep-2003-2- tcp.pdf」というURL。
[BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott
Shenker, "Dynamic Behavior of Slowly-Responsive Congestion
Control Algorithms", SIGCOMM 2001, August 2001.
フロイド、およびスコットShenker、「ゆっくり敏感な輻輳制御アルゴリズムの動的挙動」を[BBFS01]Deepak Bansal、ハーリBalakrishnanは出撃させます、SIGCOMM2001、2001年8月。
[CC03] Fabrizio Coccetti and Les Cottrell, "TCP Stack
Measurements on Lightly Loaded Testbeds", 2003. URL
"http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/".
[CC03]のファブリジオCoccettiとレス・コットレル、「軽く積み込まれたテストベッドに関するTCPスタック測定値」、2003。 URL" http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ "。
[CJ89] D. Chiu and R. Jain, "Analysis of the Increase and
Decrease Algorithms for Congestion Avoidance in Computer
Networks", Computer Networks and ISDN Systems, Vol. 17,
pp. 1-14, 1989.
[D.チウの、そして、R.ジャイナ教のCJ89と「コンピュータネットワークにおける輻輳回避のための増加と減少アルゴリズムの分析」とコンピュータNetworksとISDN Systems、Vol.17、ページ 1-14, 1989.
[CO98] J. Crowcroft and P. Oechslin, "Differentiated End-to-end
Services using a Weighted Proportional Fair Share TCP",
Computer Communication Review, 28(3):53--69, 1998.
[CO98] J.クロウクロフトとP.Oechslin、「終わりから終わりに対する荷重している比例しているフェアを使用する微分されたサービスがTCPを共有します」、コンピュータコミュニケーションレビュー、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]トムDuniganと、「フロイドのTCP遅れた出発とAIMDモッズ」、URL" http://www.csm.ornl.gov/~dunigan/net100/floyd.html "。
[F03] Gareth Fairey, "High-Speed TCP", 2003. URL
"http://www.hep.man.ac.uk/u/garethf/hstcp/".
[F03]ギャレス・フェアリ、「高速TCP」、2003。 URL" http://www.hep.man.ac.uk/u/garethf/hstcp/ "。
[F92] S. Floyd and V. Jacobson, "On Traffic Phase Effects in
Packet-Switched Gateways, Internetworking: Research and
Experience", V.3 N.3, September 1992, p.115-156. URL
"http://www.icir.org/floyd/papers.html".
[F92] S.フロイドとV.ジェーコブソン、「交通では、パケットで切り換えられたゲートウェイ、インターネットワーキングにおける効果の位相を合わせてください」 V.3 N.3、1992年9月「研究とExperience」、p.115-156。 URL" http://www.icir.org/floyd/papers.html "。
Floyd Experimental [Page 26] RFC 3649 HighSpeed TCP December 2003
[26ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
[Fl03] Sally Floyd, "Re: [Tsvwg] taking NewReno (RFC 2582) to
Proposed Standard", Email to the tsvwg mailing list, May
14, 2003.
[Fl03]Sallyフロイド、「Re:」 「NewReno(RFC2582)をProposed Standardに連れて行く[Tsvwg]」、tsvwgメーリングリストへのメール、2003年5月14日。
URLs "http://www1.ietf.org/mail-archive/working-
groups/tsvwg/current/msg04086.html" and
"http://www1.ietf.org/mail-archive/working-
groups/tsvwg/current/msg04087.html".
URLの「 http://www1.ietf.org/mail-archive/working- グループ/tsvwg/電流/msg04086.html」と「 http://www1.ietf.org/mail-archive/working- グループ/tsvwg/電流/msg04087.html。」
[FF98] Floyd, S., and Fall, K., "Promoting the Use of End-to-End
Congestion Control in the Internet", IEEE/ACM Transactions
on Networking, August 1999.
[FF98] K. フロイド、S.と秋、ネットワーク(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".
「高速のためのTCPの輻輳制御を変更し」て、[FRS02]は2002年5月にフロイド、シルヴィアRatnasamy、およびスコットShenkerを出撃させます。 URL" http://www.icir.org/floyd/notes.html "。
[GRK99] Panos Gevros, Fulvio Risso and Peter Kirstein, "Analysis
of a Method for Differential TCP Service". In Proceedings
of the IEEE GLOBECOM'99, Symposium on Global Internet ,
December 1999, Rio de Janeiro, Brazil.
[GRK99] パノスGevrosとフルビオRissoとピーター・カースタイン、「特異なTCPサービスのための方法の分析。」 IEEE GLOBECOM'99、Globalインターネット、1999年12月、リオデジャネイロ、ブラジルのSymposium'のProceedingsで。
[GV02] S. Gorinsky and H. Vin, "Extended Analysis of Binary
Adjustment Algorithms", Technical Report TR2002-39,
Department of Computer Sciences, The University of Texas
at Austin, August 2002. URL
"http://www.cs.utexas.edu/users/gorinsky/pubs.html".
[GV02] S.GorinskyとH.ヴィン、「2進の調整アルゴリズムの拡張解析」、技術報告書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ウェブページ、URL" http://www.icir.org/floyd/hstcp.html "。
[J02] Amit Jain and Sally Floyd, "Quick-Start for TCP and IP",
Work in Progress, 2002.
[J02] 「TCPとIPのためのクィックスタート」というAmitジャイナ教徒とSallyフロイドは進歩、2002年に働いています。
[JWL03] Cheng Jin, David X. Wei and Steven H. Low, "FAST TCP for
High-speed Long-distance Networks", Work in Progress, June
2003.
「高速長距離のネットワークのための速いTCP」という[JWL03]チェン・チン、デヴィッド・X.ウェイ、およびスティーブンH.安値は進行中(2003年6月)で働いています。
[K03] Tom Kelly, "Scalable TCP: Improving Performance in
HighSpeed Wide Area Networks", February 2003. URL
"http://www-lce.eng.cam.ac.uk/~ctk21/scalable/".
[K03]トム・ケリー、「スケーラブルなTCP:」 2003年2月の「HighSpeedワイドエリアネットワークにおける性能を向上させます。」 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] ダイナKatabi、マークハンドレー、およびCharlieレールス、「高帯域遅れ製品ネットワークのための輻輳制御」、SIGCOMM2002。
[M02] Matt Mathis, "Raising the Internet MTU", Web Page, URL
"http://www.psc.edu/~mathis/MTU/".
[M02]マット・マシス、「インターネットMTUを上げます」、ウェブページ、" http://www.psc.edu/~mathis/MTU/ "というURL。
Floyd Experimental [Page 27] RFC 3649 HighSpeed TCP December 2003
[27ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
[Net100] The DOE/MICS Net100 project. URL
"http://www.csm.ornl.gov/~dunigan/net100/".
[Net100] ドウ/MICS Net100は突出しています。 URL" http://www.csm.ornl.gov/~dunigan/net100/ "。
[NS] The NS Simulator, "http://www.isi.edu/nsnam/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.
[RFC1323] ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC3390] Allman, M., Floyd, S. and C., Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC3390] オールマンとM.とフロイドとS.とC.、ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、2002年10月。
[RFC3448] Handley, M., Padhye, J., Floyd, S. and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC
3448, January 2003.
[RFC3448] ハンドレー、M.、Padhye、J.、フロイド、S.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[SA03] Souza, E. and D.A., Agarwal, "A HighSpeed TCP Study:
Characteristics and Deployment Issues", LBNL Technical
Report LBNL-53215. URL
"http://www.icir.org/floyd/hstcp.html".
[SA03]スザ、E.、およびD.A.、Agarwal、「HighSpeed 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]スタニスラフShalunov、「TCPアーモンク」が進歩、2002、" http://www.internet2.edu/~shalunov/tcpar/ "というURLで働いています。
[S03] Alex Solan, private communication, 2003.
[S03] アレックスSolan、私信、2003。
[VMSS] "Web100 at ORNL", Web Page,
"http://www.csm.ornl.gov/~dunigan/netperf/web100.html".
[VMSS] 「ORNLのWeb100」、ウェブページ、" 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/ "。
18. Security Considerations
18. セキュリティ問題
This proposal makes no changes to the underlying security of TCP.
この提案はTCPの基本的なセキュリティへの変更を全く行いません。
19. IANA Considerations
19. IANA問題
There are no IANA considerations regarding this document.
このドキュメントに関するIANA問題が全くありません。
Floyd Experimental [Page 28] RFC 3649 HighSpeed TCP December 2003
[28ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
このセクションはTCP流動のためにD-バイトパケットと共に混雑出来事の間の往復の回の数を与えます、D=1500であるときに、ビーピーエスにおける、接続の平均したスループットBの関数として。 この平均したスループット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と等しいと、これは高々無くなっている出来事に同等です。旅行時間を一周させてください。 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.
0.1Rのための例=秒と1500D=バイト、これは往復のB/180000回を損失出来事の間に与えます。
Floyd Experimental [Page 29] RFC 3649 HighSpeed TCP December 2003
[29ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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.
このセクションはHighSpeed TCPのための減少パラメタの増加のためのテーブル、a(w)、およびb(w)に与えます、Low_Window=38、High_Window=83000、High_P=10^-7、およびHigh_Decrease=0.1のデフォルト値のために。
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
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
Floyd Experimental [Page 30] RFC 3649 HighSpeed TCP December 2003
[30ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
19965 41 0.17
21013 42 0.17
22101 43 0.17
23230 44 0.17
24402 45 0.16
25618 46 0.16
26881 47 0.16
28193 48 0.16
29557 49 0.15
30975 50 0.15
32450 51 0.15
33986 52 0.15
35586 53 0.14
37253 54 0.14
38992 55 0.14
40808 56 0.14
42707 57 0.13
44694 58 0.13
46776 59 0.13
48961 60 0.13
51258 61 0.13
53677 62 0.12
56230 63 0.12
58932 64 0.12
61799 65 0.12
64851 66 0.11
68113 67 0.11
71617 68 0.11
75401 69 0.10
79517 70 0.10
84035 71 0.10
89053 72 0.10
94717 73 0.09
19965 41 0.17 21013 42 0.17 22101 43 0.17 23230 44 0.17 24402 45 0.16 25618 46 0.16 26881 47 0.16 28193 48 0.16 29557 49 0.15 30975 50 0.15 32450 51 0.15 33986 52 0.15 35586 53 0.14 37253 54 0.14 38992 55 0.14 40808 56 0.14 42707 57 0.13 44694 58 0.13 46776 59 0.13 48961 60 0.13 51258 61 0.13 53677 62 0.12 56230 63 0.12 58932 64 0.12 61799 65 0.12 64851 66 0.11 68113 67 0.11 71617 68 0.11 75401 69 0.10 79517 70 0.10 84035 71 0.10 89053 72 0.10 94717 73 0.09
Table 12: Parameters for HighSpeed TCP.
テーブル12: HighSpeed TCPのためのパラメタ。
Floyd Experimental [Page 31] RFC 3649 HighSpeed TCP December 2003
[31ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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 ++;
}
最高=100000ドル。 num=38ドル。 (num=38ドル)である、「w a(w) b(w)\n」を印刷してください; 印刷してください、「------------\n」;が印刷する、「38 1 0.50円のn」; $oldbは0.50と等しいです; olda=1ドル、($num<$先端)です。等しい..ログ..ログ..登録..ログ..等しい..等しい
Table 13: Perl Program for computing parameters for HighSpeed TCP.
テーブル13: HighSpeed TCPのためのパラメタを計算するためのPerl Program。
Floyd Experimental [Page 32] RFC 3649 HighSpeed TCP December 2003
[32ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
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 ++;
}
最高=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) -(aw<1ドル)であるなら(38)) /((83000)ログ(38))+0.5を登録してください; $awは(hswin**2ドルの*2.0*$bw)/(2.0ドルのbw)と*hswin**1.2*12.8ドル等しい)を登録してください。「$bwが(0.1 -0.5)*と等しい、(($hswin)を登録してください、aw=1ドル; ($rtt>=$lastrtt+$rttstep)が$lastrttが$rttと等しいという」 %5d%9d%10d0、$rtt、$hswin$regwinをprintfするなら、$hswin+は$awと等しいです;、regwin+=1ドル($rtt++)
Table 14: Perl Program for computing the window in congestion avoidance.
テーブル14: 輻輳回避で窓を計算するためのPerl Program。
Author's Address
作者のアドレス
Sally Floyd ICIR (ICSI Center for Internet Research)
サリーフロイドICIR(インターネット調査のためのICSIセンター)
Phone: +1 (510) 666-2989 EMail: floyd@acm.org URL: http://www.icir.org/floyd/
以下に電話をしてください。 +1 (510) 666-2989 メールしてください: floyd@acm.org URL: http://www.icir.org/floyd/
Floyd Experimental [Page 33] RFC 3649 HighSpeed TCP December 2003
[33ページ]RFC3649HighSpeed TCP2003年12月に実験的なフロイド
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Floyd Experimental [Page 34]
フロイドExperimentalです。[34ページ]
一覧
スポンサーリンク
