Network Working Group M. Handley
Request for Comments: 2861 J. Padhye
Category: Experimental S. Floyd
ACIRI
June 2000
TCP Congestion Window Validation
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.
TCPの輻輳ウィンドウは、TCPフローがいつでもネットワークを持っているかもしれパケットの数を制御します。輻輳ウィンドウは、もはやネットワークの状態に関する最新の情報を反映しているという点で、しかし、送信者がアイドルやアプリケーションが限定されている長い期間は、輻輳ウィンドウの無効化につながることはできません。この文書では、輻輳ウィンドウの前の値についての情報を保存するために、スロースタートしきい値SSTHRESHを使用しながら、十分に長いアプリケーションが制限された期間からの移行後の輻輳ウィンドウcwndのを減衰するTCPの輻輳制御アルゴリズムに簡単な修正を説明しています。
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD.
輻輳ウィンドウは、輻輳ウィンドウの前の値が十分に活用されていない決してかもしれないアプリケーションが制限された期間中（すなわち、TCPのスロースタートや輻輳回避フェーズで）増加した場合、無効な輻輳ウィンドウにもなります。私たちは、TCPの送信者がTCP送信者は、アプリケーションが限定されてきたときの輻輳ウィンドウを増やすべきではない（したがって、完全に現在の輻輳ウィンドウを使用していない）ことを提案しています。私たちは、シミュレーションととFreeBSDでの実装から実験との両方これらのアルゴリズムを模索しています。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [B97].
彼らは、この文書に表示される[B97]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. The congestion window is set using an Additive-Increase, Multiplicative-Decrease (AIMD) mechanism that probes for available bandwidth, dynamically adapting to changing network conditions. This AIMD mechanism works well when the sender continually has data to send, as is typically the case for TCP used for bulk-data transfer. In contrast, for TCP used with telnet applications, the data sender often has little or no data to send, and the sending rate is often determined by the rate at which data is generated by the user. With the advent of the web, including developments such as TCP senders with dynamically-created data and HTTP 1.1 with persistent-connection TCP, the interaction between application-limited periods (when the sender sends less than is allowed by the congestion or receiver windows) and network-limited periods (when the sender is limited by the TCP window) becomes increasingly important. More precisely, we define a network-limited period as any period when the sender is sending a full window of data.
TCPの輻輳ウィンドウは、TCPフローがいつでもネットワークを持っているかもしれパケットの数を制御します。輻輳ウィンドウは動的に変化するネットワーク条件に適応する、利用可能な帯域幅のためのプローブ添加剤増加乗法-減少（AIMD）メカニズムを使用して設定されています。一般的にバルク・データ転送に使用するTCPの場合のように、送信者が継続的に、送信するデータを持っている場合は、このAIMDメカニズムがうまく機能します。これとは対照的に、telnetのアプリケーションで使用するTCPのために、データの送信者は、多くの場合、送信するためにほとんど、あるいはまったくデータを持っており、送信レートは、多くの場合、データはユーザによって生成される速度によって決定されます。こうした動的に作成されたデータと永続的接続のTCPとHTTP 1.1とTCPの送信者として開発を含むウェブの登場、と、アプリケーションが制限された期間の間の相互作用（送信者が未満を送る輻輳や受信機の窓によって許可されています） （送信者がTCPウィンドウによって制限されている）とネットワークが制限された期間がますます重要になってきます。より正確には、私たちは、送信者は、データの完全なウィンドウを送信している任意の期間として、ネットワーク制限期間を定義します。
Long periods when the sender is application-limited can lead to the invalidation of the congestion window. During periods when the TCP sender is network-limited, the value of the congestion window is repeatedly "revalidated" by the successful transmission of a window of data without loss. When the TCP sender is network-limited, there is an incoming stream of acknowledgements that "clocks out" new data, giving concrete evidence of recent available bandwidth in the network. In contrast, during periods when the TCP sender is application-limited, the estimate of available capacity represented by the congestion window may become steadily less accurate over time. In particular, capacity that had once been used by the network-limited connection might now be used by other traffic.
長い期間、送信者は、アプリケーションが制限された輻輳ウィンドウの無効化につながる可能性があります。 TCPの送信者がネットワーク限定で期間中、輻輳ウィンドウの値を繰り返し失うことなくデータの窓の送信成功によって「再検証」されます。 TCPの送信者がネットワーク限定された場合、確認応答の着信ストリームは、「クロックアウト」の新しいデータは、ネットワークの最近の利用可能な帯域幅の具体的な証拠を与えていることがあります。対照的に、TCP送信者は、アプリケーション制限である期間中に、輻輳ウィンドウによって表される利用可能な容量の推定値は、時間の経過と共に着実にそれほど正確になることができます。具体的には、一度ネットワークが制限された接続で使用されていた容量は現在、他のトラフィックによって使用される可能性があります。
Current TCP implementations have a range of behaviors for starting up after an idle period. Some current TCP implementations slow-start after an idle period longer than the RTO estimate, as suggested in [RFC2581] and in the appendix of [VJ88], while other implementations don't reduce their congestion window after an idle period. RFC 2581 [RFC2581] recommends the following: "a TCP SHOULD set cwnd to no more than RW [the initial window] before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout." A proposal for TCP's slow-start after idle has also been discussed in [HTH98]. The issue of validation of congestion information during idle periods has also been addressed in contexts other than TCP and IP, for example in "Use-it or Lose-it" mechanisms for ATM networks [J96,J95].
現在のTCP実装は、アイドル期間の後に起動させるための行動の範囲を持っています。いくつかの現在のTCP実装スロースタート他の実装がアイドル期間後に輻輳ウィンドウを縮小しませんが、[RFC2581]にし、[VJ88]の付録で提案されているようにRTO推定値よりも長いアイドル期間の後。 RFC 2581 [RFC2581]は以下のことをお勧めします。「TCPはTCPが再送タイムアウトを超える間隔でデータを送信していない場合は、送信を開始する前に、RW [初期画面]を超えないようにcwndを設定する必要があります。」アイドル後のTCPのスロースタートのための提案はまた、[HTH98]で議論されてきました。アイドル期間中の渋滞情報の検証の問題も、「使用それまたは失う - それを」ATMネットワークのためのメカニズム[J96、J95]で、たとえば、TCPとIP以外の文脈で解決されています。
To address the revalidation of the congestion window after a application-limited period, we propose a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period (i.e., at least one roundtrip time) to a network-limited period. In particular, we propose that after an idle period, the TCP sender should reduce its congestion window by half for every RTT that the flow has remained idle.
アプリケーションが制限された期間の後に輻輳ウィンドウの再検証に対処するために、我々は十分に長いアプリケーションが制限された期間（すなわち、少なくとも1往復からの移行後に輻輳ウィンドウcwndのを減衰するTCPの輻輳制御アルゴリズムに簡単な修正を提案しますネットワークが制限された期間までの時間）。特に、我々は、アイドル期間の後に、TCPの送信側がフローがアイドル状態のままであることを、すべてのRTTのために半分にすることにより、その輻輳ウィンドウを減らすべきであると提案しています。
When the congestion window is reduced, the slow-start threshold ssthresh remains as "memory" of the recent congestion window. Specifically, ssthresh is never decreased when cwnd is reduced after an application-limited period; before cwnd is reduced, ssthresh is set to the maximum of its current value, and half-way between the old and the new values of cwnd. This use of ssthresh allows a TCP sender increasing its sending rate after an application-limited period to quickly slow-start to recover most of the previous value of the congestion window. To be more precise, if ssthresh is less than 3/4 cwnd when the congestion window is reduced after an application-limited period, then ssthresh is increased to 3/4 cwnd before the reduction of the congestion window.
輻輳ウィンドウが減少すると、スロースタートしきい値SSTHRESHは、最近の輻輳ウィンドウの「メモリ」のままです。具体的には、SSTHRESHはCWNDがアプリケーション制限期間の後に低下したときに減少されることはありません。 cwndが減少する前に、SSTHRESHは、古いものとのcwndの新しい値の間、現在の値の最大値、および途中に設定されています。 SSTHRESHの使用はすぐにスロースタートが輻輳ウィンドウの前の値のほとんどを回復するためにアプリケーションが制限された期間の後にその送信レートを上げるTCP送信することができます。 SSTHRESHが輻輳ウィンドウがアプリケーション制限期間の後に減少する未満3/4 CWNDがある場合に、より正確には、SSTHRESHは、輻輳ウィンドウの縮小前の3/4 CWNDに増加されます。
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. As far as we know, all current TCP implementations increase the congestion window when an acknowledgement arrives, if allowed by the receiver's advertised window and the slow-start or congestion avoidance window increase algorithm, without checking to see if the previous value of the congestion window has in fact been used. This document proposes that the window increase algorithm not be invoked during application-limited periods [MSML99]. In particular, the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). This restriction prevents the congestion window from growing arbitrarily large, in the absence of evidence that the congestion window can be supported by the network. From [MSML99, Section 5.2]: "This restriction assures that [cwnd] only grows as long as TCP actually succeeds in injecting enough data into the network to test the path."
輻輳ウィンドウは、輻輳ウィンドウの前の値が十分に活用されていない決してかもしれないアプリケーションが制限された期間中（すなわち、TCPのスロースタートや輻輳回避フェーズで）増加した場合、無効な輻輳ウィンドウにもなります。私たちが知る限りでは、確認応答が到着したときかどうかをチェックせずに、受信機の広告ウィンドウとスロースタートや輻輳回避窓の増加アルゴリズムで許可されていれば、現在のすべてのTCP実装は、輻輳ウィンドウを増やし輻輳ウィンドウの前の値実際に使用されてきました。この文書では、ウィンドウ増加アルゴリズムはアプリケーション限定期間[MSML99]中に呼び出されないことを提案しています。具体的には、TCP送信側は、TCP送信者はアプリケーション限られていた場合、輻輳ウィンドウを増やすべきではない（したがって、完全に現在の輻輳ウィンドウを使用していません）。この制限は、輻輳ウィンドウは、ネットワークでサポートできる証拠が存在しない場合に、任意の大きさに成長から輻輳ウィンドウを防ぐことができます。 [MSML99、セクション5.2]から：「この制限は、[cwndの]のみ限り、TCPが実際のパスをテストするために、ネットワークに十分なデータを注入することに成功したとして成長することを保証します。」
A somewhat-orthogonal problem associated with maintaining a large congestion window after an application-limited period is that the sender, with a sudden large amount of data to send after a quiescent period, might immediately send a full congestion window of back-to-back packets. This problem of sending large bursts of packets back-to-back can be effectively handled using rate-based pacing (RBP,
アプリケーション限られた期間の後に大きい輻輳ウィンドウを維持することに関連幾分直交問題は、休止期間後に送信するデータの突然の大量のある送信者は、直ちにバックツーバックの完全な輻輳ウィンドウを送信するかもしれないということですパケット。バックツーバックパケットの大バーストを送信するこの問題を効果的にレートベースペーシング（RBPを、使用して処理することができます
[VH97]), or using a maximum burst size control [FF96]. We would contend that, even with mechanisms for limiting the sending of back-to-back packets or pacing packets out over the period of a roundtrip time, an old congestion window that has not been fully used for some time can not be trusted as an indication of the bandwidth currently available for that flow. We would contend that the mechanisms to pace out packets allowed by the congestion window are largely orthogonal to the algorithms used to determine the appropriate size of the congestion window.
【VH97]）、または最大バーストサイズ制御を使用して[FF96]。私たちは完全にいくつかの時間のために使用されていない古い輻輳ウィンドウのように信頼することはできません、でも、往復時間の期間にわたってバックツーバックパケットの送信またはパケットをペーシングを制限するためのメカニズムと、それを争うだろうそのフローの現在利用可能な帯域幅を示します。私たちは、輻輳ウィンドウで許可されたパケットをペーシングするメカニズムは、輻輳ウィンドウの適切なサイズを決定するために使用されるアルゴリズムの大部分は直交していると主張するだろう。
When a TCP sender has sufficient data available to fill the available network capacity for that flow, cwnd and ssthresh get set to appropriate values for the network conditions. When a TCP sender stops sending, the flow stops sampling the network conditions, and so the value of the congestion window may become inaccurate. We believe the correct conservative behavior under these circumstances is to decay the congestion window by half for every RTT that the flow remains inactive. The value of half is a very conservative figure based on how quickly multiplicative decrease would have decayed the window in the presence of loss.
TCPの送信側がその流れ、CWNDとSSTHRESHために利用可能なネットワーク容量を満たすのに利用できる十分なデータを持っている場合は、ネットワークの状況に適した値に設定します。 TCPの送信側が送信を停止すると、流れは、ネットワークの状態をサンプリング停止し、その輻輳ウィンドウの値が不正確になることがあります。我々は、これらの状況下では、正しい保守的な行動は、フローが非アクティブのままであることをすべてのRTTのために半分に輻輳ウィンドウを減衰することであると信じています。半分の値が乗算減少は、損失の存在下で窓を減衰しているだろうどのように迅速に基づき、非常に保守的な数字です。
Another possibility is that the sender may not stop sending, but may become application-limited rather than network-limited, and offer less data to the network than the congestion window allows to be sent. In this case the TCP flow is still sampling network conditions, but is not offering sufficient traffic to be sure that there is still sufficient capacity in the network for that flow to send a full congestion window. Under these circumstances we believe the correct conservative behavior is for the sender to keep track of the maximum amount of the congestion window used during each RTT, and to decay the congestion window each RTT to midway between the current cwnd value and the maximum value used.
別の可能性は、送信側が送信を停止しないかもしれないということですが、アプリケーションが制限されたのではなく、ネットワーク制限になることがあり、および輻輳ウィンドウよりもネットワークに少ないデータを提供送信することができます。この場合、TCPフローは、まだネットワークの状態をサンプリングしているが、完全な輻輳ウィンドウを送信するために、その流れのためのネットワークに十分な容量がまだあることを確認するために十分なトラフィックを提供していません。このような状況下、我々は、送信者が各RTTの間に使用される輻輳ウィンドウの最大量を追跡するために、各RTTが現在のcwndの値と使用された最大値の中間にするために輻輳ウィンドウを減衰するための正しい保守的な行動があると信じています。
Before the congestion window is reduced, ssthresh is set to the maximum of its current value and 3/4 cwnd. If the sender then has more data to send than the decayed cwnd allows, the TCP will slow-start (perform exponential increase) at least half-way back up to the old value of cwnd.
輻輳ウィンドウが縮小される前に、SSTHRESHは、その電流値と3/4のcwndの最大値に設定されています。送信者は、その後減衰したcwndが許すよりも、送信するために多くのデータを持っている場合、TCPはスロースタートをします（指数関数的な増加を行う）少なくとも半分ウェイバックのcwndの古い値まで。
The justification for this value of "3/4 cwnd" is that 3/4 cwnd is a conservative estimate of the recent average value of the congestion window, and the TCP should safely be able to slow-start at least up to this point. For a TCP in steady-state that has been reducing its congestion window each time the congestion window reached some maximum value `maxwin', the average congestion window has been 3/4 maxwin. On average, when the connection becomes application-limited, cwnd will be 3/4 maxwin, and in this case cwnd itself represents the average value of the congestion window. However, if the connection happens to become application-limited when cwnd equals maxwin, then the average value of the congestion window is given by 3/4 cwnd.
「3/4のcwnd」のこの値の正当化は3/4にcwndが輻輳ウィンドウの最近の平均値の保守的な見積もりであることである、とTCPは、安全に、少なくともここまでのスロースタートすることができるはずです。 `maxwinその輻輳ウィンドウ輻輳ウィンドウは、いくつかの最大値に達し、各時間を短縮された定常状態におけるTCPの場合、平均輻輳ウィンドウは3/4 maxwinてきました。接続は、アプリケーション制限になったときに平均して、CWNDは3/4 maxwinとなり、この場合には、それ自体をcwndを輻輳ウィンドウの平均値を表します。 CWNDがmaxwin等しいとき、接続がアプリケーション制限になるために起こる場合は、その後、輻輳ウィンドウの平均値を3/4 CWNDによって与えられます。
An alternate possibility would be to set ssthresh to the maximum of the current value of ssthresh, and the old value of cwnd, allowing TCP to slow-start all of the way back up to the old value of cwnd. Further experimentation can be used to evaluate these two options for setting ssthresh.
別の可能性は、TCPバックのcwndの古い値までの道のすべてをスロースタートすることができ、SSTHRESHの現在値、およびCWNDの古い値の最大値にSSTHRESHを設定することです。さらなる実験は、SSTHRESHを設定するためのこれらの二つのオプションを評価するために使用することができます。
For the separate issue of the increase of the congestion window in response to an acknowledgement, we believe the correct behavior is for the sender to increase the congestion window only if the window was full when the acknowledgment arrived.
確認に応じて、輻輳ウィンドウの増加の別の問題のために、我々は正しい動作が確認応答が到着したときに、ウィンドウがいっぱいだった場合にのみ、輻輳ウィンドウを高めるために、送信者のためであると考えています。
We term this set of modifications to TCP Congestion Window Validation (CWV) because they are related to ensuring the congestion window is always a valid reflection of the current network state as probed by the connection.
それらは輻輳ウィンドウを確保することに関連しているので、我々は、TCP輻輳ウィンドウ検証（CWV）への変更のこのセットを名づける接続によってプローブとして常に現在のネットワークの状態の有効な反映です。
A key issue in the CWV algorithm is to determine how to apply the guideline of reducing the congestion window once for every roundtrip time that the flow is application-limited. We use TCP's retransmission timer (RTO) as a reasonable upper bound on the roundtrip time, and reduce the congestion window roughly once per RTO.
CWVアルゴリズムにおける重要な問題は、流れが、アプリケーション制限されているすべての往復時間に一度輻輳ウィンドウを減少させる指針を適用する方法を決定することです。私たちは、往復時間の合理的な上限として、TCPの再送タイマ（RTO）を使用し、RTOごとにおよそ一度輻輳ウィンドウを減らします。
This basic algorithm could be implemented in TCP as follows: When TCP sends a new packet it checks to see if more than RTO seconds have elapsed since the previous packet was sent. If RTO has elapsed, ssthresh is set to the maximum of 3/4 cwnd and the current value of ssthresh, and then the congestion window is halved for every RTO that elapsed since the previous packet was sent. In addition, T_prev is set to the current time, and W_used is reset to zero. T_prev will be used to determine the elapsed time since the sender last was network-limited or had reduced cwnd after an idle period. When the sender is application-limited, W_used holds the maximum congestion window actually used since the sender was last network-limited.
TCPは、新たなパケットを送信すると、それは前のパケットが送信されたので、RTO秒以上が経過しているかどうかを確認し、次のようにこの基本的なアルゴリズムは、TCPで実施することができます。 RTOが経過した場合、SSTHRESHは3/4 CWNDの最大およびSSTHRESHの電流値に設定され、その後、輻輳ウィンドウは、前のパケットが送信されてから経過したすべてのRTOのために半分になります。また、T_prevは、現在の時刻に設定され、そしてW_usedはゼロにリセットされます。 T_prevは、送信者が最後のネットワーク-制限またはアイドル期間後にcwndが減少した頃からの経過時間を決定するために使用されます。送信者はアプリケーションが制限されている場合は、W_usedは、送信者が最後のネットワーク - 限定的だったので、実際に使用される最大輻輳ウィンドウを保持しています。
The mechanism for determining the number of RTOs in the most recent idle period could also be implemented by using a timer that expires every RTO after the last packet was sent instead of a check per packet - efficiency constraints on different operating systems may dictate which is more efficient to implement.
異なるオペレーティングシステム上の効率の制約がよりある指示することができる - 最後のパケットがパケットあたりのチェックの代わりに送信された後、最新のアイドル期間中のRTOの数を決定するためのメカニズムは、すべてのRTOを満了するタイマーを使用して実装することができ実施するのが効率的。
After TCP sends a packet, it also checks to see if that packet filled the congestion window. If so, the sender is network-limited, and sets the variable T_prev to the current TCP clock time, and the variable W_used to zero.
TCPはパケットを送信した後、それはまた、パケットが輻輳ウィンドウを満たしたかどうかを確認します。その場合は、送信者は、ネットワーク制限され、現在のTCPクロック時間に変数T_prev、ゼロにW_used変数を設定します。
When TCP sends a packet that does not fill the congestion window, and the TCP send queue is empty, then the sender is application-limited. The sender checks to see if the amount of unacknowledged data is greater than W_used; if so, W_used is set to the amount of unacknowledged data. In addition TCP checks to see if the elapsed time since T_prev is greater than RTO. If so, then the TCP has not just reduced its congestion window following an idle period. The TCP has been application-limited rather than network-limited for at least an entire RTO interval, but for less than two RTO intervals. In this case, TCP sets ssthresh to the maximum of 3/4 cwnd and the current value of ssthresh, and reduces its congestion window to (cwnd+W_used)/2. W_used is then set to zero, and T_prev is set to the current time, so a further reduction will not take place until at least another RTO period has elapsed. Thus, during an application-limited period the CWV algorithm reduces the congestion window once per RTO.
TCPは輻輳ウィンドウを満たしていないパケットを送信し、TCPの送信キューが空の場合、送信者はアプリケーション限られています。未確認データの量がW_used以上であるかどうかを確認するために、送信者をチェックします。もしそうであれば、W_usedは未確認データの量に設定されています。また、TCPはT_prevからの経過時間がRTOより大きいかどうかを確認します。もしそうなら、TCPは単にアイドル期間以下の輻輳ウィンドウを縮小していません。 TCPは、少なくとも全体RTO間隔の、しかし2つの未満RTO間隔に対するアプリケーション制限はなく、ネットワーク限定されています。この場合、TCPは3/4 CWNDの最大およびSSTHRESHの現在値にSSTHRESHを設定し、それに輻輳ウィンドウ（CWND + W_used）/ 2を減少させます。少なくとも別のRTOの期間が経過するまでのでさらに減少が起こらなくなり、W_usedはゼロに設定され、T_prevは、現在の時刻に設定されています。したがって、アプリケーションが制限された期間中CWVアルゴリズムはRTOごとに一度輻輳ウィンドウを減少させます。
Initially: T_last = tcpnow, T_prev = tcpnow, W_used = 0
最初：T_最後= tcpnow、T_prev = tcpnow、W_used = 0
After sending a data segment: If tcpnow - T_last >= RTO (The sender has been idle.) ssthresh = max(ssthresh, 3*cwnd/4) For i=1 To (tcpnow - T_last)/RTO win = min(cwnd, receiver's declared max window) cwnd = max(win/2, MSS) T_prev = tcpnow W_used = 0
- T_最後> = RTO（送信者がアイドル状態になっている）SSTHRESH = MAX（* CWND / 4 SSTHRESH、3）I = 1の場合（tcpnow - T_最後）へ/ RTO勝利=分（CWND tcpnow場合：データ・セグメントを送信した後、レシーバのはCWND =最大は（勝つ）最大ウィンドウを宣言/ 2、MSS）T_prev = tcpnow W_used = 0
T_last = tcpnow
T_最後= tcpnow
If window is full T_prev = tcpnow W_used = 0 Else If no more data is available to send W_used = max(W_used, amount of unacknowledged data) If tcpnow - T_prev >= RTO (The sender has been application-limited.) ssthresh = max(ssthresh, 3*cwnd/4) win = min(cwnd, receiver's declared max window) cwnd = (win + W_used)/2 T_prev = tcpnow W_used = 0
T_prev> = RTO（送信者が、アプリケーション制限されていました。）SSTHRESH =最大 - これ以上のデータがtcpnow場合= MAX（W_used、未確認データの量）W_usedを送信するために利用されていない場合は、ウィンドウがT_prev = tcpnow W_used = 0そうでいっぱいになっている場合（SSTHRESH、3×CWND / 4）（受信機のは、最大ウィンドウを宣言CWND）=分を獲得CWND =（+ W_used勝つ）/ 2 T_prev = tcpnow W_used = 0
The CWV proposal has been implemented as an option in the network simulator NS [NS]. The simulations in the validation test suite for CWV can be run with the command "./test-all-tcp" in the directory "tcl/test". The simulations show the use of CWV to reduce the congestion window after a period when the TCP connection was application-limited, and to limit the increase in the congestion window when a transfer is application-limited. As the simulations illustrate, the use of ssthresh to maintain connection history is a critical part of the Congestion Window Validation algorithm. [HPF99] discusses these simulations in more detail.
CWVの提案は、ネットワークシミュレータNS [NS]でオプションとして実装されています。 CWVの検証テストスイートでのシミュレーションは、ディレクトリ 『TCL /テスト』でコマンド「./test-all-tcp」で実行することができます。シミュレーションはCWVの使用は、TCP接続がアプリケーション限定で、転送はアプリケーション限られている場合、輻輳ウィンドウの増加を制限する期間の後に輻輳ウィンドウを縮小することを示しています。シミュレーションが示すように、接続履歴を維持するためにSSTHRESHの使用は、輻輳ウィンドウ検証アルゴリズムの重要な部分です。 [HPF99より詳細にこれらのシミュレーションを論じています。
We have implemented the CWV mechanism in the TCP implementation in FreeBSD 3.2. [HPF99] discusses these experiments in more detail.
私たちは、FreeBSD 3.2でのTCP実装でCWVメカニズムを実装しています。 [HPF99]より詳細にこれらの実験について説明します。
The first experiment examines the effects of the Congestion Window Validation mechanisms for limiting cwnd increases during application-limited periods. The experiment used a real ssh connection through a modem link emulated using Dummynet [Dummynet]. The link speed is 30Kb/s and the link has five packet buffers available. Today most modem banks have more buffering available than this, but the more buffer-limited situation sometimes occurs with older modems. In the first half of the transfer, the user is typing away over the connection. About half way through the time, the user lists a moderately large file, which causes a large burst of traffic to be transmitted.
最初の実験では、アプリケーションが制限された期間中にCWNDが増加を制限するための輻輳ウィンドウ検証メカニズムの効果を調べます。実験はDUMMYNET [DUMMYNET]を使用してエミュレートされたモデムリンクを介して実際のSSH接続を使用します。リンク速度が30KB / sであるとのリンクが可能な5つのパケットバッファを持っています。今日、ほとんどのモデムバンクはこれより多くのバッファリングを用意して、より多くのバッファが制限された状況は、時々古いモデムで発生します。転送の前半では、ユーザは、接続を介して離れて入力されます。時間を通して半分について、ユーザーがトラフィックの大バーストを送信させる適度に大きなファイルを、一覧表示されます。
For the unmodified TCP, every returning ACK during the first part of the transfer results in an increase in cwnd. As a result, the large burst of data arriving from the application to the transport layer is sent as many back-to-back packets, most of which get lost and subsequently retransmitted.
修飾されていないTCPのために、すべてのCWNDの増加の転送結果の最初の部分の間にACKを返します。その結果、トランスポート層へのアプリケーションから到着するデータの大バーストが失われ、その後再送信を受けるほとんどができるだけ多くのバックツーバックパケットを、送信されます。
For the modified TCP with Congestion Window Validation, the congestion window is not increased when the window is not full, and has been decreased during application-limited periods closer to what the user actually used. The burst of traffic is now constrained by the congestion window, resulting in a better-behaved flow with minimal loss. The end result is that the transfer happens approximately 30% faster than the transfer without CWV, due to avoiding retransmission timeouts.
ウィンドウは満杯でない場合輻輳ウィンドウ検証と変更されたTCPは、輻輳ウィンドウは増加されず、ユーザが実際に使用されるものに近いアプリケーション制限期間中減少しました。トラフィックのバーストについて最小の損失で良好に動作フローをもたらす、輻輳ウィンドウによって制約されます。最終結果は、転送が再送タイムアウトを回避によるCWVことなく転送よりも約30％高速化が起こることです。
The second experiment uses a real ssh connection over a real dialup ppp connection, where the modem bank has much more buffering. For the unmodified TCP, the initial burst from the large file does not cause loss, but does cause the RTT to increase to approximately 5 seconds, where the connection becomes bounded by the receiver's window.
第二の実験は、モデムバンクがはるかにバッファリングを持っている本当のダイアルアップPPP接続、オーバー本物のssh接続を使用しています。無修正TCPの場合は、大容量のファイルからの初期バーストは、損失が発生することはありませんが、RTTは、接続が受信側のウィンドウで囲まれた状態になる約5秒に増加させません。
For the modified TCP with Congestion Window Validation, the flow is much better behaved, and produces no large burst of traffic. In this case the linear increase for cwnd results in a slow increase in the RTT as the buffer slowly fills.
輻輳ウィンドウ検証と変更されたTCPの場合、フローははるかに優れて振る舞っており、トラフィックのない大規模なバーストを生成しません。この場合にはバッファとしてのRTTに遅い増加CWND結果の線形増加がゆっくりと充填されます。
For the second experiment, both the modified and the unmodified TCP finish delivering the data at precisely the same time. This is because the link has been fully utilized in both cases due to the modem buffer being larger than the receiver window. Clearly a modem buffer of this size is undesirable due to its effect on the RTT of competing flows, but it is necessary with current TCP implementations that produce bursts similar to those shown in the top graph.
第二の実験のために、両方の修飾と正確に同じ時間でデータを配信する非修飾TCP仕上げ。リンクが完全モデムバッファが受信ウィンドウより大きいことに起因する両方の場合に利用されているためです。明らかに、このサイズのモデムバッファが原因競合フローのRTTに対するその効果は望ましくないが、それは上のグラフに示したものと同様のバーストを生成する現在のTCP実装で必要です。
This document has presented several TCP algorithms for Congestion Window Validation, to be employed after an idle period or a period in which the sender was application-limited, and before an increase of the congestion window. The goal of these algorithms is for TCP's congestion window to reflect recent knowledge of the TCP connection about the state of the network path, while at the same time keeping some memory (i.e., in ssthresh) about the earlier state of the path. We believe that these modifications will be of benefit to both the network and to the TCP flows themselves, by preventing unnecessary packet drops due to the TCP sender's failure to update its information (or lack of information) about current network conditions. Future work will document and investigate the benefit provided by these algorithms, using both simulations and experiments. Additional future work will describe a more complex version of the CWV algorithm for TCP implementations where the sender does not have an accurate estimate of the TCP roundtrip time.
この文書では、アイドル期間または送信者が、アプリケーション制限、および輻輳ウィンドウの増加の前にあった期間の後に採用されるように、輻輳ウィンドウ検証するためのいくつかのTCPアルゴリズムを提示しました。これらのアルゴリズムの目標は、同時にパスの以前の状態について（すなわち、SSTHRESHに）いくつかのメモリを維持しながら、ネットワーク経路の状態についてのTCPコネクションの最近の知見を反映するためにTCPの輻輳ウィンドウのためです。我々は、これらの修飾は、現在のネットワークの状態についてその情報（または情報の欠如）を更新するためにTCPの送信者の障害のために、両方のネットワークにして落ちるTCPは、不要なパケットを防止することにより、自分自身の流れに有益であると考えています。今後の課題は、シミュレーションと実験の両方を使用して、これらのアルゴリズムにより提供される利点を文書化し、検討します。追加の将来の仕事は、送信者がTCPラウンドトリップ時間の正確な推定値を持っていないTCPの実装のためのCWVアルゴリズムのより複雑なバージョンを記述します。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21. URL "http://www.aciri.org/floyd/papers.html".
[FF96]秋、K.、及びフロイド、S.、タホ、リノ、およびSACK TCP、コンピュータコミュニケーションレビュー、V. 26 N. 3、1996年7月、頁5-21のシミュレーションベースの比較。 URL "http://www.aciri.org/floyd/papers.html"。
[HPF99] Mark Handley, Jitendra Padhye, Sally Floyd, TCP Congestion Window Validation, UMass CMPSCI Technical Report 99-77, September 1999. URL "ftp://www-net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".
[HPF99]マーク・ハンドリー、Jitendra Padhye、サリー・フロイド、TCP輻輳ウィンドウ検証、UMass CMPSCIテクニカルレポート99から77まで、1999年9月URL「ftp://www-net.cs.umass.edu/pub/Handley99-tcpq- TR-99-77.ps.gz」。
[HTH98] Amy Hughes, Joe Touch, John Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress.
[HTH98]エイミー・ヒューズ、ジョー・タッチ、ジョンHeidemann、「アイドルの後にTCPスロースタートの再起動で問題」が進行中で働いています。
[J88] Jacobson, V., Congestion Avoidance and Control, Originally from Proceedings of SIGCOMM '88 (Palo Alto, CA, Aug. 1988), and revised in 1992. URL "http://www-nrg.ee.lbl.gov/nrg-papers.html".
もともとSIGCOMM '88の議事録（パロアルト、CA、1988年8月）から[J88]ジェーコブソン、V.、輻輳回避とコントロール、および1992年URLは「httpに改定：//www-nrg.ee.lbl。 GOV / NRG-papers.html」。
[JKBFL96] Raj Jain, Shiv Kalyanaraman, Rohit Goyal, Sonia Fahmy, and Fang Lu, Comments on "Use-it or Lose-it", ATM Forum Document Number: ATM Forum/96-0178, URL "http://www.netlab.ohio-state.edu/~jain/atmf/af_rl5b2.htm".
[JKBFL96]ラジ・ジャイン、シヴKalyanaraman、のRohit Goyal氏、ソニアFahmy、と牙呂、 "使用それまたは失う - それを"、ATMフォーラム文書番号へのコメント：ATMフォーラム/ 96から0178、URLは「http：// WWW .netlab.ohio-state.edu /〜ジャイナ/ ATMF / af_rl5b2.htm」。
[JKGFL95] R. Jain, S. Kalyanaraman, R. Goyal, S. Fahmy, and F. Lu, A Fix for Source End System Rule 5, AF-TM 95-1660, December 1995, URL "http://www.netlab.ohio-state.edu/~jain/atmf/af_rl52.htm".
[JKGFL95] R.ジャイナ、S・カリヤナラーマン、R. Goyal氏、S. Fahmy、およびF.呂、ソースエンドシステムのルール5のための修正、AF-TM 95から1660まで、1995年12月、URLは「http：// WWW .netlab.ohio-state.edu /〜ジャイナ/ ATMF / af_rl52.htm」。
[MSML99] Matt Mathis, Jeff Semke, Jamshid Mahdavi, and Kevin Lahey, The Rate-Halving Algorithm for TCP Congestion Control, June 1999. URL "http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt".
[MSML99]マット・マシス、ジェフSemke、ジャムシードMahdavi、そしてケビン・レイヒー、TCPの輻輳制御のレート半減アルゴリズム、1999年6月URL「http://www.psc.edu/networking/ftp/papers/draft-ratehalving 。txt"。
[NS] NS, the UCB/LBNL/VINT Network Simulator. URL "http://www-mash.cs.berkeley.edu/ns/".
[NS] NS、UCB / LBNL / VINTネットワークシミュレータ。 URL "http://www-mash.cs.berkeley.edu/ns/"。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, TCP Congestion Control, RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、TCPの輻輳制御、RFC 2581、1999年4月。
[VH97] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections, Technical Report 97-661, University of Southern California, November, 1997.
[VH97]ビクラムVisweswaraiahとジョンHeidemann。アイドルTCPコネクションの再起動、テクニカルレポート97から661、南カリフォルニア大学、1997年11月の改善。
[Dummynet] Luigi Rizzo, "Dummynet and Forward Error Correction", Freenix 98, June 1998, New Orleans. URL "http://info.iet.unipi.it/~luigi/ip_dummynet/".
[DUMMYNET]ルイジ・リゾ、 "DUMMYNETと前方誤り訂正"、FREENIX 98、1998年6月、ニューオーリンズ。 URL "http://info.iet.unipi.it/~luigi/ip_dummynet/"。
General security considerations concerning TCP congestion control are discussed in RFC 2581. This document describes a algorithm for one aspect of those congestion control procedures, and so the considerations described in RFC 2581 apply to this algorithm also. There are no known additional security concerns for this specific algorithm.
TCPの輻輳制御に関する一般的なセキュリティ上の考慮事項は、この文書では、これらの輻輳制御手順の一の側面のためのアルゴリズムを説明し、そのRFC 2581に記述の考察はまた、このアルゴリズムには適用されRFC 2581で説明されています。この特定のアルゴリズムには知られている追加のセキュリティ上の懸念はありません。
Mark Handley AT&T Center for Internet Research at ICSI (ACIRI)
マーク・ハンドリーAT＆T ICSIでのインターネット研究センター（ACIRI）
Phone: +1 510 666 2946 EMail: mjh@aciri.org URL: http://www.aciri.org/mjh/
電話：+1 510 666 2946 Eメール：mjh@aciri.org URL：http://www.aciri.org/mjh/
Jitendra Padhye AT&T Center for Internet Research at ICSI (ACIRI)
ICSIでのインターネット調査のためのJitendra Padhye AT＆Tセンター（ACIRI）
Phone: +1 510 666 2887 EMail: padhye@aciri.org URL: http://www-net.cs.umass.edu/~jitu/
電話：+1 510 666 2887 Eメール：padhye@aciri.org URL：http://www-net.cs.umass.edu/~jitu/
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
サリーフロイドAT＆T ICSIでのインターネット研究センター（ACIRI）
Phone: +1 510 666 2989 EMail: floyd@aciri.org URL: http://www.aciri.org/floyd/
電話：+1 510 666 2989 Eメール：floyd@aciri.org URL：http://www.aciri.org/floyd/
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。