RFC 2861 - TCP Congestion Window Validation 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2861
タイトル : RFC 2861 - TCP混雑ウィンドウの検証
翻訳編集 : 自動生成

[要約] RFC 2861は、TCPの輻輳ウィンドウの検証に関するガイドラインです。その目的は、ネットワークの輻輳を適切に制御し、パフォーマンスを最適化することです。

Network Working Group                                         M. Handley
Request for Comments: 2861                                     J. Padhye
Category: Experimental                                          S. Floyd
                                                                   ACIRI
                                                               June 2000

TCP Congestion Window Validation

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.

このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。

著作権表示

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フローがネットワーク内にいつでも持っている可能性のあるパケットの数を制御します。ただし、送信者がアイドル状態またはアプリケーションに制限されている長い期間は、輻輳ウィンドウがネットワークの状態に関する現在の情報を反映しなくなったという点で、混雑ウィンドウの無効化につながる可能性があります。このドキュメントでは、TCPの混雑制御アルゴリズムの単純な変更について説明し、十分に長いアプリケーションに制限された期間からの移行後、混雑ウィンドウを減衰させ、スロースタートしきい値SSTHRESHを使用して、輻輳ウィンドウの以前の値に関する情報を保存します。

また、輻輳ウィンドウの前の値が完全に利用されなかった場合に、輻輳ウィンドウが増加する（つまり、TCPのスロースタートまたは輻輳回避段階で）増加すると（つまり、TCPのスロースタートまたは輻輳回避段階）、無効な輻輳ウィンドウが生じます。TCP送信者は、TCP送信者がアプリケーションに制限されている場合（したがって現在の輻輳ウィンドウを完全に使用していない場合）、輻輳ウィンドウを増やすべきではないことを提案します。これらのアルゴリズムは、シミュレーションとFreeBSDでの実装からの実験の両方で検討しました。

1. Conventions and Acronyms

1. コンベンションと頭字語

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]で説明されているように解釈する必要がある場合、[B97]で説明されているように解釈する必要がある、必要に応じて、要求されてはならない、必要ではない、そうでなければ、推奨されてはならない、そうでなければならない、そうでなければならない。

2. Introduction

2. はじめに

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）メカニズムを使用して設定され、ネットワーク条件の変化に動的に適応します。このAIMDメカニズムは、送信者が継続的に送信するデータを継続的に持っている場合にうまく機能します。これは、通常、BULK-DATA転送に使用されるTCPの場合です。対照的に、Telnetアプリケーションで使用されるTCPの場合、データ送信者には送信するデータがほとんどまたはまったくないことが多く、送信率はユーザーによってデータが生成されるレートによって決定されます。動的に作成されたデータを持つTCP送信者や永続的な接続TCPを使用したHTTP 1.1などの開発などの開発を含むWebの出現により、アプリケーション制限期間間の相互作用（送信者が渋滞または受信者ウィンドウで許可されているよりも少ない場合）ネットワーク制限期間（送信者が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が再送信のタイムアウトを超える間隔でデータを送信していない場合、送信を開始する前にCWNDをRW [初期ウィンドウ]以下に設定する必要があります。」アイドル後のTCPのスロースタートの提案も[HTH98]で議論されています。アイドル期間中の混雑情報の検証の問題は、たとえばATMネットワークの「use-itまたはlos-it」メカニズム[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.

アプリケーションが制限された期間後に輻輳ウィンドウの再検証に対処するために、TCPの輻輳制御アルゴリズムを簡単に変更して、十分に長いアプリケーション制限期間からの移行後に混雑ウィンドウを減衰させることを提案します（すなわち、少なくとも1つのラウンドトリピング時間）ネットワーク制限期間まで。特に、アイドル期間の後、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は、最近の混雑ウィンドウの「記憶」として残ります。具体的には、アプリケーションが制限された期間の後にCWNDが減少する場合、SSthreshは決して減少しません。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のスロースタートまたは輻輳回避段階）、無効な輻輳ウィンドウが生じます。私たちが知る限り、現在のすべてのTCP実装は、受信者の広告ウィンドウとスロースタート回避ウィンドウで許可されている場合、輻輳ウィンドウの以前の値を確認することなく、スロースタートまたは輻輳回避ウィンドウがアルゴリズムを増やすと、確認が届くと、輻輳ウィンドウが増加します。実際に使用されています。このドキュメントは、ウィンドウの増加アルゴリズムがアプリケーションに制限された期間中に呼び出されないことを提案しています[MSML99]。特に、TCP送信者は、TCP送信者がアプリケーションに制限されている場合（したがって、現在の輻輳ウィンドウを完全に使用していない）場合、輻輳ウィンドウを増やすべきではありません。この制限により、混雑ウィンドウがネットワークによってサポートできるという証拠がない場合、渋滞ウィンドウが任意に大きくなるのを防ぎます。[MSML99、セクション5.2]から：「この制限は、TCPが実際に十分なデータをネットワークに注入してパスをテストすることに成功している限り、[CWND]が成長することを保証します。」

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]を使用しています。私たちは、往復時間の期間にわたってバックツーバックパケットまたはペーシングパケットの送信を制限するメカニズムがあっても、しばらくの間完全に使用されていない古い輻輳窓は、現在その流れに利用可能な帯域幅の兆候。輻輳ウィンドウで許可されたパケットをペースアウトするメカニズムは、輻輳ウィンドウの適切なサイズを決定するために使用されるアルゴリズムの主に直交していると主張します。

3. Description

3. 説明

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は少なくとも中途半端にスロースタート（指数増加を実行）します。

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.

別の可能性は、SSthreshをSSthreshの現在の値の最大値とCWNDの古い値に設定し、TCPがCWNDの古い値に戻ることをすべて遅らせることができることです。さらなる実験を使用して、SSThreshを設定するためのこれら2つのオプションを評価できます。

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）に関連付けられています。これは、接続によって調査された現在のネットワーク状態を常に確認することに関連しているためです。

3.1. The basic algorithm for reducing the congestion window

3.1. 輻輳ウィンドウを減らすための基本的なアルゴリズム

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アルゴリズムの重要な問題は、フローがアプリケーションに制限されているという丸いトリップ時間ごとに1回、混雑ウィンドウを1回削減するガイドラインを適用する方法を決定することです。TCPの再送信タイマー（RTO）を往復時間の合理的な上限として使用し、RTOごとに約1回混雑ウィンドウを減らします。

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で実装できます。TCPが新しいパケットを送信すると、前のパケットが送信されてからRTO以上が経過しているかどうかを確認します。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がパケットを送信した後、そのパケットがうっ血ウィンドウに入っているかどうかを確認するためにチェックします。その場合、送信者はネットワーク制限されており、変数T_PREVを現在のTCPクロック時間に設定し、変数はゼロに使用されます。

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はSSThreshを最大3/4 CWNDとSSTHRESHの現在の値に設定し、そのうっ血ウィンドウを（CWND W_USED）/2に減らします。W_USEDはゼロに設定され、T_PREVは現在の時間に設定されているため、少なくとも別のRTO期間が経過するまで、さらなる削減は行われません。したがって、アプリケーションに制限された期間中、CWVアルゴリズムはRTOごとに1回輻輳ウィンドウを減らします。

3.2. Pseudo-code for reducing the congestion window

3.2. 輻輳ウィンドウを減らすための擬似コード

   Initially:
       T_last = 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_last = 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

4. Simulations

4. シミュレーション

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」で実行できます。シミュレーションは、TCP接続がアプリケーションに制限された期間の後にCWVを使用してうっ血ウィンドウを減らし、転送がアプリケーションに制限されている場合の混雑ウィンドウの増加を制限することを示しています。シミュレーションが示すように、接続履歴を維持するためにSSTHRESHを使用することは、うっ血ウィンドウ検証アルゴリズムの重要な部分です。[HPF99]これらのシミュレーションについては、より詳細に説明します。

5. Experiments

5. 実験

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の場合、転送の最初の部分でACKを返すすべてのACKは、CWNDが増加します。その結果、アプリケーションから輸送層に到着するデータの大きなバーストは、多くの連続したパケットと同じくらい送信され、そのほとんどは失われ、その後再送信されます。

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.

2番目の実験では、Modem Bankにはより多くのバッファリングがあるReal Dialup 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の場合、フローの動作がはるかに優れており、トラフィックの大きなバーストは生成されません。この場合、CWNDの線形増加により、バッファーがゆっくりと充填されると、RTTがゆっくりと増加します。

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.

2番目の実験では、修正されたTCPの両方で、データを正確に同時に配信します。これは、モデムバッファーが受信機ウィンドウよりも大きいため、どちらの場合もリンクが完全に利用されているためです。明らかに、このサイズのモデムバッファーは、競合するフローのRTTに対する影響のために望ましくありませんが、トップグラフに示されているものと同様のバーストを生成する現在のTCP実装では必要です。

6. Conclusions

6. 結論

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アルゴリズムを提示しました。これは、アイドル期間または送信者がアプリケーションに制限された期間の後、および輻輳ウィンドウの増加の前に使用されます。これらのアルゴリズムの目標は、TCPの混雑ウィンドウがネットワークパスの状態に関するTCP接続に関する最近の知識を反映すると同時に、パスの初期の状態についてのメモリ（つまり、ssthreshに）を維持することです。現在のネットワーク条件に関する情報（または情報の不足）の更新にTCP送信者が失敗したために、これらの変更は、ネットワークとTCPフロー自体の両方に有益であると考えています。将来の作業では、シミュレーションと実験の両方を使用して、これらのアルゴリズムによって提供される利点を文書化および調査します。追加の将来の作業では、送信者がTCP往復時間の正確な推定値を持たないTCP実装のCWVアルゴリズムのより複雑なバージョンを説明します。

7. References

7. 参考文献

[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] Fall、K。、およびFloyd、S.、Tahoe、Reno、およびSack TCPのシミュレーションベースの比較、コンピューターコミュニケーションレビュー、V。26N. 3、1996年7月、pp。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]マーク・ハンドリー、ジテンドラ・パディエ、サリー・フロイド、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] Amy Hughes、Joe Touch、John 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".

[J88] Jacobson、V.、輻輳回避と制御、もともとSigcomm '88（1988年8月、Palo Alto、CA）の議事録から、1992年に改訂されました。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] Raj Jain、Shiv Kalyanaraman、Rohit Goyal、Sonia Fahmy、およびFang Lu、「use-it or lose-it」、ATMフォーラム文書番号：ATMフォーラム/96-0178、url "http：// wwwwwwww.netlab.ohio-state.edu/〜jain/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. Jain、S。Kalyanaraman、R。Goyal、S。Fahmy、およびF. Lu、ソースエンドシステムルール5、AF-TM 95-1660、1995年12月、URL "http：// wwwの修正.NETLAB.OHIO-STATE.EDU/〜JAIN/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] Matt Mathis、Jeff Semke、Jamshid Mahdavi、およびKevin Lahey、TCP輻輳制御のレートハービングアルゴリズム、1999年6月。URL "http://www.psu/networking/ftp/papers/draft-ratehalvinving。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] Allman、M.、Paxson、V。and W. Stevens、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] Vikram VisweswaraiahとJohn 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] Luigi Rizzo、「Dummynet and Forward Error Correction」、Freenix 98、1998年6月、ニューオーリンズ。url "http://info.iet.unipi.it/~luigi/ip_dummynet/"。

8. Security Considerations

8. セキュリティに関する考慮事項

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で説明されています。このドキュメントでは、これらの混雑制御手順の1つの側面のアルゴリズムについて説明しているため、RFC 2581で説明されている考慮事項もこのアルゴリズムに適用されます。この特定のアルゴリズムに関する追加のセキュリティ上の懸念はありません。

9. Authors' Addresses

9. 著者のアドレス

Mark Handley AT&T Center for Internet Research at ICSI (ACIRI)

ICSI（Aciri）のインターネット研究のためのマークハンドリーAT＆Tセンター

   Phone: +1 510 666 2946
   EMail: mjh@aciri.org
   URL: http://www.aciri.org/mjh/

Jitendra Padhye AT&T Center for Internet Research at ICSI (ACIRI)

Jitendra Padhye ICSI（Aciri）のインターネット研究のためのAT＆Tセンター

   Phone: +1 510 666 2887
   EMail: padhye@aciri.org
   URL: http://www-net.cs.umass.edu/~jitu/

Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)

ICSIのインターネット研究のためのSally Floyd AT＆Tセンター（Aciri）

   Phone: +1 510 666 2989
   EMail: floyd@aciri.org
   URL:  http://www.aciri.org/floyd/

10. Full Copyright Statement

10. 完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。