[要約] 要約：RFC 4653は、TCPの非輻輳イベントに対する堅牢性を向上させるための提案をまとめたものです。 目的：このRFCの目的は、TCPが非輻輳イベントによって適切に動作し、ネットワークの信頼性とパフォーマンスを向上させることです。
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
TCPの堅牢性を非合唱イベントに向上させます
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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が損失を検出する方法の1つは、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]の1つの強度は、ネットワーク内の認識された混雑に従って送信率を調整する能力にあります[JAC88、RFC2581]。ネットワークからの輻輳の明示的な通知がない場合、TCPは輻輳の適応としてセグメント損失を使用します（つまり、キューオーバーフローを想定しています）。TCP受信機は、到着セグメント[RFC793]に送信者から予想される次のシーケンス番号を示す累積謝辞（ACK）を送信します。セグメントが故障して到着すると、重複したACKが生成されます。[RFC2581]で指定されているように、TCP送信者は、セグメントの損失の兆候として、3つの重複ACKの到着を使用します。TCP送信者は、失われたセグメントを再送信し、ネットワークの損失がネットワークパス内でのリソース競合によって引き起こされると仮定して、ネットワークに課される負荷を減らします。TCP送信者は、1番目または2番目の重複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は10個のセグメントを送信し、それぞれが単一のデータバイトで構成される（つまり、セグメント1〜10でバイト1〜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は、セグメント1と2を累積的に認識し、累積ACKを送信者3に送信します（次の予想シーケンス番号）。（注：遅延ACK [RFC1122、RFC2581]が採用されているかどうかに応じて、TCP Bは1つまたは2つの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（または4番目のACK）を受信すると、TCP Aはセグメント3を再送信し、送信率を約半分低下させます（輻輳制御状態調整の詳細については[RFC2581]を参照）。
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がセグメント10の後にTCP Bに到着するように遅延したと仮定します。上記のシナリオは、セグメント3の再送信とは不可欠な方法で正確に同じ方法で再生されます。言い換えれば、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 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がより堅牢である場合、パケットの再配置を引き起こす可能性があります。このようなスイッチでパケットの順序が維持されるように、文献では明示的に提案されています（例：[KM02]）。また、再送信によってパケットの破損から回復しようとするリンク層メカニズムは、パケットを並べ替えることができるため、損失を修復するために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送信者の変更のセットを指定して、TCPに非合成の堅牢性（NCR）を提供します。特に、これらの変更は、SACKがこの時点で広く展開されているため、選択的承認（SACKS）[RFC2018]と[RFC3517]に与えられたSACKベースの損失回復スキームを使用してTCPの上に構築されています（[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がTCPと同様の渋滞制御アルゴリズムを使用しているため、SCTP [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アルゴリズムを指定します。セクション4では、TCP-NCRの利点の概要を簡単に説明し、セクション5では欠点について説明します。セクション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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Readers should be familiar with the TCP terminology (e.g., FlightSize, Pipe) given in [RFC2581] and [RFC3517].
読者は、[RFC2581]および[RFC3517]に与えられたTCP用語（フライトサイズ、パイプなど）に精通している必要があります。
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つの重複したAcksだけでは、並べ替えを明らかにするには不十分な場合があります。このセクションでは、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つの重複したAcksの）。CWNDはデータの量を表すため、TCPフローは1回の往復時間（RTT）で送信できます。CWNDバイトが根本原因が損失または再注文が約1つのRTTの遅延を課すかどうかを決定する前に、CWNDバイトがネットワークを離れることを待っています再送信と輻輳制御応答の両方について。しきい値の新しい値の適切な選択は、基本的に、重複するAcksの原因と応答性に関する最良の決定を下すことの間のトレードオフです。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.
セグメントを再送信する前にしきい値を増やすだけで、TCPがパケット損失またはACK損失に脆くなる可能性があり、そのような損失により、受信者から送信者に到達する重複ACKの数が減少します。たとえば、CWNDが10セグメントであり、1つのセグメントが失われた場合、最大9つのセグメントに対応するACKの重複が送信者に到着するため、10の重複したACKしきい値が満たされません。損失の問題を相殺するために、TCPの送信[RFC3042]スキームを拡張して、TCP送信者が損失と再注文を曖昧にしている期間中に新しいデータの送信を可能にします。この新しいデータは、適切な場合に損失回復をトリガーするために、送信者に十分な複製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.
最初に拡張された制限された送信バリアント、慎重な制限された送信は、ネットワークを離れたことが知られている2つのセグメントごとに、重複した謝辞に応じて、以前に確かでないセグメントの送信を要求します。これにより、通常の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.
2番目のバリアント、積極的な限定送信は、ネットワークを離れることが知られているすべてのセグメントに対して、重複した謝辞に応じて、以前に安全でないデータセグメントを送信する必要があります。このバリアントでは、順序付けイベントからの損失を乱すのを待っている間、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つの代替案を提供します。拡張された限定送信の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.
このバリアントは、ほぼ同時に[RFC2581]の実装で送信率を減らすことを求めており、同時に約1つのRTTの再送信（および最終輻輳決定）を差し控えます。
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がセグメントが失われ、再送信する必要があると結論付けるまで、重複したAcksに直面して送信率を維持する必要があります（現在の損失回収スキームと比較した場合、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
Aggressive Limited Transmit
積極的な限定送信
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しきい値は、2*CWNDのLT_F = 1/2（または約1 RTT相当のデータ）に設定されます。送信者は、略奪された2つのセグメントごとに1つの新しいセグメントのみを送信するため、再送信がトリガーされる場合に合計1.5*CWNDセグメントが顕著であるため、送信者は慎重に制限された送信で異なります。したがって、必要なしきい値は、約1 RTTによる再送信を遅らせるために、1.5*CWNDのLT_F = 2/3です。
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倍を考えると、各サックの到着の重複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実装のみにのみ変更が必要です（両方のホストがサックをサポートすると仮定します）。変更自体は控えめです。ただし、以下で説明するように、受信機で追加のバッファースペースを利用できるようになると、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アルゴリズムは、代替のサックベースの損失回収スキームに適合させることができます。[BR04、BSRV04]非サックベースのアルゴリズムの概要。ただし、このドキュメントでこれらのアルゴリズムを指定するのではなく、ネットワーク内の未解決のセグメントの数を重大な理解しか持っていないという複雑さとセキュリティへの影響の両方があるため、それらを推奨しません。
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.
Nagleアルゴリズム[RFC896、RFC1122]を使用したTCP接続は、TCP-NCRアルゴリズムを使用する場合があります。TCP実装がTCP -NCRを実装している場合、実装はセクション3.1-3.4で提供されるさまざまな仕様に従う必要があります。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）サック情報が含まれておらず、（b）接続の累積ACKポイントを増加させたACKを受信した後、サックブロックを使用して最初のACKを受信すると、拡張された限定送信を入力する必要があります。初期化は次のとおりです。
(I.1) The TCP MUST save the current FlightSize.
（i.1）TCPは現在のフライトサイズを保存する必要があります。
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
(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は、現在のフライトサイズに基づいてdupthresh（[rfc3517]から）を設定する必要があります。
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.
上記の手順に加えて、セクション3.3のeシリーズのステップで着信ACKを処理する必要があります。
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の受領は、延長された限定送信を終了する必要があります。以下に説明するように（（T.4））、累積ACKポイントを拡張し、 * SACK情報を含むACKも、新しい拡張された限定送信フェーズの開始をトリガーします。
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ポイントを更新するACKを受信したときにこのバーストを軽減するために（ACKにサック情報が含まれているかどうかに関係なく）、次の手順を取る必要があります。TCPは次のようにリセットする必要があります。
cwnd = min (FlightSize + SMSS,FlightSizePrev)
cwnd = min（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）TCPはssthreshを次のように設定する必要があります。
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）がCWNDをFlightSizePrev以下に削減すると、このステップにより、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.
（T.3）TCPは、CWND、フライトサイズ、アプリケーションデータの可用性、およびレシーバーの宣伝されたウィンドウで許可されているように、以前に安全でないデータを送信することが許可されています。
(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.
（T.4）着信ACKが累積ACKポイントを拡張し、サック情報も含む場合、セクション3.1のステップ（I.2）と（i.3）の初期化を取得する必要があります（ただし、ステップ（I.1）が必要です。実行されていません）拡張された限定送信を再起動します。さらに、セクション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が拡張された制限された送信フェーズに入った後に到着するサック情報を含む各ACK（セクション3.1で概説されている）および拡張された限定送信終了前に、送信者は次の手順を使用する必要があります。
(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）[RFC3517]からのsetPipe（）手順を使用して、「パイプ」変数（「ネットワークで」と考えられているバイト数を表す）を設定する必要があります。注：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）の比較が下にある場合、送信に利用可能な以前に安全でないデータのSMSバイトがある場合、送信者はSMSSバイトの1つのセグメントを送信する必要があります。
(pipe + Skipped) <= (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バイトで増分する必要があります。1秒ごとに複製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）TCPはステップ（E.2）に戻る必要があり、適切なバイトが送信されるようにします。これにより、Sack情報の使用に対して（大部分）補償される可能性のあるACK損失に対する堅牢性が提供されます。
(E.6) DupThresh MUST be reset via:
（E.6）dupthreshを介してリセットする必要があります。
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").
フライトサイズは、累積的に認められていないバイトの総数（「パイプ」とは異なる）です。
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)
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.
これにより、フライトサイズが拡張された限られた送信により増加する前に、ネットワーク内のデータの量に関して、混雑制御の変更が行われることが保証されます。
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]のアルゴリズムが拡張された限定送信から引き継がれると、損失回収フェーズが終了するまで、デュプトレシュ値を一定に保持する必要があります。
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]シミュレーションを示しています（輻輳応答の遅延）。この論文は、Packet Reorderingの存在下での未修飾TCPと比較して、TCP-DCRがパフォーマンスを支援することを示しています。さらに、[BR04]の拡張バージョンは、Linux（Kernel 2.4.24）を含むエミュレーションに基づいた結果を示します。これらの結果は、TCP-DCRのパフォーマンスが、Duplicate-Sack（DSACK）[RFC2883]フィードバック（[ZKFP03]で概説されたスキームと同様）に従って間違った決定を「元に戻す」ことを目指しているLinuxのネイティブ実装に似ていることを示しています。1つ未満のRTTで並べ替えられます。DSACKベースのスキームでTCP-DCRを使用する利点は、DSACKベースのスキームが、かなり複雑なアルゴリズムを使用してネットワーク内の正確な量を推定しようとするのに対し、TCP-DCRは複雑でない変更で同様の結果を達成することです。
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の能力を示しています。たとえば、これらの論文は、Packet Redoringに対する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は、ネットワークで積極的な限定送信と実際の損失を使用してTCP送信者の場合、レシーバーのバッファリング要件を追加のCWNDまで増やします。したがって、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を使用すると、高速再送信ポイントがTCP-NCRで約1つのRTTによって遅延されるため、最大1つの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が現在のCWNDに基づいた金額（標準TCPと比較して）で再送信を単純に遅らせるだけで、他のスキームは比較的複雑な使用を使用しています。アルゴリズムパケットの並べ替えの現在のパターンに依存する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]のサックベースの損失回復は、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!
ラース・エガート、テッド・フェイバー、ウェスリー・エディ、ゴリー・フェアハースト、サリー・フロイド、サラ・ランドストローム、ナウザド・サドリー、パシ・サロラティ、ジョー・タッチ、ニティン・ヴァイディア、およびTCPMワーキンググループからのフィードバックは、この文書に大きく貢献しました。私たちのすべてに感謝します！
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「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] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限定送信を使用した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] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、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] E. BlantonとM. Allman、「TCPをパケットの再注文により堅牢にすることについて」ACMコンピューター通信レビュー、2002年1月。
[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。Balakrishnan、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.
[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. Narasimha Reddy、「TCP-DCR：TCPを非合唱イベントに堅牢にする」、2004年5月のネットワーキング2004会議の議事録。
[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。Narasimha Reddy、Nitin 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] Ladan Gharai、Colin Perkins、およびTom Lehman、「パケットの再注文、高速ネットワーク、輸送プロトコルのパフォーマンス」、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.ジェイコブソン、「混雑の回避と制御」、コンピューターコミュニケーションレビュー、Vol。18、いいえ。4、pp。314-329、1988年8月。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。Kurose、およびD. Towsley、「Tier-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 and N. McKeown、「Twostage Switchesでのパケットオーダーの維持」、IEEE Infocomの議事録、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. Paxson、「エンドツーエンドのインターネットパケットダイナミクス」、ACM Sigcommの議事録、1997年9月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「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。Xie、K。モーンー、C。シャープ、H。シュワルツバウアー、T。テイラー、I。リチナ、M。カラ、L。張、V。パクソン。ストリーム制御伝送プロトコル。2000年10月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465] Allman、M。、「適切なバイトカウント（ABC）を備えたTCP混雑制御」、RFC 3465、2003年2月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522] Ludwig、R。およびM. Meyer、「TCPのEIFEL検出アルゴリズム」、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] Blanton、E。およびM. Allman、「TCPを使用して選択的承認（DSACK）およびストリーム制御伝送プロトコル（SCTP）の重複透過シーケンス番号（TSNS）を使用して、スプリアスな再送信を検出します。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015] Ludwig、R。およびA. Gurtov、「TCPのEIFEL応答アルゴリズム」、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。and M. Kojo、「Forward RTO-Recovery（F-RTO）：TCPおよびTCPおよびThe Stream Control Transmission Protocol（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. Zhang、B。Karp、S。Floyd、L。Peterson、「RR-TCP：DSACKを使用した並べ替えの強いTCP」、第11回IEEE国際会議に関するネットワーキングプロトコル（ICNP 2003）の議事録、アトランタ、ジョージア州、2003年11月。
Authors' Addresses
著者のアドレス
Sumitha Bhandarkar Dept. of Elec. Engg. 214 ZACH College Station, TX 77843-3128
ElecのSumitha Bhandarkar Dept.engg。214ザックカレッジステーション、テキサス州77843-3128
Phone: (512) 468-8078
EMail: 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. Narasimha Reddy教授Elec。engg。315C WERC College Station、TX 77843-3128
Phone: (979) 845-7598
EMail: 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
マークオールマンICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア94704-1198
Phone: (440) 235-1792
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。