[要約] RFC 6298は、TCPの再送タイマーを計算する方法についての規格です。その目的は、ネットワークの遅延やパケットロスに応じて適切な再送タイミングを設定することです。
Internet Engineering Task Force (IETF) V. Paxson
Request for Comments: 6298 ICSI/UC Berkeley
Obsoletes: 2988 M. Allman
Updates: 1122 ICSI
Category: Standards Track J. Chu
ISSN: 2070-1721 Google
M. Sargent
CWRU
June 2011
Computing TCP's Retransmission Timer
TCPの再送信タイマーを計算します
Abstract
概要
This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988.
このドキュメントでは、伝送制御プロトコル（TCP）送信者が再送信タイマーを計算および管理するために使用する必要がある標準アルゴリズムを定義します。RFC 1122のセクション4.2.3.1のディスカッションを拡張し、アルゴリズムをAから必須にサポートする要件をアップグレードします。このドキュメントは、RFC 2988を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6298.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6298で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
The Transmission Control Protocol (TCP) [Pos81] uses a retransmission timer to ensure data delivery in the absence of any feedback from the remote data receiver. The duration of this timer is referred to as RTO (retransmission timeout). RFC 1122 [Bra89] specifies that the RTO should be calculated as outlined in [Jac88].
トランスミッションコントロールプロトコル（TCP）[POS81]は、再送信タイマーを使用して、リモートデータレシーバーからのフィードバックがない場合にデータ配信を確保します。このタイマーの期間は、RTO（再送信タイムアウト）と呼ばれます。RFC 1122 [BRA89]は、[JAC88]で概説されているようにRTOを計算する必要があることを指定します。
This document codifies the algorithm for setting the RTO. In addition, this document expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. RFC 5681 [APB09] outlines the algorithm TCP uses to begin sending after the RTO expires and a retransmission is sent. This document does not alter the behavior outlined in RFC 5681 [APB09].
このドキュメントは、RTOを設定するためのアルゴリズムを成文化します。さらに、このドキュメントは、RFC 1122のセクション4.2.3.1のディスカッションで拡張され、アルゴリズムをサポートする要件を正常にアップグレードします。RFC 5681 [APB09]は、TCPが使用するアルゴリズムの概要を説明し、RTOの有効期限が切れ、再送信が送信された後に送信を開始します。この文書は、RFC 5681 [APB09]で概説されている動作を変更しません。
In some situations, it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow. This document obsoletes RFC 2988 [PA00].
状況によっては、TCP送信者がこのドキュメントで詳述されているアルゴリズムよりも保守的であることが有益かもしれません。ただし、TCPは、次のアルゴリズムが許可するよりも攻撃的であってはなりません。このドキュメントは、RFC 2988 [PA00]を廃止します。
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 [Bra97].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[bra97]に記載されているように解釈される。
To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). In addition, we assume a clock granularity of G seconds.
現在のRTOを計算するために、TCP送信者は2つの状態変数、SRTT（滑らかな往復時間）とRTTVAR（往復時間の変動）を維持します。さらに、g秒のクロック粒度を想定しています。
The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:
SRTT、RTTVAR、およびRTOの計算を管理する規則は次のとおりです。
(2.1) Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD set RTO <- 1 second, though the "backing off" on repeated retransmission discussed in (5.5) still applies.
（2.1）送信者と受信機の間に送信されるセグメントに対して往復時間（RTT）測定が行われるまで、送信者はRTO <-1秒を設定する必要がありますが、（5.5）で議論された繰り返しの再送信で「バックオフ」を設定する必要があります。まだ適用されます。
Note that the previous version of this document used an initial RTO of 3 seconds [PA00]. A TCP implementation MAY still use this value (or any other value > 1 second). This change in the lower bound on the initial RTO is discussed in further detail in Appendix A.
このドキュメントの以前のバージョンでは、3秒の初期RTO [PA00]を使用したことに注意してください。TCP実装では、この値（またはその他の値を1秒以上）を使用する場合があります。最初のRTOの下限のこの変更については、付録Aでさらに詳しく説明します。
(2.2) When the first RTT measurement R is made, the host MUST set
（2.2）最初のRTT測定Rが作成されると、ホストは設定する必要があります
SRTT <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR)
where K = 4.
ここで、k = 4。
(2.3) When a subsequent RTT measurement R' is made, a host MUST set
（2.3）後続のRTT測定r 'が作成されると、ホストが設定する必要があります
RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'
The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. That is, updating RTTVAR and SRTT MUST be computed in the above order.
RTTVARのアップデートで使用されるSRTTの値は、2番目の割り当てを使用してSRTT自体を更新する前の値です。つまり、RTTVARとSRTTの更新は、上記の順序で計算する必要があります。
The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]).
上記は、alpha = 1/8およびbeta = 1/4を使用して計算する必要があります（[JK88]で示唆されているように）。
After the computation, a host MUST update RTO <- SRTT + max (G, K*RTTVAR)
計算後、ホストはrto <-srtt max（g、k*rttvar）を更新する必要があります
(2.4) Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second.
（2.4）RTOが計算されるたびに、1秒未満の場合、RTOは最大1秒まで丸められる必要があります。
Traditionally, TCP implementations use coarse grain clocks to measure the RTT and trigger the RTO, which imposes a large minimum value on the RTO. Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. Therefore, this specification requires a large minimum RTO as a conservative approach, while at the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior.
従来、TCPの実装は、粗い穀物時計を使用してRTTを測定し、RTOをトリガーし、RTOに大きな最小値を課しています。調査によると、TCP保守的な状態を維持し、偽りの再送信を避けるためには、大きな最小RTOが必要であることが示唆されています[AP99]。したがって、この仕様には保守的なアプローチとして大きな最小RTOが必要ですが、同時に、将来の時点で、研究がより少ない最小RTOが許容できるか優れていることを研究する可能性があることを認めています。
(2.5) A maximum value MAY be placed on RTO provided it is at least 60 seconds.
（2.5）少なくとも60秒である場合、RTOに最大値を配置できます。
TCP MUST use Karn's algorithm [KP87] for taking RTT samples. That is, RTT samples MUST NOT be made using segments that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance). The only case when TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is employed, since the timestamp option removes the ambiguity regarding which instance of the data segment triggered the acknowledgment.
TCPは、RTTサンプルを採取するためにKarnのアルゴリズム[KP87]を使用する必要があります。つまり、RTTサンプルは、再送信されたセグメントを使用して作成してはなりません（したがって、パケットの最初のインスタンスであろうと後のインスタンスの最初のインスタンスであったかどうかはあいまいです）。TCPが再送信セグメントからRTTサンプルを安全に採取できる場合の唯一のケースは、TCPタイムスタンプオプション[JBB92]が使用される場合です。これは、タイムスタンプオプションがデータセグメントのどのインスタンスが確認をトリガーしたかに関するあいまいさを削除するためです。
Traditionally, TCP implementations have taken one RTT measurement at a time (typically, once per RTT). However, when using the timestamp option, each ACK can be used as an RTT sample. RFC 1323 [JBB92] suggests that TCP connections utilizing large congestion windows should take many RTT samples per window of data to avoid aliasing effects in the estimated RTT. A TCP implementation MUST take at least one RTT measurement per RTT (unless that is not possible per Karn's algorithm).
従来、TCP実装では、一度に1つのRTT測定値を取得していました（通常、RTTごとに1回）。ただし、タイムスタンプオプションを使用する場合、各ACKはRTTサンプルとして使用できます。RFC 1323 [JBB92]は、大きな混雑ウィンドウを使用するTCP接続は、推定RTTのエイリアス効果を回避するために、データのウィンドウごとに多くのRTTサンプルを採取することを示唆しています。TCP実装では、RTTごとに少なくとも1つのRTT測定値を取得する必要があります（Karnのアルゴリズムごとに不可能な場合を除く）。
For fairly modest congestion window sizes, research suggests that timing each segment does not lead to a better RTT estimator [AP99]. Additionally, when multiple samples are taken per RTT, the alpha and beta defined in Section 2 may keep an inadequate RTT history. A method for changing these constants is currently an open research question.
かなり控えめな混雑ウィンドウサイズの場合、研究は、各セグメントをタイミングするとRTT推定器が改善されないことが示唆されています[AP99]。さらに、RTTごとに複数のサンプルを採取すると、セクション2で定義されているアルファとベータは、RTTの履歴が不十分になる可能性があります。これらの定数を変更する方法は現在、オープンな研究の質問です。
There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables. However, if the K*RTTVAR term in the RTO calculation equals zero, the variance term MUST be rounded to G seconds (i.e., use the equation given in step 2.3).
RTT測定と異なる状態変数の計算に使用されるクロック粒度Gには要件はありません。ただし、RTO計算のk*rttvar項がゼロに等しい場合、分散項はg秒に丸められる必要があります（つまり、ステップ2.3で与えられた方程式を使用します）。
RTO <- SRTT + max (G, K*RTTVAR)
Experience has shown that finer clock granularities (<= 100 msec) perform somewhat better than coarser granularities.
経験により、より細かいクロック粒度（<= 100ミリ秒）が粗い粒状よりもやや良くパフォーマンスを発揮することが示されています。
Note that [Jac88] outlines several clever tricks that can be used to obtain better precision from coarse granularity timers. These changes are widely implemented in current TCP implementations.
[Jac88]は、粗い粒度タイマーからより良い精度を得るために使用できるいくつかの巧妙なトリックを概説していることに注意してください。これらの変更は、現在のTCP実装で広く実装されています。
An implementation MUST manage the retransmission timer(s) in such a way that a segment is never retransmitted too early, i.e., less than one RTO after the previous transmission of that segment.
実装は、セグメントが早期に再送信されないように、つまりそのセグメントの以前の送信後に1つ未満のRTOを決して再送信しないように、再送信タイマーを管理する必要があります。
The following is the RECOMMENDED algorithm for managing the retransmission timer:
以下は、再送信タイマーを管理するための推奨アルゴリズムです。
(5.1) Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).
（5.1）データを含むパケットが送信されるたびに（再送信を含む）、タイマーが実行されていない場合は、RTOの数秒後に期限切れになるように実行してください（RTOの現在の値の場合）。
(5.2) When all outstanding data has been acknowledged, turn off the retransmission timer.
（5.2）すべての未解決のデータが認められたら、再送信タイマーをオフにします。
(5.3) When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire after RTO seconds (for the current value of RTO).
（5.3）新しいデータを認めたACKを受信した場合、RTOの数秒後（RTOの現在の値に対して）期限切れになるように再送信タイマーを再起動します。
When the retransmission timer expires, do the following:
再送信タイマーが期限切れになったら、次のことを行います。
(5.4) Retransmit the earliest segment that has not been acknowledged by the TCP receiver.
（5.4）TCPレシーバーによって認められていない最も初期のセグメントを再送信します。
(5.5) The host MUST set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in (2.5) above may be used to provide an upper bound to this doubling operation.
（5.5）ホストはRTO <-RTO * 2を設定する必要があります（「タイマーからバックオフ」）。上記の（2.5）で説明されている最大値は、この倍増操作の上限を提供するために使用できます。
(5.6) Start the retransmission timer, such that it expires after RTO seconds (for the value of RTO after the doubling operation outlined in 5.5).
（5.6）再送信タイマーを開始します。これにより、RTOの数秒後に期限切れになります（5.5で概説された2倍の操作の後のRTOの値に対して）。
(5.7) If the timer expires awaiting the ACK of a SYN segment and the TCP implementation is using an RTO less than 3 seconds, the RTO MUST be re-initialized to 3 seconds when data transmission begins (i.e., after the three-way handshake completes).
（5.7）タイマーがSynセグメントのACKを待って期限切れになり、TCPの実装が3秒未満のRTOを使用している場合、RTOはデータ送信が始まるときに3秒に再開する必要があります（つまり、3段階のハンドシェイク後完了）。
This represents a change from the previous version of this document [PA00] and is discussed in Appendix A.
これは、このドキュメント[PA00]の以前のバージョンからの変更を表し、付録Aで説明します。
Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in Section 2 are performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to exponential back off (rule 5.5).
再送信後、新しいRTT測定が取得されると（新しいデータが送信および承認されたときにのみ発生する可能性があります）、RTOの計算を含むセクション2で概説されている計算が実行されることに注意してください。それが指数関数的なバックオフの対象となった後に戻って（規則5.5）。
Note that a TCP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared, they should be initialized with the next RTT sample taken per (2.2) rather than using (2.3).
TCPの実装は、この状況では現在のSRTTとRTTVARが偽物である可能性が高いため、タイマーを複数回バックした後、SRTTとRTTVARをクリアする可能性があることに注意してください。SRTTとRTTVARがクリアされると、（2.3）を使用するのではなく（2.2）、次のRTTサンプルを使用して初期化する必要があります。
This document requires a TCP to wait for a given interval before retransmitting an unacknowledged segment. An attacker could cause a TCP sender to compute a large value of RTO by adding delay to a timed packet's latency, or that of its acknowledgment. However, the ability to add delay to a packet's latency often coincides with the ability to cause the packet to be lost, so it is difficult to see what an attacker might gain from such an attack that could cause more damage than simply discarding some of the TCP connection's packets.
このドキュメントでは、未承認のセグメントを再送信する前に、特定の間隔を待つためにTCPが必要です。攻撃者は、TCP送信者が、時限パケットのレイテンシまたはその謝辞の遅延に遅延を追加することにより、RTOの大きな値を計算する可能性があります。ただし、パケットのレイテンシに遅延を追加する機能は、パケットを失う能力としばしば一致するため、攻撃者がそのような攻撃から得られるものを確認することは困難です。TCP接続のパケット。
The Internet, to a considerable degree, relies on the correct implementation of the RTO algorithm (as well as those described in RFC 5681) in order to preserve network stability and avoid congestion collapse. An attacker could cause TCP endpoints to respond more aggressively in the face of congestion by forging acknowledgments for segments before the receiver has actually received the data, thus lowering RTO to an unsafe value. But to do so requires spoofing the acknowledgments correctly, which is difficult unless the attacker can monitor traffic along the path between the sender and the receiver. In addition, even if the attacker can cause the sender's RTO to reach too small a value, it appears the attacker cannot leverage this into much of an attack (compared to the other damage they can do if they can spoof packets belonging to the connection), since the sending TCP will still back off its timer in the face of an incorrectly transmitted packet's loss due to actual congestion.
インターネットは、ネットワークの安定性を維持し、渋滞の崩壊を避けるために、かなりの程度に、RTOアルゴリズムの正しい実装（およびRFC 5681に記載されているもの）に依存しています。攻撃者は、受信者が実際にデータを受信する前にセグメントの謝辞を偽造することにより、TCPのエンドポイントが混雑に直面してより積極的に応答し、RTOを安全でない値に引き下げる可能性があります。しかし、そうするには、謝辞を正しくスプーフィングする必要があります。これは、攻撃者が送信者と受信機の間のパスに沿ってトラフィックを監視できない限り困難です。さらに、攻撃者が送信者のRTOに値が小さすぎるようにすることができる場合でも、攻撃者はこれを多くの攻撃に活用できないように見えます（接続に属するパケットをスプーフィングできる場合にできる他のダメージと比較して）、送信するTCPは、実際の混雑による誤って送信されたパケットの損失に直面して、まだタイマーから戻ってくるためです。
The security considerations in RFC 5681 [APB09] are also applicable to this document.
RFC 5681 [APB09]のセキュリティ上の考慮事項もこのドキュメントに適用できます。
This document reduces the initial RTO from the previous 3 seconds [PA00] to 1 second, unless the SYN or the ACK of the SYN is lost, in which case the default RTO is reverted to 3 seconds before data transmission begins.
このドキュメントは、SynまたはsynのACKが失われない限り、過去3秒[PA00]から1秒に初期のRTOを減らします。
The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].
このメモで説明されているRTOアルゴリズムは、[JAC88]のヴァンジェイコブソンによって発信されました。
Much of the data that motivated changing the initial RTO from 3 seconds to 1 second came from Robert Love, Andre Broido, and Mike Belshe.
最初のRTOを3秒から1秒に変更する意欲があるデータの多くは、ロバートラブ、アンドレブロイド、マイクベルシェからのものでした。
[APB09] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[APB09] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 5681、2009年9月。
[Bra89] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[JBB92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[JBB92] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[POS81] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[AP99] Allman、M。およびV. Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、Sigcomm 99。
[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century", http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf, July 2009.
[Chu09] Chu、J。、「21世紀のTCPパラメーターの調整」、http：//www.ietf.org/proceedings/75/slides/tcpm-1.pdf、2009年7月。
[SLS09] Schulman, A., Levin, D., and Spring, N., "CRAWDAD data set umd/sigcomm2008 (v. 2009-03-02)", http://crawdad.cs.dartmouth.edu/umd/sigcomm2008, March, 2009.
[SLS09] Schulman、A.、Levin、D。、およびSpring、N。、 "Crawdad Data Set UMD/Sigcomm2008（v。2009-03-02）"、http://crawdad.cs.dartmouth.edu/umd/SIGCOMM2008、2009年3月。
[HKA04] Henderson, T., Kotz, D., and Abyzov, I., "CRAWDAD trace dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)", http://crawdad.cs.dartmouth.edu/dartmouth/campus/ tcpdump/fall03, November 2004.
[HKA04] Henderson、T.、Kotz、D。、およびAbyzov、I。、「Crawdad Trace Dartmouth/Campus/Tcpdump/Fall03（v。2004-11-09）」、http：//crawdad.cs.dartmouth。EDU/DARTMOUTH/CAMPUS/TCPDUMP/FALL03、2004年11月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[Jac88] Jacobson、V。、「混雑の回避と制御」、コンピューターコミュニケーションレビュー、Vol。18、いいえ。4、pp。314-329、1988年8月。
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[JK88] Jacobson、V。およびM. Karels、「混雑の回避と制御」、ftp：//ftp.ee.lbl.gov/papers/congavoid.ps.z。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.
[KP87] Karn、P。およびC. Partridge、「信頼できる輸送プロトコルにおける往復時間推定の改善」、Sigcomm 87。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[PA00] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
Choosing a reasonable initial RTO requires balancing two competing considerations:
合理的な初期RTOを選択するには、2つの競合する考慮事項のバランスをとる必要があります。
1. The initial RTO should be sufficiently large to cover most of the end-to-end paths to avoid spurious retransmissions and their associated negative performance impact.
1. 最初のRTOは、スプリアスな再送信とそれに関連する負のパフォーマンスへの影響を避けるために、エンドツーエンドのパスのほとんどをカバーするのに十分な大きさでなければなりません。
2. The initial RTO should be small enough to ensure a timely recovery from packet loss occurring before an RTT sample is taken.
2. 最初のRTOは、RTTサンプルが採取される前に発生するパケット損失からのタイムリーな回復を保証するのに十分なほど小さくなければなりません。
Traditionally, TCP has used 3 seconds as the initial RTO [Bra89] [PA00]. This document calls for lowering this value to 1 second using the following rationale:
従来、TCPは最初のRTO [BRA89] [PA00]として3秒を使用してきました。このドキュメントでは、次の理論的根拠を使用して、この値を1秒に下げることを求めています。
- Modern networks are simply faster than the state-of-the-art was at the time the initial RTO of 3 seconds was defined.
- 最新のネットワークは、3秒の最初のRTOが定義された時点で、最先端の最先端よりも高速です。
- Studies have found that the round-trip times of more than 97.5% of the connections observed in a large scale analysis were less than 1 second [Chu09], suggesting that 1 second meets criterion 1 above.
- 研究では、大規模分析で観察された接続の97.5％以上の往復時間が1秒未満[CHU09]であることがわかっており、1秒が上記の基準1を満たしていることを示唆しています。
- In addition, the studies observed retransmission rates within the three-way handshake of roughly 2%. This shows that reducing the initial RTO has benefit to a non-negligible set of connections.
- さらに、研究では、3方向の握手内の再送信率が約2％であることが観察されました。これは、最初のRTOを減らすことは、無視できない接続セットに利益をもたらすことを示しています。
- However, roughly 2.5% of the connections studied in [Chu09] have an RTT longer than 1 second. For those connections, a 1 second initial RTO guarantees a retransmission during connection establishment (needed or not).
- ただし、[CHU09]で調査された接続の約2.5％は、1秒以上RTTを持っています。これらの接続の場合、1秒の初期RTOは、接続確立中の再送信を保証します（必要かどうか）。
When this happens, this document calls for reverting to an initial RTO of 3 seconds for the data transmission phase. Therefore, the implications of the spurious retransmission are modest: (1) an extra SYN is transmitted into the network, and (2) according to RFC 5681 [APB09] the initial congestion window will be limited to 1 segment. While (2) clearly puts such connections at a disadvantage, this document at least resets the RTO such that the connection will not continually run into problems with a short timeout. (Of course, if the RTT is more than 3 seconds, the connection will still encounter difficulties. But that is not a new issue for TCP.)
これが発生した場合、このドキュメントは、データ送信フェーズで3秒の初期RTOに戻ることを求めています。したがって、偽りの再送信の意味は控えめです。（1）追加のsynがネットワークに送信され、（2）RFC 5681 [APB09]によると、初期輻輳ウィンドウは1セグメントに制限されます。（2）は明らかにそのような接続を不利な状態に置いていますが、このドキュメントは少なくともRTOをリセットして、接続が短いタイムアウトで継続的に問題に直面しないようにします。（もちろん、RTTが3秒以上の場合、接続には依然として困難が発生します。しかし、それはTCPの新しい問題ではありません。）
In addition, we note that when using timestamps, TCP will be able to take an RTT sample even in the presence of a spurious retransmission, facilitating convergence to a correct RTT estimate when the RTT exceeds 1 second.
さらに、タイムスタンプを使用する場合、TCPは偽りの再送信が存在する場合でもRTTサンプルを採取できることに注意し、RTTが1秒を超える場合の正しいRTT推定への収束を促進することに注意してください。
As an additional check on the results presented in [Chu09], we analyzed packet traces of client behavior collected at four different vantage points at different times, as follows:
[CHU09]で提示された結果の追加チェックとして、次のように、4つの異なる視点で収集されたクライアントの動作のパケットトレースを次のように分析しました。
Name Dates Pkts. Cnns. Clnts. Servs.
--------------------------------------------------------
LBL-1 Oct/05--Mar/06 292M 242K 228 74K
LBL-2 Nov/09--Feb/10 1.1B 1.2M 1047 38K
ICSI-1 Sep/11--18/07 137M 2.1M 193 486K
ICSI-2 Sep/11--18/08 163M 1.9M 177 277K
ICSI-3 Sep/14--21/09 334M 3.1M 170 253K
ICSI-4 Sep/11--18/10 298M 5M 183 189K
Dartmouth Jan/4--21/04 1B 4M 3782 132K
SIGCOMM Aug/17--21/08 11.6M 133K 152 29K
The "LBL" data was taken at the Lawrence Berkeley National Laboratory, the "ICSI" data from the International Computer Science Institute, the "SIGCOMM" data from the wireless network that served the attendees of SIGCOMM 2008, and the "Dartmouth" data was collected from Dartmouth College's wireless network. The latter two datasets are available from the CRAWDAD data repository [HKA04] [SLS09]. The table lists the dates of the data collections, the number of packets collected, the number of TCP connections observed, the number of local clients monitored, and the number of remote servers contacted. We consider only connections initiated near the tracing vantage point.
「LBL」データは、ローレンスバークレー国立研究所、国際コンピューターサイエンス研究所の「ICSI」データ、SigComm 2008の参加者にサービスを提供したワイヤレスネットワークの「SigComm」データ、および「Dartmouth」データで取得されました。ダートマスカレッジのワイヤレスネットワークから収集されました。後者の2つのデータセットは、CrawDadデータリポジトリ[HKA04] [SLS09]から入手できます。表には、データコレクションの日付、収集されたパケットの数、観測されたTCP接続の数、監視されるローカルクライアントの数、および連絡先のリモートサーバーの数がリストされています。トレースの視点の近くで開始された接続のみを検討します。
Analysis of these datasets finds the prevalence of retransmitted SYNs to be between 0.03% (ICSI-4) to roughly 2% (LBL-1 and Dartmouth).
これらのデータセットの分析では、再送信されたSynの有病率は0.03％（ICSI-4）から約2％（LBL-1およびDartmouth）の間であることがわかります。
We then analyzed the data to determine the number of additional and spurious retransmissions that would have been incurred if the initial RTO was assumed to be 1 second. In most of the datasets, the proportion of connections with spurious retransmits was less than 0.1%. However, in the Dartmouth dataset, approximately 1.1% of the connections would have sent a spurious retransmit with a lower initial RTO. We attribute this to the fact that the monitored network is wireless and therefore susceptible to additional delays from RF effects.
次に、データを分析して、初期RTOが1秒であると想定された場合に発生した追加およびスプリアス再送信の数を決定しました。ほとんどのデータセットでは、スプリアスな再送信との接続の割合は0.1％未満でした。ただし、Dartmouth Datasetでは、接続の約1.1％が、より低い初期RTOで偽の再送信を送信していました。これは、監視されているネットワークがワイヤレスであり、したがってRF効果からの追加の遅延の影響を受けやすいという事実に起因しています。
Finally, there are obviously performance benefits from retransmitting lost SYNs with a reduced initial RTO. Across our datasets, the percentage of connections that retransmitted a SYN and would realize at least a 10% performance improvement by using the smaller initial RTO specified in this document ranges from 43% (LBL-1) to 87% (ICSI-4). The percentage of connections that would realize at least a 50% performance improvement ranges from 17% (ICSI-1 and SIGCOMM) to 73% (ICSI-4).
最後に、失われたSynを再び削減して初期RTOを再送信することで、パフォーマンスの利点が明らかにあります。データセット全体で、このドキュメントで指定されたより小さな初期RTOを使用して、Synを再送信し、少なくとも10％のパフォーマンス改善を実現する接続の割合は、43％（LBL-1）から87％（ICSI-4）の範囲です。少なくとも50％のパフォーマンス改善が17％（ICSI-1およびSIGCOMM）から73％（ICSI-4）の範囲であることを実現する接続の割合は。
From the data to which we have access, we conclude that the lower initial RTO is likely to be beneficial to many connections, and harmful to relatively few.
アクセスできるデータから、初期RTOの低下は多くの接続に有益であり、比較的少数に有害である可能性が高いと結論付けます。
Authors' Addresses
著者のアドレス
Vern Paxson ICSI/UC Berkeley 1947 Center Street Suite 600 Berkeley, CA 94704-1198
Vern Paxson ICSI/UC Berkeley 1947 Center Street Suite 600 Berkeley、CA 94704-1198
Phone: 510-666-2882 EMail: vern@icir.org http://www.icir.org/vern/
電話：510-666-2882メール：vern@icir.org http://www.icir.org/vern/
Mark Allman ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
マークオールマンICSI 1947センターストリートスイート600バークレー、カリフォルニア94704-1198
Phone: 440-235-1792 EMail: mallman@icir.org http://www.icir.org/mallman/
電話：440-235-1792メール：mallman@icir.org http://www.icir.org/mallman/
H.K. Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
H.K.Jerry Chu Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043
Phone: 650-253-3010 EMail: hkchu@google.com
電話：650-253-3010メール：hkchu@google.com
Matt Sargent Case Western Reserve University Olin Building 10900 Euclid Avenue Room 505 Cleveland, OH 44106
マットサージェントケースウエスタンリザーブ大学オリンビル10900ユークリッドアベニュールーム505クリーブランド、OH 44106
Phone: 440-223-5932 EMail: mts71@case.edu
電話：440-223-5932メール：mts71@case.edu