[要約] RFC 3742は、大きな輻輳ウィンドウを持つTCPに対して制限付きのスロースタートを提案しています。その目的は、ネットワークの過負荷を回避しながら、高速なデータ転送を実現することです。
Network Working Group S. Floyd
Request for Comments: 3742 ICSI
Category: Experimental March 2004
Limited Slow-Start for TCP with Large Congestion Windows
大規模な混雑ウィンドウを備えたTCPの制限されたスロースタート
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document describes an optional modification for TCP's slow-start for use with TCP connections with 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. This note describes Limited Slow-Start as an optional mechanism for 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.
このドキュメントでは、TCPのスロースタートのオプションの変更が、大規模な渋滞ウィンドウを使用したTCP接続で使用するためのスロースタートについて説明しています。数千（または数万）のMSSサイズのセグメント（MSSの最大セグメントサイズ）の渋滞ウィンドウを使用できるTCP接続の場合、現在のスロースタート手順により、数千のセグメントだけ輻輳ウィンドウが増加する可能性があります。1回の往復時間で。このような増加により、1回の往復時間で数千のパケットが削除される可能性があります。これは多くの場合、TCPフロー自体にとって逆効果であり、残りのトラフィックが混雑したリンクを共有することでも困難です。このメモでは、Limited Slow-Startは、大規模な混雑ウィンドウを使用したTCP接続のパフォーマンスを改善するために、スロースタート中の1つのデータウィンドウの輻輳ウィンドウが増加するセグメントの数を制限するためのオプションのメカニズムとして説明しています。
This note describes an optional modification for TCP's slow-start for use with TCP connections with 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. This note describes 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.
このメモは、大規模な渋滞ウィンドウを使用したTCP接続で使用するためのTCPのスロースタートのオプションの変更について説明しています。数千（または数万）のMSSサイズのセグメント（MSSの最大セグメントサイズ）の渋滞ウィンドウを使用できるTCP接続の場合、現在のスロースタート手順により、数千のセグメントだけ輻輳ウィンドウが増加する可能性があります。1回の往復時間で。このような増加により、1回の往復時間で数千のパケットが削除される可能性があります。これは多くの場合、TCPフロー自体にとって逆効果であり、残りのトラフィックが混雑したリンクを共有することでも困難です。このメモでは、限られたスロースタートについて説明し、大規模な渋滞ウィンドウを使用したTCP接続のパフォーマンスを改善するために、スロースタート中の1つのデータウィンドウの輻輳ウィンドウが増加するセグメントの数を制限します。
When slow-start results in a large increase in the congestion window in one round-trip time, a large number of packets might be dropped in the network (even with carefully-tuned active queue management mechanisms in the routers). This drop of a large number of packets in the network can result in unnecessary retransmit timeouts for the TCP connection. The TCP connection could end up in the congestion avoidance phase with a very small congestion window, and could take a large number of round-trip times to recover its old congestion window. This poor performance is illustrated in [F02].
スロースタートの結果、1回の往復時間で混雑ウィンドウが大幅に増加すると、ネットワークに多数のパケットがドロップされる可能性があります（ルーターで慎重に調整されたアクティブキュー管理メカニズムがあっても）。ネットワーク内の多数のパケットをドロップすると、TCP接続の不必要な再送信タイムアウトが発生する可能性があります。TCP接続は、非常に小さな輻輳ウィンドウを使用して輻輳回避段階に終わる可能性があり、古い輻輳ウィンドウを回復するために多数の往復時間がかかる可能性があります。このパフォーマンスの低下は[F02]に示されています。
Limited Slow-Start introduces a parameter, "max_ssthresh", and modifies the slow-start mechanism for values of the congestion window where "cwnd" is greater than "max_ssthresh". That is, during Slow-Start, when
Limited Slow-Startは、「MAX_SSTHRESH」というパラメーターを導入し、「CWND」が「MAX_SSSTHRESH」よりも大きい混雑ウィンドウの値のスロースタートメカニズムを変更します。つまり、スロースタート中、いつです
cwnd <= max_ssthresh,
cwnd <= max_ssthresh、
cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every arriving ACK (acknowledgement) during slow-start, as is always the case. During Limited Slow-Start, when
常にそうであるように、CWNDは、スロースタート中に到着するすべてのACK（承認）に対して1つのMSS（最大セグメントサイズ）によって増加します。制限されたスロースタート中、いつ
max_ssthresh < cwnd <= ssthresh,
max_ssthresh <cwnd <= ssthresh、
the invariant is maintained so that the congestion window is increased during slow-start by at most max_ssthresh/2 MSS per round-trip time. This is done as follows:
不変は維持され、スロースタート中に往復中に最大のMAX_SSTHRESH/2ミリ秒あたり2ミリ秒が増加するようになります。これは次のように行われます。
For each arriving ACK in slow-start:
If (cwnd <= max_ssthresh)
cwnd += MSS;
else
K = int(cwnd/(0.5 max_ssthresh));
cwnd += int(MSS/K);
Thus, during Limited Slow-Start the window is increased by 1/K MSS for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of by 1 MSS as in standard slow-start [RFC2581].
したがって、制限されたスロースタート中に、標準のスロースタート[RFC2581]のように、k = int（cwnd/（0.5 max_ssthresh）ではなく、k = int（cwnd/（0.5 max_ssthresh））の場合、到着するACKごとにウィンドウが1/kmss増加します。
When
いつ
ssthresh < cwnd,
ssthresh <cwnd、
slow-start is exited, and the sender is in the Congestion Avoidance phase.
スロースタートが終了し、送信者はうっ血回避段階にあります。
Our recommendation would be for max_ssthresh to be set to 100 MSS. (This is illustrated in the NS [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". Setting max_ssthresh to Infinity causes the TCP connection in NS not to use Limited Slow-Start.)
私たちの推奨事項は、MAX_SSTHRESHが100ミリ秒に設定されることです。（これは、2002年5月1日以降のスナップショットのNS [NS]シミュレーターに示されています。テスト「./test-all-tcphighspeed tcp1a」および「./test-all-tcphighspeed tcphighspeed1」tcl/"tcl/lib "。max_sSthreshにインフィニティに設定すると、NSのTCP接続が制限されていないスロースタートを使用しません。）
With Limited Slow-Start, when the congestion window is greater than max_ssthresh, the window is increased by at most 1/2 MSS for each arriving ACK; when the congestion window is greater than 1.5 max_ssthresh, the window is increased by at most 1/3 MSS for each arriving ACK, and so on.
スロースタートが制限されている場合、輻輳ウィンドウがmax_sSthreshよりも大きい場合、到着するACKごとにウィンドウが最大1/2ミリ秒増加します。輻輳ウィンドウが1.5 max_sSthreshを超えると、到着するACKなど、最大1/3 MSSなど、ウィンドウが増加します。
With Limited Slow-Start it takes:
スロースタートが制限されていると、次の時間がかかります。
log(max_ssthresh)
log（max_ssthresh）
round-trip times to reach a congestion window of max_ssthresh, and it takes:
往復時間max_sSthreshの混雑ウィンドウに到達するには、次のようになります。
log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)
round-trip times to reach a congestion window of cwnd, for a congestion window greater than max_ssthresh.
MAX_SSTHRESHよりも大きい混雑ウィンドウの場合、CWNDの混雑ウィンドウに到達するための往復時間。
Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it would take 836 round-trip times to reach a congestion window of 83,000 packets, compared to 16 round-trip times without Limited Slow-Start (assuming no packet drops). With Limited Slow-Start, the largest transient queue during slow-start would be 100 packets; without Limited Slow-Start, the transient queue during Slow-Start would reach more than 32,000 packets.
したがって、MAX_SSSHRESHを100ミリ秒に設定したスロースタートが制限されているため、スロースタートが制限されていない（パケットドロップがないと仮定する）16回の往復時間と比較して、83,000個のパケットのうっ血ウィンドウに到達するには836回の往復時間がかかります。スロースタートが限られているため、スロースタート中の最大の一時的なキューは100個のパケットになります。スロースタートが限られていないため、スロースタート中の一時的なキューは32,000を超えるパケットに到達します。
By limiting the maximum increase in the congestion window in a round-trip time, Limited Slow-Start can reduce the number of drops during slow-start, and improve the performance of TCP connections with large congestion windows.
往復時間で輻輳ウィンドウの最大増加を制限することにより、スロースタートが制限されていると、スロースタート中のドロップ数が減り、大きな混雑ウィンドウでのTCP接続のパフォーマンスが向上します。
Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 kernel, and performed experiments comparing TCP with and without Limited Slow-Start [D02]. Results so far show improved performance for TCPs using Limited Slow-Start. There are also several experiments comparing different values for max_ssthresh.
Tom DuniganはLinux 2.4.16 Web100カーネルに制限されたスロースタートを追加し、Slow-Start [D02]との有無にかかわらずTCPを比較した実験を実施しました。これまでの結果、限られたスロースタートを使用したTCPのパフォーマンスの向上を示しています。また、MAX_SSTHRESHの異なる値を比較するいくつかの実験もあります。
There has been considerable research on mechanisms for the TCP sender to learn about the limitations of the available bandwidth, and to exit slow-start before receiving a congestion indication from the network [VEGAS,H96]. Other proposals set TCP's slow-start parameter ssthresh based on information from previous TCP connections to the same destination [WS95,G00]. This document proposes a simple limitation on slow-start that can be effective in some cases even in the absence of such mechanisms. The max_ssthresh parameter does not replace ssthresh, but is an additional parameter. Thus, Limited Slow-Start could be used in addition to mechanisms for setting ssthresh.
TCP送信者が利用可能な帯域幅の制限について学び、ネットワークから鬱血指示を受ける前にスロースタートを終了するメカニズムに関するかなりの研究がありました[Vegas、H96]。その他の提案は、以前のTCP接続から同じ宛先[WS95、G00]への情報に基づいて、TCPのスロースタートパラメーターSSthreshを設定しました。このドキュメントは、そのようなメカニズムがない場合でも場合によっては効果的であるスロースタートに関する簡単な制限を提案しています。MAX_SSTHRESHパラメーターはSSThreshを置き換えるのではなく、追加のパラメーターです。したがって、SSthreshを設定するためのメカニズムに加えて、限られたスロースタートを使用できます。
Rate-based pacing has also been proposed to improve the performance of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that rate-based pacing could be of significant benefit, and could be used in addition to the Limited Slow-Start in this proposal.
また、スロースタート[VH97、AD98、KCRP99、ASA00]中にTCPのパフォーマンスを改善するために、レートベースのペーシングも提案されています。レートベースのペーシングは大きな利益をもたらす可能性があり、この提案の制限されたスロースタートに加えて使用できると考えています。
Appropriate Byte Counting [RFC3465] proposes that TCP increase its congestion window as a function of the number of bytes acknowledged, rather than as a function of the number of ACKs received. Appropriate Byte Counting is largely orthogonal to this proposal for Limited Slow-Start.
適切なバイトカウント[RFC3465]は、TCPが、受け取ったACKの数の関数としてではなく、認識されているバイト数の関数として輻輳ウィンドウを増加させることを提案しています。適切なバイトカウントは、限られたスロースタートのこの提案の主に直交しています。
Limited Slow-Start is also orthogonal to other proposals to change mechanisms for exiting slow-start. For example, FACK TCP includes an overdamping mechanism to decrease the congestion window somewhat more aggressively when a loss occurs during slow-start [MM96]. It is also true that larger values for the MSS would reduce the size of the congestion window in units of MSS needed to fill a given pipe, and therefore would reduce the size of the transient queue in units of MSS.
制限されたスロースタートは、スロースタートを終了するためのメカニズムを変更する他の提案にも直交しています。たとえば、FACK TCPには、スロースタート中に損失が発生した場合、輻輳ウィンドウを積極的に減少させるためのオーバーダンプメカニズムが含まれています[MM96]。また、MSSの値が大きくなると、特定のパイプを埋めるために必要なMSSユニットの輻輳ウィンドウのサイズが縮小され、したがってMSSの単位の過渡キューのサイズが縮小することも事実です。
This proposal is part of a larger proposal for HighSpeed TCP for TCP connections with large congestion windows, and resulted from simulations done by Evandro de Souza, in joint work with Deb Agarwal. This proposal for Limited Slow-Start draws in part from discussions with Tom Kelly, who has used a similar modified slow-start in his own research with congestion control for high-bandwidth connections. We also thank Tom Dunigan for his experiments with Limited Slow-Start.
この提案は、Deb Agarwalとの共同作業におけるEvandro de Souzaが行ったシミュレーションに起因する、大規模な渋滞ウィンドウとのTCP接続のための高速TCPのより大きな提案の一部です。限られたスロースタートのこの提案は、高帯域幅接続のためのうっ血制御を伴う彼自身の研究で同様の修正されたスロースタートを使用したトム・ケリーとの議論から部分的に描かれています。また、スロースタートが限られている実験については、Tom Duniganに感謝します。
We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End Research Group, and members of the Transport Area Working Group, for feedback on this document.
この文書に関するフィードバックについては、エンドツーエンドの研究グループのメンバーであるReiner LudwigのAndrei Gurtov、Reiner Ludwig、およびTransport Area Working Groupのメンバーに感謝します。
This proposal makes no changes to the underlying security of TCP.
この提案は、TCPの根本的なセキュリティに変更を加えません。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465] Allman、M。、「適切なバイトカウント（ABC）を備えたTCP混雑制御」、RFC 3465、2003年2月。
[AD98] Mohit Aron and Peter Druschel, "TCP: Improving Start-up Dynamics by Adaptive Timers and Congestion Control"", TR98-318, Rice University, 1998. URL "http://cs-tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98- 318/".
[AD98] Mohit AronとPeter Druschel、「TCP：適応タイマーと混雑制御によるスタートアップダイナミクスの改善」、TR98-318、ライス大学、1998年。URL "http://cs-tr.cs.rice.edu/dienst/ui/2.0/describe/ncstrl.rice_cs/tr98-318/"。
[ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the Performance of TCP Pacing", Proceedings of the 2000 IEEE Infocom Conference, Tel-Aviv, Israel, March, 2000. URL "http://www.cs.ucsd.edu/~savage/".
[ASA00] A. Aggarwal、S。Savage、およびT. Anderson、「TCP Pacingのパフォーマンスの理解」、2000 IEEE Infocom Conference、Tel-Aviv、イスラエル、2000年3月の議事録。URL "http：// www.cs.ucsd.edu/〜savage/"。
[D02] T. Dunigan, "Floyd's TCP slow-start and AIMD mods", 2002. URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html".
[D02] T. Dunigan、「フロイドのTCPスロースタートとAIMD MODS」、2002。URL「http://www.csm.ornl.gov/~dunigan/net100/floyd.html」。
[F02] S. Floyd, "Performance Problems with TCP's Slow-Start", 2002. URL "http://www.icir.org/floyd/hstcp/slowstart/".
[F02] S. Floyd、「TCPのスロースタートのパフォーマンスの問題」、2002年。URL「http://www.icir.org/floyd/hstcp/slowstart/」。
[G00] A. Gurtov, "TCP Performance in the Presence of Congestion and Corruption Losses", Master's Thesis, University of Helsinki, Department of Computer Science, Helsinki, December 2000. URL "http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html".
[G00] A. Gurtov、「混雑と腐敗の損失の存在下でのTCPパフォーマンス」、マスターの論文、ヘルシンキ大学、ヘルシンキ、ヘルシンキ学科、2000年12月。/u/gurtov/papers/ms_thesis.html "。
[H96] J. C. Hoe, "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", SIGCOMM 96, 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".
[H96] J. C. Hoe、「TCPの混雑制御スキームのスタートアップ動作の改善」、Sigcomm 96、1996。URL「http://www.acm.org/sigcomm/sigcomm96/program.html」。
[KCRP99] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A Simulation Study of Paced TCP", BBN Technical Memorandum No. 1218, 1999. URL "http://www.ir.bbn.com/documents/techmemos/index.html".
[KCRP99] J. Kulik、R。Coulter、D。Rockwell、およびC. Partridge、「Paced TCPのシミュレーション研究」、BBNテクニカルメモ1218、1999。URL「http：//www.ir.bbn。com/documents/techmemos/index.html "。
[MM96] M. Mathis and J. Mahdavi, "Forward Acknowledgment: Refining TCP Congestion Control", SIGCOMM, August 1996.
[MM96] M. MathisおよびJ. Mahdavi、「フォワード認識：TCP混雑制御の改良」、Sigcomm、1996年8月。
[NS] The Network Simulator (NS). URL "http://www.isi.edu/nsnam/ns/".
[NS]ネットワークシミュレーター（NS）。url "http://www.isi.edu/nsnam/ns/"。
[VEGAS] Vegas Web Page, University of Arizona. URL "http://www.cs.arizona.edu/protocols/".
[ベガス]アリゾナ大学ベガスのWebページ。url "http://www.cs.arizona.edu/protocols/"。
[VH97] Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing for TCP", 1997. URL "http://www.isi.edu/lsam/publications/rate_based_pacing/".
[VH97] Vikram VisweswaraiahとJohn Heidemann、「TCPのレートベースのペーシング」、1997。URL「http://www.isi.edu/lsam/publications/rate_based_pacing/ "。
[WS95] G. Wright and W. Stevens, "TCP/IP Illustrated", Volume 2, Addison-Wesley Publishing Company, 1995.
[WS95] G.ライトとW.スティーブンス、「TCP/IP Illustrated」、第2巻、Addison-Wesley Publishing Company、1995。
Authors' Address
著者の住所
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSIセンターのインターネット研究）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。