RFC3465 日本語訳
3465 TCP Congestion Control with Appropriate Byte Counting (ABC). M.Allman. February 2003. (Format: TXT=23486 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Allman Request for Comments: 3465 BBN/NASA GRC Category: Experimental February 2003
コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 3465年のBBN/NASA GRCカテゴリ: 実験的な2003年2月
TCP Congestion Control with Appropriate Byte Counting (ABC)
適切なバイトが重要であることのTCP輻輳制御(ABC)
Status of this Memo
この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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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
このドキュメントは性能とセキュリティの両方を向上させる増加するTCPの混雑ウィンドウ(cwnd)にアルゴリズムへの変更を提案します。 データ送付者(現在の仕様[RFC2581]あたりの)に到着する承認(ACKs)の数に基づくTCPの混雑ウィンドウを増加させるよりむしろ、混雑ウィンドウは到着しているACKsによって承認されたバイト数に基づいて増加します。 アルゴリズムはcwndの成長で遅れたACKsの衝撃を緩和するのによる性能を向上させます。 同時に、アルゴリズムはaの調べられた容量とのダイレクト関係にcwndの成長を供給します。
Allman Experimental [Page 1] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[1ページ]RFC3465TCP輻輳制御
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).
経路をネットワークでつないでください、したがって、ACK勘定より少量のデータ(完全なセグメントサイズよりそれほど)だけをカバーするACKsへのさらに測定された応答を提供します。 このより適切な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の性能を向上させるアルゴリズムを含んでいます。 Experimental RFCとしての公表の1つの目標は、慎重であり、公表の前に標準化過程で使用と展開を奨励することです。 将来IETF Proposed Standardとしてこの仕様を再提出するのは、Transport Areaの意図です、より多くの経験をした後に。
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の値を直線的に増加させるのにCongestion Avoidanceアルゴリズムを使用します。 再送タイムアウトの後か転送の始めか、長い活動していない期間(いくつかの実現における)の後に、TCPは、cwndを指数関数的に増加させるのにSlow Startアルゴリズムを使用します。 RFC2581によると、遅れた出発はcwnd増加を入って来る承認の数に基礎づけます。 RFC2581が増加するcwndの、より多くの緯度、しかし、伝統的に許容する輻輳回避の間、実現は増加を到着ACKsの数に基礎づけています。 以下の2つの小区分では、私たちは、到着するACKsの数に従ってというよりむしろそれぞれ到着しているACKによって承認されるバイト数に基づくcwndを増加させるようにこれらのアルゴリズムへの変更を詳しく述べます。 私たちは、これらの変化を「適切なバイト勘定」(ABC)[All99]と呼びます。
Allman Experimental [Page 2] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[2ページ]RFC3465TCP輻輳制御
2.1 Congestion Avoidance
2.1 輻輳回避
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.
RFC2581は、cwndが転送の輻輳回避段階の間往復の時間(RTT)あたり1つのセグメントによって増加させられるべきであると指定します。 それぞれ到着しているACKのために1/cwndでcwndを増加させることによって、伝統的に、TCPsはこの増加に近似しました。 各入来が区分する受信機ACKsを発生しますが、どれかACKの損失は発生しないなら、このアルゴリズムが1RTTあたりおよそ1つのセグメントでcwndを開きます。 しかしながら、受信機道具がACKs[Bra89]を遅らせたなら、受信機は同じくらい多くのおよそ半分ACKs(およそ1つのセグメントによるあらゆる第2RTT)を返します。(ACKsは送付者にcwndをより保守的に開かせます)。 このドキュメントが示すアプローチはTCP制御ブロックに「_がackedしたバイト」変数にACKedであるバイト数を格納することです。 _がackedしたバイトが、よりなるとき、混雑ウィンドウの値であり、_がackedしたバイトはcwndの値によって減少させられます。 次に、完全サイズのセグメント(SMSS)によってcwndは増加されます。 高々1つのセグメントによる1RTTあたりの窓を開けるので、上に示されたアルゴリズムは輻輳回避の間、RFC2581によって明確に許容されています。
2.2 Slow Start
2.2遅れた出発
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).
RFC2581は、送付者がそれぞれ到着している承認のために遅れた出発の間高々1*SMSSバイトの混雑ウィンドウを増加すると述べます。 このドキュメントは、以前に不承認のバイトACKedの数に従ってTCP送付者SHOULDがそれぞれの入って来る承認でcwndを増加させるよう提案します、増加がLよりバイト以下であるなら。 増加における限界を選ぶLについて次の小区分で議論します。 以前に不承認のバイトACKedの数が1以下*SMSSバイトであるかLが1以下*SMSSバイトであるときに、この提案は、RFC2581によって許容されているほど攻撃的でなくて(ことによるとそれほど攻撃的でない。)です。 *しかしながら、cwndを1つ以上以上増加させて、独身のACKに対応したSMSSバイトはRFC2581によって許容されているより攻撃的です。 遅れた出発アルゴリズムの、より攻撃的なバージョンは[Jac88](すなわち、1RTTあたりのcwndを倍にするだけの)に概説された原則の精神の中にまだ落ちています、そして、このドキュメントは実験のために共用回線網でABCを提案します、適切な限界が適用されているなら(次のセクションを見てください)。
2.3 Choosing the Limit
2.3 限界を選ぶこと。
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
限界(遅れた出発の間にcwnd増加に選ばれたL)はアルゴリズムの攻撃性を制御します。 *L=1を選んで、SMSSバイトはRFC2581によって許容されているほど攻撃的でない振舞いを提供します。 しかしながら、aでは、L=1*SMSSバイトがあるABCは、より保守的です。
Allman Experimental [Page 3] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[3ページ]RFC3465TCP輻輳制御
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.
数、道を合わせてください。そうすれば(次のセクションで議論するように)、したがって、このドキュメントは、TCPがL=1*SMSSバイトで積み重ねますが、それが、小さい性能変化、ABC SHOULDが使用されるのを見るのを示します。
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].
受信機が「伸びACKs」(完全な大きさで分けられたセグメントが遅れたACKアルゴリズムで許容した2以上のためのACKs)[Pax97]を送るとき、非常に大きいLは多量のACKの損失の表面か場合で潜在的に交通の大きいライン料率炸裂に通じることができました。
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で議論するように)。 標準のアルゴリズムがそれぞれの入って来るセグメント[All98](両方の場合におけるいいえと仮定するか、少量のACKの損失)のためにACKを伝える受信機に関連して使用されるとき、L=2*SMSSバイトcwndの成長がケースとおよそ同じであるときにはそれに注意してください。
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)に続く遅れた出発段階の間、あります。 この状況で、多量の以前に不承認のデータのためのACKsが転送のこの段階の間、一般的であるので、TCP MUSTはRFC2581の指定されるとしてのL=1*SMSSを使用します。 これらのACKsは、どのくらいのデータが最後のRTTでネットワークを出たかを必ず示すというわけではありません、そして、したがって、ABCは正確にcwndを非常に増加させる方法を決定できません。 セグメントNはネットワークによって落とされます、そして、セグメントN+1とN+2は首尾よく受信機に到着します。例として、送付者が2写しACKsだけを受け取って、したがって、再送信タイマー(RTO)を当てにしなければならないと言って、損失を検出してください。 RTOが期限が切れるとき、セグメントNは再送されます。 「再-トランスミッション」に対応して送られたACKはセグメントN+2のためにものになるでしょう。 しかしながら、このACKは、3つのセグメントが最後のRTTでネットワークを出ましたが、むしろただ一つのセグメントだけがネットワークを出たのを示しません。 したがって、適切なcwnd増分は高々1*SMSSバイトです。
2.4 RTO Implications
2.4 RTO含意
[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]は、2の続くRTTsの1以上要素のcwndの増加が帯域幅がRTTを支配する遅いリンクの上の偽物の「再-トランスミッション」を引き起こす場合があるのを示します、[Jac88]と[RFC2988]で与えられているRTO見積り人を仮定して。 ABCは連続したRTTsでそれぞれの入って来るACKでカバーされた以前に不承認のバイトの数に従って増加(たとえ何があっても、Lは採用している)にふたをすることによってcwndを倍にするだけのこの限界の範囲内にとどまります。
Allman Experimental [Page 4] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[4ページ]RFC3465TCP輻輳制御
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勘定アルゴリズムよりむしろcwndを増加させるABCアルゴリズムを使用するいくつかの利点について概説します。
3.1 More Appropriate Congestion Window Increase
3.1 より適切な混雑窓の増加
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を定数増加します。 例えば、対話的なtelnetが一般に、ACKsがほんの数バイトのデータをカバーする接続(例えば、セキュアシェル (SSH)かtelnet)であると考えなさい、ただし、各ACKのためのバイトが受けた1*SMSSはcwndを増加させます。 多量のデータが、伝えられる(例えば、大きいファイルを表示します)必要があるとき、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.
混雑Window Validation(CWV)[RFC2861]はまた、その上の問題を訴えます。 CWVはTCP接続が蓄積できる未使用のcwndの量を制限します。 ネットワーク経路の正確な測定を入手するのにCWVに関連してABCを使用できます。
3.2 Mitigate the Impact of Delayed ACKs and Lost ACKs
3.2は遅れたACKsと無くなっているACKsの衝撃を緩和します。
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.
遅れたACKs[RFC1122、RFC2581]はそれぞれの入って来るセグメントのためにACKを送るのをTCP受信機を控えさせます。 しかしながら、受信機SHOULDは到着するあらゆる2番目の完全サイズのセグメントのためにACKを送ります。 その上、ACKsの数がデータ創始者への受信機を送った500以上原稿By減少が混雑ウィンドウの成長を遅くすることであるので、受信機はACK計測システムの下でACKを差し控えてはいけません。 L=2*SMSSバイトがあるABCを使用すると、およそcwndが受信機によって差し控えられるACKsのために増加するのを許容することによって遅れたACKsによって課された負の衝撃は否定できます。これは、混雑ウィンドウが受信機ACKsであることのケースと同様の方法でそれぞれの入って来るセグメントを育てますが、余分な交通をネットワークに追加しないで成長するのを許容します。 シミュレーション研究は、標準のACKと比べるとTCP送付者がいつアルゴリズム[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.
遅れたACKsが遅いスタートベースの損失回復の間問題であるべきでないことに注意してください、RFC2581が、受信機が不適切なセグメントをカバーするACKsを遅らせるはずがないことを勧めるとき。 したがって、上で議論するように、L>1*SMSSバイトがあるABCはそのような遅れた出発に基づいている損失回復に不適当であり、使用されているはずがありません。
Allman Experimental [Page 5] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[5ページ]RFC3465TCP輻輳制御
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受信機はおそらく遅れたACKsとL>1*を発生させるでしょう。SMSSバイトは安全でしょう。 しかしながら、このシナリオを検出するのは難しいです。 したがって、ABCを保守的に保つために、このドキュメントは、Lがどんな遅いスタートベースの損失回復でも>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の損失は到着するACKsの数に基づいて増加する混雑ウィンドウの成長を遅らせることができます。 ACKsを数えるとき、低下しているACKsはcwndを増加させるいつまでも逃された機会を表します。 L>1*SMSSバイトがあるABCを使用するのに、送付者は無くなっているACKsの効果を緩和できます。
3.3 Prevents Attacks from Misbehaving Receivers
3.3はふらちな事する受信機から攻撃を防ぎます。
[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事業部」です。 この計画はそれぞれの入って来るデータ・セグメント、各ACKingのための複数のACKsにオリジナルのTCPデータ・セグメントの少量だけを送る受信機にかかわります。 以来、TCP送付者はcwndを増加させるように数えるACKを伝統的に使用しています、そして、ACK分割は不適当に急速なcwndの成長を引き起こします、そして、順番に、潜在的に不適当な送付は評価します。 ABCを使用するTCP送付者は、この攻撃がcwnd増加がACKsの数よりむしろ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).
不適当な送付者の振舞いを引き起こすのからのふらちな事する受信機を防ぐために、このドキュメントが、TCP実現がABCを使用するのを示す、L=1*SMSSバイト(すなわち、ABCがRFC2581によって許容されているより攻撃的なcwndの成長を供給するのを許容しません)。
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
L=2*SMSSバイトがあるABCを使用する主な損失は、TCPのburstinessの増加と総合損失率の微増です。 [All98]はABCがTCP送付者のburstinessを増加させる2つの方法について議論します。 まず最初に、接続の「マイクロburstiness」は増加されています。 言い換えれば、受信機に関連してL=2*SMSSバイトがあるABCを使用するとき、それぞれの入って来るACKに対応して送られたセグメントの数は高々1つのセグメントによって増加させられました、すなわち、発信がACKsを遅らせました。 遅れた出発の間、これは、単一のパケットのためのACKに対応して後部への3つのパケットを送るのに2つの背中合わせのセグメントを送るので、増加に翻訳されます。 aを受けるとき、または、3つのパケットから4つのパケットまでの増加は2つの傑出しているパケットのためにACKを遅らせました。 ACKの損失が、より大きい炸裂を引き起こす場合があることに注意してください。 しかしながら、ABCは放出量を高々1標準の振舞いと比べると受け取られたACKあたりの1*SMSSバイト増加させるだけです。 この侮辱
Allman Experimental [Page 6] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[6ページ]RFC3465TCP輻輳制御
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].
burstinessの増加は非常に小さいバッファを持っている装置のために問題を引き起こすだけであるべきです。 さらに、ABCは遅れた出発における遅れたACKsに対応してTCP送付者の「マクロburstiness」を増加させます。 およそ1.5回の1RTTあたりのcwndに、ABCがおよそ倍にする増加よりむしろ、混雑はあらゆるRTTに窓を付けます。 しかしながら、cwndを倍にして、あらゆる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].
増加するburstinessと共に、ABC(非ABCへのABCの公正についての短い議論のための次のセクションが流れるのを見る)を使うTCP接続の損失率の穏やかな増加は来ています。 追加損失は直接ABCの増加する攻撃性に起因している場合があります。 遅れた出発の間、cwndは、より急速に増加します。 したがって、損失が発生するとき、cwndは、より大きいです、そして、より多くの低下がありそうです。 ACK勘定実現と比べるとABCと遅れたACKsを使用するとき、同様に、輻輳回避サイクルは手荒く同じくらい半分、同じくらい長くかかります。 言い換えれば、ABCを使用するとき、TCP送付者は、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が非ABC TCPより異なったタイプの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送付者を保護します。 これはひどく攻撃的な送付者からネットワークを順番に保護します。
Allman Experimental [Page 7] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[7ページ]RFC3465TCP輻輳制御
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.
これは、L=1*SMSSバイトがあるABCを使用するために変更されていた状態ですべてのTCPスタックがあるRECOMMENDSを記録します。 この変化は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.
このドキュメントはサリー・フロイドからの議論と奨励の利益を得ました。 ヴァン・ジェーコブソンとライナー・ラドウィグは、RTOを頼りにしながら、バイトの含意に関する貴重な入力を提供しました。 ライナー・ラドウィグとコスタスPentikousisはこのドキュメントの草稿の有益なフィードバックを提供しました。
Normative References
引用規格
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、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 SIGCOMM1988。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP
Implementations. ACM SIGCOMM, September 1997.
[Pax97]バーン・パクソン。 TCP実現の自動化されたパケット微量成分分析。 1997年9月のACM SIGCOMM。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC2861] ハンドレーとM.とPadhyeとJ.とS.フロイド、「TCP混雑窓の合法化」、RFC2861、2000年6月。
Allman Experimental [Page 8] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[8ページ]RFC3465TCP輻輳制御
[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] ステファン・サヴェージ、ニール・カードウェル、デヴィッドWetherall、トム・アンダーソン。 ふらちな事する受信機ACMコンピュータコミュニケーションレビュー、29(5)、10月1999日があるTCP輻輳制御
Author's Address
作者のアドレス
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-5 Cleveland, OH 44135
マークオールマンBBN技術/NASAグレンリサーチセンタルイス分野21000Brookpark通り MS54-5クリーブランド、OH 44135
Fax: 216-433-8705 Phone: 216-433-6586 EMail: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Fax: 216-433-8705 以下に電話をしてください。 216-433-6586 メールしてください: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Allman Experimental [Page 9] RFC 3465 TCP Congestion Control with ABC February 2003
ABC2003年2月があるオールマン実験的な[9ページ]RFC3465TCP輻輳制御
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Allman Experimental [Page 10]
オールマンExperimentalです。[10ページ]
一覧
スポンサーリンク
