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
                                                               June 2011
                  Computing TCP's Retransmission Timer



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 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で議論を展開するとMUSTにSHOULDからアルゴリズムをサポートする要件をアップグレードします。この文書は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


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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ドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

1. Introduction
1. はじめに

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 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での議論を拡張し、MUSTにSHOULDからアルゴリズムをサポートする要件をアップグレードします。 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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【Bra97]に記載されているように解釈されます。

2. The Basic Algorithm

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.


The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:


(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を設定すべきである、送信者と受信者の間で送信されるセグメントのためになされたものまで、 - (5.5)で説明した繰り返し再送の「バックオフ」が、1秒まだ適用されます。

         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.

(2.2) When the first RTT measurement R is made, the host MUST set


            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


            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.


The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]).

上記アルファ= 1/8、ベータ= 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.


         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

(2.5) A maximum value MAY be placed on RTO provided it is at least 60 seconds.


3. Taking RTT Samples

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のサンプルを採取するために[KP87]カーンのアルゴリズムを使用しなければなりません。すなわち、RTTサンプルが再送されたセグメントを使用して作製されてはいけません(したがって、そのため、応答パケット以降のインスタンスの最初のインスタンスのためだったかどうか曖昧である)、です。 TCPタイムスタンプオプションが[JBB92]使用されたときにタイムスタンプオプションは、データセグメントのインスタンスは、肯定応答をトリガかに関する曖昧さを除去するので、TCPが安全に再送セグメントからRTTサンプルを取ることができる場合のみです。

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の実装は(典型的には、一度RTTごとに)一度に一つのRTT測定値をとっています。タイムスタンプオプションを使用する場合しかし、各ACKは、RTTサンプルとして使用することができます。 RFC 1323 [JBB92]大混雑の窓を利用したTCP接続が推定RTTにおけるエイリアシング効果を回避するために、データの窓あたりの多くのRTTサンプルを取るべきであることを示唆しています。 (それはカーンのアルゴリズムあたりのことができない場合を除く)TCPの実装では、RTTごとに少なくとも1回のRTT測定を取る必要があります。

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.


4. Clock Granularity

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).

Gは、RTT測定値と異なる状態変数を計算するために使用されるクロックの粒度のための必要はありません。 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.


5. Managing the RTO Timer
5. RTOタイマーを管理します

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.2) When all outstanding data has been acknowledged, turn off the retransmission timer.


(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).


When the retransmission timer expires, do the following:


(5.4) Retransmit the earliest segment that has not been acknowledged by the TCP receiver.


(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.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)タイマRTO 3秒未満を使用してSYNセグメントとTCP実装のACKを待つ満了した場合、データ送信が始まるとき、RTO(3秒に再初期化されなければならない、すなわち、スリーウェイハンドシェイクの後)完了します。

         This represents a change from the previous version of this
         document [PA00] and is discussed in Appendix 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).


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).

現在のSRTTとRTTVARは、このような状況では偽であると思われるようTCP実装は、タイマーをオフにバックアップした後、複数回SRTTとRTTVARをクリアすることがあります。 SRTTとRTTVARがクリアされると、それらは次のRTT(2.2)ごとに採取したサンプルではなく、使用して(2.3)で初期化する必要があります。

6. Security Considerations

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.


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]におけるセキュリティの考慮事項も、この文書に適用されます。

7. Changes from

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.


8. Acknowledgments

The RTO algorithm described in this memo was originated by Van Jacobson in [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.


9. References
9.1. Normative References
9.1. 引用規格

[APB09] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.

[APB09]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年9月。

[Bra89] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[Bra89]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[JBB92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[JBB92]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。

[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

【Pos81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。

9.2. Informative References
9.2. 参考文献

[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.

「エンドツーエンドのネットワークパスのプロパティの推定について」[AP99]オールマン、M.およびV.パクソン、SIGCOMM 99。

[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century",, July 2009.

[Chu09]チュー、J.、 "21世紀のためのチューニングTCPパラメータ"、、2009年7月。

[SLS09] Schulman, A., Levin, D., and Spring, N., "CRAWDAD data set umd/sigcomm2008 (v. 2009-03-02)",, March, 2009.

【SLS09]シュルマン、A.、レビン、D.、および、春、N.、 "/ sigcomm2008を(V。2009-03-02)UMD CRAWDADデータセット" / sigcomm2008、2009年3月。

[HKA04] Henderson, T., Kotz, D., and Abyzov, I., "CRAWDAD trace dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)", tcpdump/fall03, November 2004.

【HKA04]ヘンダーソン、T.、Kotz、D.、およびAbyzov、I.、 "CRAWDADトレースダートマス/キャンパス/ tcpdumpの/ fall03(V 2004-11-09。)" は、http://crawdad.cs.dartmouth。 EDU /ダートマス/キャンパス/ tcpdumpを/ fall03、2004年11月。

[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.

[Jac88]ジェーコブソン、V.、「輻輳回避とコントロール」、コンピュータコミュニケーションレビュー、巻。 18、ありません。 4、頁314から329まで、1988年8月。

[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control",

[JK88]ジェーコブソン、V.とM. Karels、 "輻輳回避と制御"、。

[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.

[KP87]カーン、P.とC.ヤマウズラ、「信頼性の高いトランスポートプロトコルにおける改善のラウンドトリップ時間の見積り」、SIGCOMM 87。

[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.

[PA00]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。

Appendix A. Rationale for Lowering the Initial RTO


Choosing a reasonable initial RTO requires balancing two competing considerations:


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.


2. The initial RTO should be small enough to ensure a timely recovery from packet loss occurring before an RTT sample is taken.


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秒以上の基準1を満たしていることを示唆し、1秒未満【Chu09]であったことを見出しました。

- 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.

- 加えて、研究は、おおよそ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%はRTTより長く1秒を持っています。これらの接続のために、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.


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:


   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」データはローレンス・バークレー国立研究所で撮影された、国際コンピュータサイエンス研究所、SIGCOMM 2008の参加者を務め、ワイヤレスネットワークから「SIGCOMM」データ、および「ダートマス」データから「ICSI」のデータがしましたダートマス大学のワイヤレスネットワークから収集しました。後者の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).


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.


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).

最後に、減少初期RTOを失ったのSYNを再送からのパフォーマンス上のメリットは明らかにあります。我々のデータセットを横切って、SYNを再送し、この文書で指定されたより小さな初期RTO 87%(ICSI-4)〜43%(LBL-1)の範囲を使用して、少なくとも10%の性能向上を実現することになる接続のパーセンテージ。少なくとも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.


Authors' Addresses


Vern Paxson ICSI/UC Berkeley 1947 Center Street Suite 600 Berkeley, CA 94704-1198

バーン・パクソンICSI / UCバークレー1947センターストリートスイート600バークレー、CA 94704から1198

Phone: 510-666-2882 EMail:

電話:510-666-2882 Eメール

Mark Allman ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198

マーク・オールマンICSI 1947センターストリートスイート600バークレー、CA 94704から1198

Phone: 440-235-1792 EMail:

電話:440-235-1792 Eメール

H.K. Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043

H.K.ジェリー・チューグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043

Phone: 650-253-3010 EMail:

電話:650-253-3010 Eメール

Matt Sargent Case Western Reserve University Olin Building 10900 Euclid Avenue Room 505 Cleveland, OH 44106


Phone: 440-223-5932 EMail:

電話:440-223-5932 Eメール