Network Working Group S. Bhandarkar
Request for Comments: 4653 A. L. N. Reddy
Category: Experimental Texas A&M University
M. Allman
ICIR/ICSI
E. Blanton
Purdue University
August 2006
Improving the Robustness of TCP to Non-Congestion Events
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications.
この文書では、TCPのための非輻輳ロバストネス（NCR）を指定します。ネットワークからの明示的な輻輳通知の非存在下で、TCPは、輻輳の指標として損失を使用します。 TCPは損失を検出方法の一つは、3つの重複確認応答の到着を使用しています。しかし、このヒューリスティックは、特にネットワークパスが性能低下をもたらす、（何らかの理由で）セグメントを並べ替える場合には、必ずしも正しくありません。 TCP-NCRより良いセグメント並べ替えから、真のセグメント損失を明確にする目的で、接続の現在の状態に基づいて、損失回復をトリガするために必要な重複確認応答の数を増やすことによって、この性能劣化を軽減するように設計されています。このドキュメントでは、TCPへの変更、ならびにこれらの変更の費用と便益を指定します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. NCR Description .................................................5
3. Algorithm .......................................................6
3.1. Initialization .............................................8
3.2. Terminating Extended Limited Transmit and
Preventing Bursts ..........................................9
3.3. Extended Limited Transmit .................................10
3.4. Entering Loss Recovery ....................................11
4. Advantages .....................................................12
5. Disadvantages ..................................................12
6. Related Work ...................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
One strength of TCP [RFC793] lies in its ability to adjust its sending rate according to the perceived congestion in the network [Jac88, RFC2581]. In the absence of explicit notification of congestion from the network, TCP uses segment loss as an indication of congestion (i.e., assuming queue overflow). TCP receivers send cumulative acknowledgments (ACKs) indicating the next sequence number expected from the sender for arriving segments [RFC793]. When segments arrive out of order, duplicate ACKs are generated. As specified in [RFC2581], a TCP sender uses the arrival of three duplicate ACKs as an indication of segment loss. The TCP sender retransmits the lost segment and reduces the load imposed on the network, assuming the segment loss was caused by resource contention within the network path. The TCP sender does not assume loss on the first or second duplicate ACK, but waits for three duplicate ACKs to account for minor packet reordering. However, the use of this constant threshold of duplicate ACKs has several problems that can be mitigated with a dynamic threshold.
TCPの一つ強度は[RFC793]ネットワーク[Jac88、RFC2581]で認識される混雑に応じて、送信レートを調整する能力にあります。ネットワークから輻輳の明示的な通知の非存在下で、TCPは、輻輳の兆候（すなわち、キューのオーバーフローを想定）としてセグメント損失を使用します。 TCP受信機は、セグメント[RFC793]に到着するために、送信者から期待される次のシーケンス番号を示す累積確認応答（ACKを）送信します。セグメントは順序が狂って到着した場合、重複ACKが生成されます。 [RFC2581]で指定されるように、TCP送信者は、セグメント損失の指標としての3個の重複ACKの到着を使用します。 TCP送信者は、失われたセグメントを再送し、セグメント損失は、ネットワークパス内のリソースの競合によって引き起こされたと仮定すると、ネットワークの負荷を低減します。 TCPの送信者は、第一又は第二の重複ACKの損失を負うものではありませんが、3つの重複ACKを待つマイナーパケット並べ替えを説明するために。ただし、重複ACKのこの一定のしきい値を使用すると、動的しきい値を緩和することができるいくつかの問題があります。
The following is an example of TCP's behavior:
以下は、TCPの動作の例です。
+ TCP A is the data sender, and TCP B is the data receiver.
+ TCP Aは、データ送信側であり、TCP Bは、データ受信機です。
+ TCP A sends 10 segments, each consisting of a single data byte (i.e., transmits bytes 1-10 in segments 1-10).
+ TCP A（すなわち、セグメント1~10のバイト1~10を送信する）それぞれが単一のデータ・バイトから成る、10個のセグメントを送信します。
+ Assume segment 3 is dropped in the network.
+セグメント3がネットワークにドロップされると仮定する。
+ TCP B cumulatively acknowledges segments 1 and 2, making the cumulative ACK transmitted to the sender 3 (the next expected sequence number). (Note: TCP B may generate one or two ACKs, depending on whether delayed ACKs [RFC1122, RFC2581] are employed.)
+ TCP Bは累積センダ3（次の期待シーケンス番号）に送信累積ACKを行う、セグメント1及び2を認めます。 （注：TCP Bは、遅延ACK [RFC1122、RFC2581]を使用しているかどうかに応じて、一つまたは二つのACKを生成してもよいです。）
+ The arrival of segments 4-10 at TCP B will each trigger the transmission of a cumulative ACK for sequence number 3. (Note: [RFC2581] recommends that delayed ACKs not be used when the ACK is triggered by an out-of-order segment.)
+ TCP Bにおけるセグメント4~10の到着は、それぞれ配列番号3の累積ACKの送信をトリガする（注：[RFC2581]はACKをアウト・オブ・オーダーによってトリガされたときに遅延ACKを使用しないことをお勧めしますセグメント。）
+ When TCP A receives the third duplicate ACK (or fourth ACK overall) for sequence number 3, TCP A will retransmit segment 3 and reduce the sending rate by roughly half (see [RFC2581] for specifics on the congestion control state adjustments).
TCP Aは、配列番号3のための第3の重複ACK（又は全体的な第四ACK）を受信すると+、TCP Aは、（輻輳制御状態の調整に詳細については[RFC2581]を参照）セグメント3を再送し、おおよそ半分に送信レートを低下させます。
Alternatively, suppose segment 3 was not dropped by the network, but rather delayed such that segment 3 arrives at TCP B after segment 10. The above scenario will play out in precisely the same manner insomuch as a retransmission of segment 3 will be triggered. In other words, TCP is not capable of disambiguating this reordering event from a segment loss, resulting in an unnecessary retransmission and rate reduction.
代替的に、と仮定するセグメント3は、ネットワークによって廃棄されなかったのではなく、セグメント3は、上記のシナリオは、セグメント3の再送信がトリガされるinsomuchように正確に同じようにして再生されたセグメント10の後TCP Bに到達するように遅延しました。換言すれば、TCPは、不必要な再送信レートの減少をもたらす、セグメント損失からこの並べ替えイベントを明確化することができません。
The following is the specific motivation behind making TCP robust to reordered segments:
以下は、並べ替えのセグメントに強力なTCPを作るの背後にある特定の動機です。
* A number of Internet measurement studies have shown that packet reordering is not a rare phenomenon [Pax97, BPS99, JIDKT03, GPL04]. Further, the reordering can be well beyond that required for fast retransmit to be falsely triggered.
*インターネットの測定研究の数は、パケットの並べ替えは珍しい現象[Pax97、BPS99、JIDKT03、GPL04]ではないことを示しています。さらに、並べ替えがうまく誤ってトリガするための高速再送信のために必要なものを超えてすることができます。
* [BA02, ZKFP03] show the negative performance implications that packet reordering has on current TCP.
* [BA02、ZKFP03]パケットの並べ替えは、現在のTCP上であることを否定パフォーマンスへの影響を示しています。
* The requirement imposed by TCP for almost in-order packet delivery places a constraint on the design of future technology. Novel routing algorithms, network components, link-layer retransmission mechanisms, and applications could all be looked at with a fresh perspective if TCP were to be more robust to segment reordering. For instance, high-speed packet switches could cause resequencing of packets if TCP were more robust. There has been work proposed in the literature explicitly to ensure that packet ordering is maintained in such switches (e.g., [KM02]). Also, link-layer mechanisms that attempt to recover
*ほとんどのインオーダーパケット配信のためのTCPによって課される要件は、将来の技術の設計上の制約を課します。 TCPは、セグメント並べ替えに対してよりロバストであるとした場合に新規ルーティングアルゴリズム、ネットワークコンポーネント、リンク層再送信機構、およびアプリケーションは、すべての新鮮な視点で見たことができます。 TCPは、より堅牢であれば例えば、高速パケットスイッチは、パケットの再配列を引き起こす可能性があります。明示的にパケットの順序を保証するために、文献で提案されている作業は、このようなスイッチに維持されるがあった（例えば、[KM02]）。回復を試みる。また、リンク層の仕組み
from packet corruption by retransmitting could be allowed to reorder packets, and thus increase the chances of local loss repair rather than rely on TCP to repair the loss (and, needlessly reduce its sending rate). Additional examples include multi-path routing, high-delay satellite links, and some of the schemes proposed for a differentiated services architecture. By making TCP more robust to non-congestion events, TCP-NCR may open the design space of the future Internet components.
再送信によるパケットの破損からは、パケットの順序を変更することができ、ひいては地域の損失修復の可能性を高めるのではなく損失を修復する（そして、不その送信レートを下げる）ためにTCPに頼ることができます。さらなる例は、マルチパスルーティング、高遅延衛星リンク、および差別化サービスアーキテクチャのために提案されたスキームのいくつかを含みます。非輻輳イベントにTCPをより強固にすることにより、TCP-NCRは、将来のインターネットコンポーネントの設計空間を開くことができます。
In this document, we specify a set of TCP sender modifications to provide Non-Congestion Robustness (NCR) to TCP. In particular, these changes are built on top of TCP with selective acknowledgments (SACKs) [RFC2018] and the SACK-based loss recovery scheme given in [RFC3517], since SACK is widely deployed at this point ([MAF05] indicates that 68% of web servers and 88% of web clients utilize SACK as of spring 2004).
この文書では、我々は、TCPへの非輻輳ロバストネス（NCR）を提供するために、TCPの送信者の変更のセットを指定します。 SACKが広く、この点で展開されているので、特に、これらの変更は、選択的確認応答とTCP（サック）[RFC2018]及び[RFC3517]で与えられたSACKベースの損失回復方式の上に構築されている（[MAF05]は68％いることを示しWebサーバとWebクライアントの88％の2004年春）のようSACKを利用しています。
Note that the TCP-NCR algorithm provided in this document could be easily adapted to SCTP [RFC2960] since SCTP uses congestion control algorithms similar to TCP's (and thus has the same reordering robustness issues).
本書で提供されるTCP-NCRアルゴリズムが容易SCTP SCTPは、TCPのと同様の輻輳制御アルゴリズムを使用して（したがって、同一のリオーダリング堅牢性の問題を有している）ので、[RFC2960]に適合させることができることに留意されたいです。
As noted in several places in the remainder of this document, we consider TCP-NCR experimental in that more experience with the techniques is required before TCP-NCR should be used on a large scale on the Internet. We encourage implementation and experimentation with TCP-NCR in the hopes of gaining an understanding of its suitability for wide-scale deployment.
この文書の残りの部分でいくつかの場所で述べたように、我々はインターネット上で大規模に使用されなければならないTCP-NCRの前に必要とされる技術を用いてより多くの経験でTCP-NCRの実験を考えます。私たちは、大規模な展開のためのその適合性の理解を得ることを希望してTCP-NCRでの実装と実験を奨励します。
The remainder of this document is organized as follows. Section 2 provides a high-level description of the TCP-NCR mechanisms. In Section 3, we specify the TCP-NCR algorithm. Section 4 provides a brief overview of the benefits of TCP-NCR, while Section 5 discusses the drawbacks. Section 6 discusses related work. Section 7 discusses security concerns.
このドキュメントの残りは以下の通り構成されています。セクション2は、TCP-NCRメカニズムの高レベルの説明を提供します。第3節では、TCP-NCRのアルゴリズムを指定します。第5節は、欠点を説明しながら、第4章では、TCP-NCRの利点の概要を説明します。第6節は、関連する作業について説明します。第7節は、セキュリティ上の問題について説明します。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Readers should be familiar with the TCP terminology (e.g., FlightSize, Pipe) given in [RFC2581] and [RFC3517].
読者は、[RFC2581]及び[RFC3517]で与えられたTCPの用語（例えば、FlightSize、パイプ）に精通しなければなりません。
As discussed above, in the face of packet reordering, three duplicate ACKs may not be enough to disambiguate loss from reordering. In this section we provide a non-normative sketch of TCP-NCR. The detailed algorithms for implementing Non-Congestion Robustness for TCP are presented in the next section.
上述したように、パケットの並べ替えの面では、3つの重複ACKが並べ替えの損失を明確にするのに十分ではないかもしれません。このセクションでは、TCP-NCRの非規範的なスケッチを提供しています。 TCPのための非輻輳堅牢性を実現するための詳細なアルゴリズムは、次のセクションで提示されています。
The general idea behind TCP-NCR is to increase the threshold used to trigger a fast retransmission from the current fixed value of three duplicate ACKs [RFC2581] to approximately a congestion window of data having left the network (but not less than the currently standardized value of three duplicate ACKs). Since cwnd represents the amount of data a TCP flow can transmit in one round-trip time (RTT), waiting to receive notice that cwnd bytes have left the network before deciding whether the root cause is loss or reordering imposes a delay of roughly one RTT on both the retransmission and the congestion control response. The appropriate choice for a new value of the threshold is essentially a trade-off between making the best decision regarding the cause of the duplicate ACKs and responsiveness. The choice to trigger a retransmission only after a cwnd's worth of data is known to have left the network represents roughly the largest amount of time a TCP can wait before the (often costly) retransmission timeout may be triggered. Therefore, the algorithm described in this document attempts to make the best decision possible at the expense of timeliness.
TCP-NCRの背後にある一般概念は、現在、規格値よりも（あまりないネットワークを去ったデータの約混雑ウィンドウに3個の重複ACK [RFC2581]の現在の固定値からの高速再送をトリガするための閾値を増加させることです3個の重複ACKの）。 CWNDはCWNDバイトが根本的な原因は、損失または再順序付けが約1 RTTの遅延を課しているかどうかを決定する前に、ネットワークを去ったという通知を受け取るのを待って、TCPフローが1往復時間（RTT）で送信できるデータの量を表すため再送信と輻輳制御応答の両方で。しきい値の新しい値のための適切な選択は、基本的に重複ACKと応答性の原因に関する最高意思決定とのトレードオフです。データのみののcwnd分後に再送をトリガする選択は、（多くの場合、高価な）再送タイムアウトをトリガすることができる前にTCPが待機する時間のおおよその最大量を表しネットワークを残していることが知られています。したがって、この文書に記載されたアルゴリズムは、適時性を犠牲にして最善の決断をしようとします。
Simply increasing the threshold before retransmitting a segment can make TCP brittle to packet loss or ACK loss since such loss reduces the number of duplicate ACKs that will arrive at the sender from the receiver. For instance, if the cwnd is 10 segments and one segment is lost, a duplicate ACK threshold of 10 will never be met because duplicate ACKs corresponding to at most 9 segments will arrive at the sender. To offset the issue of loss, we extend TCP's Limited Transmit [RFC3042] scheme to allow for the sending of new data during the period when the TCP sender is disambiguating loss and reordering. This new data serves to increase the likelihood that enough duplicate ACKs arrive at the sender to trigger loss recovery if it is appropriate.
単にそのような損失は、受信機から送信側に到着する重複ACKの数を減少させるので、パケット損失またはACK損失にTCPが脆くすることができ、セグメントを再送信する前に、閾値を増加させます。 CWNDが10個のセグメントと一つのセグメントが失われている場合に最も9つのセグメントに対応する重複ACKが送信者に到達するため、例えば、10の重複ACK閾値が満たされることはありません。損失の問題を相殺するために、我々は、TCPの送信側が損失と並べ替えを一義化された期間中に、新たなデータの送信を可能にするために、TCPの限定送信[RFC3042]の方式を拡張します。この新しいデータは、それが適切である場合、十分な重複ACKが損失回復をトリガするために、送信者に届く可能性を高めるのに役立ちます。
Note that TCP tightly couples reliability and congestion control: when a segment is declared lost, a retransmission is triggered, and a change to the sending rate is also made on the assumption that the drop is due to resource contention [RFC2581]. Therefore, simply by changing the retransmission trigger, the congestion control response is also changed. However, we lack experience on the Internet as to whether delaying the point that a rate reduction takes place is appropriate for wide-scale deployment. Therefore, the Extended Limited Transmit mechanism proposed in this document offers two variants for experimentation.
そのTCP密結合の信頼性及び輻輳制御を注：セグメントが失われたと宣言された場合、再送信がトリガされ、そして送信レートの変更も降下が競合[RFC2581]をリソースに起因していると仮定して行われます。したがって、単に再送トリガを変更することにより、輻輳制御応答も変化します。しかし、我々は速度低下が起きるポイントを遅らせることは大規模な展開に適しているかどうかのインターネット上での経験を欠いています。したがって、本文書で提案されている拡張リミテッド送信メカニズムは、実験用の2つのバリエーションを提供しています。
The first Extended Limited Transmit variant, Careful Limited Transmit, calls for the transmission of one previously unsent segment, in response to duplicate acknowledgments, for every two segments that are known to have left the network. This effectively halves the sending rate, since normal TCP operation calls for the sending of one segment for every segment that has left the network. Further, the halving starts immediately and is not delayed until a retransmission is triggered. In the case of packet reordering (i.e., not segment loss), the congestion control state is restored to its previous state when reordering is determined.
第1の拡張限定送信変異体、慎重に限定送信は、ネットワークを残していることが知られている各2つのセグメントに対して、肯定応答を複製することに応答して、1つの以前に未送信のセグメントの送信を要求します。通常のTCP操作はネットワークを去ったすべてのセグメントに対して1つのセグメントの送信を要求するので、これは事実上、送信レートを半分にします。さらに、半分はすぐに開始され、再送信がトリガされるまで延期されていません。判定された並べ替えたときにパケットの並び替え（すなわち、しないセグメント損失）の場合には、輻輳制御状態を前の状態に復元されます。
The second variant, Aggressive Limited Transmit, calls for transmitting one previously unsent data segment, in response to duplicate acknowledgments, for every segment known to have left the network. With this variant, while waiting to disambiguate the loss from a reordering event, ACK-clocked transmission continues at roughly the same rate as before the event started. Retransmission and the sending rate reduction happen per [RFC2581, RFC3517], albeit with the delayed threshold described above. Although this approach delays legitimate rate reductions (possibly slightly and temporarily aggravating overall congestion on the network), the scheme has the advantage of not reducing the transmission rate in the face of segment reordering.
第二の変形例では、積極的な限定送信は、ネットワークを残していることが知られているすべてのセグメントの肯定応答を複製する応答内の1つの以前に未送信のデータセグメントを、送信するために呼び出します。この変形例では、並べ替えのイベントからの損失を明確にするために待っている間に、ACK-クロック駆動伝達は、おおよそ、イベントが始まる前と同じ速度を続けています。再送と送信レートの低減は、上述した遅延閾値とはいえ、[RFC2581、RFC3517]あたりに起こります。このアプローチは、（おそらくわずかに、一時的にネットワーク上の全体的な輻輳を悪化させる）正当レート削減を遅延させるが、スキームは、セグメント並べ替えの面における伝送速度を減少しないという利点を有します。
Which of the two Extended Limited Transmit variants is best for use on the Internet is an open question.
2つの拡張リミテッド送信のどのバリアント、インターネット上での使用に最適です未解決の問題です。
The TCP-NCR modifications make two fundamental changes to the way [RFC3517] currently operates, as follows.
以下のようにTCP-NCR修飾は、[RFC3517]は、現在動作方法には2つの基本的な変更を加えます。
First, the trigger for retransmitting a segment is changed from three duplicate ACKs [RFC2581, RFC3517] to indications that a congestion window's worth of data has left the network. Second, TCP-NCR decouples initial congestion control decisions from retransmission decisions, in some cases delaying congestion control changes relative to TCP's current behavior as defined in [RFC2581]. The algorithm provides two alternatives for extending Limited Transmit. The two variants of extended Limited Transmit are:
まず、セグメントを再送信するためのトリガは、データの輻輳ウィンドウの価値は、ネットワークを去ったことを指示までの3個の重複ACK [RFC2581、RFC3517]に変更されます。第二に、TCP-NCRは、[RFC2581]で定義されているTCPの現在の行動に対する輻輳制御の変更を遅らせるいくつかのケースでは、再送決定から最初の輻輳制御決定を切り離します。このアルゴリズムは、リミテッド送信を拡張するための2つの選択肢を提供します。拡張リミテッド送信の二つの変種は、以下のとおりです。
Careful Limited Transmit
慎重に限り送信
This variant calls for reducing the sending rate at approximately the same time [RFC2581] implementations reduce the congestion window, while at the same time withholding a retransmission (and the final congestion determination) for approximately one RTT.
この変異体は、約およそRTTのための同じ時間に同時に再送（最終的な渋滞判定）を保留しながらRFC2581]実装は、輻輳ウィンドウを減少させるの送信レートを低減するために呼び出します。
Aggressive Limited Transmit
積極的なリミテッド送信
This variant calls for maintaining the sending rate in the face of duplicate ACKs until TCP concludes that a segment is lost and needs to be retransmitted (which TCP-NCR delays by one RTT when compared with current loss recovery schemes).
この変形は、TCPは、セグメントが失われたと結論して再送が必要になるまで重複ACKの顔に送信レートを維持するために呼び出します（これは現在の損失回復スキームと比較して、1 RTTによるTCP-NCRの遅延）。
A TCP-NCR implementation MUST use either Careful Limited Transmit or Aggressive Limited Transmit.
TCP-NCRの実装は慎重に限定送信または積極的な限定送信のいずれかを使用しなければなりません。
A constant MUST be set, depending on which variant of extended Limited Transmit is used, as follows:
次のように定数が使用され、拡張限定送信のどのバリアントに応じて、設定しなければなりません。
Careful Limited Transmit
慎重に限り送信
LT_F = 2/3
LT_F = 2/3
Aggressive Limited Transmit
積極的なリミテッド送信
LT_F = 1/2
LT_F = 1/2
This constant reflects the fraction of outstanding data (including data sent during Extended Limited Transmit) that must be SACKed before a retransmission is triggered. Since Aggressive Limited Transmit sends a new segment for every segment known to have left the network, a total of roughly cwnd segments will be sent during Aggressive Limited Transmit, and therefore ideally a total of roughly 2*cwnd segments will be outstanding when a retransmission is triggered. The duplicate ACK threshold is then set to LT_F = 1/2 of 2*cwnd (or about 1 RTT worth of data). The factor is different for Careful Limited Transmit because the sender only transmits one new segment for every two segments that are SACKed and therefore will ideally have a total of 1.5*cwnd segments outstanding when the retransmission is to be triggered. Hence, the required threshold is LT_F=2/3 of 1.5*cwnd to delay the retransmission by roughly 1 RTT.
この定数は、再送信がトリガされる前に解雇されなければならない（拡張リミテッド送信時に送信されたデータを含む）の未処理データの割合を反映しています。アグレッシブ限定送信は、ネットワークを残していることが知られているすべてのセグメントのための新しいセグメントを送信するので、おおよそCWNDセグメントの合計は、積極的な限定送信の間に送信され、従って、理想的には、再送されたとき約2の合計* CWNDセグメントが未処理であろうトリガ。重複ACK閾値は次いでLT_F = 2の1/2に設定されている* CWND（又はデータの約1 RTT分）。送信者のみが解雇され、したがって、再送信がトリガされるとき、理想的には未処理の1.5×CWNDセグメントの合計を持って各2つのセグメントのための1つの新しいセグメントを送信するための要因は、慎重に限定送信のために異なっています。したがって、必要な閾値はLT_F = 1.5、2/3 * CWNDがおおよそ1 RTTにより再送信を遅らせることです。
There are situations whereby the sender cannot transmit new data during Extended Limited Transmit (e.g., lack of data from the application, receiver's advertised window limit). These situations can lead to the problems discussed in the last section when a TCP does not employ Extended Limited Transmit and is starved for ACKs. Therefore, TCP-NCR adapts the duplicate ACK threshold on each SACK arrival to be as robust as possible given the actual amount of data that has been transmitted, or roughly LT_F times the number of outstanding segments.
送信者が拡張リミテッド送信（例えば、アプリケーションからのデータの欠如、受信機の広告ウィンドウの上限）の間に新しいデータを送信することができないとなる状況があります。これらの状況はTCPが限定送信を拡張使用しないとACKのために飢えている最後のセクションで説明する問題につながることができます。したがって、TCP-NCRは、送信されたデータの実際の量、又は未処理のセグメントのおおよそLT_F時間数所与できるだけ頑丈で、各SACKの到着時に重複ACK閾値を適応させます。
The TCP-NCR modifications specified in this document lend themselves to incremental deployment. Only the TCP implementation on the sender side requires modification (assuming both hosts support SACK). The changes themselves are modest. However, as will be discussed below, availability of additional buffer space at the receiver will help maximize the benefits of using TCP-NCR but is not strictly necessary.
この文書で指定されたTCP-NCRの変更は、増分の展開に自分自身を貸します。唯一の送信側のTCP実装は、（両方のホストがSACKをサポートすると仮定して）変更する必要があります。変更自体は控えめです。しかし、後述するように、受信機での追加のバッファ領域の可用性は、TCP-NCRを使用することの利点を最大限に役立ちますが、厳密には必要ではありません。
The following algorithms depend on the notions provided by [RFC3517], and we assume the reader is familiar with the terminology given in [RFC3517]. The TCP-NCR algorithm can be adapted to alternate SACK-based loss recovery schemes. [BR04, BSRV04] outline non-SACK-based algorithms; however, we do not specify those algorithms in this document and do not recommend them due to both the complexity and security implications of having only a gross understanding of the number of outstanding segments in the network.
次のアルゴリズムは、[RFC3517]によって与えられる概念に依存し、我々は、読者が[RFC3517]で与えられた用語に精通していると仮定する。 TCP-NCRアルゴリズムは、代替SACKベースの損失回復計画に適合させることができます。 [BR04、BSRV04非SACKベースのアルゴリズムを概説します。しかし、私たちは、この文書に記載されているこれらのアルゴリズムを指定しないと、ネットワーク内の優秀なセグメント数の唯一の総理解を持つことの複雑さとセキュリティの影響の両方のためにそれらをお勧めしません。
A TCP connection using the Nagle algorithm [RFC896, RFC1122] MAY employ the TCP-NCR algorithm. If a TCP implementation does implement TCP-NCR, the implementation MUST follow the various specifications provided in Sections 3.1 - 3.4. If the Nagle algorithm is not being used, there is no way to accurately calculate the number of outstanding segments in the network (and, therefore, no good way to derive an appropriate duplicate ACK threshold) without adding state to the TCP sender. A TCP connection that does not employ the Nagle algorithm SHOULD NOT use TCP-NCR. We envision that NCR could be adapted to an implementation that carefully tracks the sequence numbers transmitted in each segment. However, we leave this as future work.
TCP-NCRのアルゴリズムを使用することができるNagleアルゴリズム[RFC896、RFC1122]を使用して、TCP接続。 3.4 - TCP実装はTCP-NCRを実装していた場合、実装はセクション3.1で提供される様々な仕様に従わなければなりません。 Nagleアルゴリズムが使用されていない場合、正確TCP送信者に状態を追加することなく、ネットワーク内の未処理セグメント（及び、適切な重複ACK閾値を導出することは、良い方法）の数を計算する方法はありません。 Nagleアルゴリズムを採用していないTCP接続はTCP-NCRを使用しないでください。我々は、NCRを注意深く各セグメントで送信シーケンス番号を追跡する実装に適合させることができることを想定しています。しかし、我々は今後の作業として、このままにしておきます。
When entering a period of loss/reordering detection and Extended Limited Transmit, a TCP-NCR MUST initialize several state variables. A TCP MUST enter Extended Limited Transmit upon receiving the first ACK with a SACK block after the reception of an ACK that (a) did not contain SACK information and (b) did increase the connection's cumulative ACK point. The initializations are:
損失/並べ替えの検出および拡張リミテッド送信の期間を入力するときは、TCP-NCRには、いくつかの状態変数を初期化する必要があります。 TCPは、（a）は、SACK情報と、（b）接続の累積ACKポイントを増加しなかったが含まれていなかったACKの受信後SACKブロックと第一ACKを受信すると限定送信拡張入力しなければなりません。初期化は以下のとおりです。
(I.1) The TCP MUST save the current FlightSize.
（I.1）TCPは、現在のFlightSizeを保存する必要があります。
FlightSizePrev = FlightSize
FlightSizePrev = FlightSize
(I.2) The TCP MUST set a variable for tracking the number of segments for which an ACK does not trigger a transmission during Careful Limited Transmit.
（I.2）TCPは、ACKは注意限定送信の間に送信をトリガしないため、セグメントの数を追跡するための変数を設定する必要があります。
Skipped = 0
スキップされた= 0
(Note: Skipped is not used during Aggressive Limited Transmit.)
（注意：スキップは、積極的な限定送信の際には使用されません。）
(I.3) The TCP MUST set DupThresh (from [RFC3517]) based on the current FlightSize.
（I.3）TCPは、現在FlightSizeに基づいDupThresh（から[RFC3517]）を設定しなければなりません。
DupThresh = max (LT_F * (FlightSize / SMSS),3)
DupThresh = MAX（LT_F *（FlightSize / SMSS）、3）
Note: We keep the lower bound of DupThresh = 3 from [RFC2581, RFC3517].
注意：私たちは[RFC2581、RFC3517]からDupThresh = 3の下限を保ちます。
In addition to the above steps, the incoming ACK MUST be processed with the E series of steps in Section 3.3.
上記のステップに加えて、入ってくるACKは、セクション3.3の手順のEシリーズで処理されなければなりません。
Extended Limited Transmit MUST be terminated at the start of loss recovery as outlined in Section 3.4.
3.4節で概説されているよう拡張リミテッド送信は、損失回復の開始時に終えなければなりません。
The arrival of an ACK that advances the cumulative ACK point while in Extended Limited Transmit, but before loss recovery is triggered, signals that a series of duplicate ACKs was caused by reordering and not congestion. Therefore, the receipt of an ACK that extends the cumulative ACK point MUST terminate Extended Limited Transmit. As described below (in (T.4)), an ACK that extends the cumulative ACK point and *also* contains SACK information will also trigger the beginning of a new Extended Limited Transmit phase.
拡張限定送信累積ACKポイントしばらく進むACKの到着が、損失回復がトリガされる前に、重複ACKの一連の輻輳を並べ替えずに起因した信号。したがって、累積ACKポイントを拡張ACKの受信は拡張限定送信を終了しなければなりません。累積ACK点と*を拡張し、ACK（（T.4）で）以下に記載するようにも* SACK情報も新しい拡張限定送信フェーズの開始をトリガする含んでいます。
Upon the termination of Extended Limited Transmit, and especially when using the Careful variant, TCP-NCR may be in a situation where the entire cwnd is not being utilized, and therefore TCP-NCR will be prone to transmitting a burst of segments into the network. Therefore, to mitigate this bursting when a TCP-NCR in the Extended Limited Transmit phase receives an ACK that updates the cumulative ACK point (regardless of whether the ACK contains SACK information), the following steps MUST be taken: (T.1) A TCP MUST reset cwnd to:
拡張限定送信の終了時に、注意深い変異体を使用する場合、特に、TCP-NCR全体CWNDが利用されていない状況であってもよく、したがって、TCP-NCRがネットワークにセグメントのバーストを送信しやすいであろう。したがって、拡張限定送信フェーズにおけるTCP-NCRは（かかわらず、ACKがSACK情報が含まれているかどうかの）累積ACKポイントを更新ACKを受信した場合、この破裂を軽減するために、以下のステップがとられなければならない：（T.1）AをTCPは、へのcwndをリセットする必要があります。
cwnd = min (FlightSize + SMSS,FlightSizePrev)
CWND =分（FlightSize + SMSS、FlightSizePrev）
This step ensures that cwnd is not grossly larger than the amount of data outstanding, a situation that would cause a line rate burst.
このステップでは、cwndのは著しく優れたデータの量、ラインレートバーストを引き起こすような状況よりも大きくないことを保証します。
(T.2) A TCP MUST set ssthresh to:
（T.2）A TCPはにSSTHRESHを設定する必要があります。
ssthresh = FlightSizePrev
SSTHRESH = FlightSizePrev
This step provides TCP-NCR with a sense of "history". If step (T.1) reduces cwnd below FlightSizePrev, this step ensures that TCP-NCR will slow start back to the operating point in effect before Extended Limited Transmit.
このステップは、「歴史」の感覚でTCP-NCRを提供します。ステップ（T.1）はFlightSizePrev以下のcwndが減少した場合は、このステップは、TCP-NCRは前に限定送信拡張効果に戻って動作点に開始遅くなることが保証されます。
(T.3) A TCP is now permitted to transmit previously unsent data as allowed by cwnd, FlightSize, application data availability, and the receiver's advertised window.
CWND、FlightSize、アプリケーション・データの可用性、および受信機の広告ウィンドウによって許容されるよう（T.3）A TCPについて以前に未送信データを送信することが許可されています。
(T.4) When an incoming ACK extends the cumulative ACK point and also contains SACK information, the initializations in steps (I.2) and (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST NOT be executed) to re-start Extended Limited Transmit. In addition, the series of steps in Section 3.3 (the "E" steps) MUST be taken.
受信ACK累積ACKポイントを拡張し、また、SACK情報が含まれている場合（T.4）、3.1項からの手順で初期化（I.2）及び（I.3）が取られなければならない（ただし、ステップ（I.1）MUST拡張再起動限定送信する）を実行できません。また、セクション3.3における一連のステップ（「E」ステップ）を払わなければなりません。
On each ACK containing SACK information that arrives after TCP-NCR has entered the Extended Limited Transmit phase (as outlined in Section 3.1) and before Extended Limited Transmit terminates, the sender MUST use the following procedure.
TCP-NCRが拡張リミテッド送信フェーズに入った後（3.1節で概説される）および拡張リミテッド送信が終了する前に、送信者は、次の手順を使用しなければならない到着SACK情報を含む各ACKで。
(E.1) The SetPipe () procedure from [RFC3517] MUST be used to set the "pipe" variable (which represents the number of bytes still considered "in the network"). Note: the current value of DupThresh MUST be used by SetPipe () to produce an accurate assessment of the amount of data still considered in the network.
（E.1）からSetPipe（）手順[RFC3517]（依然として「ネットワーク内」と見なされるバイト数を表す）「パイプ」変数を設定するために使用されなければなりません。注：DupThreshの電流値は、依然としてネットワークにおいて考慮されるデータの量の正確な評価を生成するSetPipe（）によって使用されなければなりません。
(E.2) If the comparison in equation (1), below, holds and there are SMSS bytes of previously unsent data available for transmission, then the sender MUST transmit one segment of SMSS bytes.
（E.2）式の比較（1）、以下、保持し、送信のために利用可能な以前に未送信データのSMSSバイトがある場合、送信者はSMSSバイトの一つのセグメントを送信しなければなりません。
(pipe + Skipped) <= (FlightSizePrev - SMSS) (1)
（パイプ+スキップ）<=（FlightSizePrev - SMSS）（1）
If the comparison in equation (1) does not hold or no new data can be transmitted (due to lack of data from the application or the advertised window limit), skip to step (E.6).
式の比較（1）が成立していないか、新しいデータが（これは、アプリケーションまたは広告ウィンドウ限界からデータの不足のために）送信できない場合、（E.6）に進み。
(E.3) Pipe MUST be incremented by SMSS bytes.
（E.3）パイプSMSSバイトずつインクリメントしなければなりません。
(E.4) If using Careful Limited Transmit, Skipped MUST be incremented by SMSS bytes to ensure that the next SMSS bytes of SACKed data processed does not trigger a Limited Transmit transmission (since the goal of Careful Limited Transmit is to send upon receipt of every second duplicate ACK).
慎重に限定送信を使用している場合（E.4）、スキップはSMSSだけ増分されなければならない慎重に限定送信の目標は、の受信時に送信することであるので、処理解雇データの次SMSSバイトが限定送信の送信（トリガしないことを確実にするためにバイト毎秒重複ACK）。
(E.5) A TCP MUST return to step (E.2) to ensure that as many bytes as are appropriate are transmitted. This provides robustness to ACK loss that can be (largely) compensated for using SACK information.
（E.5）A TCPが送信される適切であるように、そのような多くのバイトを確実にするために（E.2）のステップに戻らなければなりません。これは、（主に）SACK情報を用いて補償することができるACK損失に対するロバスト性を提供します。
(E.6) DupThresh MUST be reset via:
（E.6）DupThreshを介してリセットされなければなりません。
DupThresh = max (LT_F * (FlightSize / SMSS),3)
DupThresh = MAX（LT_F *（FlightSize / SMSS）、3）
where FlightSize is the total number of bytes that have not been cumulatively acknowledged (which is different from "pipe").
ここFlightSizeは（「パイプ」とは異なる）累積的に認識されなかったバイトの総数です。
When a segment is deemed lost via the algorithms in [RFC3517], Extended Limited Transmit MUST be terminated, leaving the algorithms in [RFC3517] to govern TCP's behavior. One slight change to [RFC3517] MUST be made, however. In Section 5, step (2) of [RFC3517] MUST be changed to:
セグメントは[RFC3517]でアルゴリズムを経て失わみなされた場合、拡張リミテッド送信は、TCPの動作を管理するために、[RFC3517]でアルゴリズムを残し、終了しなければなりません。 [RFC3517]に対する一つのわずかな変化は、しかし、行われなければなりません。 5章では、[RFC3517]のステップ（2）に変更しなければなりません。
(2) ssthresh = cwnd = (FlightSizePrev / 2)
（2）SSTHRESH = CWND =（FlightSizePrev / 2）
This ensures that the congestion control modifications are made with respect to the amount of data in the network before FlightSize was increased by Extended Limited Transmit.
これはFlightSizeは拡張限定送信増加した前の輻輳制御の変更は、ネットワーク内のデータの量に対して行われることを保証します。
Note: Once the algorithm in [RFC3517] takes over from Extended Limited Transmit, the DupThresh value MUST be held constant until the loss recovery phase is terminated.
注：[RFC3517]でアルゴリズムが拡張リミテッド送信から引き継ぐたら損失回復フェーズが終了するまで、DupThresh値が一定に保たなければなりません。
The major advantages of TCP-NCR are twofold. As discussed in Section 1, TCP-NCR will open up the design space for network applications and components that are currently constrained by TCP's lack of robustness to packet reordering. The second advantage is in terms of an increase in TCP performance.
TCP-NCRの主な利点は2つあります。第1節で述べたように、TCP-NCRは、現在、パケット並べ替えに対するロバスト性のTCPの欠如によって制約されているネットワーク・アプリケーションとコンポーネントの設計空間を開きます。第2の利点は、TCP性能の向上という点です。
[BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-NCR algorithm specified in this document, called TCP-DCR (Delayed Congestion Response). The paper shows that TCP-DCR aids performance in comparison to unmodified TCP in the presence of packet reordering. In addition, the extended version of [BR04] presents results based on emulations involving Linux (kernel 2.4.24). These results show that the performance of TCP-DCR is similar to Linux's native implementation that seeks to "undo" wrong decisions according to duplicate-SACK (DSACK) [RFC2883] feedback (similar to the schemes outlined in [ZKFP03]), when packets are reordered by less than one RTT. The advantage of using TCP-DCR over the DSACK-based scheme is that the DSACK-based scheme tries to estimate the exact amount of reordering in the network using fairly complex algorithms, whereas TCP-DCR achieves similar results with less complicated modifications.
【BR04]はTCP-DCR（遅延輻輳応答）と呼ばれるこの文書で指定されたTCP-NCRアルゴリズム、プリカーソルのNS-2 [NS-2]シミュレーションを提示します。紙は、パケット再命令の存在下で修飾されていないTCPと比較して、そのTCP-DCR助剤性能を示します。また、[BR04]の拡張版は、Linux（カーネル2.4.24）を含むエミュレーションに基づいて結果を提示します。これらの結果は、TCP-DCRのパフォーマンスは間違った決定は、重複-SACKし、パケット（[ZKFP03]で概説したスキームに類似）（DSACK）[RFC2883]のフィードバックをに従って「元に戻す」を目指し、Linuxのネイティブ実装に似ていることを示しています未満のRTTによって並べ替えられます。 DSACKベースのスキーム上TCP-DCRを使用する利点は、TCP-DCRは、より複雑修飾を有する類似の結果を達成する一方DSACKベースのスキームは、かなり複雑なアルゴリズムを使用してネットワークに再配列の正確な量を推定しようとすることです。
In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow for the improvement of other parts of the system. For example, these papers show that increasing TCP's robustness to packet reordering allows a novel wireless ARQ mechanism to be added at the link-layer. The added robustness of the link-layer to channel errors, in turn, increases TCP performance by not requiring TCP to retransmit packets that were dropped due to corruption (and thus also prevents TCP from needlessly reducing the sending rate when retransmitting these segments).
また、[BR04は、BSRV04】システムの他の部分の改善を可能にするTCP-DCRの能力を示します。例えば、これらの論文は、パケットの並べ替えにTCPの堅牢性を増加させると、新しい無線ARQメカニズムは、リンク層で追加することを可能にすることを示しています。エラーをチャネルにリンク層の添加ロバスト性は、今度は、腐敗に起因滴下（したがって、これらのセグメントを再送信するときに不必要送信速度を低下させるからTCPを防止）されたパケットを再送信するTCPを必要としないことにより、TCPの性能を向上させます。
Although all the changes outlined above are implemented in the sender, the receiver also potentially has a part to play. In particular, TCP-NCR increases the receiver's buffering requirement by up to an extra cwnd -- in the case of the TCP sender using Aggressive Limited Transmit and actual loss occurring in the network. Therefore, to maximize the benefits from TCP-NCR, receivers should advertise a large window to absorb the extra out-of-order traffic. In the case that the additional buffer requirements are not met, the use of the above algorithm takes into account the reduced advertised window -- with a corresponding loss in robustness to packet reordering.
上記で概説したすべての変更は、送信側で実装されていますが、受信機は、潜在的に再生する部分があります。特に、TCP-NCRは余分CWNDまですることによって、受信機のバッファリング要件を増大 - アグレッシブ限定送信し、ネットワークで発生する実際の損失を使用して、TCP送信者の場合には。したがって、TCP-NCRからの利益を最大化するために、受信機は、余分なアウトオブオーダートラフィックを吸収する大きな窓を宣伝する必要があります。追加バッファ要件が満たされていないいる場合に、上記のアルゴリズムの使用を考慮に減少広告ウィンドウをとり - パケットの並び替えに対するロバスト性の対応する損失。
In addition, using TCP-NCR could delay the delivery of data to the application by up to one RTT because the fast retransmission point is delayed by roughly one RTT in TCP-NCR. Applications that are sensitive to such delays should turn off the TCP-NCR option. For instance, a socket option could be introduced to allow applications to control whether NCR would be used for a particular connection.
また、高速再送点はTCP-NCRで約1 RTTだけ遅延されているため、TCP-NCR一RTTまですることによって、アプリケーションへのデータの配信を遅らせる可能性が使用。このような遅延に敏感なアプリケーションでは、TCP-NCRオプションをオフにする必要があります。例えば、ソケットオプションは、アプリケーションがNCRは、特定の接続のために使用されるかどうかを制御できるようにするために導入することができます。
Finally, the use of TCP-NCR makes the recovery from congestion events sluggish in comparison to the standard reaction in [RFC2581]. [BR04, BSRV04] show (via simulation) that the delay in congestion response has minimal impact on the connection itself and the traffic sharing a bottleneck. [BBFS01] also indicates (again, via simulation) that "slowly responsive" congestion control may be safe for deployment in the Internet. These studies suggest that schemes that slightly delay congestion control decisions may be reasonable; however, further experimentation on the Internet is required to verify these results.
最後に、TCP-NCRの使用は[RFC2581]で標準的な反応と比較して輻輳イベントからの回復は鈍くなります。輻輳応答遅れが接続自体とボトルネックを共有トラフィックに最小限の影響を有すること（シミュレーションを介して）BR04、BSRV04]ショー。 [BBFS01]も「ゆっくり応答」輻輳制御は、インターネットでの展開のために安全であってもよいこと（シミュレーションを経て、再び）を示しています。これらの研究は、わずか輻輳制御の決定を遅らせる手法が妥当であることを示唆しています。しかし、インターネット上のさらなる実験は、これらの結果を検証するために必要とされます。
Over the past few years, several solutions have been proposed to improve the performance of TCP in the face of segment reordering. These schemes generally fall into one of two categories (with some overlap): mechanisms that try to prevent spurious retransmits from happening and mechanisms that try to detect spurious retransmits and "undo" the needless congestion control state changes that have been taken.
過去数年間、いくつかのソリューションは、セグメント並べ替えに直面してTCPの性能を向上させるために提案されてきました。起こっスプリアス再送を検出して撮影された不輻輳制御状態の変更を「元に戻す」ことを試みるメカニズムからスプリアス再送を防止しようとするメカニズム：これらのスキームは、一般的に（ある程度の重複を有する）2つのカテゴリのいずれかに分類されます。
[BA02,ZKFP03] attempt to prevent segment reordering from triggering spurious retransmits by using various algorithms to approximate the duplicate ACK threshold required to disambiguate loss and reordering over a given network path at a given time. TCP-NCR similarly tries to prevent spurious retransmits. However, TCP-NCR takes a simplified approach compared to those in [BA02, ZKFP03], in that TCP-NCR simply delays retransmission by an amount based on the current cwnd (in comparison to standard TCP), while the other schemes use relatively complex algorithms in an attempt to derive a more precise value for DupThresh that depends on the current patterns of packet reordering. While TCP-NCR offers simplicity, the other schemes may offer more precision such that applications would not be forced to wait as long for their retransmissions. Future work could be undertaken to achieve robustness without needless delay.
[BA02、ZKFP03]所与の時間に所与のネットワーク経路上の損失および並べ替えを明確に必要な重複ACK閾値を近似するために様々なアルゴリズムを使用してスプリアス再送をトリガから並べ換えセグメントを防止しようとします。 TCP-NCRは、同様に、スプリアス再送を防ぐためにしようとします。しかし、TCP-NCRは[BA02、ZKFP03]のものに比べて簡略化されたアプローチをとる他のスキームは、比較的複雑使用しながら、その中にTCP-NCRは、単に、（標準のTCPと比較して）現在のCWNDに基づいた量だけ再送信を遅延させます試みで、アルゴリズムは、パケットの並び替えの電流パターンに依存DupThreshためのより正確な値を導出します。 TCP-NCRは、シンプルさを提供していますが、他のスキームは、アプリケーションが再送信のために限り、待つことを余儀なくされないような、より精度を提供することがあります。今後の作業は不要な遅延なく堅牢性を達成するために着手することができます。
On the other hand, several schemes have been developed to detect and mitigate needless retransmissions after the fact. [RFC3522, RFC3708, BA02, RFC4015, RFC4138] present algorithms to detect spurious retransmits and mitigate the changes these events made to the congestion control state. TCP-NCR could be used in conjunction with these algorithms, with TCP-NCR attempting to prevent spurious retransmits and some other scheme kicking in if the prevention failed. In addition, note that TCP-NCR is concentrated on preventing spurious fast retransmits; some of the above algorithms also attempt to detect and mitigate spurious timeout-based retransmits.
一方、いくつかのスキームは、事実の後に不必要な再送信を検出し、軽減するために開発されています。 [RFC3522、RFC3708、BA02、RFC4015、RFC4138]本アルゴリズムスプリアス再送を検出し、輻輳制御状態にこれらのイベントが行われた変更を緩和します。 TCP-NCRは、TCP-NCRは予防が失敗した場合、スプリアス再送とで蹴る他のいくつかのスキームを防ぐためにしようとすると、これらのアルゴリズムと組み合わせて使用することができます。また、TCP-NCRは、スプリアスの高速再送を防ぐことに集中していることに注意してください。上記のアルゴリズムのいくつかはまた、検出およびスプリアスタイムアウト・ベースの再送信を軽減しようとします。
General attacks against the congestion control of TCP are described in [RFC2581]. SACK-based loss recovery for TCP [RFC3517] mitigates some of the duplicate ACK attacks against TCP's congestion control. This document builds upon that work, and the Extended Limited Transmit algorithms specified in this document have been designed to thwart the ACK division problems that are described in [RFC3465].
TCPの輻輳制御に対する一般的な攻撃は、[RFC2581]で説明されています。 TCP [RFC3517]のためのSACKベースの損失回復には、TCPの輻輳制御に対する重複ACK攻撃のいくつかを軽減します。この文書は、ワーク上に構築され、この文書で指定された拡張限定送信アルゴリズムは、[RFC3465]に記載されているACK分割問題を阻止するために設計されています。
Feedback from Lars Eggert, Ted Faber, Wesley Eddy, Gorry Fairhurst, Sally Floyd, Sara Landstrom, Nauzad Sadry, Pasi Sarolahti, Joe Touch, Nitin Vaidya, and the TCPM working group have contributed significantly to this document. Our thanks to all!
ラースエッゲルト、テッド・フェーバー、ウェズリーエディ、Gorry Fairhurst、サリー・フロイド、サラLandstrom、Nauzad Sadry、パシSarolahti、ジョー・タッチ、ニティンVaidya、およびTCPMワーキンググループからのフィードバックは、この文書に大きく貢献してきました。私たちのすべてに感謝！
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.、およびS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、 "保守的な選択的確認応答（SACK）はTCPのために損失回復アルゴリズムをベース"、RFC 3517、2003年4月。
[BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet Reordering," ACM Computer Communication Review, January 2002.
[BA02] ACMコンピュータコミュニケーションレビュー、2002年1月「パケットの順序変更、TCPには、より強固な作ることに」E.ブラントンとM.オールマン、。
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd and S. Shenker, "Dynamic Behavior of Slowly Responsive Congestion Control Algorithms", Proceedings of ACM SIGCOMM, Sep. 2001.
【BBFS01] D. Bansal氏、H.バラクリシュナン、S. FloydおよびS. Shenker、 "ゆっくりと応答輻輳制御アルゴリズムの動的挙動"、ACM SIGCOMM、2001年9月の議事録。
[BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering is not pathological network behavior," IEEE/ACM Transactions on Networking, December 1999.
[BPS99] J.ベネット、C.ヤマウズラ、及びN. Shectmanは、ネットワーク1999年12月にIEEE / ACMトランザクション "パケットの並び替えは、病理学的ネットワークの動作は、ではありません"。
[BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making TCP Robust to Non-Congestion Events", In the Proceedings of Networking 2004 conference, May 2004. Extended version available as tech report TAMU-ECE-2003-04.
[BR04] Sumitha BhandarkarのとA. L.ナラシンハレディ、「TCP-DCR：非輻輳イベントへのTCPは堅牢にする」ネットワーク2004会議、技術レポートTAMU-ECE-2003-04として入手できる2004年5月拡張版の議事録では、。
[BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating Wireless Channel Errors", to appear in IEEE Transactions on Mobile Computing.
[BSRV04] Sumitha Bhandarkarの、Nauzad Sadry、A. L.ナラシンハレディとニティンVaidya、 "TCP-DCR：新規プロトコル耐性のある無線チャネルエラーのため"、モバイルコンピューティングに関するIEEEトランザクションに表示されます。
[GPL04] Ladan Gharai, Colin Perkins and Tom Lehman, "Packet Reordering, High Speed Networks and Transport Protocol Performance", ICCCN 2004, October 2004.
[GPL04]ラダンGharai、コリンパーキンスとトム・レーマン、「パケットの順序変更、高速ネットワークとトランスポートプロトコルのパフォーマンス」、ICCCN 2004、2004年10月。
[Jac88] V. Jacobson, "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[Jac88] V. Jacobson氏、 "輻輳回避とコントロール"、コンピュータコミュニケーションレビュー、巻。 18、ありません。 4、頁314から329 8月1988 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z。
[JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. Towsley, "Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003.
【JIDKT03] S. Jaiswal、G. Iannaccone、C. Diot、J.黒瀬、及びD. Towsley、 "ティア1のIPバックボーンにおける測定とアウトオブシーケンスパケットの分類、" IEEE INFOCOMの議事録、2003年。
[KM02] I. Keslassy and N. McKeown, "Maintaining packet order in twostage switches," Proceedings of the IEEE Infocom, June 2002
[KM02] I. KeslassyとN.マッケオン、「twostageスイッチでパケットの順序を維持しながら、」IEEEインフォコム、2002年6月の議事録
[MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005.
【MAF05] A.メディナ、M.オールマン、S.フロイド。インターネットにおけるトランスポートプロトコルの進化を測定します。 ACMコンピュータコミュニケーションレビュー、35（2）、2005年4月。
[NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/
[NS-2〕NS-2ネットワークシミュレータ。 http://www.isi.edu/nsnam/
[Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings of ACM SIGCOMM, September 1997.
[Pax97] V.パクソン、ACM SIGCOMM、1997年9月の「エンド・ツー・エンドのインターネットパケットダイナミクス、」議事。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]フロイド、S.、Mahdavi、J.、マティス、M.、およびM.ポドルスキー、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. Stream Control Transmission Protocol. October 2000.
[RFC2960] R.スチュワート、Q.謝、K. Morneault、C.シャープ、H. Schwarzbauer、T.テイラー、I. Rytina、M.カラ、L.チャン、V.パクソン。ストリーム制御伝送プロトコル。 2000年10月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]オールマン、M.、RFC 3465、2003年2月 "適切なバイトカウント（ABC）とTCP輻輳制御"。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、RFC 3522、2003年4月。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, February 2004.
[RFC3708]ブラントン、E.およびM.オールマン、RFC 3708、2004年2月「スプリアス再送を検出するためにTCP複製選択的確認応答（DSACKs）およびストリーム制御伝送プロトコル（SCTP）重複送信シーケンス番号（TSNを）の使用」。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015]ルートヴィヒ、R.とA. Gurtov、 "TCPのためのアイフェルレスポンスアルゴリズム"、RFC 4015、2005年2月。
[RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)", RFC 4138, August 2005.
[RFC4138] Sarolahti、P.とM.古城、 "フォワードRTO-復旧（F-RTO）：TCPおよびストリーム制御伝送プロトコル（SCTP）とスプリアス再送タイムアウトを検出するためのアルゴリズム"、RFC 4138、2005年8月。
[ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, "RR-TCP: A Reordering-Robust TCP with DSACK", in Proceedings of the Eleventh IEEE International Conference on Networking Protocols (ICNP 2003), Atlanta, GA, November, 2003.
【ZKFP03] M.張、B.カープ、S.フロイド、L. Petersonの、 "RR-TCP：DSACKと並べ替えロバストTCP"、ネットワークプロトコル上の第十IEEE国際会議（ICNP 2003年）の議事録、アトランタ、GA、2003年11月。
Authors' Addresses
著者のアドレス
Sumitha Bhandarkar Dept. of Elec. Engg. 214 ZACH College Station, TX 77843-3128
エレックのSumitha Bhandarkarの部門。エング。 214ザックカレッジステーション、テキサス州77843から3128
Phone: (512) 468-8078 EMail: sumitha@tamu.edu URL: http://students.cs.tamu.edu/sumitha/
電話：（512）468-8078 Eメール：sumitha@tamu.edu URL：http://students.cs.tamu.edu/sumitha/
A. L. Narasimha Reddy Professor Dept. of Elec. Engg. 315C WERC College Station, TX 77843-3128
エレックのA. L.ナラシンハレディ教授部長。エング。 315C WERCカレッジステーション、テキサス州77843から3128
Phone: (979) 845-7598 EMail: reddy@ee.tamu.edu URL: http://ee.tamu.edu/~reddy/
電話：（979）845-7598 Eメール：reddy@ee.tamu.edu URL：http://ee.tamu.edu/~reddy/
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198
インターネットリサーチ1947センターストリートのためのマーク・オールマンICSIセンター、スイート600バークレー、CA 94704から1198
Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/
電話：（440）235-1792 Eメール：mallman@icir.org URL：http://www.icir.org/mallman/
Ethan Blanton Purdue University Computer Science 305 North University Street West Lafayette, IN 47907
イーサンブラントンパデュー大学コンピュータサイエンス305ノースユニバーシティストリートウェスト・ラファイエット、インディアナ47907
EMail: eblanton@cs.purdue.edu
メールアドレス：eblanton@cs.purdue.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。