[要約] RFC 3465は、TCPの輻輳制御において適切なバイトカウント（ABC）を使用する方法について説明しています。ABCの目的は、正確な輻輳制御を実現し、ネットワークの適切な利用とパフォーマンスを向上させることです。
Network Working Group M. Allman
Request for Comments: 3465 BBN/NASA GRC
Category: Experimental February 2003
TCP Congestion Control with Appropriate Byte Counting (ABC)
適切なバイトカウントを備えたTCP混雑制御（ABC）
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly.
このドキュメントは、TCPがうっ血ウィンドウを増やす方法の小さな変更を提案しています。到着する承認ごとに一定の量だけ輻輳ウィンドウを増やすという従来の方法ではなく、この文書は、各ACKがカバーする以前の未知のバイトの数に基づいて増加することを示唆しています。この変更により、TCPのパフォーマンスが向上し、セキュリティホールTCPレシーバーが使用することができるセキュリティホールを閉じて、送信者が送信率を迅速に増加させるように誘導します。
Terminology
用語
Much of the language in this document is taken from [RFC2581].
このドキュメントの言語の多くは[RFC2581]から取得されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
1 Introduction
1はじめに
This document proposes a modification to the algorithm for increasing TCP's congestion window (cwnd) that improves both performance and security. Rather than increasing a TCP's congestion window based on the number of acknowledgments (ACKs) that arrive at the data sender (per the current specification [RFC2581]), the congestion window is increased based on the number of bytes acknowledged by the arriving ACKs. The algorithm improves performance by mitigating the impact of delayed ACKs on the growth of cwnd. At the same time, the algorithm provides cwnd growth in direct relation to the probed capacity of a network path, therefore providing a more measured response to ACKs that cover only small amounts of data (less than a full segment size) than ACK counting. This more appropriate cwnd growth can improve both performance and can prevent inappropriate cwnd growth in response to a misbehaving receiver. On the other hand, in some cases the modified cwnd growth algorithm causes larger bursts of segments to be sent into the network. In some cases this can lead to a non-negligible increase in the drop rate and reduced performance (see section 4 for a larger discussion of the issues).
このドキュメントでは、パフォーマンスとセキュリティの両方を改善するTCPの混雑ウィンドウ（CWND）を増やすためのアルゴリズムの変更を提案します。データ送信者（現在の仕様[RFC2581]ごとに）に到達する謝辞の数（ACK）の数に基づいてTCPの輻輳ウィンドウを増やすのではなく、到着ACKによって認められるバイト数に基づいて輻輳ウィンドウが増加します。このアルゴリズムは、CWNDの成長に対する遅延ACKの影響を緩和することにより、パフォーマンスを向上させます。同時に、アルゴリズムは、ネットワークパスのプローブ容量に直接関連してCWND成長を提供するため、ACKカウントより少量のデータのみ（完全なセグメントサイズ未満）のみをカバーするACKに対してより測定された応答を提供します。このより適切なCWND成長は、両方のパフォーマンスを改善し、不正な受信者に応じて不適切なCWND成長を防ぐことができます。一方、場合によっては、修正されたCWND成長アルゴリズムにより、セグメントの大きなバーストがネットワークに送信されます。場合によっては、これが低下率の無視できない増加とパフォーマンスの低下につながる可能性があります（問題のより大きな議論についてはセクション4を参照）。
This document is organized as follows. Section 2 outlines the modified algorithm for increasing TCP's congestion window. Section 3 discusses the advantages of using the modified algorithm. Section 4 discusses the disadvantages of the approach outlined in this document. Section 5 outlines some of the fairness issues that must be considered for the modified algorithm. Section 6 discusses security considerations.
このドキュメントは次のように整理されています。セクション2では、TCPの混雑ウィンドウを増やすための変更されたアルゴリズムの概要を説明します。セクション3では、変更されたアルゴリズムを使用することの利点について説明します。セクション4では、このドキュメントで概説されているアプローチの欠点について説明します。セクション5では、修正されたアルゴリズムで考慮する必要がある公平性の問題のいくつかの概要を説明します。セクション6では、セキュリティ上の考慮事項について説明します。
Statement of Intent
主旨書
This specification contains an algorithm improving the performance of TCP which is understood to be effective and safe, but which has not been widely deployed. One goal of publication as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. It is the intent of the Transport Area to re-submit this specification as an IETF Proposed Standard in the future, after more experience has been gained.
この仕様には、効果的かつ安全であると理解されているが広く展開されていないTCPのパフォーマンスを改善するアルゴリズムが含まれています。実験的なRFCとしての公開の1つの目標は、賢明であり、標準トラックで公開される前に使用と展開を奨励することです。より多くの経験が得られた後、将来のIETF提案基準としてこの仕様を再提出することは、輸送エリアの意図です。
2 A Modified Algorithm for Increasing the Congestion Window
2混雑ウィンドウを増やすための変更されたアルゴリズム
As originally outlined in [Jac88] and specified in [RFC2581], TCP uses two algorithms for increasing the congestion window. During steady-state, TCP uses the Congestion Avoidance algorithm to linearly increase the value of cwnd. At the beginning of a transfer, after a retransmission timeout or after a long idle period (in some implementations), TCP uses the Slow Start algorithm to increase cwnd exponentially. According to RFC 2581, slow start bases the cwnd increase on the number of incoming acknowledgments. During congestion avoidance RFC 2581 allows more latitude in increasing cwnd, but traditionally implementations have based the increase on the number of arriving ACKs. In the following two subsections, we detail modifications to these algorithms to increase cwnd based on the number of bytes being acknowledged by each arriving ACK, rather than by the number of ACKs that arrive. We call these changes "Appropriate Byte Counting" (ABC) [All99].
もともと[JAC88]で概説され、[RFC2581]で指定されているように、TCPは輻輳ウィンドウを増やすために2つのアルゴリズムを使用します。定常状態では、TCPはうっ血回避アルゴリズムを使用して、CWNDの値を直線的に増加させます。転送の開始時に、再送信タイムアウト後または長いアイドル期間（いくつかの実装で）の後（一部の実装）、TCPはスロースタートアルゴリズムを使用してCWNDを指数関数的に増加させます。RFC 2581によると、スロースタートは、着信謝辞の数のCWNDの増加に基づいています。混雑回避中、RFC 2581はCWNDの増加により緯度を増やすことができますが、伝統的に実装は到着ACKの数に基づいています。次の2つのサブセクションでは、これらのアルゴリズムの修正を詳細に説明し、到着するACKの数ではなく、到着するACKによって認められるバイト数に基づいてCWNDを増やします。これらの変更を「適切なバイトカウント」（ABC）[All99]と呼びます。
RFC 2581 specifies that cwnd should be increased by 1 segment per round-trip time (RTT) during the congestion avoidance phase of a transfer. Traditionally, TCPs have approximated this increase by increasing cwnd by 1/cwnd for each arriving ACK. This algorithm opens cwnd by roughly 1 segment per RTT if the receiver ACKs each incoming segment and no ACK loss occurs. However, if the receiver implements delayed ACKs [Bra89], the receiver returns roughly half as many ACKs, which causes the sender to open cwnd more conservatively (by approximately 1 segment every second RTT). The approach that this document suggests is to store the number of bytes that have been ACKed in a "bytes_acked" variable in the TCP control block. When bytes_acked becomes greater than or equal to the value of the congestion window, bytes_acked is reduced by the value of cwnd. Next, cwnd is incremented by a full-sized segment (SMSS). The algorithm suggested above is specifically allowed by RFC 2581 during congestion avoidance because it opens the window by at most 1 segment per RTT.
RFC 2581は、転送の混雑回避段階で、往復時間（RTT）ごとにCWNDを1セグメント（RTT）に増やす必要があることを指定します。従来、TCPは、到着するACKごとにCWNDを1/CWND増加させることにより、この増加を近似してきました。このアルゴリズムは、受信機が各受信セグメントでACK損失が発生しない場合、RTTごとに約1セグメントでCWNDを開きます。ただし、レシーバーが遅延ACK [BRA89]を実装すると、受信機は約半分のACKを返します。これにより、送信者はより保守的にCWNDを開きます（2秒ごとに約1セグメントで）。このドキュメントが提案するアプローチは、TCPコントロールブロックに「BYTES_ACKED」変数にACKEDが付けられたバイト数を保存することです。bytes_ackedが輻輳ウィンドウの値以上になると、bytes_ackedはcwndの値によって減少します。次に、CWNDはフルサイズのセグメント（SMSS）によって増加します。上記の提案されたアルゴリズムは、RTTごとに最大1セグメントでウィンドウを開くため、混雑回避中にRFC 2581によって特異的に許可されています。
RFC 2581 states that the sender increments the congestion window by at most, 1*SMSS bytes for each arriving acknowledgment during slow start. This document proposes that a TCP sender SHOULD increase cwnd by the number of previously unacknowledged bytes ACKed by each incoming acknowledgment, provided the increase is not more than L bytes. Choosing the limit on the increase, L, is discussed in the next subsection. When the number of previously unacknowledged bytes ACKed is less than or equal to 1*SMSS bytes, or L is less than or equal to 1*SMSS bytes, this proposal is no more aggressive (and possibly less aggressive) than allowed by RFC 2581. However, increasing cwnd by more than 1*SMSS bytes in response to a single ACK is more aggressive than allowed by RFC 2581. The more aggressive version of the slow start algorithm still falls within the spirit of the principles outlined in [Jac88] (i.e., of no more than doubling the cwnd per RTT), and this document proposes ABC for experimentation in shared networks, provided an appropriate limit is applied (see next section).
RFC 2581は、送信者が輻輳ウィンドウをせいぜい増加させていると述べています。このドキュメントは、TCP送信者は、増加がLバイト以下ではない場合、各着信の承認によってアクセスされた以前の未把持バイトの数によってCWNDを増やす必要があることを提案しています。増加の制限を選択するLは、次のサブセクションで説明されています。Acked Ackedが以前に承認されていないバイトの数が1*SMSSバイト以下である場合、またはLが1*SMSSバイト以下である場合、この提案はRFC 2581で許可されているよりも攻撃的ではありません（そしておそらく攻撃的ではありません）。ただし、単一のACKに応答して1*SMSSバイトを超えるCWNDを増やすことは、RFC 2581で許可されているよりも攻撃的です。スロースタートアルゴリズムのより積極的なバージョンは、[JAC88]（つまり、、RTTごとにCWNDを2倍にしない）、このドキュメントは、適切な制限が適用されている場合、共有ネットワークでの実験のためにABCを提案します（次のセクションを参照）。
The limit, L, chosen for the cwnd increase during slow start, controls the aggressiveness of the algorithm. Choosing L=1*SMSS bytes provides behavior that is no more aggressive than allowed by RFC 2581. However, ABC with L=1*SMSS bytes is more conservative in a number of key ways (as discussed in the next section) and therefore, this document suggests that even though with L=1*SMSS bytes TCP stacks will see little performance change, ABC SHOULD be used.
スロースタート中にCWND増加のために選択された制限Lは、アルゴリズムの攻撃性を制御します。L = 1*SMSSバイトを選択すると、RFC 2581で許可されているよりも積極的ではない動作が提供されます。ただし、L = 1*SMSSバイトのABCは、多くの重要な方法でより保守的です（次のセクションで説明しているように）。このドキュメントは、L = 1*SMSSバイトTCPスタックではパフォーマンスの変化がほとんどない場合、ABCを使用する必要があることを示唆しています。
A very large L could potentially lead to large line-rate bursts of traffic in the face of a large amount of ACK loss or in the case when the receiver sends "stretch ACKs" (ACKs for more than the two full-sized segments allowed by the delayed ACK algorithm) [Pax97].
非常に大きなLは、大量のACK損失に直面して、または受信機が「ストレッチACK」を送信する場合、大量のトラフィックの大きなラインレートバーストにつながる可能性があります（許可されている2つのフルサイズのセグメント以上のACK遅延ACKアルゴリズム）[Pax97]。
This document specifies that TCP implementations MAY use L=2*SMSS bytes and MUST NOT use L > 2*SMSS bytes. This choice balances between being conservative (L=1*SMSS bytes) and being potentially very aggressive. In addition, L=2*SMSS bytes exactly balances the negative impact of the delayed ACK algorithm (as discussed in more detail in section 3.2). Note that when L=2*SMSS bytes cwnd growth is roughly the same as the case when the standard algorithms are used in conjunction with a receiver that transmits an ACK for each incoming segment [All98] (assuming no or small amounts of ACK loss in both cases).
このドキュメントは、TCP実装ではL = 2*SMSSバイトを使用し、L> 2*SMSSバイトを使用してはならないことを指定しています。この選択は、保守的であること（L = 1*SMSSバイト）と潜在的に非常に攻撃的であることとのバランスをとります。さらに、L = 2*SMSSバイトは、遅延ACKアルゴリズムの負の影響のバランスを正確にバランスさせます（セクション3.2で詳細に説明します）。L = 2*SMSSバイトの場合、CWND成長は、標準アルゴリズムが各入っているセグメントのACKを送信する受信機と併用して使用される場合とほぼ同じであることに注意してください[ALL98]どちらの場合も）。
The exception to the above suggestion is during a slow start phase that follows a retransmission timeout (RTO). In this situation, a TCP MUST use L=1*SMSS as specified in RFC 2581 since ACKs for large amounts of previously unacknowledged data are common during this phase of a transfer. These ACKs do not necessarily indicate how much data has left the network in the last RTT, and therefore ABC cannot accurately determine how much to increase cwnd. As an example, say segment N is dropped by the network, and segments N+1 and N+2 arrive successfully at the receiver. The sender will receive only two duplicate ACKs and therefore must rely on the retransmission timer (RTO) to detect the loss. When the RTO expires, segment N is retransmitted. The ACK sent in response to the retransmission will be for segment N+2. However, this ACK does not indicate that three segments have left the network in the last RTT, but rather only a single segment left the network. Therefore, the appropriate cwnd increment is at most 1*SMSS bytes.
上記の提案の例外は、再送信タイムアウト（RTO）に続くスロースタートフェーズ中です。この状況では、TCPは、RFC 2581で指定されているようにL = 1*SMSSを使用する必要があります。これは、転送のこの段階では大量の未装飾データのACKが一般的であるためです。これらのACKは、最後のRTTでネットワークを離れたデータの量を必ずしも示しているわけではないため、ABCはCWNDを増加させる量を正確に判断できません。例として、セグメントnはネットワークによってドロップされ、セグメントn 1とn 2がレシーバーに正常に到着します。送信者は、2つの重複したAcksのみを受け取るため、損失を検出するために再送信タイマー（RTO）に依存する必要があります。RTOの有効期限が切れると、セグメントnが再送信されます。再送信に応じて送信されたACKはセグメントn 2の場合になります。ただし、このACKは、3つのセグメントが最後のRTTでネットワークを離れたことを示していませんが、単一のセグメントのみがネットワークを離れました。したがって、適切なCWND増分は最大1*SMSSバイトです。
[Jac88] shows that increases in cwnd of more than a factor of two in succeeding RTTs can cause spurious retransmissions on slow links where the bandwidth dominates the RTT, assuming the RTO estimator given in [Jac88] and [RFC2988]. ABC stays within this limit of no more than doubling cwnd in successive RTTs by capping the increase (no matter what L is employed) by the number of previously unacknowledged bytes covered by each incoming ACK.
[JAC88]は、後続のRTTの2倍以上の2倍以上のCWNDの増加が、帯域幅がRTTを支配する遅いリンクで偽りの再送信を引き起こす可能性があることを示しています。ABCは、各着信ACKでカバーされている以前に承認されていないバイトの数によって増加（Lが使用されていても）をキャップすることにより、連続したRTTのCWNDを2倍にする以下のこの制限内にとどまります。
3 Advantages
3つの利点
This section outlines several advantages of using the ABC algorithm to increase cwnd, rather than the standard ACK counting algorithm given in [RFC2581].
このセクションでは、[RFC2581]に与えられた標準のACKカウントアルゴリズムではなく、ABCアルゴリズムを使用してCWNDを増加させるといういくつかの利点を概説します。
The ABC algorithm outlined in section 2 increases TCP's cwnd in proportion to the amount of data actually sent into the network. ACK counting, on the other hand, increments cwnd by a constant upon the arrival of each ACK. For instance, consider an interactive telnet connection (e.g., ssh or telnet) in which ACKs generally cover only a few bytes of data, but cwnd is increased by 1*SMSS bytes for each ACK received. When a large amount of data needs to be transmitted (e.g., displaying a large file) the data is sent in one large burst because the cwnd grows by 1*SMSS bytes per ACK rather than based on the actual amount of capacity used. Such a line-rate burst of data can potentially cause a large amount of segment loss.
セクション2で概説されているABCアルゴリズムは、実際にネットワークに送信されたデータの量に比例してTCPのCWNDを増加させます。一方、ACKカウントは、各ACKの到着時に定数によってCWNDを増加させます。たとえば、ACKが一般的に数バイトのデータしかカバーしないインタラクティブテルネット接続（SSHやTelnetなど）を検討しますが、CWNDは受信した各ACKの1*SMSSバイトによって増加します。大量のデータを送信する必要がある場合（たとえば、大きなファイルを表示する）、CWNDは実際の容量の量に基づいてではなく、ACKあたり1*SMSSバイトで成長するため、1つの大きなバーストでデータが送信されます。このようなラインレートデータのバーストは、大量のセグメントの損失を引き起こす可能性があります。
Congestion Window Validation (CWV) [RFC2861] addresses the above problem as well. CWV limits the amount of unused cwnd a TCP connection can accumulate. ABC can be used in conjunction with CWV to obtain an accurate measure of the network path.
混雑ウィンドウ検証（CWV）[RFC2861]は、上記の問題にも対処します。CWVは、使用されていないCWNDの量を制限します。TCP接続は蓄積します。ABCをCWVと組み合わせて使用して、ネットワークパスの正確な測定値を取得できます。
Delayed ACKs [RFC1122,RFC2581] allow a TCP receiver to refrain from sending an ACK for each incoming segment. However, a receiver SHOULD send an ACK for every second full-sized segment that arrives. Furthermore, a receiver MUST NOT withhold an ACK for more than 500 ms. By reducing the number of ACKs sent to the data originator the receiver is slowing the growth of the congestion window under an ACK counting system. Using ABC with L=2*SMSS bytes can roughly negate the negative impact imposed by delayed ACKs by allowing cwnd to be increased for ACKs that are withheld by the receiver. This allows the congestion window to grow in a manner similar to the case when the receiver ACKs each incoming segment, but without adding extra traffic to the network. Simulation studies have shown increased throughput when a TCP sender uses ABC when compared to the standard ACK counting algorithm [All99], especially for short transfers that never leave the initial slow start period.
遅延ACK [RFC1122、RFC2581]により、TCPレシーバーは、各着信セグメントのACKの送信を控えることができます。ただし、レシーバーは、到着する2つのフルサイズのセグメントごとにACKを送信する必要があります。さらに、レシーバーは500ミリ秒以上ACKを差し控えてはなりません。データオリジナルに送信されるACKの数を減らすことにより、受信機はACKカウントシステムの下での輻輳ウィンドウの成長を遅らせています。L = 2*SMSSバイトでABCを使用すると、レシーバーが差し控えられているACKのCWNDを増加させることにより、遅延ACKによって課される負の影響を大幅に無効にすることができます。これにより、輻輳ウィンドウは、受信機が各着信セグメントをアシクする場合と同様の方法で成長できますが、ネットワークに追加のトラフィックを追加することはできません。シミュレーション研究では、TCP送信者が標準のACKカウントアルゴリズム[ALL99]と比較した場合、特に最初の遅い開始期間を離れることのない短い転送の場合、ABCを使用するとスループットの増加が示されています。
Note that delayed ACKs should not be an issue during slow start-based loss recovery, as RFC 2581 recommends that receivers should not delay ACKs that cover out-of-order segments. Therefore, as discussed above, ABC with L > 1*SMSS bytes is inappropriate for such slow start based loss recovery and MUST NOT be used.
RFC 2581は、順序外セグメントをカバーするACKを遅らせることはないことを推奨するため、遅延ACKはスロースタートベースの損失回復中に問題ではないことに注意してください。したがって、上記で説明したように、L> 1*SMSSバイトを含むABCは、このような遅いスタートベースの損失回復には不適切であり、使用してはなりません。
Note: In the case when an entire window of data is lost, a TCP receiver will likely generate delayed ACKs and an L > 1*SMSS bytes would be safe. However, detecting this scenario is difficult. Therefore to keep ABC conservative, this document mandates that L MUST NOT be > 1*SMSS bytes in any slow start-based loss recovery.
注：データのウィンドウ全体が失われた場合、TCPレシーバーが遅延ACKを生成する可能性が高く、L> 1*SMSSバイトが安全になります。ただし、このシナリオを検出することは困難です。したがって、ABC保守派を維持するために、この文書は、Lが遅いスタートベースの損失回復で1*SMSSバイトを> 1*SMSSにしてはならないことを義務付けています。
ACK loss can also retard the growth of a congestion window that increases based on the number of ACKs that arrive. When counting ACKs, dropped ACKs represent forever-missed opportunities to increase cwnd. Using ABC with L > 1*SMSS bytes allows the sender to mitigate the effect of lost ACKs.
ACKの損失は、到着したACKの数に基づいて増加する混雑ウィンドウの成長を遅らせる可能性があります。Acksをカウントするとき、ドロップされたAcksは、CWNDを増やすための永遠にミスされた機会を表しています。l> 1*SMSSバイトでABCを使用すると、送信者が失われたACKの効果を軽減できます。
[SCWA99] outlines several methods for a receiver to induce a TCP sender into violating congestion control and transmitting data at a potentially inappropriate rate. One of the outlined attacks is "ACK Division". This scheme involves the receiver sending multiple ACKs for each incoming data segment, each ACKing only a small portion of the original TCP data segment. Since TCP senders have traditionally used ACK counting to increase cwnd, ACK division causes inappropriately rapid cwnd growth and, in turn, a potentially inappropriate sending rate. A TCP sender that uses ABC can prevent this attack from being used to undermine standard congestion control because the cwnd increase is based on the number of bytes ACKed, rather than the number of ACKs received.
[SCWA99]は、受信者がTCP送信者に渋滞制御に違反し、潜在的に不適切な速度でデータを送信するように誘導するためのいくつかの方法を概説しています。概説された攻撃の1つは「ACK部門」です。このスキームでは、受信者が受信データセグメントごとに複数のACKを送信し、それぞれが元のTCPデータセグメントのごく一部のみをアックします。TCP送信者は伝統的にACKカウントを使用してCWNDを増加させてきたため、ACK師団は不適切に急速なCWND成長を引き起こし、その結果、潜在的に不適切な送信率を引き起こします。ABCを使用するTCP送信者は、CWNDの増加は、受信したACKの数ではなく、ACKEDの数に基づいているため、この攻撃が標準的な混雑制御を損なうのを防ぐことができます。
To prevent misbehaving receivers from inducing inappropriate sender behavior, this document suggests TCP implementations use ABC, even if L=1*SMSS bytes (i.e., not allowing ABC to provide more aggressive cwnd growth than allowed by RFC 2581).
誤動作レシーバーが不適切な送信者の動作を誘導するのを防ぐために、このドキュメントは、L = 1*SMSSバイト（つまり、ABCがRFC 2581で許可されているよりも積極的なCWND成長を提供しない）であっても、TCP実装がABCを使用することを示唆しています。
4 Disadvantages
4つの短所
The main disadvantages of using ABC with L=2*SMSS bytes are an increase in the burstiness of TCP and a small increase in the overall loss rate. [All98] discusses the two ways that ABC increases the burstiness of the TCP sender. First, the "micro burstiness" of the connection is increased. In other words, the number of segments sent in response to each incoming ACK is increased by at most 1 segment when using ABC with L=2*SMSS bytes in conjunction with a receiver that is sending delayed ACKs. During slow start this translates into an increase from sending 2 back-to-back segments to sending 3 back-to-back packets in response to an ACK for a single packet. Or, an increase from 3 packets to 4 packets when receiving a delayed ACK for two outstanding packets. Note that ACK loss can cause larger bursts. However, ABC only increases the burst size by at most 1*SMSS bytes per ACK received when compared to the standard behavior. This slight increase in the burstiness should only cause problems for devices that have very small buffers. In addition, ABC increases the "macro burstiness" of the TCP sender in response to delayed ACKs in slow start. Rather than increasing cwnd by roughly 1.5 times per RTT, ABC roughly doubles the congestion window every RTT. However, doubling cwnd every RTT fits within the spirit of slow start, as originally outlined [Jac88].
l = 2*SMSSバイトでABCを使用することの主な欠点は、TCPの爆発の増加と全体的な損失率のわずかな増加です。[All98]は、ABCがTCP送信者の爆発を増やす2つの方法について説明しています。まず、接続の「ミクロバーティネス」が増加します。言い換えれば、l = 2*SMSSバイトでABCを使用して遅延ACKを送信しているレシーバーを使用してABCを使用すると、各入ってくるACKに応じて送信されるセグメントの数が最大1セグメントによって増加します。スロースタート中に、これは2つの連続したセグメントを送信することから、単一のパケットのACKに応じて3つのバックツーバックパケットを送信することから増加します。または、2つの優れたパケットに対して遅延ACKを受信するときに、3つのパケットから4つのパケットへの増加。ACKの損失は、より大きなバーストを引き起こす可能性があることに注意してください。ただし、ABCは、標準の動作と比較した場合、受信したACKあたりの最大1*SMSSバイトだけでバーストサイズを増加させます。このわずかな増加は、非常に小さなバッファーを持つデバイスに問題を引き起こすはずです。さらに、ABCは、スロースタートでの遅延ACKに応答して、TCP送信者の「マクロバーティネス」を増加させます。RTTごとにCWNDを約1.5倍増加させるのではなく、ABCはRTTごとに輻輳ウィンドウをほぼ2倍にします。ただし、最初に概説したように、すべてのRTTがスピリットの精神に適合します[JAC88]。
With the increased burstiness comes a modest increase in the loss rate for a TCP connection employing ABC (see the next section for a short discussion on the fairness of ABC to non-ABC flows). The additional loss can be directly attributable to the increased aggressiveness of ABC. During slow start cwnd is increased more rapidly. Therefore when loss occurs cwnd is larger and more drops are likely. Similarly, a congestion avoidance cycle takes roughly half, as long when using ABC and delayed ACKs when compared to an ACK counting implementation. In other words, a TCP sender reaches the capacity of the network path, drops a packet and reduces the congestion window by half roughly twice as often when using ABC. However, as discussed above, in spite of the additional loss an ABC TCP sender generally obtains better overall performance than a non-ABC TCP [All99].
爆発の増加に伴い、ABCを採用しているTCP接続の損失率がわずかに増加します（ABCの非ABCフローに対する公平性に関する短い議論については、次のセクションを参照してください）。追加の損失は、ABCの攻撃性の増加に直接起因する可能性があります。スロースタート中にCWNDがより急速に増加します。したがって、損失が発生すると、CWNDが大きくなり、より多くのドロップが可能性が高くなります。同様に、ACKカウントの実装と比較した場合、ABCおよび遅延ACKを使用する場合、混雑回避サイクルは約半分になります。言い換えれば、TCP送信者はネットワークパスの容量に到達し、パケットをドロップし、ABCを使用するときに渋滞ウィンドウをほぼ2倍頻繁に削減します。ただし、上記のように、追加の損失にもかかわらず、ABC TCP送信者は一般に、非ABC TCPよりも優れた全体的なパフォーマンスを取得します[All99]。
Due to the increase in the packet drop rate we suggest ABC be implemented in conjunction with selective acknowledgments [RFC2018].
パケットドロップレートの増加により、ABCは選択的承認と併せて実装することをお勧めします[RFC2018]。
5 Fairness Considerations
5つの公平な考慮事項
[All99] presents several simple simulations conducted to measure the impact of ABC on competing traffic (both ABC and non-ABC). The experiments show that while ABC increases the drop rate for the connection using ABC, competing traffic is not greatly effected. The experiments show that standard TCP and ABC both obtain roughly the same throughput, regardless of the variant of the competing traffic. The simulations also reaffirm that ABC outperforms non-ABC TCP in an environment with varying types of TCP connections. On the other hand, the simulations presented in [All99] are not necessarily realistic. Therefore we are encouraging more experimentation in the Internet.
[ALL99]は、ABCが競合するトラフィック（ABCと非ABCの両方）に与える影響を測定するために実施されたいくつかの簡単なシミュレーションを提示します。実験では、ABCはABCを使用して接続のドロップレートを増加させますが、競合するトラフィックは大きく影響しないことを示しています。実験では、標準のTCPとABCは、競合するトラフィックのバリアントに関係なく、ほぼ同じスループットを取得することを示しています。また、このシミュレーションは、ABCがさまざまなタイプのTCP接続を備えた環境でABC TCPよりも優れていることを再確認します。一方、[ALL99]で提示されたシミュレーションは、必ずしも現実的ではありません。したがって、インターネットでのより多くの実験を奨励しています。
6 Security Considerations
6つのセキュリティ上の考慮事項
As discussed in section 3.3, ABC protects a TCP sender from a misbehaving receiver that induces the sender into transmitting at an inappropriate rate with an "ACK division" attack. This, in turn, protects the network from an overly aggressive sender.
セクション3.3で説明したように、ABCは、「ACK分割」攻撃で送信者が不適切なレートで送信するように誘導する不正な受信機からTCP送信者を保護します。これにより、ネットワークが過度に攻撃的な送信者から保護されます。
7 Conclusions
7つの結論
This document RECOMMENDS that all TCP stacks be modified to use ABC with L=1*SMSS bytes. This change does not increase the aggressiveness of TCP. Furthermore, simulations of ABC with L=2*SMSS bytes show a promising performance improvement that we encourage researchers to experiment with in the Internet.
このドキュメントでは、すべてのTCPスタックを変更して、L = 1*SMSSバイトでABCを使用することを推奨しています。この変更は、TCPの攻撃性を高めません。さらに、L = 2*SMSSバイトによるABCのシミュレーションは、研究者がインターネットで実験することを奨励する有望なパフォーマンス改善を示しています。
Acknowledgments
謝辞
This document has benefited from discussions with and encouragement from Sally Floyd. Van Jacobson and Reiner Ludwig provided valuable input on the implications of byte counting on the RTO. Reiner Ludwig and Kostas Pentikousis provided valuable feedback on a draft of this document.
この文書は、サリー・フロイドとの議論と励ましの恩恵を受けています。Van JacobsonとReiner Ludwigは、RTOにカウントするバイトの意味について貴重なインプットを提供しました。Reiner LudwigとKostas Pentikousisは、この文書のドラフトに関する貴重なフィードバックを提供しました。
Normative References
引用文献
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年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。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
Informative References
参考引用
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 29(3), July 1998.
[All98]マーク・オールマン。TCP謝辞の生成と使用について。ACMコンピューター通信レビュー、29（3）、1998年7月。
[All99] Mark Allman. TCP Byte Counting Refinements. ACM Computer Communication Review, 29(3), July 1999.
[all99]マーク・オールマン。TCPバイトカウントの改良。ACMコンピューター通信レビュー、29（3）、1999年7月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. ACM SIGCOMM 1988.
[Jac88]ヴァンジェイコブソン。混雑の回避と制御。ACM SIGCOMM 1988。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. ACM SIGCOMM, September 1997.
[Pax97] Vern Paxson。TCP実装の自動パケットトレース分析。ACM Sigcomm、1997年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP混雑ウィンドウ検証」、RFC 2861、2000年6月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson. TCP Congestion Control with a Misbehaving Receiver. ACM Computer Communication Review, 29(5), October 1999.
[SCWA99] Stefan Savage、Neal Cardwell、David Wetherall、Tom Anderson。誤動作レシーバーを使用したTCP混雑制御。ACMコンピューター通信レビュー、29（5）、1999年10月。
Author's Address
著者の連絡先
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-5 Cleveland, OH 44135
マークオールマンBBNテクノロジーズ/NASAグレンリサーチセンタールイスフィールド21000 Brookpark Rd。MS 54-5クリーブランド、OH 44135
Fax: 216-433-8705
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。