[要約] RFC 7661は、TCPを更新してレート制限されたトラフィックをサポートするためのものであり、要約すると以下のようになります。1. 目的：TCPの仕様を改善し、レート制限されたトラフィックの効率的な処理を可能にする。 2. 要約：このRFCでは、新しいTCPオプションとアルゴリズムを導入し、ネットワークの帯域幅を効果的に制御するための手段を提供する。
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 7661 A. Sathiaseelan
Obsoletes: 2861 R. Secchi
Category: Experimental University of Aberdeen
ISSN: 2070-1721 October 2015
Updating TCP to Support Rate-Limited Traffic
レート制限されたトラフィックをサポートするためのTCPの更新
Abstract
概要
This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.
このドキュメントでは、輻輳ウィンドウではなくアプリケーションによって送信レートが制限されている期間を示すトラフィックにTCPが使用されている場合に発生する問題に対処するメカニズムを提供します。これは、TCPの実験的なアップデートを提供し、TCP送信者がレート制限された間隔に従って迅速に再起動できるようにします。この方法は、TCPを使用してレート制限されたトラフィックを送信するアプリケーションにメリットをもたらすと同時に、輻輳が発生した場合に適切な応答を提供することが期待されています。
This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.
このドキュメントはまた、RFC 2861で定義されたTCP輻輳ウィンドウ検証（CWV）の実験的仕様を評価し、RFC 2861が重要な問題に対処しようとしたが、広く使用されているソリューションを提供できなかったと結論付けています。したがって、このドキュメントでは、RFC 2861のステータスを実験的から歴史的に再分類しています。このドキュメントはRFC 2861を廃止します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7661.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7661で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Implementation of New CWV ..................................5
1.2. Standards Status of This Document ..........................5
2. Reviewing Experience with TCP-CWV ...............................5
3. Terminology .....................................................7
4. A New Congestion Window Validation Method .......................8
4.1. Initialisation .............................................8
4.2. Estimating the Validated Capacity Supported by a Path ......8
4.3. Preserving cwnd during a Rate-Limited Period ..............10
4.4. TCP Congestion Control during the Non-validated Phase .....11
4.4.1. Response to Congestion in the Non-validated Phase ..12
4.4.2. Sender Burst Control during the
Non-validated Phase ................................14
4.4.3. Adjustment at the End of the Non-validated
Period (NVP) .......................................14
4.5. Examples of Implementation ................................15
4.5.1. Implementing the pipeACK Measurement ...............15
4.5.2. Measurement of the NVP and pipeACK Samples .........16
4.5.3. Implementing Detection of the cwnd-Limited
Condition ..........................................17
5. Determining a Safe Period to Preserve cwnd .....................17
6. Security Considerations ........................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................19
Acknowledgments ...................................................21
Authors' Addresses ................................................21
TCP is used for traffic with a range of application behaviours. The TCP congestion window (cwnd) controls the maximum number of unacknowledged packets/bytes that a TCP flow may have in the network at any time, a value known as the FlightSize [RFC5681]. FlightSize is a measure of the volume of data that is unacknowledged at a specific time. A bulk application will always have data available to transmit. The rate at which it sends is therefore limited by the maximum permitted by the receiver advertised window and the sender congestion window (cwnd). The FlightSize of a bulk flow increases with the cwnd and tracks the volume of data acknowledged in the last Round-Trip Time (RTT).
TCPは、さまざまなアプリケーション動作のトラフィックに使用されます。 TCP輻輳ウィンドウ（cwnd）は、TCPフローがネットワーク内でいつでも保持できる未確認のパケット/バイトの最大数、FlightSize [RFC5681]として知られる値を制御します。 FlightSizeは、特定の時間に確認応答されていないデータの量の測定値です。バルクアプリケーションには、常に送信可能なデータがあります。したがって、送信速度は、受信者のアドバタイズされたウィンドウと送信者の輻輳ウィンドウ（cwnd）によって許可された最大値によって制限されます。バルクフローのFlightSizeはcwndとともに増加し、最後のラウンドトリップ時間（RTT）で確認されたデータの量を追跡します。
In contrast, a rate-limited application will experience periods when the sender is either idle or unable to send at the maximum rate permitted by the cwnd. In this case, the volume of data sent (FlightSize) can change significantly from one RTT to another and can be much less than the cwnd. Hence, it is possible that the FlightSize could significantly exceed the recently used capacity. The update in this document targets the operation of TCP in such rate-limited cases.
対照的に、レート制限されたアプリケーションでは、送信者がアイドル状態であるか、cwndで許可されている最大レートで送信できない期間が発生します。この場合、送信されるデータの量（FlightSize）は、RTT間で大幅に変化する可能性があり、cwndよりもはるかに少なくなる可能性があります。したがって、FlightSizeが最近使用された容量を大幅に超える可能性があります。このドキュメントの更新は、このようなレート制限のある場合のTCPの操作を対象としています。
Standard TCP states that a TCP sender SHOULD set cwnd to no more than the Restart Window (RW) before beginning transmission if the TCP sender has not sent data in an interval exceeding the retransmission timeout, i.e., when an application becomes idle [RFC5681]. [RFC2861] notes that this TCP behaviour was not always observed in current implementations. Experiments confirm this to still be the case (see [Bis08]).
標準TCPは、TCP送信者が再送信タイムアウトを超える間隔でデータを送信しなかった場合、つまりアプリケーションがアイドルになった場合に、送信を開始する前にTCP送信者がcwndを再起動ウィンドウ（RW）以下に設定する必要があると述べています[RFC5681]。 [RFC2861]は、このTCP動作が現在の実装で常に観察されたわけではないことを指摘しています。実験では、これが依然として事実であることを確認しています（[Bis08]を参照）。
Congestion Window Validation (CWV) [RFC2861] introduced the term "application-limited period" for the time when the sender sends less than is allowed by the congestion or receiver windows. [RFC2861] described a method that improved support for applications that vary their transmission rate, i.e., applications that either have (short) idle periods between transmissions or change the rate at which they send. These applications are characterised by the TCP FlightSize often being less than the cwnd. Many Internet applications exhibit this behaviour, including web browsing, HTTP-based adaptive streaming, applications that support query/response type protocols, network file sharing, and live video transmission. Many such applications currently avoid using long-lived (persistent) TCP connections (e.g., servers that use HTTP/1.1 [RFC7230] typically support persistent HTTP connections but do not enable this by default). Instead, such applications often either use a succession of short TCP transfers or use UDP.
輻輳ウィンドウ検証（CWV）[RFC2861]は、送信側が輻輳ウィンドウまたは受信側ウィンドウで許可されている量よりも少ない時間を送信するときに「アプリケーション制限期間」という用語を導入しました。 [RFC2861]は、送信レートを変化させるアプリケーション、つまり送信と送信の間に（短い）アイドル期間があるか、送信レートを変更するアプリケーションのサポートを改善する方法について説明しました。これらのアプリケーションの特徴は、TCP FlightSizeがcwndよりも小さいことです。 Webブラウジング、HTTPベースのアダプティブストリーミング、クエリ/応答タイプのプロトコルをサポートするアプリケーション、ネットワークファイル共有、ライブビデオ送信など、多くのインターネットアプリケーションがこの動作を示します。現在、このようなアプリケーションの多くは、長期間の（永続的な）TCP接続の使用を避けています（たとえば、HTTP / 1.1 [RFC7230]を使用するサーバーは、通常、永続的なHTTP接続をサポートしていますが、デフォルトではこれを有効にしていません）。代わりに、そのようなアプリケーションは、多くの場合、一連の短いTCP転送を使用するか、UDPを使用します。
Standard TCP does not impose additional restrictions on the growth of the congestion window when a TCP sender is unable to send at the maximum rate allowed by the cwnd. In this case, the rate-limited sender may grow a cwnd far beyond that corresponding to the current transmit rate, resulting in a value that does not reflect current information about the state of the network path the flow is using. Use of such an invalid cwnd may result in reduced application performance and/or could significantly contribute to network congestion.
標準のTCPは、TCP送信者がcwndで許可されている最大レートで送信できない場合、輻輳ウィンドウの拡大に追加の制限を課しません。この場合、レート制限された送信側は、現在の送信レートに対応する値をはるかに超えてcwndを増やす可能性があり、その結果、フローが使用しているネットワークパスの状態に関する現在の情報を反映しない値になります。このような無効なcwndを使用すると、アプリケーションのパフォーマンスが低下したり、ネットワークの輻輳に大きく影響したりする可能性があります。
[RFC2861] proposed a solution to these issues in an experimental method known as CWV. CWV was intended to help reduce cases where TCP accumulated an invalid (inappropriately large) cwnd. The use and drawbacks of using the CWV algorithm described in RFC 2861 with an application are discussed in Section 2.
[RFC2861]は、CWVとして知られている実験的な方法でこれらの問題の解決策を提案しました。 CWVは、TCPが無効な（不適切に大きな）cwndを蓄積するケースを減らすのに役立つことを目的としています。 RFC 2861で説明されているCWVアルゴリズムをアプリケーションで使用する場合の欠点については、セクション2で説明します。
Section 3 defines relevant terminology.
セクション3では、関連する用語を定義します。
Section 4 specifies an alternative to CWV that seeks to address the same issues but does so in a way that is expected to mitigate the impact on an application that varies its sending rate. The updated method applies to the rate-limited conditions (including both application-limited and idle senders).
セクション4では、同じ問題に対処しようとするCWVの代替を指定しますが、その方法は、送信速度を変化させるアプリケーションへの影響を軽減することが期待される方法で行います。更新された方法は、レート制限条件（アプリケーション制限送信者とアイドル送信者の両方を含む）に適用されます。
The goals of this update are:
この更新の目的は次のとおりです。
o To not change the behaviour of a TCP sender that performs bulk transfers that fully use the cwnd.
o cwndを完全に使用するバルク転送を実行するTCP送信側の動作を変更しないため。
o To provide a method that co-exists with standard TCP and other flows that use this updated method.
o 標準のTCPおよびこの更新されたメソッドを使用する他のフローと共存するメソッドを提供する。
o To reduce transfer latency for applications that change their rate over short intervals of time.
o 短い時間間隔でレートを変更するアプリケーションの転送レイテンシを削減するため。
o To avoid a TCP sender growing a large "non-validated" cwnd, when it has not recently sent using this cwnd.
o 最近このcwndを使用して送信していない場合に、TCP送信者が大きな「検証されていない」cwndを拡大するのを防ぐため
o To remove the incentive for ad hoc application or network stack methods (such as "padding") solely to maintain a large cwnd for future transmission.
o 将来の送信のために大きなcwndを維持するためだけに、アドホックアプリケーションまたはネットワークスタックメソッド（「パディング」など）のインセンティブを削除する。
o To provide an incentive for the use of long-lived connections rather than a succession of short-lived flows, benefiting both the long-lived flows and other flows sharing capacity with these flows when congestion is encountered.
o 一連の短命フローではなく長命接続の使用に対するインセンティブを提供することで、輻輳が発生したときに長命フローとこれらのフローと容量を共有する他のフローの両方に利益をもたらします。
Section 5 describes the rationale for selecting the safe period to preserve the cwnd.
セクション5では、cwndを保存するための安全な期間を選択する根拠について説明します。
The method specified in Section 4 of this document is a sender-side-only change to the TCP congestion control behaviour of TCP.
このドキュメントのセクション4で指定されている方法は、TCPのTCP輻輳制御動作に対する送信側のみの変更です。
The method creates a new protocol state and requires a sender to determine when the cwnd is validated or non-validated to control the entry and exit from this state (see Section 4.3). It defines how a TCP sender manages the growth of the cwnd using the set of rules defined in Section 4.
このメソッドは、新しいプロトコル状態を作成し、送信者がcwndを検証するかどうかを判断して、この状態の開始と終了を制御します（セクション4.3を参照）。これは、TCP送信者がセクション4で定義された一連のルールを使用してcwndの増加を管理する方法を定義します。
Implementation of this specification requires an implementor to define a method to measure the available capacity using a set of pipeACK samples. The details of this measurement are implementation-specific. An example is provided in Section 4.5.1, but other methods are permitted. A sender also needs to provide a method to determine when it becomes cwnd-limited. Implementation of this may require consideration of other TCP methods (see Section 4.5.3).
この仕様の実装では、pipeACKサンプルのセットを使用して使用可能な容量を測定するメソッドを実装者が定義する必要があります。この測定の詳細は実装固有です。例をセクション4.5.1に示しますが、他の方法も許可されます。送信者は、cwnd制限になる時期を判別する方法も提供する必要があります。これを実装するには、他のTCPメソッドを検討する必要がある場合があります（セクション4.5.3を参照）。
A sender is also recommended to provide a method that controls the maximum burst size (see Section 4.4.2). However, implementors are allowed flexibility in how this method is implemented, and the choice of an appropriate method is expected to depend on the way in which the sender stack implements other TCP methods (such as TCP Segment Offload (TSO)).
送信者は、最大バーストサイズを制御する方法を提供することも推奨されます（セクション4.4.2を参照）。ただし、実装者はこのメソッドの実装方法に柔軟性があり、適切なメソッドの選択は、送信側スタックが他のTCPメソッド（TCPセグメントオフロード（TSO）など）を実装する方法に依存すると予想されます。
The document obsoletes the methods described in [RFC2861]. It recommends a set of mechanisms, including the use of pacing during a non-validated period. The updated mechanisms are intended to have a less aggressive congestion impact than would be exhibited by a standard TCP sender.
このドキュメントは、[RFC2861]で説明されているメソッドを廃止します。検証されていない期間のペーシングの使用など、一連のメカニズムを推奨します。更新されたメカニズムは、標準のTCP送信者が示すよりも積極的な輻輳の影響を少なくすることを目的としています。
The specification in this document is classified as "Experimental" pending experience with deployed implementations of the methods.
このドキュメントの仕様は、メソッドの実装の実装に関する「実験的」な保留中の経験として分類されています。
[RFC2861] described a simple modification to the TCP congestion control algorithm that decayed the cwnd after the transition to a "sufficiently-long" idle period. This used the slow-start threshold (ssthresh) to save information about the previous value of the congestion window. The approach relaxed the standard TCP behaviour for an idle session [RFC5681], which was intended to improve application performance. CWV also modified the behaviour when a sender transmitted at a rate less than allowed by cwnd.
[RFC2861]は、「十分に長い」アイドル期間への移行後にcwndを減衰させるTCP輻輳制御アルゴリズムの簡単な変更について説明しました。これは、スロースタートしきい値（ssthresh）を使用して、輻輳ウィンドウの以前の値に関する情報を保存しました。このアプローチは、アプリケーションのパフォーマンスを向上させることを目的としたアイドルセッション[RFC5681]の標準TCP動作を緩和しました。 CWVは、送信者がcwndで許可されているよりも低いレートで送信した場合の動作も変更しました。
[RFC2861] proposed two sets of responses: one after an "application-limited period" and one after an "idle period". Although this distinction was argued, in practice, differentiating the two conditions was found problematic in actual networks (see, e.g., [Bis10]). While this offered predictable performance for long on-off periods (>>1 RTT) or slowly varying rate-based traffic, the performance could be unpredictable for variable-rate traffic and depended both upon whether an accurate RTT had been obtained and the pattern of application traffic relative to the measured RTT.
[RFC2861]は、「アプリケーション限定期間」の後と「アイドル期間」の後の2組の応答を提案しました。この区別は議論されたが、実際には、2つの条件を区別することは、実際のネットワークでは問題があることがわかった（たとえば、[Bis10]を参照）。これにより、長いオンオフ期間（>> 1 RTT）またはゆっくり変化するレートベースのトラフィックで予測可能なパフォーマンスが提供されましたが、パフォーマンスは可変レートトラフィックでは予測できず、正確なRTTが取得されたかどうかと、測定されたRTTに対するアプリケーショントラフィック。
Many applications can and often do vary their transmission over a wide range of rates. Using [RFC2861], such applications often experienced varying performance, which made it hard for application developers to predict the TCP latency even when using a path with stable network characteristics. We argue that an attempt to classify application behaviour as application-limited or idle is problematic and also inappropriate. This document therefore explicitly avoids trying to differentiate these two cases, instead treating all rate-limited traffic uniformly.
多くのアプリケーションでは、さまざまなレートで伝送を変化させることができます。 [RFC2861]を使用すると、このようなアプリケーションはさまざまなパフォーマンスを経験することが多く、安定したネットワーク特性を持つパスを使用している場合でも、アプリケーション開発者がTCPレイテンシを予測することは困難でした。アプリケーションの動作をアプリケーション制限またはアイドルとして分類する試みは問題があり、不適切でもあると私たちは主張します。したがって、このドキュメントでは、これら2つのケースを区別することを明示的に避け、代わりにすべてのレート制限されたトラフィックを均一に扱います。
[RFC2861] has been implemented in some mainstream operating systems
as the default behaviour [Bis08]. Analysis (e.g., [Bis10] and
[Fai12]) has shown that a TCP sender using CWV is able to use
available capacity on a shared path after an idle period. This can
benefit variable-rate applications, especially over long delay paths,
when compared to the slow-start restart specified by standard TCP.
However, CWV would only benefit an application if the idle period
were less than several Retransmission Timeout (RTO) intervals
[RFC6298], since the behaviour would otherwise be the same as for
standard TCP, which resets the cwnd to the TCP Restart Window after
this period.
To enable better performance for variable-rate applications with TCP, some operating systems have chosen to support non-standard methods, or applications have resorted to "padding" streams by sending dummy data to maintain their sending rate when they have no data to transmit. Although transmitting redundant data across a network path provides good evidence that the path can sustain data at the offered rate, padding also consumes network capacity and reduces the opportunity for congestion-free statistical multiplexing. For variable-rate flows, the benefits of statistical multiplexing can be significant, and it is therefore a goal to find a viable alternative to padding streams.
TCPを使用する可変レートアプリケーションのパフォーマンスを向上させるために、一部のオペレーティングシステムは非標準のメソッドをサポートすることを選択しました。または、アプリケーションは、送信するデータがない場合にダミーデータを送信して送信レートを維持することにより、ストリームを「パディング」する手段をとっています。ネットワークパスを介して冗長データを送信すると、パスが提供されたレートでデータを維持できるという優れた証拠が得られますが、パディングはネットワーク容量を消費し、輻輳のない統計的多重化の機会を減らします。可変レートフローの場合、統計的多重化のメリットは非常に大きくなる可能性があるため、パディングストリームに代わる実行可能な方法を見つけることが目標です。
Experience with [RFC2861] suggests that although the CWV method benefited the network in a rate-limited scenario (reducing the probability of network congestion), the behaviour was too conservative for many common rate-limited applications. This mechanism did not therefore offer the desirable increase in application performance for rate-limited applications, and it is unclear whether applications actually use this mechanism in the general Internet.
[RFC2861]の経験から、CWV方式はレート制限シナリオ（ネットワークの輻輳の可能性を低減）でネットワークに利益をもたらしましたが、この動作は多くの一般的なレート制限アプリケーションでは保守的すぎることが示唆されました。したがって、このメカニズムは、レート制限されたアプリケーションのアプリケーションパフォーマンスの望ましい向上を提供せず、アプリケーションが実際にこのメカニズムを一般的なインターネットで使用しているかどうかは不明です。
Therefore, it was concluded that CWV, as defined in [RFC2861], was often a poor solution for many rate-limited applications. It had the correct motivation but the wrong approach to solving this problem.
したがって、[RFC2861]で定義されているように、CWVは多くのレート制限アプリケーションにとって不十分なソリューションであることが多いと結論付けられました。正しい動機はありましたが、この問題を解決するための間違ったアプローチがありました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The document assumes familiarity with the terminology of TCP congestion control [RFC5681].
このドキュメントは、TCP輻輳制御の用語[RFC5681]に精通していることを前提としています。
The following additional terminology is introduced in this document:
このドキュメントでは、次の追加の用語を紹介しています。
o cwnd-limited: A TCP flow that has sent the maximum number of segments permitted by the cwnd, where the application utilises the allowed sending rate (see Section 4.5.3).
o cwnd-limited：cwndによって許可された最大数のセグメントを送信したTCPフロー。アプリケーションは許可された送信レートを使用します（セクション4.5.3を参照）。
o pipeACK sample: A measure of the volume of data acknowledged by the network within an RTT.
o pipeACKサンプル：RTT内のネットワークによって確認応答されたデータの量の測定。
o pipeACK variable: A variable that measures the available capacity using the set of pipeACK samples (see Section 4.2).
o pipeACK変数：pipeACKサンプルのセットを使用して利用可能な容量を測定する変数（セクション4.2を参照）。
o pipeACK Sampling Period: The maximum period that a measured pipeACK sample may influence the pipeACK variable.
o pipeACKサンプリング期間：測定されたpipeACKサンプルがpipeACK変数に影響を与える可能性がある最大期間。
o Non-validated phase: The phase where the cwnd reflects a previous measurement of the available path capacity.
o 未検証フェーズ：cwndが使用可能なパス容量の以前の測定を反映するフェーズ。
o Non-validated period (NVP): The maximum period for which cwnd is preserved in the non-validated phase.
o 非検証期間（NVP）：cwndが非検証フェーズで保持される最大期間。
o Rate-limited: A TCP flow that does not consume more than one half of cwnd and hence operates in the non-validated phase. This includes periods when an application is either idle or chooses to send at a rate less than the maximum permitted by the cwnd.
o レート制限：cwndの半分以上を消費しないため、検証されていないフェーズで動作するTCPフロー。これには、アプリケーションがアイドル状態であるか、またはcwndで許可されている最大値未満の速度で送信することを選択した期間が含まれます。
o Validated phase: The phase where the cwnd reflects a current estimate of the available path capacity.
o 検証済みフェーズ：cwndが使用可能なパス容量の現在の見積もりを反映するフェーズ。
This section proposes an update to the TCP congestion control behaviour during a rate-limited interval. This new method intentionally does not differentiate between times when the sender has become idle or chooses to send at a rate less than the maximum allowed by the cwnd.
このセクションでは、レート制限インターバル中のTCP輻輳制御動作の更新を提案します。この新しい方法は、送信者がアイドル状態になったときと、cwndで許可されている最大値よりも低い速度で送信することを選択したときを意図的に区別しません。
In the non-validated phase, the capacity used by an application can be less than that allowed by the TCP cwnd. This update allows an application to preserve a recently used cwnd while in the non-validated phase and then to resume transmission at a previous rate without incurring the delay of slow-start. However, if the TCP sender experiences congestion using the preserved cwnd, it is required to immediately reset the cwnd to an appropriate value specified by the method. If a sender does not take advantage of the preserved cwnd within the non-validated period (NVP), the value of cwnd is reduced, ensuring the value better reflects the capacity that was recently actually used.
検証されていないフェーズでは、アプリケーションで使用される容量は、TCP cwndで許可されている容量より少なくなる可能性があります。この更新により、アプリケーションは、検証されていないフェーズで最近使用されたcwndを保持し、スロースタートの遅延を発生させることなく、以前のレートで送信を再開できます。ただし、保存されたcwndを使用してTCP送信側で輻輳が発生した場合は、cwndをメソッドで指定された適切な値にすぐにリセットする必要があります。送信者が非検証期間（NVP）内に保存されたcwndを利用しない場合、cwndの値が削減され、最近実際に使用された容量をより適切に反映するようになります。
It is expected that this update will satisfy the requirements of many rate-limited applications and at the same time provide an appropriate method for use in the Internet. New CWV reduces this incentive for an application to send "padding" data simply to keep transport congestion state.
このアップデートは、多くのレート制限されたアプリケーションの要件を満たし、同時にインターネットで使用するための適切な方法を提供することが期待されています。新しいCWVは、アプリケーションが「パディング」データを送信してトランスポートの輻輳状態を維持するというこのインセンティブを減らします。
The method is specified in the following subsections and is expected to encourage applications and TCP stacks to use standards-based congestion control methods. It may also encourage the use of long-lived connections where this offers benefit (such as persistent HTTP).
この方法は次のサブセクションで指定されており、アプリケーションとTCPスタックが標準ベースの輻輳制御方法を使用することを奨励すると予想されます。これにより、永続的なHTTPなど、メリットのある長寿命の接続の使用が促進される場合もあります。
A sender starts a TCP connection in the validated phase and initialises the pipeACK variable to the "undefined" value. This value inhibits use of the value in cwnd calculations.
送信者は検証フェーズでTCP接続を開始し、pipeACK変数を「未定義」の値に初期化します。この値は、cwnd計算での値の使用を禁止します。
[RFC6675] defines "FlightSize", a variable that indicates the instantaneous amount of data that has been sent but not cumulatively acknowledged. In this method, a new variable "pipeACK" is introduced to measure the acknowledged size of the network pipe. This is used to determine if the sender has validated the cwnd. pipeACK differs from FlightSize in that it is evaluated over a window of acknowledged data, rather than reflecting the amount of data outstanding.
[RFC6675]は「FlightSize」を定義しています。これは、送信されたが累積的に確認応答されていないデータの瞬間的な量を示す変数です。この方法では、ネットワークパイプの確認済みサイズを測定するために、新しい変数「pipeACK」が導入されています。これは、送信者がcwndを検証したかどうかを判断するために使用されます。 pipeACKは、未処理のデータ量を反映するのではなく、確認済みデータのウィンドウに対して評価されるという点でFlightSizeとは異なります。
A sender determines a pipeACK sample by measuring the volume of data that was acknowledged by the network over the period of a measured Round-Trip Time (RTT). Using the variables defined in [RFC6675], a value could be measured by caching the value of HighACK and, after one RTT, measuring the difference between the cached HighACK value and the current HighACK value. A sender MAY count TCP DupACKs that acknowledge new data when collecting the pipeACK sample. Other equivalent methods may be used.
送信者は、測定された往復時間（RTT）の期間中にネットワークによって確認応答されたデータの量を測定することにより、pipeACKサンプルを決定します。 [RFC6675]で定義されている変数を使用して、HighACKの値をキャッシュし、1つのRTTの後で、キャッシュされたHighACK値と現在のHighACK値の差を測定することで値を測定できます。送信者は、pipeACKサンプルを収集するときに新しいデータを確認するTCP DupACKをカウントしてもよい（MAY）。他の同等の方法が使用されてもよい。
A sender is not required to continuously update the pipeACK variable after each received ACK but SHOULD perform a pipeACK sample at least once per RTT when it has sent unacknowledged segments.
送信者は、ACKを受信するたびにpipeACK変数を継続的に更新する必要はありませんが、確認応答されていないセグメントを送信した場合、RTTごとに少なくとも1回はpipeACKサンプルを実行する必要があります。
The pipeACK variable MAY consider multiple pipeACK samples over the pipeACK Sampling Period. The value of the pipeACK variable MUST NOT exceed the maximum (highest value) within the pipeACK Sampling Period. This specification defines the pipeACK Sampling Period as Max(3*RTT, 1 second). This period enables a sender to compensate for large fluctuations in the sending rate, where there may be pauses in transmission, and allows the pipeACK variable to reflect the largest recently measured pipeACK sample.
pipeACK変数は、pipeACKサンプリング期間にわたって複数のpipeACKサンプルを考慮してもよい（MAY）。 pipeACK変数の値は、pipeACKサンプリング期間内の最大値（最高値）を超えてはなりません（MUST NOT）。この仕様では、pipeACKサンプリング周期をMax（3 * RTT、1秒）と定義しています。この期間により、送信側は送信速度の大きな変動（送信が一時停止される可能性がある場合）を補正でき、pipeACK変数に最近測定された最大のpipeACKサンプルを反映できます。
When no measurements are available (e.g., a sender that has just started transmission or immediately after loss recovery), the pipeACK variable is set to the "undefined value". This value is used to inhibit entering the non-validated phase until the first new measurement of a pipeACK sample. (Section 4.5 provides examples of implementation.)
使用可能な測定値がない場合（たとえば、送信を開始したばかりの送信者または損失回復の直後）、pipeACK変数は「未定義の値」に設定されます。この値は、pipeACKサンプルの最初の新しい測定まで、検証されていないフェーズに入ることを禁止するために使用されます。 （セクション4.5に実装例を示します。）
The pipeACK variable MUST NOT be updated during TCP Fast Recovery. That is, the sender stops collecting pipeACK samples during loss recovery. The method RECOMMENDS enabling the TCP SACK option [RFC2018] and RECOMMENDS the method defined in [RFC6675] to recover missing segments. This allows the sender to more accurately determine the number of missing bytes during the loss recovery phase, and using this method will result in a more appropriate cwnd following loss.
pipeACK変数は、TCP高速復旧中に更新してはなりません（MUST NOT）。つまり、送信側は損失回復中にpipeACKサンプルの収集を停止します。 TCP SACKオプションを有効にする方法[RFC2018]を推奨し、[RFC6675]で定義された方法を推奨して、欠落したセグメントを回復します。これにより、送信者は損失回復フェーズ中に失われたバイト数をより正確に判断でき、この方法を使用すると、損失後のより適切なcwndが得られます。
Note: The use of pipeACK rather than FlightSize can change the behaviour of a TCP flow when a sender does not always have data available to send. One example arises when there is a pause in transmission after sending a sequence of many packets, and the sender experiences loss at or near the end of its transmission sequence. In this case, the TCP flow may have used a significant amount of capacity just prior to the loss (which would be reflected in the volume of data acknowledged, recorded in the pipeACK variable), but at the actual time of loss, the number of unacknowledged packets in flight (at the end of the sequence) may be small, i.e., there is a small FlightSize. After loss recovery, the sender resets its congestion control state.
注：送信者が常に送信可能なデータを持っているとは限らない場合、FlightSizeではなくpipeACKを使用すると、TCPフローの動作が変わる可能性があります。多くのパケットのシーケンスを送信した後に送信が一時停止し、送信シーケンスが送信シーケンスの最後またはその近くで損失を被った場合に、1つの例が発生します。この場合、TCPフローは、損失の直前に相当量の容量を使用した可能性があります（これは、確認応答され、pipeACK変数に記録されたデータの量に反映されます）が、実際の損失時には、 （シーケンスの最後の）飛行中の未確認のパケットは小さい場合があります。つまり、FlightSizeが小さい場合があります。損失の回復後、送信者は輻輳制御状態をリセットします。
[Fai12] explored the benefits of different responses to congestion for application-limited streams. If the response is based only on the Loss FlightSize, the sender would assign a small cwnd and ssthresh, based only on the volume of data sent after the loss. When the sender next starts to transmit, it can incur many RTTs of delay in slow-start before it reacquires its previous rate. When the pipeACK value is also used to calculate the cwnd and ssthresh (as specified in Section 4.4.1), the sender can use a value that also reflects the recently used capacity before the loss. This prevents a variable-rate application from being unduly penalised. When the sender resumes, it starts at one-half its previous rate, similar to the behaviour of a bulk TCP flow [Hos15]. To ensure an appropriate reaction to ongoing congestion, this method requires that the pipeACK variable is reset after it is used in this way.
[Fai12]は、アプリケーションが限定されたストリームの輻輳に対するさまざまな応答の利点を調査しました。応答がLoss FlightSizeのみに基づいている場合、送信者は、損失後に送信されたデータの量のみに基づいて、小さなcwndとssthreshを割り当てます。送信側が次に送信を開始すると、スロースタートで以前のレートを再取得する前に、多くのRTTの遅延が発生する可能性があります。 pipeACK値がcwndおよびssthresh（セクション4.4.1で指定）の計算にも使用される場合、送信者は、損失前に最近使用された容量も反映する値を使用できます。これにより、可変レートのアプリケーションが過度にペナルティを受けることを防ぎます。送信者が再開すると、バルクTCPフロー[Hos15]の動作と同様に、以前のレートの半分で開始します。進行中の輻輳に対する適切な反応を保証するために、この方法では、pipeACK変数がこのように使用された後にリセットされる必要があります。
The updated method creates a new TCP sender phase that captures whether the cwnd reflects a validated or non-validated value. The phases are defined as:
更新されたメソッドは、cwndが検証済みの値または検証済みでない値を反映しているかどうかをキャプチャする新しいTCP送信側フェーズを作成します。フェーズは次のように定義されます。
o Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined (i.e., at the start or directly after loss recovery). This is the normal phase, where cwnd is expected to be an approximate indication of the capacity currently available along the network path, and the standard methods are used to increase cwnd (currently, the standard methods are described in [RFC5681]).
o 検証されたフェーズ：pipeACK> =（1/2）* cwnd、またはpipeACKは未定義です（つまり、開始時または損失回復の直後）。これは通常のフェーズであり、cwndはネットワークパスに沿って現在利用可能な容量のおおよその指標であると予想され、標準の方法を使用してcwndを増やします（現在、標準の方法は[RFC5681]で説明されています）。
o Non-validated phase: pipeACK <(1/2)*cwnd. This is the phase where the cwnd has a value based on a previous measurement of the available capacity, and the usage of this capacity has not been validated in the pipeACK Sampling Period, that is, when it is not known whether the cwnd reflects the currently available capacity along the network path. The mechanisms to be used in this phase seek to determine a safe value for cwnd and an appropriate reaction to congestion.
o 検証されていないフェーズ：pipeACK <（1/2）* cwnd。これは、cwndが使用可能な容量の以前の測定に基づく値を持ち、この容量の使用がpipeACKサンプリング期間で検証されていないフェーズです。つまり、cwndが現在の値を反映しているかどうかが不明な場合です。ネットワークパスに沿って利用可能な容量。このフェーズで使用されるメカニズムは、cwndの安全な値と輻輳に対する適切な反応を決定しようとします。
Note: A threshold is needed to determine whether a sender is in the validated or non-validated phase. A standard TCP sender in slow-start is permitted to double its FlightSize from one RTT to the next. This motivated the choice of a threshold value of 1/2. This threshold ensures a sender does not further increase the cwnd as long as the FlightSize is less than (1/2*cwnd). Furthermore, a sender with a FlightSize less than (1/2*cwnd) may, in the next RTT, be permitted by the cwnd to send at a rate that more than doubles the FlightSize; hence, this case needs to be regarded as non-validated, and a sender therefore needs to employ additional mechanisms while in this phase.
注：送信者が検証済みフェーズか非検証フェーズかを判別するには、しきい値が必要です。スロースタートの標準TCP送信者は、1つのRTTから次のRTTにFlightSizeを2倍にすることができます。これにより、1/2のしきい値を選択する動機が生まれました。このしきい値は、FlightSizeが（1/2 * cwnd）未満である限り、送信者がcwndをさらに増加させないことを保証します。さらに、FlightSizeが（1/2 * cwnd）未満の送信者は、次のRTTで、cwndがFlightSizeの2倍を超えるレートで送信することを許可される場合があります。したがって、このケースは検証されていないものと見なす必要があり、送信者はこのフェーズで追加のメカニズムを使用する必要があります。
A TCP sender implementing this specification MUST enter the non-validated phase when the pipeACK is less than (1/2)*cwnd. (The note at the end of Section 4.4.1 describes why pipeACK<=(1/2)*cwnd is expected to be a safe value.)
この仕様を実装するTCP送信者は、pipeACKが（1/2）* cwnd未満の場合、検証されていないフェーズに入る必要があります。 （セクション4.4.1の最後の注記では、pipeACK <=（1/2）* cwndが安全な値であると予想される理由を説明しています。）
A TCP sender that enters the non-validated phase preserves the cwnd (i.e., the cwnd only increases after a sender fully uses the cwnd in this phase; otherwise, the cwnd neither grows nor reduces). The phase is concluded when the sender transmits sufficient data so that pipeACK > (1/2)*cwnd (i.e., the sender is no longer rate-limited) or when the sender receives an indication of congestion.
検証されていないフェーズに入るTCP送信者は、cwndを保持します（つまり、送信者がこのフェーズでcwndを完全に使用した後でのみcwndが増加します。それ以外の場合、cwndは増加も減少もしません）。フェーズは、senderが十分なデータを送信してpipeACK>（1/2）* cwnd（つまり、送信側がレート制限されなくなった）になるか、送信側が輻輳の指示を受信したときに終了します。
After a fixed period of time (the non-validated period (NVP)), the sender adjusts the cwnd (Section 4.4.3). The NVP SHOULD NOT exceed five minutes. Section 5 discusses the rationale for choosing a safe value for this period.
一定期間（非検証期間（NVP））の後、送信者はcwndを調整します（セクション4.4.3）。 NVPは5分を超えてはなりません。セクション5では、この期間の安全な値を選択する根拠について説明します。
The behaviour in the non-validated phase is specified as:
検証されていないフェーズでの動作は、次のように指定されます。
o A sender determines whether to increase the cwnd based upon whether it is cwnd-limited (see Section 4.5.3):
o 送信者は、cwndが制限されているかどうかに基づいて、cwndを増やすかどうかを決定します（セクション4.5.3を参照）。
* A sender that is cwnd-limited MAY use the standard TCP method to increase cwnd (i.e., the standard method permits a TCP sender that fully utilises the cwnd to increase the cwnd each time it receives an ACK).
* cwndが制限されている送信者は、標準のTCP方法を使用してcwndを増やすことができます（つまり、標準の方法では、cwndを完全に利用するTCP送信者が、ACKを受信するたびにcwndを増やすことができます）。
* A sender that is not cwnd-limited MUST NOT increase the cwnd when ACK packets are received in this phase (i.e., needs to avoid growing the cwnd when it has not recently sent using the current size of cwnd).
* cwndで制限されていない送信者は、このフェーズでACKパケットを受信したときにcwndを増やしてはなりません（つまり、cwndの現在のサイズを使用して最近送信されていないときにcwndが大きくなるのを避ける必要があります）。
o If the sender receives an indication of congestion while in the non-validated phase (i.e., detects loss), the sender MUST exit the non-validated phase (reducing the cwnd as defined in Section 4.4.1).
o 送信者が非検証フェーズ中に輻輳の指示を受信した場合（つまり、損失を検出した場合）、送信者は非検証フェーズを終了する必要があります（セクション4.4.1で定義されているようにcwndを減らします）。
o If the Retransmission Timeout (RTO) expires while in the non-validated phase, the sender MUST exit the non-validated phase. It then resumes using the standard TCP RTO mechanism [RFC5681].
o 検証されていないフェーズで再送信タイムアウト（RTO）が期限切れになった場合、送信者は検証されていないフェーズを終了する必要があります。次に、標準のTCP RTOメカニズム[RFC5681]を使用して再開します。
o A sender with a pipeACK variable greater than (1/2)*cwnd SHOULD enter the validated phase. (A rate-limited sender will not normally be impacted by whether it is in a validated or non-validated phase, since it will normally not increase FlightSize to use the entire cwnd. However, a change to the validated phase will release the sender from constraints on the growth of cwnd and result in using the standard congestion response.)
o （1/2）* cwndより大きいpipeACK変数を持つ送信者は、検証フェーズに入る必要があります（SHOULD）。 （レート制限された送信側は、通常はFlightSizeを増やしてcwnd全体を使用することはないため、検証済みフェーズまたは非検証フェーズの影響を受けません。ただし、検証済みフェーズへの変更により、送信者はcwndの成長に対する制約であり、標準の輻輳応答を使用することになります。）
The cwnd-limited behaviour may be triggered during a transient condition that occurs when a sender is in the non-validated phase and receives an ACK that acknowledges received data, the cwnd was fully utilised, and more data is awaiting transmission than may be sent with the current cwnd. The sender MAY then use the standard method to increase the cwnd. (Note that if the sender succeeds in sending these new segments, the updated cwnd and pipeACK variables will eventually result in a transition to the validated phase.)
cwndが制限された動作は、送信者が検証されていないフェーズにあり、受信データを確認するACKを受信し、cwndが完全に利用され、送信されるよりも多くのデータが送信を待機しているときに発生する一時的な状態の間にトリガーされる場合があります現在のcwnd。次に、送信者は標準の方法を使用してcwndを増やすことができます（MAY）。 （送信者がこれらの新しいセグメントの送信に成功した場合、更新されたcwnd変数とpipeACK変数は、最終的には検証済みフェーズに移行することに注意してください。）
Reception of congestion feedback while in the non-validated phase is interpreted as an indication that it was inappropriate for the sender to use the preserved cwnd. The sender is therefore required to quickly reduce the rate to avoid further congestion. Since the cwnd does not have a validated value, a new cwnd value needs to be selected based on the utilised rate.
検証されていないフェーズでの輻輳フィードバックの受信は、送信者が保存されたcwndを使用することが不適切であったことを示すものと解釈されます。したがって、送信者は、さらに輻輳を回避するために、レートをすばやく下げる必要があります。 cwndには検証済みの値がないため、使用率に基づいて新しいcwnd値を選択する必要があります。
A sender that detects a packet drop MUST record the current FlightSize in the variable LossFlightSize and MUST calculate a safe cwnd for loss recovery using the method below:
パケットドロップを検出する送信者は、現在のFlightSizeを変数LossFlightSizeに記録する必要があり、以下の方法を使用して損失回復のための安全なcwndを計算する必要があります。
cwnd = (Max(pipeACK,LossFlightSize))/2.
The pipeACK value is not updated during loss recovery (see Section 4.2). If there is a valid pipeACK value, the new cwnd is adjusted to reflect that a non-validated cwnd may be larger than the actual FlightSize or recently used FlightSize (recorded in pipeACK). The updated cwnd therefore prevents overshoot by a sender, significantly increasing its transmission rate during the recovery period.
損失回復中はpipeACK値は更新されません（セクション4.2を参照）。有効なpipeACK値がある場合、新しいcwndは、検証されていないcwndが実際のFlightSizeまたは最近使用されたFlightSize（pipeACKに記録されている）よりも大きくなる可能性があることを反映するように調整されます。したがって、更新されたcwndは、送信者によるオーバーシュートを防ぎ、回復期間中の送信速度を大幅に向上させます。
At the end of the recovery phase, the TCP sender MUST reset the cwnd using the method below:
回復フェーズの最後に、TCP送信者は以下の方法を使用してcwndをリセットする必要があります。
cwnd = (Max(pipeACK,LossFlightSize) - R)/2.
Where R is the volume of data that was successfully retransmitted during the recovery phase. This corresponds to segments retransmitted and considered lost by the pipe estimation algorithm at the end of recovery. It does not include the additional cost of multiple retransmission of the same data. The loss of segments indicates that the path capacity was exceeded by at least R; hence, the calculated cwnd is reduced by at least R before the window is halved.
ここで、Rは、回復フェーズ中に正常に再送信されたデータの量です。これは、回復の終わりにパイプ推定アルゴリズムによって再送信され、失われたと見なされるセグメントに対応します。同じデータの複数の再送信の追加コストは含まれません。セグメントの損失は、パス容量が少なくともRを超えたことを示しています。したがって、計算されたcwndは、ウィンドウが半分になる前に少なくともRだけ減少します。
The calculated cwnd value MUST NOT be reduced below 1 TCP Maximum Segment Size (MSS).
計算されたcwnd値は、1 TCP最大セグメントサイズ（MSS）未満にしてはなりません（MUST NOT）。
After completing the loss recovery phase, the sender MUST re-initialise the pipeACK variable to the "undefined" value. This ensures that standard TCP methods are used immediately after completing loss recovery until a new pipeACK value can be determined.
損失回復フェーズの完了後、送信者はpipeACK変数を「未定義」値に再初期化する必要があります。これにより、損失回復が完了した直後に新しいpipeACK値を決定できるまで、標準のTCPメソッドが確実に使用されます。
The ssthresh is adjusted using the standard TCP method (Step 6 in Section 3.2 of RFC 5681 assigns the ssthresh a value equal to cwnd at the end of the loss recovery).
ssthreshは、標準のTCP方式を使用して調整されます（RFC 5681のセクション3.2のステップ6は、ssthreshに損失回復の最後にcwndと等しい値を割り当てます）。
Note: The adjustment by reducing cwnd by the volume of data not sent (R) follows the method proposed for Jump Start [Liu07]. The inclusion of the term R makes the adjustment more conservative than standard TCP. This is required, since a sender in the non-validated phase is allowed a rate higher than a standard TCP sender would have achieved in the last RTT (i.e., to have more than doubled the number of segments in flight relative to what was sent in the previous RTT). The additional reduction after congestion is beneficial when the LossFlightSize has significantly overshot the available path capacity, incurring significant loss (e.g., following a change of path characteristics or when additional traffic has taken a larger share of the network bottleneck during a period when the sender transmits less).
注：送信されないデータ量（R）によってcwndを減らすことによる調整は、ジャンプスタート[Liu07]で提案された方法に従います。 Rという用語を含めると、調整は標準のTCPよりも保守的になります。検証されていないフェーズの送信者は、最後のRTTで標準のTCP送信者が達成したレートよりも高いレートが許可されるため、これが必要です（つまり、送信されたセグメントと比較して、飛行中のセグメント数が2倍以上になります）以前のRTT）。 LossFlightSizeが使用可能なパス容量を大幅にオーバーシュートし、大幅な損失が生じた場合（たとえば、パス特性の変更後、または送信者が送信している期間中に追加のトラフィックがネットワークボトルネックの大きなシェアを占めた場合）輻輳後の追加の削減は有益です。もっと少なく）。
Note: The pipeACK value is only valid during a non-validated phase; therefore, this does not exceed cwnd/2. If LossFlightSize and R were small, then this can result in the final cwnd after loss recovery being at most one-quarter of the cwnd on detection of congestion. This reduction is conservative, and pipeACK is then reset to undefined; hence, cwnd updates after a congestion event do not depend upon the pipeACK history before congestion was detected.
注：pipeACK値は、検証されていないフェーズでのみ有効です。したがって、これはcwnd / 2を超えません。 LossFlightSizeとRが小さい場合、輻輳の検出時に、損失回復後の最終的なcwndが最大でcwndの4分の1になる可能性があります。この削減は控えめであり、pipeACKは未定義にリセットされます。したがって、輻輳イベント後のcwndの更新は、輻輳が検出される前のpipeACK履歴に依存しません。
TCP congestion control allows a sender to accumulate a cwnd that would allow it to send a burst of segments with a total size up to the difference between the FlightSize and cwnd. Such bursts can impact other flows that share a network bottleneck and/or may induce congestion when buffering is limited.
TCP輻輳制御により、送信者はcwndを蓄積できます。これにより、合計サイズがFlightSizeとcwndの差までのセグメントのバーストを送信できます。このようなバーストは、ネットワークのボトルネックを共有する他のフローに影響を与えたり、バッファリングが制限されているときに輻輳を引き起こしたりする可能性があります。
Various methods have been proposed to control the sender burstiness [Hug01] [All05]. For example, TCP can limit the number of new segments it sends per received ACK. This is effective when a flow of ACKs is received but cannot be used to control a sender that has not sent appreciable data in the previous RTT [All05].
送信者のバースト性を制御するために、さまざまな方法が提案されています[Hug01] [All05]。たとえば、TCPは、受信したACKごとに送信する新しいセグメントの数を制限できます。これは、ACKのフローが受信されたが、以前のRTT [All05]でかなりのデータを送信していない送信者を制御するために使用できない場合に有効です。
This document recommends using a method to avoid line-rate bursts after an idle or rate-limited interval when there is less reliable information about the capacity of the network path. A TCP sender in the non-validated phase SHOULD control the maximum burst size, e.g., using a rate-based pacing algorithm in which a sender paces out the cwnd over its estimate of the RTT, or some other method, to prevent many segments being transmitted contiguously at line-rate. The most appropriate method(s) to implement pacing depend on the design of the TCP/IP stack, speed of interface, and whether hardware support (such as TSO) is used. This document does not recommend any specific method.
このドキュメントでは、ネットワークパスの容量に関する信頼性の低い情報がある場合に、アイドルまたはレート制限インターバルの後のラインレートバーストを回避する方法を使用することを推奨しています。検証されていないフェーズのTCP送信者は、最大バーストサイズを制御する必要があります（SHOULD）。たとえば、送信者がCTTをRTTの推定値またはその他の方法でペースアウトするレートベースのペーシングアルゴリズムを使用して、多くのセグメントが防止されます。ラインレートで連続的に送信されます。ペーシングを実装する最も適切な方法は、TCP / IPスタックの設計、インターフェースの速度、およびハードウェアサポート（TSOなど）が使用されているかどうかによって異なります。このドキュメントでは、特定の方法を推奨していません。
An application that remains in the non-validated phase for a period greater than the NVP is required to adjust its congestion control state. If the sender exits the non-validated phase after this period, it MUST update the ssthresh:
NVPより長い期間非検証フェーズに留まるアプリケーションは、その輻輳制御状態を調整する必要があります。この期間の後に送信者が検証されていないフェーズを終了する場合は、ssthreshを更新する必要があります。
ssthresh = max(ssthresh, 3*cwnd/4).
ssthresh = max（ssthresh、3 * cwnd / 4）。
(This adjustment of ssthresh ensures that the sender records that it has safely sustained the present rate. The change is beneficial to rate-limited flows that encounter occasional congestion and could otherwise suffer an unwanted additional delay in recovering the sending rate.)
（ssthreshのこの調整により、送信者が現在のレートを安全に維持したことが記録されます。この変更は、時々発生する輻輳に遭遇し、送信レートの回復で不要な追加の遅延が発生する可能性があるレート制限されたフローに有益です。）
The sender MUST then update cwnd to be not greater than:
次に、送信者はcwndを次の値以下に更新する必要があります。
cwnd = max((1/2)*cwnd, IW).
cwnd = max（（1/2）* cwnd、IW）。
Where IW is the appropriate TCP initial window used by the TCP sender (see, e.g., [RFC5681]).
IWは、TCP送信者が使用する適切なTCP初期ウィンドウです（たとえば、[RFC5681]を参照）。
Note: These cwnd and ssthresh adjustments cause the sender to enter slow-start (since ssthresh > cwnd). This adjustment ensures that the sender responds conservatively after remaining in the non-validated phase for more than the non-validated period. In this case, it reduces the cwnd by a factor of two from the preserved value. This adjustment is helpful when flows accumulate but do not use a large cwnd; this adjustment seeks to mitigate the impact when these flows later resume transmission. This could, for instance, mitigate the impact if multiple high-rate application flows were to become idle over an extended period of time and then were simultaneously awakened by an external event.
注：これらのcwndおよびssthreshの調整により、送信者はスロースタートに入ります（ssthresh> cwndであるため）。この調整により、送信者は、検証されていない期間を超えて検証されていないフェーズに留まった後、控えめに応答します。この場合、それはcwndを保持された値から2倍に減らします。この調整は、フローが蓄積するが大きなcwndを使用しない場合に役立ちます。この調整は、これらのフローが後で送信を再開するときに影響を軽減することを目的としています。これにより、たとえば、複数の高速アプリケーションフローが長時間アイドル状態になり、その後外部イベントによって同時に起動された場合の影響を緩和できます。
This section provides informative examples of implementation methods. Implementations may choose to use other methods that comply with the normative requirements.
このセクションでは、実装方法の有益な例を示します。実装は、規範的な要件に準拠する他の方法を使用することを選択できます。
A pipeACK sample may be measured once each RTT. This reduces the sender processing burden for calculating after each acknowledgment and also reduces storage requirements at the sender.
pipeACKサンプルは、RTTごとに1回測定できます。これにより、各確認応答後に計算するための送信側の処理負担が軽減され、送信側のストレージ要件も軽減されます。
Since application behaviour can be bursty using CWV, it may be desirable to implement a maximum filter to accumulate the measured values so that the pipeACK variable records the largest pipeACK sample within the pipeACK Sampling Period. One simple way to implement this is to divide the pipeACK Sampling Period into several (e.g., five) equal-length measurement periods. The sender then records the start time for each measurement period and the highest measured pipeACK sample. At the end of the measurement period, any measurement(s) that is older than the pipeACK Sampling Period is discarded. The pipeACK variable is then assigned the largest of the set of the highest measured values.
アプリケーションの動作はCWVを使用するとバースト性になる可能性があるため、pipeACK変数がpipeACK Sampling Period内で最大のpipeACKサンプルを記録するように、測定値を累積する最大フィルターを実装することが望ましい場合があります。これを実装する簡単な方法の1つは、pipeACKのサンプリング周期をいくつかの（たとえば5つの）等しい長さの測定周期に分割することです。次に、送信者は、各測定期間の開始時間と、測定された最高のpipeACKサンプルを記録します。測定期間の最後に、pipeACKサンプリング期間より古い測定は破棄されます。次に、pipeACK変数に、最高の測定値のセットの最大値が割り当てられます。
pipeACK sample (Bytes)
^
| +----------+----------+ +----------+---......
| | Sample A | Sample B | No | Sample C | Sample D
| | | | Sample | |
| | |\ 5 | | | |
| | | | | | | /\ 4 |
| | | | | |\ 3 | | | \ |
| | | \ | | \--- | | / \ | /| 2
| |/ \------| - | | / \------/ \...
+//-+----------+---------\+----/ /----+/---------+-------------> Time
<------------------------------------------------|
Sampling Period Current Time
Figure 1: Example of Measuring pipeACK Samples
図1：pipeACKサンプルの測定例
Figure 1 shows an example of how measurement samples may be collected. At the time represented by the figure, new samples are being accumulated into sample D. Three previous samples also fall within the pipeACK Sampling Period: A, B, and C. There was also a period of inactivity between samples B and C during which no measurements were taken (because no new data segments were acknowledged). The current value of the pipeACK variable will be 5, the maximum across all samples. During this period, the pipeACK samples may be regarded as zero and hence do not contribute to the calculated pipeACK value.
図1は、測定サンプルの収集方法の例を示しています。図に示されている時点で、新しいサンプルがサンプルDに蓄積されています。以前の3つのサンプルもpipeACKサンプリング期間A、B、Cに該当します。サンプルBとCの間にも、非アクティブな期間があり、測定が行われた（新しいデータセグメントが確認されなかったため）。 pipeACK変数の現在の値は5で、すべてのサンプルで最大です。この期間中、pipeACKサンプルはゼロと見なされ、計算されたpipeACK値に寄与しません。
After one further measurement period, Sample A will be discarded, since it then is older than the pipeACK Sampling Period, and the pipeACK variable will be recalculated. Its value will be the larger of Sample C or the final value accumulated in Sample D.
さらに1つの測定期間の後、サンプルAはpipeACK Sampling Periodよりも古いため破棄され、pipeACK変数が再計算されます。その値は、サンプルCまたはサンプルDに累積された最終値の大きい方になります。
The mechanism requires a number of measurements of time. These measurements could be implemented using protocol timers but do not necessarily require a new timer to be implemented. Avoiding the use of dedicated timers can save operating system resources, especially when there may be large numbers of TCP flows.
このメカニズムでは、多数の時間測定が必要です。これらの測定はプロトコルタイマーを使用して実装できますが、必ずしも新しいタイマーを実装する必要はありません。専用タイマーの使用を回避すると、特に多数のTCPフローがある場合に、オペレーティングシステムのリソースを節約できます。
The NVP could be measured by recording a timestamp when the sender enters the non-validated phase. Each time a sender transmits a new segment, this timestamp can be used to determine if the NVP has expired. If the measured period exceeds the NVP, the sender can then take into account how many units of the NVP have passed and make one reduction (defined in Section 4.4.3) for each NVP.
NVPは、送信者が検証されていないフェーズに入ったときにタイムスタンプを記録することで測定できます。送信者が新しいセグメントを送信するたびに、このタイムスタンプを使用して、NVPの有効期限が切れているかどうかを判断できます。測定された期間がNVPを超える場合、送信者はNVPの何ユニットが通過したかを考慮して、各NVPについて1つの削減（セクション4.4.3で定義）を行うことができます。
Similarly, the time measurements for collecting pipeACK samples and determining the pipeACK Sampling Period could be derived by using a timestamp to record when each sample was measured and using this to calculate how much time has passed when each new ACK is received.
同様に、pipeACKサンプルを収集し、pipeACKサンプリング期間を決定するための時間測定値は、タイムスタンプを使用して各サンプルが測定された時間を記録し、これを使用して新しいACKを受信するたびに経過した時間を計算することによって導出できます。
A sender needs to implement a method that detects the cwnd-limited condition (see Section 4.4). This detects a condition where a sender in the non-validated phase receives an ACK, but the size of cwnd prevents sending more new data.
送信者は、cwnd制限条件を検出するメソッドを実装する必要があります（セクション4.4を参照）。これは、検証されていないフェーズの送信者がACKを受信する状態を検出しますが、cwndのサイズにより、新しいデータの送信が妨げられます。
In simple terms, this condition is true only when the FlightSize of a TCP sender is equal to or larger than the current cwnd. However, an implementation also needs to consider constraints on the way in which the cwnd variable can be used; for instance, implementations need to support other TCP methods such as the Nagle Algorithm and TCP Segment Offload (TSO) that also use cwnd to control transmission. These other methods can result in a sender becoming cwnd-limited when the cwnd is nearly, rather than completely, equal to the FlightSize.
簡単に言うと、この条件は、TCP送信者のFlightSizeが現在のcwnd以上である場合にのみ当てはまります。ただし、実装では、cwnd変数の使用方法に関する制約も考慮する必要があります。たとえば、実装では、NagleアルゴリズムやTCPセグメントオフロード（TSO）など、他にもcwndを使用して送信を制御する他のTCPメソッドをサポートする必要があります。これらの他のメソッドは、cwndがFlightSizeと完全ではなくほぼ同じである場合に、送信者がcwnd制限になる可能性があります。
This section documents the rationale for selecting the maximum period that cwnd may be preserved, known as the NVP.
このセクションでは、NVPと呼ばれる、cwndが保持される最大期間を選択する根拠を説明します。
Limiting the period that cwnd may be preserved avoids undesirable side effects that would result if the cwnd were to be kept unnecessarily high for an arbitrarily long period, which was a part of the problem that CWV originally attempted to address. The period a sender may safely preserve the cwnd is a function of the period that a network path is expected to sustain the capacity reflected by cwnd. There is no ideal choice for this time.
cwndが保持される期間を制限することで、CWVが最初に対処しようとしていた問題の一部である、cwndが不必要に長い期間不必要に高く維持される場合に発生する望ましくない副作用を回避します。送信者がcwndを安全に保持できる期間は、ネットワークパスがcwndによって反映される容量を維持すると予想される期間の関数です。今回は理想的な選択肢はありません。
A period of five minutes was chosen for this NVP. This is a compromise that was larger than the idle intervals of common applications but not sufficiently larger than the period for which the capacity of an Internet path may commonly be regarded as stable. The capacity of wired networks is usually relatively stable for periods of several minutes, and that load stability increases with the capacity. This suggests that cwnd may be preserved for at least a few minutes.
このNVPには5分の期間が選択されました。これは、一般的なアプリケーションのアイドル間隔よりも大きく、インターネットパスの容量が一般的に安定していると見なされる期間よりも十分に大きくない妥協です。有線ネットワークの容量は通常、数分間は比較的安定しており、負荷の安定性は容量とともに増加します。これは、cwndが少なくとも数分間保持される可能性があることを示唆しています。
There are cases where the TCP throughput exhibits significant variability over a time less than five minutes. Examples could include wireless topologies, where TCP rate variations may fluctuate on the order of a few seconds as a consequence of medium access protocol instabilities. Mobility changes may also impact TCP performance over short time scales. Senders that observe such rapid changes in the path characteristic may also experience increased congestion with the new method; however, such variation would likely also impact TCP's behaviour when supporting interactive and bulk applications.
TCPスループットが5分未満の時間で大きな変動を示す場合があります。例としては、ワイヤレストポロジが挙げられ、TCPアクセスレートの変動は、メディアアクセスプロトコルの不安定性の結果として数秒程度変動する可能性があります。モビリティの変更は、短期間のTCPパフォーマンスにも影響を与える可能性があります。パスの特性のこのような急速な変化を観察する送信者も、新しい方法で輻輳が増加する可能性があります。ただし、このようなバリエーションは、対話型アプリケーションとバルクアプリケーションをサポートするときのTCPの動作にも影響を与える可能性があります。
Routing algorithms may change the network path that is used by a transport. Although a change of path can in turn disrupt the RTT measurement and may result in a change of the capacity available to a TCP connection, we assume these path changes do not usually occur frequently (compared to a time frame of a few minutes).
ルーティングアルゴリズムは、トランスポートで使用されるネットワークパスを変更する場合があります。パスの変更はRTT測定を妨害し、TCP接続で利用可能な容量の変更をもたらす可能性がありますが、これらのパスの変更は通常（数分の時間枠と比較して）頻繁に発生しないと想定しています。
The value of five minutes is therefore expected to be sufficient for most current applications. Simulation studies (e.g., [Bis11]) also suggest that for many practical applications, the performance using this value will not be significantly different from that observed using a non-standard method that does not reset the cwnd after idle.
したがって、現在のほとんどのアプリケーションでは5分の値で十分であると予想されます。シミュレーション調査（例：[Bis11]）はまた、多くの実用的なアプリケーションでは、この値を使用したパフォーマンスは、アイドル後にcwndをリセットしない非標準の方法を使用して観察されたものと大幅に異なることはないことを示唆しています。
Finally, other TCP sender mechanisms have used a five-minute timer, and there could be simplifications in some implementations by reusing the same interval. TCP defines a default user timeout of five minutes [RFC793], which is how long transmitted data may remain unacknowledged before a connection is forcefully closed.
最後に、他のTCP送信機メカニズムは5分のタイマーを使用しており、同じ間隔を再利用することにより、実装によっては簡素化できる場合があります。 TCPは、デフォルトのユーザータイムアウトを5分[RFC793]に定義しています。これは、接続が強制的にクローズされる前に、送信されたデータが確認応答されないままでいられる時間です。
General security considerations concerning TCP congestion control are discussed in [RFC5681]. This document describes an algorithm that updates one aspect of the congestion control procedures, so the considerations described in [RFC5681] also apply to this algorithm.
TCP輻輳制御に関する一般的なセキュリティの考慮事項は、[RFC5681]で説明されています。このドキュメントでは、輻輳制御手順の1つの側面を更新するアルゴリズムについて説明しているため、[RFC5681]で説明されている考慮事項は、このアルゴリズムにも適用されます。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<http：//www.rfc- editor.org/info/rfc2018>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, DOI 10.17487/RFC2861, June 2000, <http://www.rfc-editor.org/info/rfc2861>.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP Congestion Window Validation」、RFC 2861、DOI 10.17487 / RFC2861、2000年6月、<http://www.rfc-editor.org/info / rfc2861>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<http：//www.rfc- editor.org/info/rfc6298>。
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, DOI 10.17487/RFC6675, August 2012, <http://www.rfc-editor.org/info/rfc6675>.
[RFC6675] Blanton、E.、Allman、M.、Wang、L.、Jarvinen、I.、Kojo、M。、およびY. Nishida、「TCPの選択的確認応答（SACK）に基づく保守的な損失回復アルゴリズム」、 RFC 6675、DOI 10.17487 / RFC6675、2012年8月、<http://www.rfc-editor.org/info/rfc6675>。
[All05] Allman, M. and E. Blanton, "Notes on Burst Mitigation for Transport Protocols", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 2, DOI 10.1145/1064413.1064419, April 2005.
[All05] Allman、M。、およびE. Blanton、「トランスポートプロトコルのバースト軽減に関するメモ」、ACM SIGCOMM Computer Communication Review、Volume 35、Issue 2、DOI 10.1145 / 1064413.1064419、2005年4月。
[Bis08] Biswas, I. and G. Fairhurst, "A Practical Evaluation of Congestion Window Validation Behaviour", 9th Annual Postgraduate Symposium in the Convergence of Telecommunications, Networking and Broadcasting (PGNet), Liverpool, UK, 2008.
[Bis08] Biswas、I.およびG. Fairhurst、「A Congestion Window Validation Behaviour Behaviour Behaviour Behaviour」、第9回年次大学院シンポジウム、電気通信、ネットワークおよび放送（PGNet）のコンバージェンス、イギリス、リバプール、2008年。
[Bis10] Biswas, I., Sathiaseelan, A., Secchi, R., and G. Fairhurst, "Analysing TCP for Bursty Traffic", Int'l J. of Communications, Network and System Sciences, DOI 10.4236/ijcns.2010.37078, July 2010.
[Bis10] Biswas、I.、Sathiaseelan、A.、Secchi、R.、and G. Fairhurst、 "Analysing TCP for Bursty Traffic"、Int'l J. of Communications、Network and System Sciences、DOI 10.4236 / ijcns.2010.37078 、2010年7月。
[Bis11] Biswas, I., "Internet Congestion Control for Variable-Rate TCP Traffic", PhD Thesis, School of Engineering, University of Aberdeen, 2011.
[Bis11] Biswas、I。、「可変レートTCPトラフィックのインターネット輻輳制御」、博士論文、工学部、アバディーン大学、2011年。
[Fai12] Sathiaseelan, A., Secchi, R., Fairhurst, G., and I. Biswas, "Enhancing TCP Performance to support Variable-Rate Traffic", 2nd Capacity Sharing Workshop, ACM CoNEXT, Nice, France, December 2012.
[Fai12] Sathiaseelan、A.、Secchi、R.、Fairhurst、G。、およびI. Biswas、「Enhanceing TCP Performance to support Variable-Rate Traffic」、第2容量共有ワークショップ、ACM CoNEXT、ニース、フランス、2012年12月。
[Hos15] Hossain, Z., "A Study of Mechanisms to Support Variable-Rate Internet Applications over a Multi-service Satellite Platform", PhD Thesis, School of Engineering, University of Aberdeen, January 2015.
[Hos15] Hossain、Z.、「マルチサービスサテライトプラットフォームを介して可変レートインターネットアプリケーションをサポートするメカニズムの研究」、博士論文、工学部、アバディーン大学、2015年1月。
[Hug01] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress, draft-hughes-restart-00, December 2001.
[Hug01] Hughes、A.、Touch、J。、およびJ. Heidemann、「Issues in TCP Slow-Start Restart After After Idle」、Work in Progress、draft-hughes-restart-00、2001年12月。
[Liu07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion Control without a Startup Phase", 5th International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), Los Angeles, California, February 2007.
[Liu07] Liu、D.、Allman、M.、Jin、S。、およびL. Wang、「起動フェーズなしの輻輳制御」、高速長距離ネットワークのプロトコルに関する第5回国際ワークショップ（PFLDnet）、ロサンゼルス、カリフォルニア、2007年2月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
Acknowledgments
謝辞
This document was produced by the TCP Maintenance and Minor Extensions (tcpm) working group.
このドキュメントは、TCP Maintenance and Minor Extensions（tcpm）ワーキンググループによって作成されました。
The authors acknowledge the contributions of Dr. I. Biswas and Dr. Ziaul Hossain in supporting the evaluation of CWV and for their help in developing the mechanisms proposed in this document. We also acknowledge comments received from the Internet Congestion Control Research Group, in particular Yuchung Cheng, Mirja Kuehlewind, Joe Touch, and Mark Allman. This work was partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
著者は、CWVの評価をサポートし、このドキュメントで提案されているメカニズムを開発するのを支援してくれたDr. I. BiswasとDr. Ziaul Hossainの貢献を認めます。また、インターネットの輻輳制御研究グループから寄せられたコメント、特にユチュン・チェン、ミルジャ・キュールウィンド、ジョー・タッチ、マーク・オールマンにも感謝いたします。この作業の一部は、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、その第7フレームワークプログラムの下で欧州共同体から資金提供を受けました。
Authors' Addresses
著者のアドレス
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom
Godred Fairhurst University of Aberdeen School of Engineeringフレーザーノーブルビルディングアバディーン、スコットランドAB24 3UEイギリス
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Arjuna Sathiaseelan University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom
Arjuna Sathiaseelanアバディーン大学工学部Fraser Noble Buildingアバディーン、スコットランドAB24 3UEイギリス
Email: arjuna@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Raffaello Secchi University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom
Raffaello Secchiアバディーン大学工学部Fraser Noble Buildingアバディーン、スコットランドAB24 3UEイギリス
Email: raffaello@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk