RFC2525 日本語訳
2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S.Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B.Volz. March 1999. (Format: TXT=137201 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Paxson
Request for Comments: 2525 Editor
Category: Informational ACIRI / ICSI
M. Allman
NASA Glenn Research Center/Sterling Software
S. Dawson
Real-Time Computing Laboratory
W. Fenner
Xerox PARC
J. Griner
NASA Glenn Research Center
I. Heavens
Spider Software Ltd.
K. Lahey
NASA Ames Research Center/MRJ
J. Semke
Pittsburgh Supercomputing Center
B. Volz
Process Software Corporation
March 1999
コメントを求めるワーキンググループV.パクソンの要求をネットワークでつないでください: 2525年のエディタカテゴリ: 1999年のコンピューティング研究所W.フェナーゼロックスPARC J.Griner NASAグレンリサーチセンタI.天のクモのソフトウェア株式会社K.レーヒー米航空宇宙局エイムズ研究所/MRJ J.SemkeピッツバーグスーパーコンピューティングセンターB.フォルツ過程ソフトウェア社の行進のリアルタイムの情報のACIRI / ICSI M.オールマンNASAグレンリサーチセンタ/英貨のソフトウェアS.ドーソン
Known TCP Implementation Problems
知られているTCP実現問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Table of Contents
目次
1. INTRODUCTION....................................................2
2. KNOWN IMPLEMENTATION PROBLEMS...................................3
2.1 No initial slow start........................................3
2.2 No slow start after retransmission timeout...................6
2.3 Uninitialized CWND...........................................9
2.4 Inconsistent retransmission.................................11
2.5 Failure to retain above-sequence data.......................13
2.6 Extra additive constant in congestion avoidance.............17
2.7 Initial RTO too low.........................................23
2.8 Failure of window deflation after loss recovery.............26
2.9 Excessively short keepalive connection timeout..............28
2.10 Failure to back off retransmission timeout..................31
1. 序論…2 2. 実現問題を知っています…3 2.1 初期の遅れた出発がありません…3 2.2 再送タイムアウトの後の遅れた出発がありません…6 2.3Uninitialized CWND…9 2.4 矛盾した「再-トランスミッション」…11 系列を超えたデータを保有しない2.5のこと…13 輻輳回避における2.6の余分な付加的な定数…17 2.7 あまりに低くRTOに頭文字をつけてください…23 2.8 損失回復の後の窓のデフレの失敗…26 2.9 過度に短いkeepalive接続タイムアウト…再送タイムアウトを戻さない28 2.10のこと…31
Paxson, et. al. Informational [Page 1] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[1ページ]情報のRFC2525TCP実現問題行進
2.11 Insufficient interval between keepalives....................34
2.12 Window probe deadlock.......................................36
2.13 Stretch ACK violation.......................................40
2.14 Retransmission sends multiple packets.......................43
2.15 Failure to send FIN notification promptly...................45
2.16 Failure to send a RST after Half Duplex Close...............47
2.17 Failure to RST on close with data pending...................50
2.18 Options missing from TCP MSS calculation....................54
3. SECURITY CONSIDERATIONS........................................56
4. ACKNOWLEDGEMENTS...............................................56
5. REFERENCES.....................................................57
6. AUTHORS' ADDRESSES.............................................58
7. FULL COPYRIGHT STATEMENT.......................................60
keepalivesの2.11の不十分な間隔…34 2.12窓の徹底的調査行き詰まり…36 2.13 ACK違反を伸ばしてください…40 2.14 Retransmissionは複数のパケットを送ります…即座に通知をFINに送らない43 2.15のこと…Half Duplex Closeの後にRSTを送らない45 2.16のこと…近くのデータが未定の存在RSTへの47 2.17失敗…TCP MSS計算によってなくなった50 2.18のオプション…54 3. セキュリティ問題…56 4. 承認…56 5. 参照…57 6. 作者のアドレス…58 7. 完全な著作権宣言文…60
1. Introduction
1. 序論
This memo catalogs a number of known TCP implementation problems. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is hoped that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet.
このメモは多くの知られているTCP実現問題をカタログに載せます。そうすることにおける目標は既存のインターネットで現在のTCP/IPインプリメンテーションの品質を高めることによって状態を改良することです。 作成者を問題と彼らの解決策を意識するようにすることによって性能と正当性問題の両方を解決できることが望まれています。 長期で、これがネットワーク(失敗の接続と再送されたデータの両方を処理しながら費やされた時間のためネットワークサーバで誤りについて議定書の中で述べて、ロードするのにおいて当然の接続失敗のレート)における不要な交通の減少を供給することが望まれています。 これは、世界的なインターネットの安定性を確実にするのを助けるでしょう。
Each problem is defined as follows:
各問題は以下の通り定義されます:
Name of Problem
The name associated with the problem. In this memo, the name is
given as a subsection heading.
名前、Problemでは、名前は問題と交際しました。 このメモでは、小区分見出しとして名前を与えます。
Classification
One or more problem categories for which the problem is
classified: "congestion control", "performance", "reliability",
"resource management".
問題が分類されている分類Oneか、より多くの問題カテゴリ: 「輻輳制御」、「性能」、「信頼性」、「資源管理。」
Description
A definition of the problem, succinct but including necessary
background material.
問題の記述A定義、簡潔な、しかし、包含必要なバックグラウンドの材料。
Significance
A brief summary of the sorts of environments for which the problem
is significant.
問題が重要である環境の種類の意味のA簡潔な概要。
Paxson, et. al. Informational [Page 2] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[2ページ]情報のRFC2525TCP実現問題行進
Implications
Why the problem is viewed as a problem.
問題が問題として見なされるという含意Why。
Relevant RFCs
The RFCs defining the TCP specification with which the problem
conflicts. These RFCs often qualify behavior using terms such as
MUST, SHOULD, MAY, and others written capitalized. See RFC 2119
for the exact interpretation of these terms.
問題が闘争するTCP仕様を定義する関連RFCs RFCs。 これらのRFCsはしばしば資格を得ます。SHOULD、使用がそのようなものを呼ぶ振舞いがそうしなければならない、5月、および大文字で書かれた状態で書かれている他のもの。 これらの用語の正確な解釈に関してRFC2119を見てください。
Trace file demonstrating the problem
One or more ASCII trace files demonstrating the problem, if
applicable.
問題を示して、適切であるなら、問題Oneのデモをするファイルか、より多くのASCII跡のファイルをたどってください。
Trace file demonstrating correct behavior
One or more examples of how correct behavior appears in a trace,
if applicable.
振舞いが跡でどれくらい正しく見えるかに関する正しい振舞いOneか、より多くの例のデモをして、適切であるなら、ファイルをたどってください。
References
References that further discuss the problem.
さらに問題について議論する参照References。
How to detect
How to test an implementation to see if it exhibits the problem.
This discussion may include difficulties and subtleties associated
with causing the problem to manifest itself, and with interpreting
traces to detect the presence of the problem (if applicable).
それが問題を示すかどうかを見るために実現をテストするためにHowを検出する方法。 この議論は困難と問題が現れることを引き起こして、問題の存在を検出するために跡を解釈すると関連している微妙さを含むかもしれません(適切であるなら)。
How to fix
For known causes of the problem, how to correct the
implementation.
問題のFor知られている原因、どう実現を修正するかを修理する方法。
2. Known implementation problems
2. 知られている実現問題
2.1.
2.1.
Name of Problem
No initial slow start
Problemのいいえの初期の遅れた出発の名前
Classification
Congestion control
分類Congestionコントロール
Description
When a TCP begins transmitting data, it is required by RFC 1122,
4.2.2.15, to engage in a "slow start" by initializing its
congestion window, cwnd, to one packet (one segment of the maximum
size). (Note that an experimental change to TCP, documented in
[RFC2414], allows an initial value somewhat larger than one
packet.) It subsequently increases cwnd by one packet for each
ACK it receives for new data. The minimum of cwnd and the
記述When a TCPはデータを送り始めて、それは.15(aに従事するためには、「始めを遅くしてください」という混雑が窓を付ける初期値設定)がcwndするRFC1122、4.2.2によって必要とされます、あるパケット(最大サイズのあるセグメント)に。 ([RFC2414]に記録されたTCPへの実験的な変化が1つのパケットよりいくらか大きい初期の値を許容することに注意してください。) それは次に、1つのパケットでcwndを増加させます。各ACKに関しては、新しいデータのために、受信します。 そしてcwndの最小限。
Paxson, et. al. Informational [Page 3] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[3ページ]情報のRFC2525TCP実現問題行進
receiver's advertised window bounds the highest sequence number
the TCP can transmit. A TCP that fails to initialize and
increment cwnd in this fashion exhibits "No initial slow start".
受信機のTCPが伝えることができる中で最も高い一連番号の広告を出している窓の領域。 cwndを初期化して、増加しないTCPはこんなやり方で「初期の遅れた出発がありません」を示します。
Significance
In congested environments, detrimental to the performance of other
connections, and possibly to the connection itself.
意味Inは他の接続に関する実績、およびことによると接続自体に、有害な環境を充血させました。
Implications
A TCP failing to slow start when beginning a connection results in
traffic bursts that can stress the network, leading to excessive
queueing delays and packet loss.
接続を始めるとネットワークを強調できる交通炸裂がもたらされるとき、遅くならない含意A TCPが始まります、過度の待ち行列遅れとパケット損失に通じて。
Implementations exhibiting this problem might do so because they
suffer from the general problem of not including the required
congestion window. These implementations will also suffer from
"No slow start after retransmission timeout".
必要な混雑ウィンドウを含んでいないという一般的問題が欠点であるので、この問題を示す実現はそうするかもしれません。 また、これらの実現は「再送タイムアウトの後の遅れた出発がありません」に苦しむでしょう。
There are different shades of "No initial slow start". From the
perspective of stressing the network, the worst is a connection
that simply always sends based on the receiver's advertised
window, with no notion of a separate congestion window. Another
form is described in "Uninitialized CWND" below.
「初期の遅れた出発がありません」の異なった色合いがあります。 ネットワークを強調することの見解から、最悪は受信機の広告を出している窓に基づいていつも単に発信する接続です、別々の混雑ウィンドウの概念なしで。 別のフォームは以下の"Uninitialized CWND"で説明されます。
Relevant RFCs
RFC 1122 requires use of slow start. RFC 2001 gives the specifics
of slow start.
関連RFCs RFC1122は遅れた出発の使用を必要とします。 RFC2001は遅れた出発の詳細を与えます。
Trace file demonstrating it
Made using tcpdump [Jacobson89] recording at the connection
responder. No losses reported by the packet filter.
接続応答者に記録しながらMade使用tcpdumpで[Jacobson89]それを示して、ファイルをたどってください。 損失は全くパケットフィルタで報告しませんでした。
10:40:42.244503 B > A: S 1168512000:1168512000(0) win 32768
<mss 1460,nop,wscale 0> (DF) [tos 0x8]
10:40:42.259908 A > B: S 3688169472:3688169472(0)
ack 1168512001 win 32768 <mss 1460>
10:40:42.389992 B > A: . ack 1 win 33580 (DF) [tos 0x8]
10:40:42.664975 A > B: P 1:513(512) ack 1 win 32768
10:40:42.700185 A > B: . 513:1973(1460) ack 1 win 32768
10:40:42.718017 A > B: . 1973:3433(1460) ack 1 win 32768
10:40:42.762945 A > B: . 3433:4893(1460) ack 1 win 32768
10:40:42.811273 A > B: . 4893:6353(1460) ack 1 win 32768
10:40:42.829149 A > B: . 6353:7813(1460) ack 1 win 32768
10:40:42.853687 B > A: . ack 1973 win 33580 (DF) [tos 0x8]
10:40:42.864031 B > A: . ack 3433 win 33580 (DF) [tos 0x8]
10:40:42.244503B>A: S1168512000: 1168512000(0)勝利32768<mss1460、nop、wscale0>(DF)[tos0x8]10:40:42.259908A>B: S3688169472: 3688169472(0) ack1168512001は32768<mss1460>10:40:42.389992B>A:を獲得します。 . ack1は33580(DF)[tos0x8]10:40:42.664975A>Bを獲得します: P1: 513(512) ack1は32768 10:40:42.700185A>Bを獲得します: . 513:1973 (1460)ack1は32768 10:40:42.718017A>Bを獲得します: . 1973: 3433(1460)ack1は32768 10:40:42.762945A>Bを獲得します: . 3433: 4893(1460)ack1は32768 10:40:42.811273A>Bを獲得します: . 4893: 6353(1460)ack1は32768 10:40:42.829149A>Bを獲得します: . 6353: 7813(1460)ack1は32768 10:40:42.853687B>A:を獲得します。 . ack1973は33580(DF)[tos0x8]10:40:42.864031B>A:を獲得します。 . ack3433は33580(DF)を獲得します。[tos0x8]
Paxson, et. al. Informational [Page 4] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[4ページ]情報のRFC2525TCP実現問題行進
After the third packet, the connection is established. A, the
connection responder, begins transmitting to B, the connection
initiator. Host A quickly sends 6 packets comprising 7812 bytes,
even though the SYN exchange agreed upon an MSS of 1460 bytes
(implying an initial congestion window of 1 segment corresponds to
1460 bytes), and so A should have sent at most 1460 bytes.
3番目のパケットの後に、接続は確立されます。 A(接続応答者)はB、接続創始者に伝わり始めます。 ホストAは6つのパケットに7812バイトをすばやく含ませます、SYN交換が1460バイトのMSSに同意したので(1つのセグメントの初期の混雑ウィンドウを含意するのは1460バイトに対応しています)、Aは高々1460バイト発信するべきでしたが。
The ACKs sent by B to A in the last two lines indicate that this
trace is not a measurement error (slow start really occurring but
the corresponding ACKs having been dropped by the packet filter).
最後の2つの線におけるBからAによって送られたACKsが、この跡が測定誤差でないことを示す、(遅く、発生にもかかわらず、対応ACKsが本当にパケットフィルタによって落とされ始めてください、そうした、)
A second trace confirmed that the problem is repeatable.
2番目の跡は、問題が反復可能であると確認しました。
Trace file demonstrating correct behavior
Made using tcpdump recording at the connection originator. No
losses reported by the packet filter.
接続創始者に記録するtcpdumpを使用することで正しい振舞いMadeのデモをして、ファイルをたどってください。 損失は全くパケットフィルタで報告しませんでした。
12:35:31.914050 C > D: S 1448571845:1448571845(0)
win 4380 <mss 1460>
12:35:32.068819 D > C: S 1755712000:1755712000(0)
ack 1448571846 win 4096
12:35:32.069341 C > D: . ack 1 win 4608
12:35:32.075213 C > D: P 1:513(512) ack 1 win 4608
12:35:32.286073 D > C: . ack 513 win 4096
12:35:32.287032 C > D: . 513:1025(512) ack 1 win 4608
12:35:32.287506 C > D: . 1025:1537(512) ack 1 win 4608
12:35:32.432712 D > C: . ack 1537 win 4096
12:35:32.433690 C > D: . 1537:2049(512) ack 1 win 4608
12:35:32.434481 C > D: . 2049:2561(512) ack 1 win 4608
12:35:32.435032 C > D: . 2561:3073(512) ack 1 win 4608
12:35:32.594526 D > C: . ack 3073 win 4096
12:35:32.595465 C > D: . 3073:3585(512) ack 1 win 4608
12:35:32.595947 C > D: . 3585:4097(512) ack 1 win 4608
12:35:32.596414 C > D: . 4097:4609(512) ack 1 win 4608
12:35:32.596888 C > D: . 4609:5121(512) ack 1 win 4608
12:35:32.733453 D > C: . ack 4097 win 4096
12:35:31.914050C>D: S1448571845: 1448571845(0)勝利4380<mss1460>12:35:32.068819D>C: S1755712000: 1755712000(0) ack1448571846は4096 12:35:32.069341C>Dを獲得します: . ack1は4608 12:35:32.075213C>Dを獲得します: P1: 513(512) ack1は4608 12:35:32.286073D>Cを獲得します: . ack513は4096 12:35:32.287032C>Dを獲得します: . 513: 1025(512) ack1は4608 12:35:32.287506C>Dを獲得します: . 1025: 1537(512) ack1は4608 12:35:32.432712D>Cを獲得します: . ack1537は4096 12:35:32.433690C>Dを獲得します: . 1537: 2049(512) ack1は4608 12:35:32.434481C>Dを獲得します: . 2049: 2561(512) ack1は4608 12:35:32.435032C>Dを獲得します: . 2561: 3073(512) ack1は4608 12:35:32.594526D>Cを獲得します: . ack3073は4096 12:35:32.595465C>Dを獲得します: . 3073: 3585(512) ack1は4608 12:35:32.595947C>Dを獲得します: . 3585: 4097(512) ack1は4608 12:35:32.596414C>Dを獲得します: . 4097: 4609(512) ack1は4608 12:35:32.596888C>Dを獲得します: . 4609: 5121(512) ack1は4608 12:35:32.733453D>Cを獲得します: . ack4097は4096を獲得します。
References
This problem is documented in [Paxson97].
問題が記録される参照This[Paxson97]。
How to detect
For implementations always manifesting this problem, it shows up
immediately in a packet trace or a sequence plot, as illustrated
above.
For実現がいつもこの問題を表すのをどう検出するか、すぐパケット跡か系列陰謀で現れます、上で例証されるように。
Paxson, et. al. Informational [Page 5] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[5ページ]情報のRFC2525TCP実現問題行進
How to fix
If the root problem is that the implementation lacks a notion of a
congestion window, then unfortunately this requires significant
work to fix. However, doing so is important, as such
implementations also exhibit "No slow start after retransmission
timeout".
根本問題がどうIfを修理するためには、実現が混雑ウィンドウの概念を欠いているということであるか、そして、残念ながら、これは修理するために重要な仕事を必要とします。 しかしながら、また、そのような実現が「再送タイムアウトの後の遅れた出発がありません」を示すとき、そうするのは重要です。
2.2.
2.2.
Name of Problem
No slow start after retransmission timeout
再送タイムアウトの後のProblemいいえ遅れた出発の名前
Classification
Congestion control
分類Congestionコントロール
Description
When a TCP experiences a retransmission timeout, it is required by
RFC 1122, 4.2.2.15, to engage in "slow start" by initializing its
congestion window, cwnd, to one packet (one segment of the maximum
size). It subsequently increases cwnd by one packet for each ACK
it receives for new data until it reaches the "congestion
avoidance" threshold, ssthresh, at which point the congestion
avoidance algorithm for updating the window takes over. A TCP
that fails to enter slow start upon a timeout exhibits "No slow
start after retransmission timeout".
記述When a TCPは再送タイムアウトを経験して、それは.15(中で従事するためには、「始めを遅くしてください」という混雑が窓を付ける初期値設定)がcwndするRFC1122、4.2.2によって必要とされます、あるパケット(最大サイズのあるセグメント)に。 各ACKに関しては、新しいデータのために「輻輳回避」敷居に達するまで受信します、ssthresh、窓をアップデートするための輻輳回避アルゴリズムが持って行くどのポイントで。それは次に、1つのパケットでcwndを増加させます。タイムアウトに遅れた出発を入れないTCPは「再送タイムアウトの後の遅れた出発がありません」を示します。
Significance
In congested environments, severely detrimental to the performance
of other connections, and also the connection itself.
意味Inは厳しく他の接続に関する実績に有害な環境を充血させて、また、接続自体を充血させました。
Implications
Entering slow start upon timeout forms one of the cornerstones of
Internet congestion stability, as outlined in [Jacobson88]. If
TCPs fail to do so, the network becomes at risk of suffering
"congestion collapse" [RFC896].
タイムアウトの含意Entering遅れた出発は[Jacobson88]に概説されているようにインターネット混雑の安定性の礎石の1つを形成します。 TCPsがそうしないなら、ネットワークは苦しみ「混雑崩壊」[RFC896]を危険な状態に一体どうならせます。
Relevant RFCs
RFC 1122 requires use of slow start after loss. RFC 2001 gives
the specifics of how to implement slow start. RFC 896 describes
congestion collapse.
関連RFCs RFC1122は損失の後に遅れた出発の使用を必要とします。 RFC2001はどう遅れた出発を実行するかに関する詳細を与えます。 RFC896は混雑崩壊について説明します。
The retransmission timeout discussed here should not be confused
with the separate "fast recovery" retransmission mechanism
discussed in RFC 2001.
ここで議論した再送タイムアウトはRFC2001で議論する別々の「速い回復」「再-トランスミッション」メカニズムに混乱するべきではありません。
Trace file demonstrating it
Made using tcpdump recording at the sending TCP (A). No losses
reported by the packet filter.
跡は、それを示しながら、ファイルされます。発信TCP(A)に記録しながらtcpdumpを使用するMade。 損失は全くパケットフィルタで報告しませんでした。
Paxson, et. al. Informational [Page 6] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[6ページ]情報のRFC2525TCP実現問題行進
10:40:59.090612 B > A: . ack 357125 win 33580 (DF) [tos 0x8] 10:40:59.222025 A > B: . 357125:358585(1460) ack 1 win 32768 10:40:59.868871 A > B: . 357125:358585(1460) ack 1 win 32768 10:41:00.016641 B > A: . ack 364425 win 33580 (DF) [tos 0x8] 10:41:00.036709 A > B: . 364425:365885(1460) ack 1 win 32768 10:41:00.045231 A > B: . 365885:367345(1460) ack 1 win 32768 10:41:00.053785 A > B: . 367345:368805(1460) ack 1 win 32768 10:41:00.062426 A > B: . 368805:370265(1460) ack 1 win 32768 10:41:00.071074 A > B: . 370265:371725(1460) ack 1 win 32768 10:41:00.079794 A > B: . 371725:373185(1460) ack 1 win 32768 10:41:00.089304 A > B: . 373185:374645(1460) ack 1 win 32768 10:41:00.097738 A > B: . 374645:376105(1460) ack 1 win 32768 10:41:00.106409 A > B: . 376105:377565(1460) ack 1 win 32768 10:41:00.115024 A > B: . 377565:379025(1460) ack 1 win 32768 10:41:00.123576 A > B: . 379025:380485(1460) ack 1 win 32768 10:41:00.132016 A > B: . 380485:381945(1460) ack 1 win 32768 10:41:00.141635 A > B: . 381945:383405(1460) ack 1 win 32768 10:41:00.150094 A > B: . 383405:384865(1460) ack 1 win 32768 10:41:00.158552 A > B: . 384865:386325(1460) ack 1 win 32768 10:41:00.167053 A > B: . 386325:387785(1460) ack 1 win 32768 10:41:00.175518 A > B: . 387785:389245(1460) ack 1 win 32768 10:41:00.210835 A > B: . 389245:390705(1460) ack 1 win 32768 10:41:00.226108 A > B: . 390705:392165(1460) ack 1 win 32768 10:41:00.241524 B > A: . ack 389245 win 8760 (DF) [tos 0x8]
10:40:59.090612B>A: . ack357125は33580(DF)[tos0x8]10:40:59.222025A>Bを獲得します: . 357125:358585 (1460)ack1は32768 10:40:59.868871A>Bを獲得します: . 357125:358585 (1460)ack1は32768 10:41:00.016641B>A:を獲得します。 . ack364425は33580(DF)[tos0x8]10:41:00.036709A>Bを獲得します: . 364425:365885 (1460)ack1は32768 10:41:00.045231A>Bを獲得します: . 365885:367345 (1460)ack1は32768 10:41:00.053785A>Bを獲得します: . 367345:368805 (1460)ack1は32768 10:41:00.062426A>Bを獲得します: . 368805:370265 (1460)ack1は32768 10:41:00.071074A>Bを獲得します: . 370265:371725 (1460)ack1は32768 10:41:00.079794A>Bを獲得します: . 371725:373185 (1460)ack1は32768 10:41:00.089304A>Bを獲得します: . 373185:374645 (1460)ack1は32768 10:41:00.097738A>Bを獲得します: . 374645:376105 (1460)ack1は32768 10:41:00.106409A>Bを獲得します: . 376105:377565 (1460)ack1は32768 10:41:00.115024A>Bを獲得します: . 377565:379025 (1460)ack1は32768 10:41:00.123576A>Bを獲得します: . 379025:380485 (1460)ack1は32768 10:41:00.132016A>Bを獲得します: . 380485:381945 (1460)ack1は32768 10:41:00.141635A>Bを獲得します: . 381945:383405 (1460)ack1は32768 10:41:00.150094A>Bを獲得します: . 383405:384865 (1460)ack1は32768 10:41:00.158552A>Bを獲得します: . 384865:386325 (1460)ack1は32768 10:41:00.167053A>Bを獲得します: . 386325:387785 (1460)ack1は32768 10:41:00.175518A>Bを獲得します: . 387785:389245 (1460)ack1は32768 10:41:00.210835A>Bを獲得します: . 389245:390705 (1460)ack1は32768 10:41:00.226108A>Bを獲得します: . 390705:392165 (1460)ack1は32768 10:41:00.241524B>A:を獲得します。 . ack389245は8760(DF)を獲得します。[tos0x8]
The first packet indicates the ack point is 357125. 130 msec
after receiving the ACK, A transmits the packet after the ACK
point, 357125:358585. 640 msec after this transmission, it
retransmits 357125:358585, in an apparent retransmission timeout.
At this point, A's cwnd should be one MSS, or 1460 bytes, as A
enters slow start. The trace is consistent with this possibility.
最初のパケットは、ackポイントが357125であることを示します。 130 ACKを受けた後のmsec、AはACKポイント、357125の後にパケットを伝えます: 358585。 640msec、このトランスミッションの後に、357125を再送します: 見かけの再送タイムアウトにおける358585。 ここに、Aが遅れた出発に入るとき、Aのcwndは1MSS、または1460バイトであるべきです。 跡はこの可能性と一致しています。
B replies with an ACK of 364425, indicating that A has filled a
sequence hole. At this point, A's cwnd should be 1460*2 = 2920
bytes, since in slow start receiving an ACK advances cwnd by MSS.
However, A then launches 19 consecutive packets, which is
inconsistent with slow start.
Aが系列穴をふさいだのを示して、Bは364425のACKと共に返答します。 ここに、Aのcwndは1460*2 = 2920バイトであるべきです、ACKを受けるとcwndが遅れた出発でMSSによって進められるので。 しかしながら、次に、Aは19の連続したパケットを始めます(遅れた出発に矛盾しています)。
A second trace confirmed that the problem is repeatable.
2番目の跡は、問題が反復可能であると確認しました。
Trace file demonstrating correct behavior
Made using tcpdump recording at the sending TCP (C). No losses
reported by the packet filter.
発信TCP(C)に記録するtcpdumpを使用することで正しい振舞いMadeのデモをして、ファイルをたどってください。 損失は全くパケットフィルタで報告しませんでした。
12:35:48.442538 C > D: P 465409:465921(512) ack 1 win 4608 12:35:48.544483 D > C: . ack 461825 win 4096 12:35:48.703496 D > C: . ack 461825 win 4096 12:35:49.044613 C > D: . 461825:462337(512) ack 1 win 4608
12:35:48.442538C>D: P465409: 465921(512) ack1は4608 12:35:48.544483D>Cを獲得します: . ack461825は4096 12:35:48.703496D>Cを獲得します: . ack461825は4096 12:35:49.044613C>Dを獲得します: . 461825: 462337(512) ack1は4608を獲得します。
Paxson, et. al. Informational [Page 7] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[7ページ]情報のRFC2525TCP実現問題行進
12:35:49.192282 D > C: . ack 465921 win 2048 12:35:49.192538 D > C: . ack 465921 win 4096 12:35:49.193392 C > D: P 465921:466433(512) ack 1 win 4608 12:35:49.194726 C > D: P 466433:466945(512) ack 1 win 4608 12:35:49.350665 D > C: . ack 466945 win 4096 12:35:49.351694 C > D: . 466945:467457(512) ack 1 win 4608 12:35:49.352168 C > D: . 467457:467969(512) ack 1 win 4608 12:35:49.352643 C > D: . 467969:468481(512) ack 1 win 4608 12:35:49.506000 D > C: . ack 467969 win 3584
12:35:49.192282D>C: . ack465921は2048 12:35:49.192538D>Cを獲得します: . ack465921は4096 12:35:49.193392C>Dを獲得します: P465921: 466433(512) ack1は4608 12:35:49.194726C>Dを獲得します: P466433: 466945(512) ack1は4608 12:35:49.350665D>Cを獲得します: . ack466945は4096 12:35:49.351694C>Dを獲得します: . 466945: 467457(512) ack1は4608 12:35:49.352168C>Dを獲得します: . 467457: 467969(512) ack1は4608 12:35:49.352643C>Dを獲得します: . 467969: 468481(512) ack1は4608 12:35:49.506000D>Cを獲得します: . ack467969は3584を獲得します。
After C transmits the first packet shown to D, it takes no action
in response to D's ACKs for 461825, because the first packet
already reached the advertised window limit of 4096 bytes above
461825. 600 msec after transmitting the first packet, C
retransmits 461825:462337, presumably due to a timeout. Its
congestion window is now MSS (512 bytes).
CがDに見せられた最初のパケットを伝えた後に、461825のためのDのACKsに対応して行動を全く取りません、最初のパケットが461825より上で既に4096バイトの広告を出している窓の限界に達したので。 600 最初のパケットを伝えた後のmsec、Cは461825を再送します: おそらくタイムアウトによる462337。 現在、混雑ウィンドウはMSS(512バイト)です。
D acks 465921, indicating that C's retransmission filled a
sequence hole. This ACK advances C's cwnd from 512 to 1024. Very
shortly after, D acks 465921 again in order to update the offered
window from 2048 to 4096. This ACK does not advance cwnd since it
is not for new data. Very shortly after, C responds to the newly
enlarged window by transmitting two packets. D acks both,
advancing cwnd from 1024 to 1536. C in turn transmits three
packets.
D acks465921、Cの「再-トランスミッション」が系列をいっぱいにしたのを示して、掘ってください。 このACKは512〜1024年までCのcwndを進めます。 非常にまもなく、後に、Dは、2048年から4096年まで提供された窓をアップデートするために再び465921をacksします。 このACKは、それが新しいデータのためのものでないので、cwndを進めません。 非常にまもなく、後に、Cは、2つのパケットを伝えることによって、新たに拡大している窓に応じます。 acksについてDともに1024年から1536年までcwndを進める。 Cは順番に3つのパケットを伝えます。
References
This problem is documented in [Paxson97].
問題が記録される参照This[Paxson97]。
How to detect
Packet loss is common enough in the Internet that generally it is
not difficult to find an Internet path that will force
retransmission due to packet loss.
Packetの損失を検出するのがインターネットでインターネット経路がそれであることがわかるのが難しくないほどどう一般的であるかがパケット損失のため「再-トランスミッション」を強制するでしょう。
If the effective window prior to loss is large enough, however,
then the TCP may retransmit using the "fast recovery" mechanism
described in RFC 2001. In a packet trace, the signature of fast
recovery is that the packet retransmission occurs in response to
the receipt of three duplicate ACKs, and subsequent duplicate ACKs
may lead to the transmission of new data, above both the ack point
and the highest sequence transmitted so far. An absence of three
duplicate ACKs prior to retransmission suffices to distinguish
between timeout and fast recovery retransmissions. In the face of
only observing fast recovery retransmissions, generally it is not
difficult to repeat the data transfer until observing a timeout
retransmission.
しかしながら、損失の前の有効な窓が十分大きいなら、TCPは、RFC2001で説明された「速い回復」メカニズムを使用することで再送するかもしれません。 パケット跡では、速い回復の署名はパケット「再-トランスミッション」が3写しACKsの領収書に対応して現れて、その後の写しACKsが新しいデータの伝達に通じるかもしれないということです、ackポイントと今までのところ伝えられている中で最も高い系列の両方の上で。 「再-トランスミッション」の前の3写しACKsの不在は、タイムアウトと速い回復「再-トランスミッション」を見分けるために十分です。 速い回復「再-トランスミッション」を観測することだけに直面して、一般にそれはタイムアウト「再-トランスミッション」を観測するまでデータ転送を繰り返すのが難しくはありません。
Paxson, et. al. Informational [Page 8] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[8ページ]情報のRFC2525TCP実現問題行進
Once armed with a trace exhibiting a timeout retransmission,
determining whether the TCP follows slow start is done by
computing the correct progression of cwnd and comparing it to the
amount of data transmitted by the TCP subsequent to the timeout
retransmission.
cwndの正しい進行を計算することによってTCPが遅れた出発に続くかどうかすることを決定して、タイムアウト「再-トランスミッション」を示す跡を一度武装させられて、それをデータ量と比較するのはタイムアウト「再-トランスミッション」へのその後のTCPで伝わりました。
How to fix
If the root problem is that the implementation lacks a notion of a
congestion window, then unfortunately this requires significant
work to fix. However, doing so is critical, for reasons outlined
above.
根本問題がどうIfを修理するためには、実現が混雑ウィンドウの概念を欠いているということであるか、そして、残念ながら、これは修理するために重要な仕事を必要とします。 しかしながら、そうするのは上に概説された理由で批判的です。
2.3.
2.3.
Name of Problem
Uninitialized CWND
問題Uninitialized CWNDという名前
Classification
Congestion control
分類Congestionコントロール
Description
As described above for "No initial slow start", when a TCP
connection begins cwnd is initialized to one segment (or perhaps a
few segments, if experimenting with [RFC2414]). One particular
form of "No initial slow start", worth separate mention as the bug
is fairly widely deployed, is "Uninitialized CWND". That is,
while the TCP implements the proper slow start mechanism, it fails
to initialize cwnd properly, so slow start in fact fails to occur.
または、上で「初期の遅れた出発がありません」に説明された記述As、TCP接続が始まるとき、cwndが1つのセグメントに初期化される、(恐らくいくつかのセグメント[RFC2414)を実験するなら。 バグは別々の言及の価値がありますが、「初期の遅れた出発がありません」の1つの特定のフォームが"Uninitialized CWND"です。 すなわち、TCPが適切な遅れた出発メカニズムを実行しますが、適切にcwndを初期化しないので、事実上、遅れた出発は起こりません。
One way the bug can occur is if, during the connection
establishment handshake, the SYN ACK packet arrives without an MSS
option. The faulty implementation uses receipt of the MSS option
to initialize cwnd to one segment; if the option fails to arrive,
then cwnd is instead initialized to a very large value.
バグが発生できる1つの方法はコネクション確立握手の間、SYN ACKパケットがMSSオプションなしで到着するかどうかということです。 不完全な実現は1つのセグメントにcwndを初期化するのにMSSオプションの領収書を使用します。 オプションが到着しないなら、cwndは代わりに非常に大きい値に初期化されます。
Significance
In congested environments, detrimental to the performance of other
connections, and likely to the connection itself. The burst can
be so large (see below) that it has deleterious effects even in
uncongested environments.
意味Inは他の接続に関する実績に有害で、接続自体に、ありそうな環境を充血させました。 炸裂が非常に大きい場合があるので(以下を見てください)、それには、非充血している環境さえにおける有害な効果があります。
Implications
A TCP exhibiting this behavior is stressing the network with a
large burst of packets, which can cause loss in the network.
この振舞いを示す含意A TCPがネットワークの損失をもたらすことができるパケットの大きい炸裂に伴うネットワークを強調しています。
Relevant RFCs
RFC 1122 requires use of slow start. RFC 2001 gives the specifics
of slow start.
関連RFCs RFC1122は遅れた出発の使用を必要とします。 RFC2001は遅れた出発の詳細を与えます。
Paxson, et. al. Informational [Page 9] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[9ページ]情報のRFC2525TCP実現問題行進
Trace file demonstrating it
This trace was made using tcpdump running on host A. Host A is
the sender and host B is the receiver. The advertised window and
timestamp options have been omitted for clarity, except for the
first segment sent by host A. Note that A sends an MSS option in
its initial SYN but B does not include one in its reply.
送付者とホストBは受信機です。回答におけるインクルード1ではなく、それをtcpdumpが広告を出している窓とタイムスタンプオプションが明快ために省略されたということであり、最初のセグメントを除いて、Aが初期のSYNにもかかわらず、BでMSSオプションを送るホストA.Noteによって送られて、ホストA.Host Aの上で作業しながら使用されるThis跡がされた示すのがそうするファイルをたどってください。
16:56:02.226937 A > B: S 237585307:237585307(0) win 8192
<mss 536,nop,wscale 0,nop,nop,timestamp[|tcp]>
16:56:02.557135 B > A: S 1617216000:1617216000(0)
ack 237585308 win 16384
16:56:02.557788 A > B: . ack 1 win 8192
16:56:02.566014 A > B: . 1:537(536) ack 1
16:56:02.566557 A > B: . 537:1073(536) ack 1
16:56:02.567120 A > B: . 1073:1609(536) ack 1
16:56:02.567662 A > B: P 1609:2049(440) ack 1
16:56:02.568349 A > B: . 2049:2585(536) ack 1
16:56:02.568909 A > B: . 2585:3121(536) ack 1
16:56: 02.226937 >B: S237585307: 237585307(0)勝利8192<mss536、nop、wscale0、nop、nop、タイムスタンプ[| tcp]>16:56:02.557135B>A: S1617216000: 1617216000(0) ack237585308は16384 16:56:02.557788A>Bを獲得します: . ack1は8192 16:56:02.566014A>Bを獲得します: . 1: 537(536) ack1 16:56:02.566557A>B: . 537: 1073(536) ack1 16:56:02.567120A>B: . 1073: 1609(536) ack1 16:56:02.567662A>B: P1609: 2049(440) ack1 16:56:02.568349A>B: . 2049: 2585(536) ack1 16:56:02.568909A>B: . 2585: 3121(536) ack1
[54 additional burst segments deleted for brevity]
[簡潔さのために削除された54の追加炸裂セグメント]
16:56:02.936638 A > B: . 32065:32601(536) ack 1 16:56:03.018685 B > A: . ack 1
16:56: 02.936638 >B: . 32065: 32601(536) ack1 16:56:03.018685B>A: . ack1
After the three-way handshake, host A bursts 61 segments into the
network, before duplicate ACKs on the first segment cause a
retransmission to occur. Since host A did not wait for the ACK on
the first segment before sending additional segments, it is
exhibiting "Uninitialized CWND"
3方向ハンドシェイクの後に、ホストAは61のセグメントをネットワークに押し破きます、最初のセグメントの写しACKsが「再-トランスミッション」を現れさせる前に。 追加セグメントを送る前にホストAが最初のセグメントのACKを待たなかったので、それは"Uninitialized CWND"を示しています。
Trace file demonstrating correct behavior
正しい振舞いを示す跡のファイル
See the example for "No initial slow start".
「初期の遅れた出発がありません」のための例を見てください。
References
This problem is documented in [Paxson97].
問題が記録される参照This[Paxson97]。
How to detect
This problem can be detected by examining a packet trace recorded
at either the sender or the receiver. However, the bug can be
difficult to induce because it requires finding a remote TCP peer
that does not send an MSS option in its SYN ACK.
送付者か受信機のどちらかに記録されたパケット跡を調べることによって、どうThis問題を検出するかを検出できます。SYN ACKでMSSオプションを送らないリモートTCP同輩を見つけるのが必要であるので、しかしながら、バグは引き起こすのが難しい場合があります。
How to fix
This problem can be fixed by ensuring that cwnd is initialized
upon receipt of a SYN ACK, even if the SYN ACK does not contain an
MSS option.
cwndがSYN ACKを受け取り次第初期化されるのを確実にすることによって、どうThis問題を修正するかを修理できます、SYN ACKがMSSオプションを含まないでも。
Paxson, et. al. Informational [Page 10] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[10ページ]情報のRFC2525TCP実現問題行進
2.4.
2.4.
Name of Problem
Inconsistent retransmission
Problem Inconsistent retransmissionという名前
Classification
Reliability
分類の信頼性
Description
If, for a given sequence number, a sending TCP retransmits
different data than previously sent for that sequence number, then
a strong possibility arises that the receiving TCP will
reconstruct a different byte stream than that sent by the sending
application, depending on which instance of the sequence number it
accepts.
記述If、与えられた一連番号のために、送付TCPは以前にその一連番号に呼びにやられるのと異なったデータを再送します、次に、受信TCPが送付アプリケーションで送られたそれと異なったバイト・ストリームを再建する強い可能性が起こります、それが一連番号のどの例を受け入れるかによって。
Such a sending TCP exhibits "Inconsistent retransmission".
そのような送付TCPは「矛盾した「再-トランスミッション」」を示します。
Significance
Critical for all environments.
すべての環境のための意味Critical。
Implications
Reliable delivery of data is a fundamental property of TCP.
データの含意Reliable配送はTCPの基本財産です。
Relevant RFCs
RFC 793, section 1.5, discusses the central role of reliability in
TCP operation.
関連RFCs RFC793(セクション1.5)はTCP操作における信頼性の中心的役割について議論します。
Trace file demonstrating it
Made using tcpdump recording at the receiving TCP (B). No losses
reported by the packet filter.
跡は、それを示しながら、ファイルされます。受信TCP(B)に記録しながらtcpdumpを使用するMade。 損失は全くパケットフィルタで報告しませんでした。
12:35:53.145503 A > B: FP 90048435:90048461(26)
ack 393464682 win 4096
4500 0042 9644 0000
3006 e4c2 86b1 0401 83f3 010a b2a4 0015
055e 07b3 1773 cb6a 5019 1000 68a9 0000
data starts here>504f 5254 2031 3334 2c31 3737*2c34 2c31
2c31 3738 2c31 3635 0d0a
12:35:53.146479 B > A: R 393464682:393464682(0) win 8192
12:35:53.851714 A > B: FP 90048429:90048463(34)
ack 393464682 win 4096
4500 004a 965b 0000
3006 e4a3 86b1 0401 83f3 010a b2a4 0015
055e 07ad 1773 cb6a 5019 1000 8bd3 0000
data starts here>5041 5356 0d0a 504f 5254 2031 3334 2c31
3737*2c31 3035 2c31 3431 2c34 2c31 3539
0d0a
12:35: 53.145503 >B: FP90048435: 90048461(26) ack393464682勝利4096 4500 0042 9644 0000 3006e4c2 86b1 0401 83f3 010a b2a4 0015 055e 07b3 1773cb6a 5019 1000 68a9 0000データはここから>504f5254 2031 3334 2c31 3737*2c34 2c31 2c31 3738 2c31 3635 0d0a12:35:53.146479B>A:を始動します。 R393464682: 393464682(0)勝利8192 12:35:53.851714A>B: FP90048429: 90048463(34) ack393464682勝利4096 4500 004a 965b0000 3006e4a3 86b1 0401 83f3 010a b2a4 0015 055e 07ad1773cb6a5019 1000 8bd3 0000データはここから>5041 5356 0d0a 504f5254 2031 3334 2c31 3737*2c31 3035 2c31 3431 2c34 2c31 3539 0d0aを始動します。
Paxson, et. al. Informational [Page 11] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[11ページ]情報のRFC2525TCP実現問題行進
The sequence numbers shown in this trace are absolute and not
adjusted to reflect the ISN. The 4-digit hex values show a dump
of the packet's IP and TCP headers, as well as payload. A first
sends to B data for 90048435:90048461. The corresponding data
begins with hex words 504f, 5254, etc.
この跡に示された一連番号は、絶対であり、ISNを反映するように調整されません。 4ケタの十六進法値はパケットのIPのダンプとペイロードと同様にTCPヘッダーを見せています。 第1は90048435のためのBデータに発信します: 90048461。 対応するデータは十六進法単語504f、5254などで始まります。
B responds with a RST. Since the recording location was local to
B, it is unknown whether A received the RST.
BはRSTと共に応じます。録音位置がBに地方であったので、AがRSTを受けたかどうかが、未知です。
A then sends 90048429:90048463, which includes six sequence
positions below the earlier transmission, all 26 positions of the
earlier transmission, and two additional sequence positions.
そしてAは発信します。90048429:90048463 以前のトランスミッションの下における6つの系列位置、以前のトランスミッションのすべての26の位置、および2つの追加系列位置を含んでいる。
The retransmission disagrees starting just after sequence
90048447, annotated above with a leading '*'. These two bytes
were originally transmitted as hex 2c34 but retransmitted as hex
2c31. Subsequent positions disagree as well.
「再-トランスミッション」は上に主な'*'で注釈された系列90048447のすぐ後から意見を異にします。 これらの2バイトは、元々、十六進法2c34として伝えられましたが、十六進法2c31として再送されました。 また、その後の位置は意見を異にします。
This behavior has been observed in other traces involving
different hosts. It is unknown how to repeat it.
この振舞いは、異なったホストにかかわりながら、他の跡で観測されました。 どのようにそれを繰り返すかは未知です。
In this instance, no corruption would occur, since B has already
indicated it will not accept further packets from A.
この場合、Bが、Aから一層のパケットを受け入れないのを既に示したので、不正は全く起こらないでしょう。
A second example illustrates a slightly different instance of the
problem. The tracing again was made with tcpdump at the receiving
TCP (D).
2番目の例は問題のわずかに異なった例を例証します。 たどることは再び受信TCP(D)のtcpdumpで作られました。
22:23:58.645829 C > D: P 185:212(27) ack 565 win 4096
4500 0043 90a3 0000
3306 0734 cbf1 9eef 83f3 010a 0525 0015
a3a2 faba 578c 70a4 5018 1000 9a53 0000
data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538
2c32 3339 2c35 2c34 330d 0a
22:23:58.646805 D > C: . ack 184 win 8192
4500 0028 beeb 0000
3e06 ce06 83f3 010a cbf1 9eef 0015 0525
578c 70a4 a3a2 fab9 5010 2000 342f 0000
22:31:36.532244 C > D: FP 186:213(27) ack 565 win 4096
4500 0043 9435 0000
3306 03a2 cbf1 9eef 83f3 010a 0525 0015
a3a2 fabb 578c 70a4 5019 1000 9a51 0000
data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538
2c32 3339 2c35 2c34 330d 0a
22:23:58.645829C>D: P185: 212(27) ack565勝利4096 4500 0043 90a3 0000 3306 0734cbf1 9eef 83f3 010a0525 0015a3a2 faba 578c 70a4 5018 1000 9a53 0000データはここから>504f5254 2032 3033 2c32 3431 2c31 3538 2c32 3339 2c35 2c34 330d 0a22:23:58.646805D>Cを始動します: . ack184は8192 4500 0028beeb0000 3e06 ce06 83f3 010a cbf1 9eef0015 0525 578c 70a4 a3a2 fab9 5010 2000 342f0000 22:31:36.532244C>Dを獲得します: FP186: 213(27) ack565勝利4096 4500 0043 9435 0000 3306 03a2 cbf1 9eef 83f3 010a0525 0015a3a2 fabb 578c 70a4 5019 1000 9a51 0000データはここから>504f5254 2032 3033 2c32 3431 2c31 3538 2c32 3339 2c35 2c34 330d 0aを始動します。
Paxson, et. al. Informational [Page 12] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[12ページ]情報のRFC2525TCP実現問題行進
In this trace, sequence numbers are relative. C sends 185:212,
but D only sends an ACK for 184 (so sequence number 184 is
missing). C then sends 186:213. The packet payload is identical
to the previous payload, but the base sequence number is one
higher, resulting in an inconsistent retransmission.
この跡では、一連番号は相対的です。 Cは発信します。185:212 Dだけが184のためにACKを送るだけです(したがって、一連番号184はなくなっています)。 次に、Cは186を送ります: 213。 パケットペイロードは前のペイロードと同じですが、ベース一連番号は、より高く1です、矛盾した「再-トランスミッション」をもたらして。
Neither trace exhibits checksum errors.
どちらの跡もチェックサム誤りを示しません。
Trace file demonstrating correct behavior
(Omitted, as presumably correct behavior is obvious.)
正しい振舞いを示す跡のファイル(省略されて、同じくらいおそらく正しい振舞いは明白です。)
References
None known.
知られている参照None。
How to detect
This problem unfortunately can be very difficult to detect, since
available experience indicates it is quite rare that it is
manifested. No "trigger" has been identified that can be used to
reproduce the problem.
残念ながら、どうThis問題を検出するかは検出するのが非常に難しい場合があります、利用可能な経験が、それが表されるのが、かなりまれであることを示すので。 問題を再生させるのに使用できない「引き金」は全く特定されました。
How to fix
In the absence of a known "trigger", we cannot always assess how
to fix the problem.
知られている「引き金」の不在をInに固定するために、私たちはどういつもどう問題を修正するかを評価できるというわけではないか。
In one implementation (not the one illustrated above), the problem
manifested itself when (1) the sender received a zero window and
stalled; (2) eventually an ACK arrived that offered a window
larger than that in effect at the time of the stall; (3) the
sender transmitted out of the buffer of data it held at the time
of the stall, but (4) failed to limit this transfer to the buffer
length, instead using the newly advertised (and larger) offered
window. Consequently, in addition to the valid buffer contents,
it sent whatever garbage values followed the end of the buffer.
If it then retransmitted the corresponding sequence numbers, at
that point it sent the correct data, resulting in an inconsistent
retransmission. Note that this instance of the problem reflects a
more general problem, that of initially transmitting incorrect
data.
ある実現(上で例証されなかったいずれのものも)では、(1) 送付者がaゼロの窓を受け取って、失速したとき、問題は現れました。 (2) 結局、事実上、売店時点でそれより大きい窓を提供したACKは到着しました。 (3) 送付者はそれが売店時点で保持したデータに関するバッファから伝わりましたが、(4)はこの転送をバッファ長に制限しませんでした、代わりに新たに広告を出して(より大きい)の提供された窓を使用して。 その結果、有効なバッファの内容に加えて、それは値が続いたどんなゴミにもバッファの端を送りました。 次に、対応する一連番号を再送したなら、その時正しいデータを送りました、矛盾した「再-トランスミッション」をもたらして。 問題のこの例が、より一般的な問題、初めは伝わっている間違ったデータのものを反映することに注意してください。
2.5.
2.5.
Name of Problem
Failure to retain above-sequence data
系列を超えたデータを保有するProblem Failureという名前
Classification
Congestion control, performance
分類Congestionコントロール、性能
Paxson, et. al. Informational [Page 13] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[13ページ]情報のRFC2525TCP実現問題行進
Description
When a TCP receives an "above sequence" segment, meaning one with
a sequence number exceeding RCV.NXT but below RCV.NXT+RCV.WND, it
SHOULD queue the segment for later delivery (RFC 1122, 4.2.2.20).
(See RFC 793 for the definition of RCV.NXT and RCV.WND.) A TCP
that fails to do so is said to exhibit "Failure to retain above-
sequence data".
記述When a TCPが「上の系列」セグメントを受けて、一連番号がRCV.NXTにもかかわらず、RCV.NXT+RCV.WNDの下のそれを超えている1つを意味して、SHOULDが後の配送のためにセグメントを列に並ばせる、(RFC、1122 4.2 .2 .20)。 (RCV.NXTとRCV.WNDの定義に関してRFC793を見てください。) そうしないTCPは「上で系列データを保有しないこと」を示すと言われています。
It may sometimes be appropriate for a TCP to discard above-
sequence data to reclaim memory. If they do so only rarely, then
we would not consider them to exhibit this problem. Instead, the
particular concern is with TCPs that always discard above-sequence
data.
TCPがメモリを取り戻すために上で系列データを捨てるのは、時々適切であるかもしれません。 次に、私たちが、めったにだけ彼らがこの問題を示すと考えないようにそうするなら。 代わりに、特別の関心がいつも系列を超えたデータを捨てるTCPsと共にあります。
Significance
In environments prone to packet loss, detrimental to the
performance of both other connections and the connection itself.
他の接続と接続自体の両方の性能にパケット損失に傾向があって、有害な意味In環境。
Implications
In times of congestion, a failure to retain above-sequence data
will lead to numerous otherwise-unnecessary retransmissions,
aggravating the congestion and potentially reducing performance by
a large factor.
混雑の含意In倍、系列を超えたデータを保有しない場合、多数のそうでなければ、不要な「再-トランスミッション」に通じるでしょう、混雑をいらいらさせて、潜在的に大きい要素による性能を抑えて。
Relevant RFCs
RFC 1122 revises RFC 793 by upgrading the latter's MAY to a SHOULD
on this issue.
後者をアップグレードさせるのによるRFC793がこの問題のSHOULDにそうするかもしれない関連RFCs RFC1122改正。
Trace file demonstrating it
Made using tcpdump recording at the receiving TCP. No losses
reported by the packet filter.
跡は、それを示しながら、ファイルされます。受信TCPに記録しながらtcpdumpを使用するMade。 損失は全くパケットフィルタで報告しませんでした。
B is the TCP sender, A the receiver. A exhibits failure to retain
above sequence-data:
TCP送付者、Aは受信機ですか?B、Aは系列データを超えて保有する失敗を示します:
10:38:10.164860 B > A: . 221078:221614(536) ack 1 win 33232 [tos 0x8] 10:38:10.170809 B > A: . 221614:222150(536) ack 1 win 33232 [tos 0x8] 10:38:10.177183 B > A: . 222150:222686(536) ack 1 win 33232 [tos 0x8] 10:38:10.225039 A > B: . ack 222686 win 25800
10:38:10.164860B>A: . 221078: 221614(536) ack1は33232[tos0x8]10:38:10.170809B>A:を獲得します。 . 221614: 222150(536) ack1は33232[tos0x8]10:38:10.177183B>A:を獲得します。 . 222150: 222686(536) ack1は33232[tos0x8]10:38:10.225039A>Bを獲得します: . ack222686は25800を獲得します。
Here B has sent up to (relative) sequence 222686 in-sequence, and
A accordingly acknowledges.
ここで、Bは222686が中で配列して、Aがそれに従って、承認する(相対的)の系列に発信しました。
10:38:10.268131 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:10.337995 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:10.344065 B > A: . 224294:224830(536) ack 1 win 33232 [tos 0x8] 10:38:10.350169 B > A: . 224830:225366(536) ack 1 win 33232 [tos 0x8] 10:38:10.356362 B > A: . 225366:225902(536) ack 1 win 33232 [tos 0x8]
10:38:10.268131B>A: . 223222: 223758(536) ack1は33232[tos0x8]10:38:10.337995B>A:を獲得します。 . 223758: 224294(536) ack1は33232[tos0x8]10:38:10.344065B>A:を獲得します。 . 224294: 224830(536) ack1は33232[tos0x8]10:38:10.350169B>A:を獲得します。 . 224830: 225366(536) ack1は33232[tos0x8]10:38:10.356362B>A:を獲得します。 . 225366: 225902(536) ack1は33232を獲得します。[tos0x8]
Paxson, et. al. Informational [Page 14] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[14ページ]情報のRFC2525TCP実現問題行進
10:38:10.362445 B > A: . 225902:226438(536) ack 1 win 33232 [tos 0x8] 10:38:10.368579 B > A: . 226438:226974(536) ack 1 win 33232 [tos 0x8] 10:38:10.374732 B > A: . 226974:227510(536) ack 1 win 33232 [tos 0x8] 10:38:10.380825 B > A: . 227510:228046(536) ack 1 win 33232 [tos 0x8] 10:38:10.387027 B > A: . 228046:228582(536) ack 1 win 33232 [tos 0x8] 10:38:10.393053 B > A: . 228582:229118(536) ack 1 win 33232 [tos 0x8] 10:38:10.399193 B > A: . 229118:229654(536) ack 1 win 33232 [tos 0x8] 10:38:10.405356 B > A: . 229654:230190(536) ack 1 win 33232 [tos 0x8]
10:38:10.362445B>A: . 225902: 226438(536) ack1は33232[tos0x8]10:38:10.368579B>A:を獲得します。 . 226438: 226974(536) ack1は33232[tos0x8]10:38:10.374732B>A:を獲得します。 . 226974: 227510(536) ack1は33232[tos0x8]10:38:10.380825B>A:を獲得します。 . 227510: 228046(536) ack1は33232[tos0x8]10:38:10.387027B>A:を獲得します。 . 228046: 228582(536) ack1は33232[tos0x8]10:38:10.393053B>A:を獲得します。 . 228582: 229118(536) ack1は33232[tos0x8]10:38:10.399193B>A:を獲得します。 . 229118: 229654(536) ack1は33232[tos0x8]10:38:10.405356B>A:を獲得します。 . 229654: 230190(536) ack1は33232を獲得します。[tos0x8]
A now receives 13 additional packets from B. These are above-
sequence because 222686:223222 was dropped. The packets do
however fit within the offered window of 25800. A does not
generate any duplicate ACKs for them.
Aが現在受信される、B.Theseからの13の追加パケットが上の系列である、222686:223222 落とされました。 しかしながら、パケットは25800の提供された窓の中で合います。 Aは彼らのために少しの写しACKsも発生させません。
The trace contributor (V. Paxson) verified that these 13 packets
had valid IP and TCP checksums.
跡の貢献者(V.パクソン)は、これらの13のパケットには有効なIPとTCPチェックサムがあったことを確かめました。
10:38:11.917728 B > A: . 222686:223222(536) ack 1 win 33232 [tos 0x8] 10:38:11.930925 A > B: . ack 223222 win 32232
10:38:11.917728B>A: . 222686: 223222(536) ack1は33232[tos0x8]10:38:11.930925A>Bを獲得します: . ack223222は32232を獲得します。
B times out for 222686:223222 and retransmits it. Upon receiving
it, A only acknowledges 223222. Had it retained the valid above-
sequence packets, it would instead have ack'd 230190.
そして、222686のためのB回: 223222、それを再送します。 それを受ける場合、Aは223222しか承認しません。 有効な上の系列パケットを保有したなら、それは代わりにackを持っているでしょう。230190はそうするでしょう。
10:38:12.048438 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:12.054397 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:12.068029 A > B: . ack 224294 win 31696
10:38:12.048438B>A: . 223222: 223758(536) ack1は33232[tos0x8]10:38:12.054397B>A:を獲得します。 . 223758: 224294(536) ack1は33232[tos0x8]10:38:12.068029A>Bを獲得します: . ack224294は31696を獲得します。
B retransmits two more packets, and A only acknowledges them.
This pattern continues as B retransmits the entire set of
previously-received packets.
Bはもう2つのパケットを再送します、そして、Aはそれらを承認するだけです。 Bが全体のセットの以前に容認されたパケットを再送するのに従って、このパターンは続きます。
A second trace confirmed that the problem is repeatable.
2番目の跡は、問題が反復可能であると確認しました。
Trace file demonstrating correct behavior
Made using tcpdump recording at the receiving TCP (C). No losses
reported by the packet filter.
受信TCP(C)に記録するtcpdumpを使用することで正しい振舞いMadeのデモをして、ファイルをたどってください。 損失は全くパケットフィルタで報告しませんでした。
09:11:25.790417 D > C: . 33793:34305(512) ack 1 win 61440 09:11:25.791393 D > C: . 34305:34817(512) ack 1 win 61440 09:11:25.792369 D > C: . 34817:35329(512) ack 1 win 61440 09:11:25.792369 D > C: . 35329:35841(512) ack 1 win 61440 09:11:25.793345 D > C: . 36353:36865(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904
09:11:25.790417D>C: . 33793: 34305(512) ack1は61440 09:11:25.791393D>Cを獲得します: . 34305: 34817(512) ack1は61440 09:11:25.792369D>Cを獲得します: . 34817: 35329(512) ack1は61440 09:11:25.792369D>Cを獲得します: . 35329: 35841(512) ack1は61440 09:11:25.793345D>Cを獲得します: . 36353: 36865(512) ack1は61440 09:11:25.794321C>Dを獲得します: . ack35841は59904を獲得します。
A sequence hole occurs because 35841:36353 has been dropped.
系列穴が起こる、35841:36353 落とされました。
Paxson, et. al. Informational [Page 15] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[15ページ]情報のRFC2525TCP実現問題行進
09:11:25.794321 D > C: . 36865:37377(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904 09:11:25.795297 D > C: . 37377:37889(512) ack 1 win 61440 09:11:25.795297 C > D: . ack 35841 win 59904 09:11:25.796273 C > D: . ack 35841 win 61440 09:11:25.798225 D > C: . 37889:38401(512) ack 1 win 61440 09:11:25.799201 C > D: . ack 35841 win 61440 09:11:25.807009 D > C: . 38401:38913(512) ack 1 win 61440 09:11:25.807009 C > D: . ack 35841 win 61440 (many additional lines omitted) 09:11:25.884113 D > C: . 52737:53249(512) ack 1 win 61440 09:11:25.884113 C > D: . ack 35841 win 61440
09:11:25.794321D>C: . 36865: 37377(512) ack1は61440 09:11:25.794321C>Dを獲得します: . ack35841は59904 09:11:25.795297D>Cを獲得します: . 37377: 37889(512) ack1は61440 09:11:25.795297C>Dを獲得します: . ack35841は59904 09:11:25.796273C>Dを獲得します: . ack35841は61440 09:11:25.798225D>Cを獲得します: . 37889: 38401(512) ack1は61440 09:11:25.799201C>Dを獲得します: . ack35841は61440 09:11:25.807009D>Cを獲得します: . 38401: 38913(512) ack1は61440 09:11:25.807009C>Dを獲得します: . ack35841は61440(省略された多くの追加線)09:11:25.884113D>Cを獲得します: . 52737: 53249(512) ack1は61440 09:11:25.884113C>Dを獲得します: . ack35841は61440を獲得します。
Each additional, above-sequence packet C receives from D elicits a
duplicate ACK for 35841.
CがDから受けるそれぞれの追加していて、上の系列のパケットは35841のために写しACKを引き出します。
09:11:25.887041 D > C: . 35841:36353(512) ack 1 win 61440
09:11:25.887041 C > D: . ack 53249 win 44032
09:11:25.887041D>C: . 35841: 36353(512) ack1は61440 09:11:25.887041C>Dを獲得します: . ack53249は44032を獲得します。
D retransmits 35841:36353 and C acknowledges receipt of data all
the way up to 53249.
Dは35841を再送します: 36353とCはデータの領収書をいっぱいに53249まで受け取ったことを知らせます。
References
This problem is documented in [Paxson97].
問題が記録される参照This[Paxson97]。
How to detect
Packet loss is common enough in the Internet that generally it is
not difficult to find an Internet path that will result in some
above-sequence packets arriving. A TCP that exhibits "Failure to
retain ..." may not generate duplicate ACKs for these packets.
However, some TCPs that do retain above-sequence data also do not
generate duplicate ACKs, so failure to do so does not definitively
identify the problem. Instead, the key observation is whether
upon retransmission of the dropped packet, data that was
previously above-sequence is acknowledged.
どうPacketの損失を検出するかはインターネットで系列を超えたいくつかのパケットをもたらすインターネット経路が到着しているのがわかるのが難しくないほど一般的です。 「保有する失敗」を示すTCP… これらのパケットのために写しACKsを発生させないかもしれません。 しかしながら、系列を超えたデータを保有するいくつかのTCPsがも写しACKsを発生させないので、そうしない場合、決定的に問題を特定しません。 代わりに、主要な観測は低下しているパケットの「再-トランスミッション」では、以前に系列であるデータが承認されるかどうかということです。
Two considerations in detecting this problem using a packet trace
are that it is easiest to do so with a trace made at the TCP
receiver, in order to unambiguously determine which packets
arrived successfully, and that such packets may still be correctly
discarded if they arrive with checksum errors. The latter can be
tested by capturing the entire packet contents and performing the
IP and TCP checksum algorithms to verify their integrity; or by
confirming that the packets arrive with the same checksum and
contents as that with which they were sent, with a presumption
that the sending TCP correctly calculates checksums for the
packets it transmits.
パケット跡を使用することにおけるこの問題を検出することにおける2つの問題はしたがって、どのパケットが首尾よく到着したかを明白に決定するためにTCP受信機で作られた跡を処理するのが最も簡単であり、チェックサム誤りと共に到着するならそのようなパケットがまだ正しく捨てられているかもしれないということです。 彼らの保全について確かめるために全体のパケットコンテンツを得て、IPとTCPチェックサムアルゴリズムを実行することによって、後者をテストできます。 または、それらが送られたそれとしての同じチェックサムとコンテンツ、発信しているTCPがパケットのために正しくチェックサムについて計算するという推定でパケットが到着すると確認することによって、それは伝わります。
Paxson, et. al. Informational [Page 16] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[16ページ]情報のRFC2525TCP実現問題行進
It is considerably easier to verify that an implementation does
NOT exhibit this problem. This can be done by recording a trace
at the data sender, and observing that sometimes after a
retransmission the receiver acknowledges a higher sequence number
than just that which was retransmitted.
実現がこの問題を示さないことを確かめるのはかなり簡単です。 データ送付者に跡を記録して、時々受信機がまさしく再送されたそれより高い一連番号に承認する「再-トランスミッション」の後にそれを観測することによって、これができます。
How to fix
If the root problem is that the implementation lacks buffer, then
then unfortunately this requires significant work to fix.
However, doing so is important, for reasons outlined above.
根本問題がどうIfを修理するためには、実現がバッファを欠いているということであるか、そして、そして残念ながら、これは修理するために重要な仕事を必要とします。 しかしながら、そうするのは上に概説された理由で重要です。
2.6.
2.6.
Name of Problem
Extra additive constant in congestion avoidance
輻輳回避におけるProblem Extraの付加的な定数の名前
Classification
Congestion control / performance
分類Congestionコントロール/性能
Description
RFC 1122 section 4.2.2.15 states that TCP MUST implement
Jacobson's "congestion avoidance" algorithm [Jacobson88], which
calls for increasing the congestion window, cwnd, by:
記述RFC1122部4.2 .2 .15 そのTCP MUST道具ジェーコブソンの「輻輳回避」アルゴリズム[Jacobson88](混雑ウィンドウ、cwndを増加させるように求める)は述べます:
MSS * MSS / cwnd
MSS*MSS / cwnd
for each ACK received for new data [RFC2001]. This has the effect
of increasing cwnd by approximately one segment in each round trip
time.
それぞれに関しては、ACKは新しいデータ[RFC2001]のために受信しました。 これには、およそ1つのセグメントによるcwndを増やすという周遊旅行毎回効果があります。
Some TCP implementations add an additional fraction of a segment
(typically MSS/8) to cwnd for each ACK received for new data
[Stevens94, Wright95]:
いくつかのTCP実現が新しいデータ[Stevens94、Wright95]のために受け取られた各ACKのためにセグメント(通常MSS/8)の追加部分をcwndに加えます:
(MSS * MSS / cwnd) + MSS/8
(MSS*MSS / cwnd)+MSS/8
These implementations exhibit "Extra additive constant in
congestion avoidance".
これらの実現は「輻輳回避における余分な付加的な定数」を示します。
Significance
May be detrimental to performance even in completely uncongested
environments (see Implications).
意味、5月、完全に非充血している環境さえにおける性能に有害にしてください(Implicationsを見てください)。
In congested environments, may also be detrimental to the
performance of other connections.
また、混雑している環境で、他の接続に関する実績に有害であるかもしれません。
Paxson, et. al. Informational [Page 17] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[17ページ]情報のRFC2525TCP実現問題行進
Implications
The extra additive term allows a TCP to more aggressively open its
congestion window (quadratic rather than linear increase). For
congested networks, this can increase the loss rate experienced by
all connections sharing a bottleneck with the aggressive TCP.
余分な付加的な用語がTCPを許容する含意は積極的に、混雑ウィンドウ(直線的であるというよりむしろ二次の増加)を以上に開けます。 混雑しているネットワークのために、これは攻撃的なTCPとボトルネックを共有しているすべての接続によって経験された損失率を増加させることができます。
However, even for completely uncongested networks, the extra
additive term can lead to diminished performance, as follows. In
congestion avoidance, a TCP sender probes the network path to
determine its available capacity, which often equates to the
number of buffers available at a bottleneck link. With linear
congestion avoidance, the TCP only probes for sufficient capacity
(buffer) to hold one extra packet per RTT.
しかしながら、完全に非充血しているネットワークのためにさえ、余分な付加的な用語は以下の減少している性能につながることができます。 輻輳回避では、TCP送付者は、有効な容量を測定するためにネットワーク経路を調べます。(容量はしばしばボトルネックリンクで利用可能なバッファの数に一致しています)。 直線的な輻輳回避で、TCPは1RTTあたり1つの余分なパケットを保持できるくらいの容量(バッファ)のために調べるだけです。
Thus, when it exceeds the available capacity, generally only one
packet will be lost (since on the previous RTT it already found
that the path could sustain a window with one less packet in
flight). If the congestion window is sufficiently large, then the
TCP will recover from this single loss using fast retransmission
and avoid an expensive (in terms of performance) retransmission
timeout.
有効な容量を超えているとき、したがって、一般に1つのパケットだけが失われるでしょう(前のRTTで経路がもう1つのパケット減で飛行で窓を支えることができるのが既にわかったので)。 混雑ウィンドウが十分大きいなら、TCPはこの単一の損失から速い「再-トランスミッション」を使用することで回復して、高価な(性能による)再送タイムアウトを避けるでしょう。
However, when the additional additive term is used, then cwnd can
increase by more than one packet per RTT, in which case the TCP
probes more aggressively. If in the previous RTT it had reached
the available capacity of the path, then the excess due to the
extra increase will again be lost, but now this will result in
multiple losses from the flight instead of a single loss. TCPs
that do not utilize SACK [RFC2018] generally will not recover from
multiple losses without incurring a retransmission timeout
[Fall96,Hoe96], significantly diminishing performance.
しかしながら、追加付加的な期間が使用されているとき、次に、cwndは1RTTあたり1つ以上のパケットで増加できます、その場合、TCPが、より積極的に調べます。 前のRTTで経路の有効な容量に達したなら、余分な増加による過剰は再び失われるでしょうが、今、これは単一の損失の代わりに飛行からの複数の損失をもたらすでしょう。 再送タイムアウト[Fall96、Hoe96]を被らないで、一般に、SACK[RFC2018]を利用しないTCPsが複数の損失から回復しないでしょう、性能をかなり減少させて。
Relevant RFCs
RFC 1122 requires use of the "congestion avoidance" algorithm.
RFC 2001 outlines the fast retransmit/fast recovery algorithms.
RFC 2018 discusses the SACK option.
関連RFCs RFC1122は「輻輳回避」アルゴリズムの使用を必要とします。 RFC2001は速さについて概説します。/速い回復アルゴリズムを再送してください。RFC2018はSACKオプションについて議論します。
Trace file demonstrating it
Recorded using tcpdump running on the same FDDI LAN as host A.
Host A is the sender and host B is the receiver. The connection
establishment specified an MSS of 4,312 bytes and a window scale
factor of 4. We omit the establishment and the first 2.5 MB of
data transfer, as the problem is best demonstrated when the window
has grown to a large value. At the beginning of the trace
excerpt, the congestion window is 31 packets. The connection is
never receiver-window limited, so we omit window advertisements
from the trace for clarity.
それを示して、同じFDDI LANがホストA.Host Aが送付者であり、ホストBが. コネクション確立がMSSを指定した受信機であるので4,312バイト上で作業されるRecorded使用がtcpdumpする窓のスケールが因数分解する4のファイルをたどってください。 私たちは設立と最初の2.5MBのデータ転送を省略します、窓が大きい値に成長したなら問題が特に示されるとき。 跡の抜粋の始めに、混雑ウィンドウは31のパケットです。 接続が決して制限された受信機窓でないので、私たちは明快ために跡からの窓の広告を省略します。
Paxson, et. al. Informational [Page 18] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[18ページ]情報のRFC2525TCP実現問題行進
11:42:07.697951 B > A: . ack 2383006 11:42:07.699388 A > B: . 2508054:2512366(4312) 11:42:07.699962 A > B: . 2512366:2516678(4312) 11:42:07.700012 B > A: . ack 2391630 11:42:07.701081 A > B: . 2516678:2520990(4312) 11:42:07.701656 A > B: . 2520990:2525302(4312) 11:42:07.701739 B > A: . ack 2400254 11:42:07.702685 A > B: . 2525302:2529614(4312) 11:42:07.703257 A > B: . 2529614:2533926(4312) 11:42:07.703295 B > A: . ack 2408878 11:42:07.704414 A > B: . 2533926:2538238(4312) 11:42:07.704989 A > B: . 2538238:2542550(4312) 11:42:07.705040 B > A: . ack 2417502 11:42:07.705935 A > B: . 2542550:2546862(4312) 11:42:07.706506 A > B: . 2546862:2551174(4312) 11:42:07.706544 B > A: . ack 2426126 11:42:07.707480 A > B: . 2551174:2555486(4312) 11:42:07.708051 A > B: . 2555486:2559798(4312) 11:42:07.708088 B > A: . ack 2434750 11:42:07.709030 A > B: . 2559798:2564110(4312) 11:42:07.709604 A > B: . 2564110:2568422(4312) 11:42:07.710175 A > B: . 2568422:2572734(4312) *
11:42:07.697951B>A: . ack2383006 11:42:07.699388A>B: . 2508054:2512366 (4312) 11:42: 07.699962 >B: . 2512366:2516678 (4312)11:42:07.700012B>A: . ack2391630 11:42:07.701081A>B: . 2516678:2520990 (4312) 11:42: 07.701656 >B: . 2520990:2525302 (4312)11:42:07.701739B>A: . ack2400254 11:42:07.702685A>B: . 2525302:2529614 (4312) 11:42: 07.703257 >B: . 2529614:2533926 (4312)11:42:07.703295B>A: . ack2408878 11:42:07.704414A>B: . 2533926:2538238 (4312) 11:42: 07.704989 >B: . 2538238:2542550 (4312)11:42:07.705040B>A: . ack2417502 11:42:07.705935A>B: . 2542550:2546862 (4312) 11:42: 07.706506 >B: . 2546862:2551174 (4312)11:42:07.706544B>A: . ack2426126 11:42:07.707480A>B: . 2551174:2555486 (4312) 11:42: 07.708051 >B: . 2555486:2559798 (4312)11:42:07.708088B>A: . ack2434750 11:42:07.709030A>B: . 2559798:2564110 (4312) 11:42: 07.709604 >B: . 2564110:2568422 (4312) 11:42: 07.710175 >B: . 2568422:2572734(4312) *
11:42:07.710215 B > A: . ack 2443374 11:42:07.710799 A > B: . 2572734:2577046(4312) 11:42:07.711368 A > B: . 2577046:2581358(4312) 11:42:07.711405 B > A: . ack 2451998 11:42:07.712323 A > B: . 2581358:2585670(4312) 11:42:07.712898 A > B: . 2585670:2589982(4312) 11:42:07.712938 B > A: . ack 2460622 11:42:07.713926 A > B: . 2589982:2594294(4312) 11:42:07.714501 A > B: . 2594294:2598606(4312) 11:42:07.714547 B > A: . ack 2469246 11:42:07.715747 A > B: . 2598606:2602918(4312) 11:42:07.716287 A > B: . 2602918:2607230(4312) 11:42:07.716328 B > A: . ack 2477870 11:42:07.717146 A > B: . 2607230:2611542(4312) 11:42:07.717717 A > B: . 2611542:2615854(4312) 11:42:07.717762 B > A: . ack 2486494 11:42:07.718754 A > B: . 2615854:2620166(4312) 11:42:07.719331 A > B: . 2620166:2624478(4312) 11:42:07.719906 A > B: . 2624478:2628790(4312) **
11:42:07.710215B>A: . ack2443374 11:42:07.710799A>B: . 2572734:2577046 (4312) 11:42: 07.711368 >B: . 2577046:2581358 (4312)11:42:07.711405B>A: . ack2451998 11:42:07.712323A>B: . 2581358:2585670 (4312) 11:42: 07.712898 >B: . 2585670:2589982 (4312)11:42:07.712938B>A: . ack2460622 11:42:07.713926A>B: . 2589982:2594294 (4312) 11:42: 07.714501 >B: . 2594294:2598606 (4312)11:42:07.714547B>A: . ack2469246 11:42:07.715747A>B: . 2598606:2602918 (4312) 11:42: 07.716287 >B: . 2602918:2607230 (4312)11:42:07.716328B>A: . ack2477870 11:42:07.717146A>B: . 2607230:2611542 (4312) 11:42: 07.717717 >B: . 2611542:2615854 (4312)11:42:07.717762B>A: . ack2486494 11:42:07.718754A>B: . 2615854:2620166 (4312) 11:42: 07.719331 >B: . 2620166:2624478 (4312) 11:42: 07.719906 >B: . 2624478:2628790(4312) **
11:42:07.719958 B > A: . ack 2495118 11:42:07.720500 A > B: . 2628790:2633102(4312) 11:42:07.721080 A > B: . 2633102:2637414(4312) 11:42:07.721739 B > A: . ack 2503742 11:42:07.722348 A > B: . 2637414:2641726(4312)
11:42:07.719958B>A: . ack2495118 11:42:07.720500A>B: . 2628790:2633102 (4312) 11:42: 07.721080 >B: . 2633102:2637414 (4312)11:42:07.721739B>A: . ack2503742 11:42:07.722348A>B: . 2637414:2641726(4312)
Paxson, et. al. Informational [Page 19] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[19ページ]情報のRFC2525TCP実現問題行進
11:42:07.722918 A > B: . 2641726:2646038(4312) 11:42:07.769248 B > A: . ack 2512366
11:42: 07.722918 >B: . 2641726:2646038 (4312)11:42:07.769248B>A: . ack2512366
The receiver's acknowledgment policy is one ACK per two packets
received. Thus, for each ACK arriving at host A, two new packets
are sent, except when cwnd increases due to congestion avoidance,
in which case three new packets are sent.
受信機の承認方針は2つのパケットあたりのACKが受け取った1です。 したがって、ホストAに到着する各ACKに関して2つの新しいパケットを送ります、cwndが輻輳回避のため増加する時を除いて、その場合、3つの新しいパケットを送ります。
With an ack-every-two-packets policy, cwnd should only increase
one MSS per 2 RTT. However, at the point marked "*" the window
increases after 7 ACKs have arrived, and then again at "**" after
6 more ACKs.
2つのackパケット毎の方針で、cwndはある2RTTあたりのMSSを増加させるだけであるはずです。 もう6ACKsの後に「しかしながら、「*」であるとマークされたポイントでは、窓は、7ACKsが到着した後に増加して、」 再びそして、**でそうします。」
While we do not have space to show the effect, this trace suffered
from repeated timeout retransmissions due to multiple packet
losses during a single RTT.
私たちには、効果を示しているスペースがありませんが、苦しまれたこの跡は複数のパケット損失のため独身のRTTの間タイムアウト「再-トランスミッション」を繰り返しました。
Trace file demonstrating correct behavior
Made using the same host and tracing setup as above, except now
A's TCP has been modified to remove the MSS/8 additive constant.
Tcpdump reported 77 packet drops; the excerpt below is fully
self-consistent so it is unlikely that any of these occurred
during the excerpt.
現在のAのTCPを除いて、同じホストを使用する振舞いMadeとたどることが同じくらい上でセットアップされるのが正しい跡のファイルの示すことは、MSS/8の付加的な定数を取り除くように変更されました。 Tcpdumpは77パケット滴を報告しました。 以下での抜粋が自己完全に一貫しているので、これらのどれかが抜粋の間起こったのは、ありそうもないです。
We again begin when cwnd is 31 packets (this occurs significantly
later in the trace, because the congestion avoidance is now less
aggressive with opening the window).
cwndが31のパケット(これは後で跡にかなり起こります、輻輳回避が現在それほど窓を開けるのに攻撃的でないので)であるときに、私たちは再び始めます。
14:22:21.236757 B > A: . ack 5194679 14:22:21.238192 A > B: . 5319727:5324039(4312) 14:22:21.238770 A > B: . 5324039:5328351(4312) 14:22:21.238821 B > A: . ack 5203303 14:22:21.240158 A > B: . 5328351:5332663(4312) 14:22:21.240738 A > B: . 5332663:5336975(4312) 14:22:21.270422 B > A: . ack 5211927 14:22:21.271883 A > B: . 5336975:5341287(4312) 14:22:21.272458 A > B: . 5341287:5345599(4312) 14:22:21.279099 B > A: . ack 5220551 14:22:21.280539 A > B: . 5345599:5349911(4312) 14:22:21.281118 A > B: . 5349911:5354223(4312) 14:22:21.281183 B > A: . ack 5229175 14:22:21.282348 A > B: . 5354223:5358535(4312) 14:22:21.283029 A > B: . 5358535:5362847(4312) 14:22:21.283089 B > A: . ack 5237799 14:22:21.284213 A > B: . 5362847:5367159(4312) 14:22:21.284779 A > B: . 5367159:5371471(4312) 14:22:21.285976 B > A: . ack 5246423 14:22:21.287465 A > B: . 5371471:5375783(4312)
14:22:21.236757B>A: . ack5194679 14:22:21.238192A>B: . 5319727:5324039 (4312) 14:22: 21.238770 >B: . 5324039:5328351 (4312)14:22:21.238821B>A: . ack5203303 14:22:21.240158A>B: . 5328351:5332663 (4312) 14:22: 21.240738 >B: . 5332663:5336975 (4312)14:22:21.270422B>A: . ack5211927 14:22:21.271883A>B: . 5336975:5341287 (4312) 14:22: 21.272458 >B: . 5341287:5345599 (4312)14:22:21.279099B>A: . ack5220551 14:22:21.280539A>B: . 5345599:5349911 (4312) 14:22: 21.281118 >B: . 5349911:5354223 (4312)14:22:21.281183B>A: . ack5229175 14:22:21.282348A>B: . 5354223:5358535 (4312) 14:22: 21.283029 >B: . 5358535:5362847 (4312)14:22:21.283089B>A: . ack5237799 14:22:21.284213A>B: . 5362847:5367159 (4312) 14:22: 21.284779 >B: . 5367159:5371471 (4312)14:22:21.285976B>A: . ack5246423 14:22:21.287465A>B: . 5371471:5375783(4312)
Paxson, et. al. Informational [Page 20] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[20ページ]情報のRFC2525TCP実現問題行進
14:22:21.288036 A > B: . 5375783:5380095(4312) 14:22:21.288073 B > A: . ack 5255047 14:22:21.289155 A > B: . 5380095:5384407(4312) 14:22:21.289725 A > B: . 5384407:5388719(4312) 14:22:21.289762 B > A: . ack 5263671 14:22:21.291090 A > B: . 5388719:5393031(4312) 14:22:21.291662 A > B: . 5393031:5397343(4312) 14:22:21.291701 B > A: . ack 5272295 14:22:21.292870 A > B: . 5397343:5401655(4312) 14:22:21.293441 A > B: . 5401655:5405967(4312) 14:22:21.293481 B > A: . ack 5280919 14:22:21.294476 A > B: . 5405967:5410279(4312) 14:22:21.295053 A > B: . 5410279:5414591(4312) 14:22:21.295106 B > A: . ack 5289543 14:22:21.296306 A > B: . 5414591:5418903(4312) 14:22:21.296878 A > B: . 5418903:5423215(4312) 14:22:21.296917 B > A: . ack 5298167 14:22:21.297716 A > B: . 5423215:5427527(4312) 14:22:21.298285 A > B: . 5427527:5431839(4312) 14:22:21.298324 B > A: . ack 5306791 14:22:21.299413 A > B: . 5431839:5436151(4312) 14:22:21.299986 A > B: . 5436151:5440463(4312) 14:22:21.303696 B > A: . ack 5315415 14:22:21.305177 A > B: . 5440463:5444775(4312) 14:22:21.305755 A > B: . 5444775:5449087(4312) 14:22:21.308032 B > A: . ack 5324039 14:22:21.309525 A > B: . 5449087:5453399(4312) 14:22:21.310101 A > B: . 5453399:5457711(4312) 14:22:21.310144 B > A: . ack 5332663 ***
14:22: 21.288036 >B: . 5375783:5380095 (4312)14:22:21.288073B>A: . ack5255047 14:22:21.289155A>B: . 5380095:5384407 (4312) 14:22: 21.289725 >B: . 5384407:5388719 (4312)14:22:21.289762B>A: . ack5263671 14:22:21.291090A>B: . 5388719:5393031 (4312) 14:22: 21.291662 >B: . 5393031:5397343 (4312)14:22:21.291701B>A: . ack5272295 14:22:21.292870A>B: . 5397343:5401655 (4312) 14:22: 21.293441 >B: . 5401655:5405967 (4312)14:22:21.293481B>A: . ack5280919 14:22:21.294476A>B: . 5405967:5410279 (4312) 14:22: 21.295053 >B: . 5410279:5414591 (4312)14:22:21.295106B>A: . ack5289543 14:22:21.296306A>B: . 5414591:5418903 (4312) 14:22: 21.296878 >B: . 5418903:5423215 (4312)14:22:21.296917B>A: . ack5298167 14:22:21.297716A>B: . 5423215:5427527 (4312) 14:22: 21.298285 >B: . 5427527:5431839 (4312)14:22:21.298324B>A: . ack5306791 14:22:21.299413A>B: . 5431839:5436151 (4312) 14:22: 21.299986 >B: . 5436151:5440463 (4312)14:22:21.303696B>A: . ack5315415 14:22:21.305177A>B: . 5440463:5444775 (4312) 14:22: 21.305755 >B: . 5444775:5449087 (4312)14:22:21.308032B>A: . ack5324039 14:22:21.309525A>B: . 5449087:5453399 (4312) 14:22: 21.310101 >B: . 5453399:5457711 (4312)14:22:21.310144B>A: . ack5332663***
14:22:21.311615 A > B: . 5457711:5462023(4312) 14:22:21.312198 A > B: . 5462023:5466335(4312) 14:22:21.341876 B > A: . ack 5341287 14:22:21.343451 A > B: . 5466335:5470647(4312) 14:22:21.343985 A > B: . 5470647:5474959(4312) 14:22:21.350304 B > A: . ack 5349911 14:22:21.351852 A > B: . 5474959:5479271(4312) 14:22:21.352430 A > B: . 5479271:5483583(4312) 14:22:21.352484 B > A: . ack 5358535 14:22:21.353574 A > B: . 5483583:5487895(4312) 14:22:21.354149 A > B: . 5487895:5492207(4312) 14:22:21.354205 B > A: . ack 5367159 14:22:21.355467 A > B: . 5492207:5496519(4312) 14:22:21.356039 A > B: . 5496519:5500831(4312) 14:22:21.357361 B > A: . ack 5375783 14:22:21.358855 A > B: . 5500831:5505143(4312) 14:22:21.359424 A > B: . 5505143:5509455(4312) 14:22:21.359465 B > A: . ack 5384407
14:22: 21.311615 >B: . 5457711:5462023 (4312) 14:22: 21.312198 >B: . 5462023:5466335 (4312)14:22:21.341876B>A: . ack5341287 14:22:21.343451A>B: . 5466335:5470647 (4312) 14:22: 21.343985 >B: . 5470647:5474959 (4312)14:22:21.350304B>A: . ack5349911 14:22:21.351852A>B: . 5474959:5479271 (4312) 14:22: 21.352430 >B: . 5479271:5483583 (4312)14:22:21.352484B>A: . ack5358535 14:22:21.353574A>B: . 5483583:5487895 (4312) 14:22: 21.354149 >B: . 5487895:5492207 (4312)14:22:21.354205B>A: . ack5367159 14:22:21.355467A>B: . 5492207:5496519 (4312) 14:22: 21.356039 >B: . 5496519:5500831 (4312)14:22:21.357361B>A: . ack5375783 14:22:21.358855A>B: . 5500831:5505143 (4312) 14:22: 21.359424 >B: . 5505143:5509455 (4312)14:22:21.359465B>A: . ack5384407
Paxson, et. al. Informational [Page 21] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[21ページ]情報のRFC2525TCP実現問題行進
14:22:21.360605 A > B: . 5509455:5513767(4312) 14:22:21.361181 A > B: . 5513767:5518079(4312) 14:22:21.361225 B > A: . ack 5393031 14:22:21.362485 A > B: . 5518079:5522391(4312) 14:22:21.363057 A > B: . 5522391:5526703(4312) 14:22:21.363096 B > A: . ack 5401655 14:22:21.364236 A > B: . 5526703:5531015(4312) 14:22:21.364810 A > B: . 5531015:5535327(4312) 14:22:21.364867 B > A: . ack 5410279 14:22:21.365819 A > B: . 5535327:5539639(4312) 14:22:21.366386 A > B: . 5539639:5543951(4312) 14:22:21.366427 B > A: . ack 5418903 14:22:21.367586 A > B: . 5543951:5548263(4312) 14:22:21.368158 A > B: . 5548263:5552575(4312) 14:22:21.368199 B > A: . ack 5427527 14:22:21.369189 A > B: . 5552575:5556887(4312) 14:22:21.369758 A > B: . 5556887:5561199(4312) 14:22:21.369803 B > A: . ack 5436151 14:22:21.370814 A > B: . 5561199:5565511(4312) 14:22:21.371398 A > B: . 5565511:5569823(4312) 14:22:21.375159 B > A: . ack 5444775 14:22:21.376658 A > B: . 5569823:5574135(4312) 14:22:21.377235 A > B: . 5574135:5578447(4312) 14:22:21.379303 B > A: . ack 5453399 14:22:21.380802 A > B: . 5578447:5582759(4312) 14:22:21.381377 A > B: . 5582759:5587071(4312) 14:22:21.381947 A > B: . 5587071:5591383(4312) ****
14:22: 21.360605 >B: . 5509455:5513767 (4312) 14:22: 21.361181 >B: . 5513767:5518079 (4312)14:22:21.361225B>A: . ack5393031 14:22:21.362485A>B: . 5518079:5522391 (4312) 14:22: 21.363057 >B: . 5522391:5526703 (4312)14:22:21.363096B>A: . ack5401655 14:22:21.364236A>B: . 5526703:5531015 (4312) 14:22: 21.364810 >B: . 5531015:5535327 (4312)14:22:21.364867B>A: . ack5410279 14:22:21.365819A>B: . 5535327:5539639 (4312) 14:22: 21.366386 >B: . 5539639:5543951 (4312)14:22:21.366427B>A: . ack5418903 14:22:21.367586A>B: . 5543951:5548263 (4312) 14:22: 21.368158 >B: . 5548263:5552575 (4312)14:22:21.368199B>A: . ack5427527 14:22:21.369189A>B: . 5552575:5556887 (4312) 14:22: 21.369758 >B: . 5556887:5561199 (4312)14:22:21.369803B>A: . ack5436151 14:22:21.370814A>B: . 5561199:5565511 (4312) 14:22: 21.371398 >B: . 5565511:5569823 (4312)14:22:21.375159B>A: . ack5444775 14:22:21.376658A>B: . 5569823:5574135 (4312) 14:22: 21.377235 >B: . 5574135:5578447 (4312)14:22:21.379303B>A: . ack5453399 14:22:21.380802A>B: . 5578447:5582759 (4312) 14:22: 21.381377 >B: . 5582759:5587071 (4312) 14:22: 21.381947 >B: . 5587071:5591383(4312) ****
"***" marks the end of the first round trip. Note that cwnd did
not increase (as evidenced by each ACK eliciting two new data
packets). Only at "****", which comes near the end of the second
round trip, does cwnd increase by one packet.
「***」は最初の周遊旅行の終わりを示します。 cwndが増加しなかったことに注意してください(2つの新しいデータ・パケットを引き出す各ACKによって証明されるように)。 「」 単に****」では、どれが2番目の周遊旅行の終わり頃に来て、cwndをするかは1つのパケットで増加します。
This trace did not suffer any timeout retransmissions. It
transferred the same amount of data as the first trace in about
half as much time. This difference is repeatable between hosts A
and B.
この跡はどんなタイムアウト「再-トランスミッション」も受けませんでした。 それはおよそ半分の時間における最初の跡と同じデータ量を移しました。 この違いはホストAとBの間で反復可能です。
References
[Stevens94] and [Wright95] discuss this problem. The problem of
Reno TCP failing to recover from multiple losses except via a
retransmission timeout is discussed in [Fall96,Hoe96].
参照[Stevens94]と[Wright95]はこの問題について議論します。 [Fall96、Hoe96]でリノTCPが再送タイムアウト以外の複数の損失から回復しないという問題について議論します。
Paxson, et. al. Informational [Page 22] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[22ページ]情報のRFC2525TCP実現問題行進
How to detect
If source code is available, that is generally the easiest way to
detect this problem. Search for each modification to the cwnd
variable; (at least) one of these will be for congestion
avoidance, and inspection of the related code should immediately
identify the problem if present.
どうIfソースコードを検出するかは、この問題を検出する利用可能で、すなわち、一般に最も簡単な方法です。 cwnd変数への各変更を捜し求めてください。 (少なくとも) これらの1つは輻輳回避のためにものになるでしょう、そして、存在しているなら、関連するコードの点検はすぐに、問題を特定するべきです。
The problem can also be detected by closely examining packet
traces taken near the sender. During congestion avoidance, cwnd
will increase by an additional segment upon the receipt of
(typically) eight acknowledgements without a loss. This increase
is in addition to the one segment increase per round trip time (or
two round trip times if the receiver is using delayed ACKs).
また、密接に送付者の近くで取られたパケット跡を調べることによって、問題を検出できます。 輻輳回避の間、cwndは(通常)8つの承認の領収書の追加セグメントで損失なしで増加するでしょう。 この増加は周遊旅行時間あたり1つのセグメント増加に加えています(受信機が遅れたACKsを使用しているなら、2は旅行時間を一周させます)。
Furthermore, graphs of the sequence number vs. time, taken from
packet traces, are normally linear during congestion avoidance.
When viewing packet traces of transfers from senders exhibiting
this problem, the graphs appear quadratic instead of linear.
その上、通常、一連番号対パケット跡からかかる時間のグラフは輻輳回避の間、直線的です。 この問題を示す送付者からの転送のパケット跡を見るとき、グラフは直線的の代わりに二次に見えます。
Finally, the traces will show that, with sufficiently large
windows, nearly every loss event results in a timeout.
最終的に、跡は、ほとんどあらゆる損失出来事が十分大きい窓でタイムアウトをもたらすのを示すでしょう。
How to fix
This problem may be corrected by removing the "+ MSS/8" term from
the congestion avoidance code that increases cwnd each time an ACK
of new data is received.
「どう取り外すのによる問題がcwndを増加させる輻輳回避コードからの各回」 + MSS/8インチの用語のときに直るかもしれないThisに新しいデータのACKを固定するかは受け取られています。
2.7.
2.7.
Name of Problem
Initial RTO too low
Problem Initial RTOも名義の安値
Classification
Performance
分類パフォーマンス
Description
When a TCP first begins transmitting data, it lacks the RTT
measurements necessary to have computed an adaptive retransmission
timeout (RTO). RFC 1122, 4.2.3.1, states that a TCP SHOULD
initialize RTO to 3 seconds. A TCP that uses a lower value
exhibits "Initial RTO too low".
データを送って、TCPが最初に始める記述When、それは適応型の再送タイムアウト(RTO)を計算したのに必要なRTT測定値を欠いています。 RFC、1122 4.2 .3 .1 TCP SHOULDが3秒までRTOを初期化すると述べます。 下側の値を使用するTCPは「あまりに低くRTOに頭文字をつけてください」を示します。
Significance
In environments with large RTTs (where "large" means any value
larger than the initial RTO), TCPs will experience very poor
performance.
大きいRTTs(「大きいこと」が初期のRTOより大きいどんな値も意味するところ)がある意味In環境、TCPsは非常に不十分な性能を経験するでしょう。
Paxson, et. al. Informational [Page 23] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[23ページ]情報のRFC2525TCP実現問題行進
Implications
Whenever RTO < RTT, very poor performance can result as packets
are unnecessarily retransmitted (because RTO will expire before an
ACK for the packet can arrive) and the connection enters slow
start and congestion avoidance. Generally, the algorithms for
computing RTO avoid this problem by adding a positive term to the
estimated RTT. However, when a connection first begins it must
use some estimate for RTO, and if it picks a value less than RTT,
the above problems will arise.
含意Whenever RTO<RTT、パケットが不必要に再送されるように(パケットのためのACKが到着できる前にRTOが期限が切れるので)非常に不十分な性能は結果として生じることができます、そして、接続は遅れた出発と輻輳回避に入ります。 一般に、RTOを計算するためのアルゴリズムは、およそRTTに積極的な用語を加えることによって、この問題を避けます。 しかしながら、接続が最初に始まると、RTOに何らかの見積りを使用しなければなりません、そして、RTTほど値を選ばないと、上の問題は起こるでしょう。
Furthermore, when the initial RTO < RTT, it can take a long time
for the TCP to correct the problem by adapting the RTT estimate,
because the use of Karn's algorithm (mandated by RFC 1122,
4.2.3.1) will discard many of the candidate RTT measurements made
after the first timeout, since they will be measurements of
retransmitted segments.
初期のRTO<RTTであるときに、その上、TCPがRTT見積りを適合させることによって問題を修正するには長い時かかるかもしれません、Karnのアルゴリズム(RFC1122、4.2.3で、.1を強制する)の使用が最初のタイムアウトの後にされた候補RTT測定の多くを捨てるので、再送されたセグメントの測定値になるので。
Relevant RFCs
RFC 1122 states that TCPs SHOULD initialize RTO to 3 seconds and
MUST implement Karn's algorithm.
関連RFCs RFC1122はTCPs SHOULDが3秒までRTOを初期化すると述べて、Karnのアルゴリズムを実行しなければなりません。
Trace file demonstrating it
The following trace file was taken using tcpdump at host A, the
data sender. The advertised window and SYN options have been
omitted for clarity.
跡は、それを示しながら、ファイルされます。ホストA、データ送付者でtcpdumpを使用することで次の跡のファイルを取りました。 広告を出している窓とSYNオプションは明快ために省略されました。
07:52:39.870301 A > B: S 2786333696:2786333696(0) 07:52:40.548170 B > A: S 130240000:130240000(0) ack 2786333697 07:52:40.561287 A > B: P 1:513(512) ack 1 07:52:40.753466 A > B: . 1:513(512) ack 1 07:52:41.133687 A > B: . 1:513(512) ack 1 07:52:41.458529 B > A: . ack 513 07:52:41.458686 A > B: . 513:1025(512) ack 1 07:52:41.458797 A > B: P 1025:1537(512) ack 1 07:52:41.541633 B > A: . ack 513 07:52:41.703732 A > B: . 513:1025(512) ack 1 07:52:42.044875 B > A: . ack 513 07:52:42.173728 A > B: . 513:1025(512) ack 1 07:52:42.330861 B > A: . ack 1537 07:52:42.331129 A > B: . 1537:2049(512) ack 1 07:52:42.331262 A > B: P 2049:2561(512) ack 1 07:52:42.623673 A > B: . 1537:2049(512) ack 1 07:52:42.683203 B > A: . ack 1537 07:52:43.044029 B > A: . ack 1537 07:52:43.193812 A > B: . 1537:2049(512) ack 1
07:52: 39.870301 >B: S2786333696: 2786333696(0)07:52:40.548170B>A: S130240000: 130240000(0) ack2786333697 07:52:40.561287A>B: P1: 513(512) ack1 07:52:40.753466A>B: . 1: 513(512) ack1 07:52:41.133687A>B: . 1: 513(512) ack1 07:52:41.458529B>A: . ack513 07:52:41.458686A>B: . 513: 1025(512) ack1 07:52:41.458797A>B: P1025: 1537(512) ack1 07:52:41.541633B>A: . ack513 07:52:41.703732A>B: . 513: 1025(512) ack1 07:52:42.044875B>A: . ack513 07:52:42.173728A>B: . 513: 1025(512) ack1 07:52:42.330861B>A: . ack1537 07:52:42.331129A>B: . 1537: 2049(512) ack1 07:52:42.331262A>B: P2049: 2561(512) ack1 07:52:42.623673A>B: . 1537: 2049(512) ack1 07:52:42.683203B>A: . ack1537 07:52:43.044029B>A: . ack1537 07:52:43.193812A>B: . 1537: 2049(512) ack1
Paxson, et. al. Informational [Page 24] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[24ページ]情報のRFC2525TCP実現問題行進
Note from the SYN/SYN-ACK exchange, the RTT is over 600 msec.
However, from the elapsed time between the third and fourth lines
(the first packet being sent and then retransmitted), it is
apparent the RTO was initialized to under 200 msec. The next line
shows that this value has doubled to 400 msec (correct exponential
backoff of RTO), but that still does not suffice to avoid an
unnecessary retransmission.
SYN/SYN-ACKから、交換、RTTが600以上msecであることに注意してください。 しかしながら、3番目と4番目の線(送られて、次に再送される最初のパケット)の間の経過時間から、RTOが200未満msecに初期化されたのは、明らかです。 次の線は、この値がmsec(RTOの正しい指数のbackoff)を400まで倍にしたのを示しますが、それは、不要な「再-トランスミッション」を避けるためにまだ十分ではありません。
Finally, an ACK from B arrives for the first segment. Later two
more duplicate ACKs for 513 arrive, indicating that both the
original and the two retransmissions arrived at B. (Indeed, a
concurrent trace at B showed that no packets were lost during the
entire connection). This ACK opens the congestion window to two
packets, which are sent back-to-back, but at 07:52:41.703732 RTO
again expires after a little over 200 msec, leading to an
unnecessary retransmission, and the pattern repeats. By the end
of the trace excerpt above, 1536 bytes have been successfully
transmitted from A to B, over an interval of more than 2 seconds,
reflecting terrible performance.
最終的に、BからのACKは最初のセグメントのために到着します。 その後、513のためのもう2写しACKsが到着します、オリジナルと2「再-トランスミッション」の両方がB.に届いたのを示して(本当に、Bの同時発生の跡はパケットが全く全体の接続の間失われなかったのを示しました)。 このACKは混雑ウィンドウを2つのパケットまで開けますが、200余りの後余りに再び07:52:41.703732RTOにmsec、不要な「再-トランスミッション」に通じて、およびパターン反復を吐き出します。(パケットは背中合わせの状態で送られます)。 跡の抜粋の終わりまでには、上に、1536バイトはAからBまで首尾よく伝えられました、2秒以上の間隔にわたって、ひどい性能を反映して。
Trace file demonstrating correct behavior
The following trace file was taken using tcpdump at host C, the
data sender. The advertised window and SYN options have been
omitted for clarity.
次の跡がファイルする振舞いがホストC、データ送付者でtcpdumpを使用することで取られたのが正しいファイルの示すことをたどってください。 広告を出している窓とSYNオプションは明快ために省略されました。
17:30:32.090299 C > D: S 2031744000:2031744000(0) 17:30:32.900325 D > C: S 262737964:262737964(0) ack 2031744001 17:30:32.900326 C > D: . ack 1 17:30:32.910326 C > D: . 1:513(512) ack 1 17:30:34.150355 D > C: . ack 513 17:30:34.150356 C > D: . 513:1025(512) ack 1 17:30:34.150357 C > D: . 1025:1537(512) ack 1 17:30:35.170384 D > C: . ack 1025 17:30:35.170385 C > D: . 1537:2049(512) ack 1 17:30:35.170386 C > D: . 2049:2561(512) ack 1 17:30:35.320385 D > C: . ack 1537 17:30:35.320386 C > D: . 2561:3073(512) ack 1 17:30:35.320387 C > D: . 3073:3585(512) ack 1 17:30:35.730384 D > C: . ack 2049
17:30:32.090299C>D: S2031744000: 2031744000(0)17:30:32.900325D>C: S262737964: 262737964(0) ack2031744001 17:30:32.900326C>D: . ack1 17:30:32.910326Cの>D: . 1: 513(512) ack1 17:30:34.150355D>C: . ack513 17:30:34.150356C>D: . 513: 1025(512) ack1 17:30:34.150357Cの>D: . 1025: 1537(512) ack1 17:30:35.170384D>C: . ack1025 17:30:35.170385C>D: . 1537: 2049(512) ack1 17:30:35.170386Cの>D: . 2049: 2561(512) ack1 17:30:35.320385D>C: . ack1537 17:30:35.320386C>D: . 2561: 3073(512) ack1 17:30:35.320387Cの>D: . 3073: 3585(512) ack1 17:30:35.730384D>C: . ack2049
The initial SYN/SYN-ACK exchange shows that RTT is more than 800
msec, and for some subsequent packets it rises above 1 second, but
C's retransmit timer does not ever expire.
初期のSYN/SYN-ACK交換は、RTTが800以上msecであることを示します、そして、いくつかのその後のパケットに関して、1秒より上で上昇しますが、Cの再送信タイマは期限が切れません。
References
This problem is documented in [Paxson97].
問題が記録される参照This[Paxson97]。
Paxson, et. al. Informational [Page 25] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[25ページ]情報のRFC2525TCP実現問題行進
How to detect
This problem is readily detected by inspecting a packet trace of
the startup of a TCP connection made over a long-delay path. It
can be diagnosed from either a sender-side or receiver-side trace.
Long-delay paths can often be found by locating remote sites on
other continents.
どうThis問題を検出するかは、長時間の遅延経路であることを変更されたTCP接続の始動のパケット跡を点検することによって、容易に検出されます。 送付者側か受信機サイド跡のどちらかからそれを診断できます。 他の大陸にリモートサイトの場所を見つけることによって、長時間の遅延経路をしばしば見つけることができます。
How to fix
As this problem arises from a faulty initialization, one hopes
fixing it requires a one-line change to the TCP source code.
どうこの問題をAsに固定するかは不完全な初期化から起こって、人は、それを修理するのがTCPソースコードへの1線の変化を必要とすることを望んでいます。
2.8.
2.8.
Name of Problem
Failure of window deflation after loss recovery
損失回復の後の窓のデフレのProblem Failureという名前
Classification
Congestion control / performance
分類Congestionコントロール/性能
Description
The fast recovery algorithm allows TCP senders to continue to
transmit new segments during loss recovery. First, fast
retransmission is initiated after a TCP sender receives three
duplicate ACKs. At this point, a retransmission is sent and cwnd
is halved. The fast recovery algorithm then allows additional
segments to be sent when sufficient additional duplicate ACKs
arrive. Some implementations of fast recovery compute when to
send additional segments by artificially incrementing cwnd, first
by three segments to account for the three duplicate ACKs that
triggered fast retransmission, and subsequently by 1 MSS for each
new duplicate ACK that arrives. When cwnd allows, the sender
transmits new data segments.
TCP送付者が損失回復の間、新しいセグメントを伝えるために速い回復アルゴリズムで続けることができる記述。 まず最初に、TCP送付者が3写しACKsを受け取った後に速い「再-トランスミッション」は開始されます。 ここに、「再-トランスミッション」を送ります、そして、cwndを半分にします。 そして、十分な追加写しACKsが到着するとき、速い回復アルゴリズムは、追加セグメントが送られるのを許容します。 それが速い「再-トランスミッション」の引き金となった3写しACKsの原因になるように最初に、3つのセグメントで人工的にcwndを増加して、次にそれぞれの新しい写しACKあたり1MSSで追加セグメントを送るために到着するとき、速い回復のいくつかの実現が計算されます。 いつ、cwndが許容するか、送付者は新しいデータ・セグメントを伝えます。
When an ACK arrives that covers new data, cwnd is to be reduced by
the amount by which it was artificially increased. However, some
TCP implementations fail to "deflate" the window, causing an
inappropriate amount of data to be sent into the network after
recovery. One cause of this problem is the "header prediction"
code, which is used to handle incoming segments that require
little work. In some implementations of TCP, the header
prediction code does not check to make sure cwnd has not been
artificially inflated, and therefore does not reduce the
artificially increased cwnd when appropriate.
新しいデータをカバーするACKが到着すると、cwndはそれは人工的に増加させられた量によって減少させられることになっています。 しかしながら、いくつかのTCP実現は窓に「空気を抜かせません」、不適当なデータ量が回復の後にネットワークに送られることを引き起こして。 この問題の1つの原因が「ヘッダー予測」コードです。(そのコードは、ほとんど仕事を必要としない入って来るセグメントを扱うのに使用されます)。 TCPのいくつかの実現では、ヘッダー予測コードは、cwndが人工的にふくらませられていないのを確実にするためにチェックしないで、またしたがって、適切であるときに、人工的に増加するcwndを減少させません。
Significance
TCP senders that exhibit this problem will transmit a burst of
data immediately after recovery, which can degrade performance, as
well as network stability. Effectively, the sender does not
この問題を示す意味TCP送付者が回復直後データの炸裂を伝えるでしょう、ネットワークの安定性と同様に。回復は性能を下げることができます。 事実上、送付者はそうしません。
Paxson, et. al. Informational [Page 26] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[26ページ]情報のRFC2525TCP実現問題行進
reduce the size of cwnd as much as it should (to half its value
when loss was detected), if at all. This can harm the performance
of the TCP connection itself, as well as competing TCP flows.
cwndのサイズを減少するべきであるほど(損失であるときに、半分まで、値は検出されました)せいぜい減少させてください。 これはTCP接続に関する実績自体、および競争しているTCP流れに害を及ぼすことができます。
Implications
A TCP sender exhibiting this problem does not reduce cwnd
appropriately in times of congestion, and therefore may contribute
to congestive collapse.
この問題を示す含意A TCP送付者は、混雑の時代にcwndを適切に減少させないで、したがって、充血性の崩壊に貢献するかもしれません。
Relevant RFCs
RFC 2001 outlines the fast retransmit/fast recovery algorithms.
[Brakmo95] outlines this implementation problem and offers a fix.
関連RFCs RFC2001は速さについて概説します。/速い回復アルゴリズムを再送してください。[Brakmo95]は、この実現問題について概説して、フィックスを提供します。
Trace file demonstrating it
The following trace file was taken using tcpdump at host A, the
data sender. The advertised window (which never changed) has been
omitted for clarity, except for the first packet sent by each
host.
跡は、それを示しながら、ファイルされます。ホストA、データ送付者でtcpdumpを使用することで次の跡のファイルを取りました。 広告を出している窓(決して変化しなかった)は各ホストによって送られた最初のパケット以外の明快ために省略されました。
08:22:56.825635 A.7505 > B.7505: . 29697:30209(512) ack 1 win 4608 08:22:57.038794 B.7505 > A.7505: . ack 27649 win 4096 08:22:57.039279 A.7505 > B.7505: . 30209:30721(512) ack 1 08:22:57.321876 B.7505 > A.7505: . ack 28161 08:22:57.322356 A.7505 > B.7505: . 30721:31233(512) ack 1 08:22:57.347128 B.7505 > A.7505: . ack 28673 08:22:57.347572 A.7505 > B.7505: . 31233:31745(512) ack 1 08:22:57.347782 A.7505 > B.7505: . 31745:32257(512) ack 1 08:22:57.936393 B.7505 > A.7505: . ack 29185 08:22:57.936864 A.7505 > B.7505: . 32257:32769(512) ack 1 08:22:57.950802 B.7505 > A.7505: . ack 29697 win 4096 08:22:57.951246 A.7505 > B.7505: . 32769:33281(512) ack 1 08:22:58.169422 B.7505 > A.7505: . ack 29697 08:22:58.638222 B.7505 > A.7505: . ack 29697 08:22:58.643312 B.7505 > A.7505: . ack 29697 08:22:58.643669 A.7505 > B.7505: . 29697:30209(512) ack 1 08:22:58.936436 B.7505 > A.7505: . ack 29697 08:22:59.002614 B.7505 > A.7505: . ack 29697 08:22:59.003026 A.7505 > B.7505: . 33281:33793(512) ack 1 08:22:59.682902 B.7505 > A.7505: . ack 33281 08:22:59.683391 A.7505 > B.7505: P 33793:34305(512) ack 1 08:22:59.683748 A.7505 > B.7505: P 34305:34817(512) ack 1 *** 08:22:59.684043 A.7505 > B.7505: P 34817:35329(512) ack 1 08:22:59.684266 A.7505 > B.7505: P 35329:35841(512) ack 1 08:22:59.684567 A.7505 > B.7505: P 35841:36353(512) ack 1 08:22:59.684810 A.7505 > B.7505: P 36353:36865(512) ack 1 08:22:59.685094 A.7505 > B.7505: P 36865:37377(512) ack 1
08:22:56.825635A.7505>B.7505: . 29697: 30209(512) ack1は4608 08:22:57.038794B.7505>A.7505を獲得します: . ack27649は4096 08:22:57.039279A.7505>B.7505を獲得します: . 30209: 30721(512) ack1 08:22:57.321876B.7505>A.7505: . ack28161 08:22:57.322356A.7505>B.7505: . 30721: 31233(512) ack1 08:22:57.347128B.7505>A.7505: . ack28673 08:22:57.347572A.7505>B.7505: . 31233: 31745(512) ack1 08:22:57.347782A.7505>B.7505: . 31745: 32257(512) ack1 08:22:57.936393B.7505>A.7505: . ack29185 08:22:57.936864A.7505>B.7505: . 32257: 32769(512) ack1 08:22:57.950802B.7505>A.7505: . ack29697は4096 08:22:57.951246A.7505>B.7505を獲得します: . 32769: 33281(512) ack1 08:22:58.169422B.7505>A.7505: . ack29697 08:22:58.638222B.7505>A.7505: . ack29697 08:22:58.643312B.7505>A.7505: . ack29697 08:22:58.643669A.7505>B.7505: . 29697: 30209(512) ack1 08:22:58.936436B.7505>A.7505: . ack29697 08:22:59.002614B.7505>A.7505: . ack29697 08:22:59.003026A.7505>B.7505: . 33281: 33793(512) ack1 08:22:59.682902B.7505>A.7505: . ack33281 08:22:59.683391A.7505>B.7505: P33793: 34305(512) ack1 08:22:59.683748A.7505>B.7505: P34305: 34817(512) ack1***08:22:59.684043A.7505>B.7505: P34817: 35329(512) ack1 08:22:59.684266A.7505>B.7505: P35329: 35841(512) ack1 08:22:59.684567A.7505>B.7505: P35841: 36353(512) ack1 08:22:59.684810A.7505>B.7505: P36353: 36865(512) ack1 08:22:59.685094A.7505>B.7505: P36865: 37377(512) ack1
Paxson, et. al. Informational [Page 27] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[27ページ]情報のRFC2525TCP実現問題行進
The first 12 lines of the trace show incoming ACKs clocking out a
window of data segments. At this point in the transfer, cwnd is 7
segments. The next 4 lines of the trace show 3 duplicate ACKs
arriving from the receiver, followed by a retransmission from the
sender. At this point, cwnd is halved (to 3 segments) and
artificially incremented by the three duplicate ACKs that have
arrived, making cwnd 6 segments. The next two lines show 2 more
duplicate ACKs arriving, each of which increases cwnd by 1
segment. So, after these two duplicate ACKs arrive the cwnd is 8
segments and the sender has permission to send 1 new segment
(since there are 7 segments outstanding). The next line in the
trace shows this new segment being transmitted. The next packet
shown in the trace is an ACK from host B that covers the first 7
outstanding segments (all but the new segment sent during
recovery). This should cause cwnd to be reduced to 3 segments and
2 segments to be transmitted (since there is already 1 outstanding
segment in the network). However, as shown by the last 7 lines of
the trace, cwnd is not reduced, causing a line-rate burst of 7 new
segments.
跡の最初の12の線が、入って来るACKsがデータ・セグメントの窓の仕事を終えるのを示します。 ここに、転送では、cwndは7つのセグメントです。 跡の次の4つの線が、3が「再-トランスミッション」によって送付者から続かれた受信機から到着するACKsをコピーするのを示します。 ここに、cwndは半分に(3つのセグメントへの)にされて到着した3写しACKsによって人工的に増加されています、cwnd6セグメントを作って。 次の2つの線が、もう2がACKs到着をコピーするのを示します。それは1つのセグメントでcwndをそれぞれ増加させます。 それで、これらの2写しACKsが到着した後にcwndは8つのセグメントです、そして、送付者には、1つの新しいセグメントを送る許可があります(未払いの7つのセグメントがあるので)。 跡の次の線は、この新しいセグメントが伝えられるのを示します。 跡で見せられた次のパケットは最初の7つの傑出しているセグメントをカバーするホストBからのACK(新しいセグメント以外のすべてが回復の間、発信した)です。 これで、伝えられるためにcwndを3つのセグメントと2つのセグメントまで減少させるべきです(ネットワークには1つの傑出しているセグメントが既にあるので)。 しかしながら、跡の最後の7つの線によって示されるように、cwndは減少しません、7つの新しいセグメントのライン料率炸裂を引き起こして。
Trace file demonstrating correct behavior
The trace would appear identical to the one above, only it would
stop after the line marked "***", because at this point host A
would correctly reduce cwnd after recovery, allowing only 2
segments to be transmitted, rather than producing a burst of 7
segments.
「跡が示す正しい振舞いを示す跡のファイルが上でものと同じに見えて、線が、」 *が**であるとマークした後に止まるでしょう」、ホストAはここにcwnd後回復を正しく減少させるでしょう、したがって、2つのセグメントだけが7つのセグメントの炸裂を発生させるよりむしろ伝えられるのを許容して。
References
This problem is documented and the performance implications
analyzed in [Brakmo95].
参照This問題は、記録されていて[Brakmo95]で分析された性能含意です。
How to detect
Failure of window deflation after loss recovery can be found by
examining sender-side packet traces recorded during periods of
moderate loss (so cwnd can grow large enough to allow for fast
recovery when loss occurs).
送付者サイドパケット跡を調べることによって損失回復を見つけられることができた後にどう窓のデフレのFailureを検出するかは適度の損失の期間、記録しました(したがって、損失が発生すると、cwndは速い回復を考慮できるくらい大きくなることができます)。
How to fix
When this bug is caused by incorrect header prediction, the fix is
to add a predicate to the header prediction test that checks to
see whether cwnd is inflated; if so, the header prediction test
fails and the usual ACK processing occurs, which (in this case)
takes care to deflate the window. See [Brakmo95] for details.
どうこのバグをWhenに固定するかは不正確なヘッダー予測で引き起こされます、とフィックスはcwndが充満しているか否かに関係なく、見るためにチェックするヘッダー予測テストに述部を追加することになっています。 そうだとすれば、ヘッダー予測テストは失敗します、そして、普通のACK処理((この場合)窓に空気を抜かせるために注意される)は起こります。 詳細に関して[Brakmo95]を見てください。
2.9.
2.9.
Name of Problem
Excessively short keepalive connection timeout
Problem Excessivelyの短いkeepalive接続タイムアウトの名前
Paxson, et. al. Informational [Page 28] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[28ページ]情報のRFC2525TCP実現問題行進
Classification
Reliability
分類の信頼性
Description
Keep-alive is a mechanism for checking whether an idle connection
is still alive. According to RFC 1122, keepalive should only be
invoked in server applications that might otherwise hang
indefinitely and consume resources unnecessarily if a client
crashes or aborts a connection during a network failure.
生きている記述Keepは、無駄な接続がまだ生きているかどうかチェックするためのメカニズムです。 RFC1122によると、keepaliveはクライアントがネットワーク失敗の間、接続を墜落するか、または中止するなら、そうでなければ、無期限に掛かっていて、不必要にリソースを消費するかもしれないサーバ・アプリケーションに呼び出されるだけであるべきです。
RFC 1122 also specifies that if a keep-alive mechanism is
implemented it MUST NOT interpret failure to respond to any
specific probe as a dead connection. The RFC does not specify a
particular mechanism for timing out a connection when no response
is received for keepalive probes. However, if the mechanism does
not allow ample time for recovery from network congestion or
delay, connections may be timed out unnecessarily.
また、RFC1122は、生きている生活費メカニズムが実行されるなら停止コネクションとしてどんな特定の徹底的調査にも応じないことを解釈してはいけないと指定します。 keepalive徹底的調査のために応答を全く受けないとき、RFCは接続からタイミングに特定のメカニズムを指定しません。 しかしながら、メカニズムがネットワークの混雑か遅れからの回復のための十分な時間を許容しないなら、接続は外で不必要に調節されるかもしれません。
Significance
In congested networks, can lead to unwarranted termination of
connections.
意味Inはネットワークを充血させて、接続の保証のない終了に通じることができます。
Implications
It is possible for the network connection between two peer
machines to become congested or to exhibit packet loss at the time
that a keep-alive probe is sent on a connection. If the keep-
alive mechanism does not allow sufficient time before dropping
connections in the face of unacknowledged probes, connections may
be dropped even when both peers of a connection are still alive.
含意Itは2台の同輩マシンの間のネットワーク接続が混雑するようになるか、または当時パケット損失を示すのにおいて生きている生活費探測装置が接続に送られるのが可能です。 接続の両方の同輩がまだ生きるときさえ、不承認の徹底的調査に直面して接続を落とす前に生きている生活費メカニズムが十分な時間を許容しないなら、接続は落とされるかもしれません。
Relevant RFCs
RFC 1122 specifies that the keep-alive mechanism may be provided.
It does not specify a mechanism for determining dead connections
when keepalive probes are not acknowledged.
関連RFCs RFC1122は、生きている生活費メカニズムが提供されるかもしれないと指定します。 それはkeepalive徹底的調査が承諾されないとき停止コネクションを決定するのにメカニズムを指定しません。
Trace file demonstrating it
Made using the Orchestra tool at the peer of the machine using
keep-alive. After connection establishment, incoming keep-alives
were dropped by Orchestra to simulate a dead connection.
跡は、それを示しながら、ファイルされます。使用が生かすマシンの同輩でOrchestraツールを使用するMade。 後コネクション確立の、そして、入って来る生活費アリフは、停止コネクションをシミュレートするためにOrchestraによって落とされました。
22:11:12.040000 A > B: 22666019:0 win 8192 datasz 4 SYN 22:11:12.060000 B > A: 2496001:22666020 win 4096 datasz 4 SYN ACK 22:11:12.130000 A > B: 22666020:2496002 win 8760 datasz 0 ACK (more than two hours elapse) 00:23:00.680000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23:01.770000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23:02.870000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23.03.970000 A > B: 22666019:2496002 win 8760 datasz 1 ACK
22:11: 12.040000 >B: 22666019:0 勝利8192datasz4SYN22:11:12.060000B>A: 2496001:22666020 4096datasz4SYN ACK22:11:12.130000A>Bを獲得してください: 22666020:2496002 8760datasz0ACK(2時間以上は経過する)00:23:00.680000A>Bを獲得してください: 22666019:2496002 1ACKの8760datasz00:23:01.770000A>Bを獲得してください: 22666019:2496002 1ACKの8760datasz00:23:02.870000A>Bを獲得してください: 22666019:2496002 1ACKの8760datasz00:23.03.970000A>Bを獲得してください: 22666019:2496002 勝利8760datasz1ACK
Paxson, et. al. Informational [Page 29] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[29ページ]情報のRFC2525TCP実現問題行進
00:23.05.070000 A > B: 22666019:2496002 win 8760 datasz 1 ACK
00: 23.05 .070000 >B: 22666019:2496002 勝利8760datasz1ACK
The initial three packets are the SYN exchange for connection
setup. About two hours later, the keepalive timer fires because
the connection has been idle. Keepalive probes are transmitted a
total of 5 times, with a 1 second spacing between probes, after
which the connection is dropped. This is problematic because a 5
second network outage at the time of the first probe results in
the connection being killed.
初期の3つのパケットが接続設定へのSYN交換です。 接続が無駄であるので、およそ2時間後に、keepaliveタイマは撃たれます。 Keepalive探測装置は合計5回送られます、1が徹底的調査の間で2番目に、区切られている状態で。その時、接続は落とされます。 最初の徹底的調査時点の5 2番目のネットワーク供給停止が殺されている接続をもたらすので、これは問題が多いです。
Trace file demonstrating correct behavior
Made using the Orchestra tool at the peer of the machine using
keep-alive. After connection establishment, incoming keep-alives
were dropped by Orchestra to simulate a dead connection.
使用が生かすマシンの同輩でOrchestraツールを使用することで正しい振舞いMadeのデモをして、ファイルをたどってください。 後コネクション確立の、そして、入って来る生活費アリフは、停止コネクションをシミュレートするためにOrchestraによって落とされました。
16:01:52.130000 A > B: 1804412929:0 win 4096 datasz 4 SYN 16:01:52.360000 B > A: 16512001:1804412930 win 4096 datasz 4 SYN ACK 16:01:52.410000 A > B: 1804412930:16512002 win 4096 datasz 0 ACK (two hours elapse) 18:01:57.170000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:03:12.220000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:04:27.270000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:05:42.320000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:06:57.370000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:08:12.420000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:09:27.480000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:10:43.290000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:11:57.580000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:13:12.630000 A > B: 1804412929:16512002 win 4096 datasz 0 RST ACK
16:01: 52.130000 >B: 1804412929:0 勝利4096datasz4SYN16:01:52.360000B>A: 16512001:1804412930 4096datasz4SYN ACK16:01:52.410000A>Bを獲得してください: 1804412930:16512002 4096datasz0ACK(2時間は経過する)18:01:57.170000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:03:12.220000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:04:27.270000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:05:42.320000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:06:57.370000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:08:12.420000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:09:27.480000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:10:43.290000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:11:57.580000A>Bを獲得してください: 1804412929:16512002 4096datasz0ACK18:13:12.630000A>Bを獲得してください: 1804412929:16512002 勝利4096datasz0RST ACK
In this trace, when the keep-alive timer expires, 9 keepalive
probes are sent at 75 second intervals. 75 seconds after the last
probe is sent, a final RST segment is sent indicating that the
connection has been closed. This implementation waits about 11
minutes before timing out the connection, while the first
implementation shown allows only 5 seconds.
この跡では、75は間隔を後援します。そこでは、生きている生活費タイマが期限が切れて、9つのkeepalive徹底的調査のときに発信します。 最後の探測装置を送った75秒後に、最終的なRSTセグメントに接続が閉店したのを示させます。 この実現はタイミングの数分前の11時頃に接続をじっと凌ぎ通しますが、示された最初の実現はほんの5秒を許容します。
References
This problem is documented in [Dawson97].
問題が記録される参照This[Dawson97]。
How to detect
For implementations manifesting this problem, it shows up on a
packet trace after the keepalive timer fires if the peer machine
receiving the keepalive does not respond. Usually the keepalive
timer will fire at least two hours after keepalive is turned on,
but it may be sooner if the timer value has been configured lower,
or if the keepalive mechanism violates the specification (see
Insufficient interval between keepalives problem). In this
For実現がこの問題を表すのをどう検出するか、keepaliveを受ける同輩マシンが反応しないならkeepaliveタイマが撃たれた後にそれはパケット跡に現れます。 通常、keepaliveがつけられた少なくとも2時間後にkeepaliveタイマは撃たれるでしょうが、タイマ値が、より低く構成されたか、またはkeepaliveメカニズムが仕様に違反するなら、早さ以上であるかもしれません(keepalives問題のInsufficient間隔を見ます)。 これで
Paxson, et. al. Informational [Page 30] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[30ページ]情報のRFC2525TCP実現問題行進
example, suppressing the response of the peer to keepalive probes
was accomplished using the Orchestra toolkit, which can be
configured to drop packets. It could also have been done by
creating a connection, turning on keepalive, and disconnecting the
network connection at the receiver machine.
例、keepalive徹底的調査への同輩の応答を抑圧するのは、Orchestraツールキット(パケットを落とすために構成できる)を使用することで達成されました。 また、接続を創造することによって、それをしたかもしれません、受信機マシンでkeepaliveをつけて、ネットワーク接続を外して。
How to fix
This problem can be fixed by using a different method for timing
out keepalives that allows a longer period of time to elapse
before dropping the connection. For example, the algorithm for
timing out on dropped data could be used. Another possibility is
an algorithm such as the one shown in the trace above, which sends
9 probes at 75 second intervals and then waits an additional 75
seconds for a response before closing the connection.
接続を落とす前により長い期間を経過させるタイミングの出ているkeepalivesに異なった方法を使用することによって、どうThis問題を修正するかを修理できます。 例えば、低下しているデータのタイミングのためのアルゴリズムを使用できました。 別の可能性は跡にどれが上では、75回の2番目の間隔を置いて9個の探測装置を送って、次に、接続を終える前に応答を追加75秒待つかが示されたものなどのアルゴリズムです。
2.10.
2.10.
Name of Problem
Failure to back off retransmission timeout
Problem Failureという再送タイムアウトで支持する名前
Classification
Congestion control / reliability
分類Congestionのコントロール/信頼性
Description
The retransmission timeout is used to determine when a packet has
been dropped in the network. When this timeout has expired
without the arrival of an ACK, the segment is retransmitted. Each
time a segment is retransmitted, the timeout is adjusted according
to an exponential backoff algorithm, doubling each time. If a TCP
fails to receive an ACK after numerous attempts at retransmitting
the same segment, it terminates the connection. A TCP that fails
to double its retransmission timeout upon repeated timeouts is
said to exhibit "Failure to back off retransmission timeout".
再送タイムアウトが使用されている記述は、パケットがいつネットワークで落とされたかを決定します。 このタイムアウトがACKの到着なしで期限が切れたとき、セグメントは再送されます。 その都度倍増して、セグメントが再送されるたびに指数のbackoffアルゴリズムに応じて、タイムアウトは調整されます。 TCPが同じセグメントを再送することへの頻繁な試みの後にACKを受け取らないなら、それは接続を終えます。 繰り返されたタイムアウトで再送タイムアウトを倍にしないTCPは「再送タイムアウトを戻さないこと」を示すと言われています。
Significance
Backing off the retransmission timer is a cornerstone of network
stability in the presence of congestion. Consequently, this bug
can have severe adverse affects in congested networks. It also
affects TCP reliability in congested networks, as discussed in the
next section.
再送信タイマーの意味Backingは混雑があるときネットワークの安定性の礎石です。 その結果、このバグは混雑しているネットワークで厳しい不利な感情を持つことができます。 また、それは次のセクションで議論するように混雑しているネットワークでTCPの信頼性に影響します。
Implications
It is possible for the network connection between two TCP peers to
become congested or to exhibit packet loss at the time that a
retransmission is sent on a connection. If the retransmission
mechanism does not allow sufficient time before dropping
含意Itは2人のTCP同輩の間のネットワーク接続が混雑するようになるか、または当時パケット損失を示すのにおいて「再-トランスミッション」が接続に送られるのが可能です。 「再-トランスミッション」メカニズムが低下する前に十分な時間を許容しないなら
Paxson, et. al. Informational [Page 31] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[31ページ]情報のRFC2525TCP実現問題行進
connections in the face of unacknowledged segments, connections
may be dropped even when, by waiting longer, the connection could
have continued.
不承認のセグメントに直面して接続、より長い間待つのによる接続が続けられていた状態で持つことができたなら、接続は落とされるかもしれません。
Relevant RFCs
RFC 1122 specifies mandatory exponential backoff of the
retransmission timeout, and the termination of connections after
some period of time (at least 100 seconds).
Relevant RFCs RFC 1122 specifies mandatory exponential backoff of the retransmission timeout, and the termination of connections after some period of time (at least 100 seconds).
Trace file demonstrating it
Made using tcpdump on an intermediate host:
Trace file demonstrating it Made using tcpdump on an intermediate host:
16:51:12.671727 A > B: S 510878852:510878852(0) win 16384
16:51:12.672479 B > A: S 2392143687:2392143687(0)
ack 510878853 win 16384
16:51:12.672581 A > B: . ack 1 win 16384
16:51:15.244171 A > B: P 1:3(2) ack 1 win 16384
16:51:15.244933 B > A: . ack 3 win 17518 (DF)
16:51:12.671727 A > B: S 510878852:510878852(0) win 16384 16:51:12.672479 B > A: S 2392143687:2392143687(0) ack 510878853 win 16384 16:51:12.672581 A > B: . ack 1 win 16384 16:51:15.244171 A > B: P 1:3(2) ack 1 win 16384 16:51:15.244933 B > A: . ack 3 win 17518 (DF)
<receiving host disconnected>
<receiving host disconnected>
16:51:19.381176 A > B: P 3:5(2) ack 1 win 16384 16:51:20.162016 A > B: P 3:5(2) ack 1 win 16384 16:51:21.161936 A > B: P 3:5(2) ack 1 win 16384 16:51:22.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:23.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:24.161879 A > B: P 3:5(2) ack 1 win 16384 16:51:25.161857 A > B: P 3:5(2) ack 1 win 16384 16:51:26.161836 A > B: P 3:5(2) ack 1 win 16384 16:51:27.161814 A > B: P 3:5(2) ack 1 win 16384 16:51:28.161791 A > B: P 3:5(2) ack 1 win 16384 16:51:29.161769 A > B: P 3:5(2) ack 1 win 16384 16:51:30.161750 A > B: P 3:5(2) ack 1 win 16384 16:51:31.161727 A > B: P 3:5(2) ack 1 win 16384
16:51:19.381176 A > B: P 3:5(2) ack 1 win 16384 16:51:20.162016 A > B: P 3:5(2) ack 1 win 16384 16:51:21.161936 A > B: P 3:5(2) ack 1 win 16384 16:51:22.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:23.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:24.161879 A > B: P 3:5(2) ack 1 win 16384 16:51:25.161857 A > B: P 3:5(2) ack 1 win 16384 16:51:26.161836 A > B: P 3:5(2) ack 1 win 16384 16:51:27.161814 A > B: P 3:5(2) ack 1 win 16384 16:51:28.161791 A > B: P 3:5(2) ack 1 win 16384 16:51:29.161769 A > B: P 3:5(2) ack 1 win 16384 16:51:30.161750 A > B: P 3:5(2) ack 1 win 16384 16:51:31.161727 A > B: P 3:5(2) ack 1 win 16384
16:51:32.161701 A > B: R 5:5(0) ack 1 win 16384
16:51:32.161701 A > B: R 5:5(0) ack 1 win 16384
The initial three packets are the SYN exchange for connection
setup, then a single data packet, to verify that data can be
transferred. Then the connection to the destination host was
disconnected, and more data sent. Retransmissions occur every
second for 12 seconds, and then the connection is terminated with
a RST. This is problematic because a 12 second pause in
connectivity could result in the termination of a connection.
The initial three packets are the SYN exchange for connection setup, then a single data packet, to verify that data can be transferred. Then the connection to the destination host was disconnected, and more data sent. Retransmissions occur every second for 12 seconds, and then the connection is terminated with a RST. This is problematic because a 12 second pause in connectivity could result in the termination of a connection.
Trace file demonstrating correct behavior
Again, a tcpdump taken from a third host:
Trace file demonstrating correct behavior Again, a tcpdump taken from a third host:
Paxson, et. al. Informational [Page 32] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 32] RFC 2525 TCP Implementation Problems March 1999
16:59:05.398301 A > B: S 2503324757:2503324757(0) win 16384
16:59:05.399673 B > A: S 2492674648:2492674648(0)
ack 2503324758 win 16384
16:59:05.399866 A > B: . ack 1 win 17520
16:59:06.538107 A > B: P 1:3(2) ack 1 win 17520
16:59:06.540977 B > A: . ack 3 win 17518 (DF)
16:59:05.398301 A > B: S 2503324757:2503324757(0) win 16384 16:59:05.399673 B > A: S 2492674648:2492674648(0) ack 2503324758 win 16384 16:59:05.399866 A > B: . ack 1 win 17520 16:59:06.538107 A > B: P 1:3(2) ack 1 win 17520 16:59:06.540977 B > A: . ack 3 win 17518 (DF)
<receiving host disconnected>
<receiving host disconnected>
16:59:13.121542 A > B: P 3:5(2) ack 1 win 17520 16:59:14.010928 A > B: P 3:5(2) ack 1 win 17520 16:59:16.010979 A > B: P 3:5(2) ack 1 win 17520 16:59:20.011229 A > B: P 3:5(2) ack 1 win 17520 16:59:28.011896 A > B: P 3:5(2) ack 1 win 17520 16:59:44.013200 A > B: P 3:5(2) ack 1 win 17520 17:00:16.015766 A > B: P 3:5(2) ack 1 win 17520 17:01:20.021308 A > B: P 3:5(2) ack 1 win 17520 17:02:24.027752 A > B: P 3:5(2) ack 1 win 17520 17:03:28.034569 A > B: P 3:5(2) ack 1 win 17520 17:04:32.041567 A > B: P 3:5(2) ack 1 win 17520 17:05:36.048264 A > B: P 3:5(2) ack 1 win 17520 17:06:40.054900 A > B: P 3:5(2) ack 1 win 17520
16:59:13.121542 A > B: P 3:5(2) ack 1 win 17520 16:59:14.010928 A > B: P 3:5(2) ack 1 win 17520 16:59:16.010979 A > B: P 3:5(2) ack 1 win 17520 16:59:20.011229 A > B: P 3:5(2) ack 1 win 17520 16:59:28.011896 A > B: P 3:5(2) ack 1 win 17520 16:59:44.013200 A > B: P 3:5(2) ack 1 win 17520 17:00:16.015766 A > B: P 3:5(2) ack 1 win 17520 17:01:20.021308 A > B: P 3:5(2) ack 1 win 17520 17:02:24.027752 A > B: P 3:5(2) ack 1 win 17520 17:03:28.034569 A > B: P 3:5(2) ack 1 win 17520 17:04:32.041567 A > B: P 3:5(2) ack 1 win 17520 17:05:36.048264 A > B: P 3:5(2) ack 1 win 17520 17:06:40.054900 A > B: P 3:5(2) ack 1 win 17520
17:07:44.061306 A > B: R 5:5(0) ack 1 win 17520
17:07:44.061306 A > B: R 5:5(0) ack 1 win 17520
In this trace, when the retransmission timer expires, 12
retransmissions are sent at exponentially-increasing intervals,
until the interval value reaches 64 seconds, at which time the
interval stops growing. 64 seconds after the last retransmission,
a final RST segment is sent indicating that the connection has
been closed. This implementation waits about 9 minutes before
timing out the connection, while the first implementation shown
allows only 12 seconds.
In this trace, when the retransmission timer expires, 12 retransmissions are sent at exponentially-increasing intervals, until the interval value reaches 64 seconds, at which time the interval stops growing. 64 seconds after the last retransmission, a final RST segment is sent indicating that the connection has been closed. This implementation waits about 9 minutes before timing out the connection, while the first implementation shown allows only 12 seconds.
References
None known.
References None known.
How to detect
A simple transfer can be easily interrupted by disconnecting the
receiving host from the network. tcpdump or another appropriate
tool should show the retransmissions being sent. Several trials
in a low-rtt environment may be required to demonstrate the bug.
How to detect A simple transfer can be easily interrupted by disconnecting the receiving host from the network. tcpdump or another appropriate tool should show the retransmissions being sent. Several trials in a low-rtt environment may be required to demonstrate the bug.
How to fix
For one of the implementations studied, this problem seemed to be
the result of an error introduced with the addition of the
Brakmo-Peterson RTO algorithm [Brakmo95], which can return a value
of zero where the older Jacobson algorithm always returns a
How to fix For one of the implementations studied, this problem seemed to be the result of an error introduced with the addition of the Brakmo-Peterson RTO algorithm [Brakmo95], which can return a value of zero where the older Jacobson algorithm always returns a
Paxson, et. al. Informational [Page 33] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 33] RFC 2525 TCP Implementation Problems March 1999
positive value. Brakmo and Peterson specified an additional step
of min(rtt + 2, RTO) to avoid problems with this. Unfortunately,
in the implementation this step was omitted when calculating the
exponential backoff for the RTO. This results in an RTO of 0
seconds being multiplied by the backoff, yielding again zero, and
then being subjected to a later MAX operation that increases it to
1 second, regardless of the backoff factor.
positive value. Brakmo and Peterson specified an additional step of min(rtt + 2, RTO) to avoid problems with this. Unfortunately, in the implementation this step was omitted when calculating the exponential backoff for the RTO. This results in an RTO of 0 seconds being multiplied by the backoff, yielding again zero, and then being subjected to a later MAX operation that increases it to 1 second, regardless of the backoff factor.
A similar TCP persist failure has the same cause.
A similar TCP persist failure has the same cause.
2.11.
2.11.
Name of Problem
Insufficient interval between keepalives
Name of Problem Insufficient interval between keepalives
Classification
Reliability
Classification Reliability
Description
Keep-alive is a mechanism for checking whether an idle connection
is still alive. According to RFC 1122, keep-alive may be included
in an implementation. If it is included, the interval between
keep-alive packets MUST be configurable, and MUST default to no
less than two hours.
Description Keep-alive is a mechanism for checking whether an idle connection is still alive. According to RFC 1122, keep-alive may be included in an implementation. If it is included, the interval between keep-alive packets MUST be configurable, and MUST default to no less than two hours.
Significance
In congested networks, can lead to unwarranted termination of
connections.
Significance In congested networks, can lead to unwarranted termination of connections.
Implications
According to RFC 1122, keep-alive is not required of
implementations because it could: (1) cause perfectly good
connections to break during transient Internet failures; (2)
consume unnecessary bandwidth ("if no one is using the connection,
who cares if it is still good?"); and (3) cost money for an
Internet path that charges for packets. Regarding this last
point, we note that in addition the presence of dial-on-demand
links in the route can greatly magnify the cost penalty of excess
keepalives, potentially forcing a full-time connection on a link
that would otherwise only be connected a few minutes a day.
Implications According to RFC 1122, keep-alive is not required of implementations because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets. Regarding this last point, we note that in addition the presence of dial-on-demand links in the route can greatly magnify the cost penalty of excess keepalives, potentially forcing a full-time connection on a link that would otherwise only be connected a few minutes a day.
If keepalive is provided the RFC states that the required inter-
keepalive distance MUST default to no less than two hours. If it
does not, the probability of connections breaking increases, the
bandwidth used due to keepalives increases, and cost increases
over paths which charge per packet.
If keepalive is provided the RFC states that the required inter- keepalive distance MUST default to no less than two hours. If it does not, the probability of connections breaking increases, the bandwidth used due to keepalives increases, and cost increases over paths which charge per packet.
Paxson, et. al. Informational [Page 34] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 34] RFC 2525 TCP Implementation Problems March 1999
Relevant RFCs
RFC 1122 specifies that the keep-alive mechanism may be provided.
It also specifies the two hour minimum for the default interval
between keepalive probes.
Relevant RFCs RFC 1122 specifies that the keep-alive mechanism may be provided. It also specifies the two hour minimum for the default interval between keepalive probes.
Trace file demonstrating it
Made using the Orchestra tool at the peer of the machine using
keep-alive. Machine A was configured to use default settings for
the keepalive timer.
Trace file demonstrating it Made using the Orchestra tool at the peer of the machine using keep-alive. Machine A was configured to use default settings for the keepalive timer.
11:36:32.910000 A > B: 3288354305:0 win 28672 datasz 4 SYN 11:36:32.930000 B > A: 896001:3288354306 win 4096 datasz 4 SYN ACK 11:36:32.950000 A > B: 3288354306:896002 win 28672 datasz 0 ACK
11:36:32.910000 A > B: 3288354305:0 win 28672 datasz 4 SYN 11:36:32.930000 B > A: 896001:3288354306 win 4096 datasz 4 SYN ACK 11:36:32.950000 A > B: 3288354306:896002 win 28672 datasz 0 ACK
11:50:01.190000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 11:50:01.210000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
11:50:01.190000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 11:50:01.210000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:03:29.410000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:03:29.430000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:03:29.410000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:03:29.430000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:16:57.630000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:16:57.650000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:16:57.630000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:16:57.650000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:30:25.850000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:30:25.870000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:30:25.850000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:30:25.870000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:43:54.070000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:43:54.090000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12:43:54.070000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:43:54.090000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
The initial three packets are the SYN exchange for connection
setup. About 13 minutes later, the keepalive timer fires because
the connection is idle. The keepalive is acknowledged, and the
timer fires again in about 13 more minutes. This behavior
continues indefinitely until the connection is closed, and is a
violation of the specification.
The initial three packets are the SYN exchange for connection setup. About 13 minutes later, the keepalive timer fires because the connection is idle. The keepalive is acknowledged, and the timer fires again in about 13 more minutes. This behavior continues indefinitely until the connection is closed, and is a violation of the specification.
Trace file demonstrating correct behavior
Made using the Orchestra tool at the peer of the machine using
keep-alive. Machine A was configured to use default settings for
the keepalive timer.
Trace file demonstrating correct behavior Made using the Orchestra tool at the peer of the machine using keep-alive. Machine A was configured to use default settings for the keepalive timer.
17:37:20.500000 A > B: 34155521:0 win 4096 datasz 4 SYN 17:37:20.520000 B > A: 6272001:34155522 win 4096 datasz 4 SYN ACK 17:37:20.540000 A > B: 34155522:6272002 win 4096 datasz 0 ACK
17:37:20.500000 A > B: 34155521:0 win 4096 datasz 4 SYN 17:37:20.520000 B > A: 6272001:34155522 win 4096 datasz 4 SYN ACK 17:37:20.540000 A > B: 34155522:6272002 win 4096 datasz 0 ACK
19:37:25.430000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 19:37:25.450000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
19:37:25.430000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 19:37:25.450000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
Paxson, et. al. Informational [Page 35] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 35] RFC 2525 TCP Implementation Problems March 1999
21:37:30.560000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 21:37:30.570000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
21:37:30.560000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 21:37:30.570000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
23:37:35.580000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 23:37:35.600000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
23:37:35.580000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 23:37:35.600000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
01:37:40.620000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 01:37:40.640000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
01:37:40.620000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 01:37:40.640000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
03:37:45.590000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 03:37:45.610000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
03:37:45.590000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 03:37:45.610000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
The initial three packets are the SYN exchange for connection
setup. Just over two hours later, the keepalive timer fires
because the connection is idle. The keepalive is acknowledged,
and the timer fires again just over two hours later. This
behavior continues indefinitely until the connection is closed.
The initial three packets are the SYN exchange for connection setup. Just over two hours later, the keepalive timer fires because the connection is idle. The keepalive is acknowledged, and the timer fires again just over two hours later. This behavior continues indefinitely until the connection is closed.
References
This problem is documented in [Dawson97].
References This problem is documented in [Dawson97].
How to detect
For implementations manifesting this problem, it shows up on a
packet trace. If the connection is left idle, the keepalive
probes will arrive closer together than the two hour minimum.
How to detect For implementations manifesting this problem, it shows up on a packet trace. If the connection is left idle, the keepalive probes will arrive closer together than the two hour minimum.
2.12.
2.12.
Name of Problem
Window probe deadlock
Name of Problem Window probe deadlock
Classification
Reliability
Classification Reliability
Description
When an application reads a single byte from a full window, the
window should not be updated, in order to avoid Silly Window
Syndrome (SWS; see [RFC813]). If the remote peer uses a single
byte of data to probe the window, that byte can be accepted into
the buffer. In some implementations, at this point a negative
argument to a signed comparison causes all further new data to be
considered outside the window; consequently, it is discarded
(after sending an ACK to resynchronize). These discards include
the ACKs for the data packets sent by the local TCP, so the TCP
will consider the data unacknowledged.
Description When an application reads a single byte from a full window, the window should not be updated, in order to avoid Silly Window Syndrome (SWS; see [RFC813]). If the remote peer uses a single byte of data to probe the window, that byte can be accepted into the buffer. In some implementations, at this point a negative argument to a signed comparison causes all further new data to be considered outside the window; consequently, it is discarded (after sending an ACK to resynchronize). These discards include the ACKs for the data packets sent by the local TCP, so the TCP will consider the data unacknowledged.
Paxson, et. al. Informational [Page 36] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 36] RFC 2525 TCP Implementation Problems March 1999
Consequently, the application may be unable to complete sending
new data to the remote peer, because it has exhausted the transmit
buffer available to its local TCP, and buffer space is never being
freed because incoming ACKs that would do so are being discarded.
If the application does not read any more data, which may happen
due to its failure to complete such sends, then deadlock results.
Consequently, the application may be unable to complete sending new data to the remote peer, because it has exhausted the transmit buffer available to its local TCP, and buffer space is never being freed because incoming ACKs that would do so are being discarded. If the application does not read any more data, which may happen due to its failure to complete such sends, then deadlock results.
Significance
It's relatively rare for applications to use TCP in a manner that
can exercise this problem. Most applications only transmit bulk
data if they know the other end is prepared to receive the data.
However, if a client fails to consume data, putting the server in
persist mode, and then consumes a small amount of data, it can
mistakenly compute a negative window. At this point the client
will discard all further packets from the server, including ACKs
of the client's own data, since they are not inside the
(impossibly-sized) window. If subsequently the client consumes
enough data to then send a window update to the server, the
situation will be rectified. That is, this situation can only
happen if the client consumes 1 < N < MSS bytes, so as not to
cause a window update, and then starts its own transmission
towards the server of more than a window's worth of data.
Significance It's relatively rare for applications to use TCP in a manner that can exercise this problem. Most applications only transmit bulk data if they know the other end is prepared to receive the data. However, if a client fails to consume data, putting the server in persist mode, and then consumes a small amount of data, it can mistakenly compute a negative window. At this point the client will discard all further packets from the server, including ACKs of the client's own data, since they are not inside the (impossibly-sized) window. If subsequently the client consumes enough data to then send a window update to the server, the situation will be rectified. That is, this situation can only happen if the client consumes 1 < N < MSS bytes, so as not to cause a window update, and then starts its own transmission towards the server of more than a window's worth of data.
Implications
TCP connections will hang and eventually time out.
Implications TCP connections will hang and eventually time out.
Relevant RFCs
RFC 793 describes zero window probing. RFC 813 describes Silly
Window Syndrome.
Relevant RFCs RFC 793 describes zero window probing. RFC 813 describes Silly Window Syndrome.
Trace file demonstrating it
Trace made from a version of tcpdump modified to print out the
sequence number attached to an ACK even if it's dataless. An
unmodified tcpdump would not print seq:seq(0); however, for this
bug, the sequence number in the ACK is important for unambiguously
determining how the TCP is behaving.
Trace file demonstrating it Trace made from a version of tcpdump modified to print out the sequence number attached to an ACK even if it's dataless. An unmodified tcpdump would not print seq:seq(0); however, for this bug, the sequence number in the ACK is important for unambiguously determining how the TCP is behaving.
[ Normal connection startup and data transmission from B to A.
Options, including MSS of 16344 in both directions, omitted
for clarity. ]
16:07:32.327616 A > B: S 65360807:65360807(0) win 8192
16:07:32.327304 B > A: S 65488807:65488807(0) ack 65360808 win 57344
16:07:32.327425 A > B: . 1:1(0) ack 1 win 57344
16:07:32.345732 B > A: P 1:2049(2048) ack 1 win 57344
16:07:32.347013 B > A: P 2049:16385(14336) ack 1 win 57344
16:07:32.347550 B > A: P 16385:30721(14336) ack 1 win 57344
16:07:32.348683 B > A: P 30721:45057(14336) ack 1 win 57344
16:07:32.467286 A > B: . 1:1(0) ack 45057 win 12288
[ Normal connection startup and data transmission from B to A. Options, including MSS of 16344 in both directions, omitted for clarity. ] 16:07:32.327616 A > B: S 65360807:65360807(0) win 8192 16:07:32.327304 B > A: S 65488807:65488807(0) ack 65360808 win 57344 16:07:32.327425 A > B: . 1:1(0) ack 1 win 57344 16:07:32.345732 B > A: P 1:2049(2048) ack 1 win 57344 16:07:32.347013 B > A: P 2049:16385(14336) ack 1 win 57344 16:07:32.347550 B > A: P 16385:30721(14336) ack 1 win 57344 16:07:32.348683 B > A: P 30721:45057(14336) ack 1 win 57344 16:07:32.467286 A > B: . 1:1(0) ack 45057 win 12288
Paxson, et. al. Informational [Page 37] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 37] RFC 2525 TCP Implementation Problems March 1999
16:07:32.467854 B > A: P 45057:57345(12288) ack 1 win 57344
16:07:32.467854 B > A: P 45057:57345(12288) ack 1 win 57344
[ B fills up A's offered window ] 16:07:32.667276 A > B: . 1:1(0) ack 57345 win 0
[ B fills up A's offered window ] 16:07:32.667276 A > B: . 1:1(0) ack 57345 win 0
[ B probes A's window with a single byte ] 16:07:37.467438 B > A: . 57345:57346(1) ack 1 win 57344
[ B probes A's window with a single byte ] 16:07:37.467438 B > A: . 57345:57346(1) ack 1 win 57344
[ A resynchronizes without accepting the byte ] 16:07:37.467678 A > B: . 1:1(0) ack 57345 win 0
[ A resynchronizes without accepting the byte ] 16:07:37.467678 A > B: . 1:1(0) ack 57345 win 0
[ B probes A's window again ] 16:07:45.467438 B > A: . 57345:57346(1) ack 1 win 57344
[ B probes A's window again ] 16:07:45.467438 B > A: . 57345:57346(1) ack 1 win 57344
[ A resynchronizes and accepts the byte (per the ack field) ] 16:07:45.667250 A > B: . 1:1(0) ack 57346 win 0
[ A resynchronizes and accepts the byte (per the ack field) ] 16:07:45.667250 A > B: . 1:1(0) ack 57346 win 0
[ The application on A has started generating data. The first
packet A sends is small due to a memory allocation bug. ]
16:07:51.358459 A > B: P 1:2049(2048) ack 57346 win 0
[ The application on A has started generating data. The first packet A sends is small due to a memory allocation bug. ] 16:07:51.358459 A > B: P 1:2049(2048) ack 57346 win 0
[ B acks A's first packet ] 16:07:51.467239 B > A: . 57346:57346(0) ack 2049 win 57344
[ B acks A's first packet ] 16:07:51.467239 B > A: . 57346:57346(0) ack 2049 win 57344
[ This looks as though A accepted B's ACK and is sending
another packet in response to it. In fact, A is trying
to resynchronize with B, and happens to have data to send
and can send it because the first small packet didn't use
up cwnd. ]
16:07:51.467698 A > B: . 2049:14337(12288) ack 57346 win 0
[ This looks as though A accepted B's ACK and is sending another packet in response to it. In fact, A is trying to resynchronize with B, and happens to have data to send and can send it because the first small packet didn't use up cwnd. ] 16:07:51.467698 A > B: . 2049:14337(12288) ack 57346 win 0
[ B acks all of the data that A has sent ] 16:07:51.667283 B > A: . 57346:57346(0) ack 14337 win 57344
[ B acks all of the data that A has sent ] 16:07:51.667283 B > A: . 57346:57346(0) ack 14337 win 57344
[ A tries to resynchronize. Notice that by the packets
seen on the network, A and B *are* in fact synchronized;
A only thinks that they aren't. ]
16:07:51.667477 A > B: . 14337:14337(0) ack 57346 win 0
[ A tries to resynchronize. Notice that by the packets seen on the network, A and B *are* in fact synchronized; A only thinks that they aren't. ] 16:07:51.667477 A > B: . 14337:14337(0) ack 57346 win 0
[ A's retransmit timer fires, and B acks all of the data.
A once again tries to resynchronize. ]
16:07:52.467682 A > B: . 1:14337(14336) ack 57346 win 0
16:07:52.468166 B > A: . 57346:57346(0) ack 14337 win 57344
16:07:52.468248 A > B: . 14337:14337(0) ack 57346 win 0
[ A's retransmit timer fires, and B acks all of the data. A once again tries to resynchronize. ] 16:07:52.467682 A > B: . 1:14337(14336) ack 57346 win 0 16:07:52.468166 B > A: . 57346:57346(0) ack 14337 win 57344 16:07:52.468248 A > B: . 14337:14337(0) ack 57346 win 0
[ A's retransmit timer fires again, and B acks all of the data.
A once again tries to resynchronize. ]
16:07:55.467684 A > B: . 1:14337(14336) ack 57346 win 0
[ A's retransmit timer fires again, and B acks all of the data. A once again tries to resynchronize. ] 16:07:55.467684 A > B: . 1:14337(14336) ack 57346 win 0
Paxson, et. al. Informational [Page 38] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 38] RFC 2525 TCP Implementation Problems March 1999
16:07:55.468172 B > A: . 57346:57346(0) ack 14337 win 57344 16:07:55.468254 A > B: . 14337:14337(0) ack 57346 win 0
16:07:55.468172 B > A: . 57346:57346(0) ack 14337 win 57344 16:07:55.468254 A > B: . 14337:14337(0) ack 57346 win 0
Trace file demonstrating correct behavior
Made between the same two hosts after applying the bug fix
mentioned below (and using the same modified tcpdump).
Trace file demonstrating correct behavior Made between the same two hosts after applying the bug fix mentioned below (and using the same modified tcpdump).
[ Connection starts up with data transmission from B to A.
Note that due to a separate bug (the fact that A and B
are communicating over a loopback driver), B erroneously
skips slow start. ]
17:38:09.510854 A > B: S 3110066585:3110066585(0) win 16384
17:38:09.510926 B > A: S 3110174850:3110174850(0)
ack 3110066586 win 57344
17:38:09.510953 A > B: . 1:1(0) ack 1 win 57344
17:38:09.512956 B > A: P 1:2049(2048) ack 1 win 57344
17:38:09.513222 B > A: P 2049:16385(14336) ack 1 win 57344
17:38:09.513428 B > A: P 16385:30721(14336) ack 1 win 57344
17:38:09.513638 B > A: P 30721:45057(14336) ack 1 win 57344
17:38:09.519531 A > B: . 1:1(0) ack 45057 win 12288
17:38:09.519638 B > A: P 45057:57345(12288) ack 1 win 57344
[ Connection starts up with data transmission from B to A. Note that due to a separate bug (the fact that A and B are communicating over a loopback driver), B erroneously skips slow start. ] 17:38:09.510854 A > B: S 3110066585:3110066585(0) win 16384 17:38:09.510926 B > A: S 3110174850:3110174850(0) ack 3110066586 win 57344 17:38:09.510953 A > B: . 1:1(0) ack 1 win 57344 17:38:09.512956 B > A: P 1:2049(2048) ack 1 win 57344 17:38:09.513222 B > A: P 2049:16385(14336) ack 1 win 57344 17:38:09.513428 B > A: P 16385:30721(14336) ack 1 win 57344 17:38:09.513638 B > A: P 30721:45057(14336) ack 1 win 57344 17:38:09.519531 A > B: . 1:1(0) ack 45057 win 12288 17:38:09.519638 B > A: P 45057:57345(12288) ack 1 win 57344
[ B fills up A's offered window ] 17:38:09.719526 A > B: . 1:1(0) ack 57345 win 0
[ B fills up A's offered window ] 17:38:09.719526 A > B: . 1:1(0) ack 57345 win 0
[ B probes A's window with a single byte. A resynchronizes
without accepting the byte ]
17:38:14.499661 B > A: . 57345:57346(1) ack 1 win 57344
17:38:14.499724 A > B: . 1:1(0) ack 57345 win 0
[ B probes A's window with a single byte. A resynchronizes without accepting the byte ] 17:38:14.499661 B > A: . 57345:57346(1) ack 1 win 57344 17:38:14.499724 A > B: . 1:1(0) ack 57345 win 0
[ B probes A's window again. A resynchronizes and accepts
the byte, as indicated by the ack field ]
17:38:19.499764 B > A: . 57345:57346(1) ack 1 win 57344
17:38:19.519731 A > B: . 1:1(0) ack 57346 win 0
[ B probes A's window again. A resynchronizes and accepts the byte, as indicated by the ack field ] 17:38:19.499764 B > A: . 57345:57346(1) ack 1 win 57344 17:38:19.519731 A > B: . 1:1(0) ack 57346 win 0
[ B probes A's window with a single byte. A resynchronizes
without accepting the byte ]
17:38:24.499865 B > A: . 57346:57347(1) ack 1 win 57344
17:38:24.499934 A > B: . 1:1(0) ack 57346 win 0
[ B probes A's window with a single byte. A resynchronizes without accepting the byte ] 17:38:24.499865 B > A: . 57346:57347(1) ack 1 win 57344 17:38:24.499934 A > B: . 1:1(0) ack 57346 win 0
[ The application on A has started generating data.
B acks A's data and A accepts the ACKs and the
data transfer continues ]
17:38:28.530265 A > B: P 1:2049(2048) ack 57346 win 0
17:38:28.719914 B > A: . 57346:57346(0) ack 2049 win 57344
[ The application on A has started generating data. B acks A's data and A accepts the ACKs and the data transfer continues ] 17:38:28.530265 A > B: P 1:2049(2048) ack 57346 win 0 17:38:28.719914 B > A: . 57346:57346(0) ack 2049 win 57344
17:38:28.720023 A > B: . 2049:16385(14336) ack 57346 win 0 17:38:28.720089 A > B: . 16385:30721(14336) ack 57346 win 0
17:38:28.720023 A > B: . 2049:16385(14336) ack 57346 win 0 17:38:28.720089 A > B: . 16385:30721(14336) ack 57346 win 0
Paxson, et. al. Informational [Page 39] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 39] RFC 2525 TCP Implementation Problems March 1999
17:38:28.720370 B > A: . 57346:57346(0) ack 30721 win 57344
17:38:28.720370 B > A: . 57346:57346(0) ack 30721 win 57344
17:38:28.720462 A > B: . 30721:45057(14336) ack 57346 win 0 17:38:28.720526 A > B: P 45057:59393(14336) ack 57346 win 0 17:38:28.720824 A > B: P 59393:73729(14336) ack 57346 win 0 17:38:28.721124 B > A: . 57346:57346(0) ack 73729 win 47104
17:38:28.720462 A > B: . 30721:45057(14336) ack 57346 win 0 17:38:28.720526 A > B: P 45057:59393(14336) ack 57346 win 0 17:38:28.720824 A > B: P 59393:73729(14336) ack 57346 win 0 17:38:28.721124 B > A: . 57346:57346(0) ack 73729 win 47104
17:38:28.721198 A > B: P 73729:88065(14336) ack 57346 win 0 17:38:28.721379 A > B: P 88065:102401(14336) ack 57346 win 0
17:38:28.721198 A > B: P 73729:88065(14336) ack 57346 win 0 17:38:28.721379 A > B: P 88065:102401(14336) ack 57346 win 0
17:38:28.721557 A > B: P 102401:116737(14336) ack 57346 win 0 17:38:28.721863 B > A: . 57346:57346(0) ack 116737 win 36864
17:38:28.721557 A > B: P 102401:116737(14336) ack 57346 win 0 17:38:28.721863 B > A: . 57346:57346(0) ack 116737 win 36864
References
None known.
References None known.
How to detect
Initiate a connection from a client to a server. Have the server
continuously send data until its buffers have been full for long
enough to exhaust the window. Next, have the client read 1 byte
and then delay for long enough that the server TCP sends a window
probe. Now have the client start sending data. At this point, if
it ignores the server's ACKs, then the client's TCP suffers from
the problem.
How to detect Initiate a connection from a client to a server. Have the server continuously send data until its buffers have been full for long enough to exhaust the window. Next, have the client read 1 byte and then delay for long enough that the server TCP sends a window probe. Now have the client start sending data. At this point, if it ignores the server's ACKs, then the client's TCP suffers from the problem.
How to fix
In one implementation known to exhibit the problem (derived from
4.3-Reno), the problem was introduced when the macro MAX() was
replaced by the function call max() for computing the amount of
space in the receive window:
How to fix In one implementation known to exhibit the problem (derived from 4.3-Reno), the problem was introduced when the macro MAX() was replaced by the function call max() for computing the amount of space in the receive window:
tp->rcv_wnd = max(win, (int)(tp->rcv_adv - tp->rcv_nxt));
tp->rcv_wnd = max(win, (int)(tp->rcv_adv - tp->rcv_nxt));
When data has been received into a window beyond what has been
advertised to the other side, rcv_nxt > rcv_adv, making this
negative. It's clear from the (int) cast that this is intended,
but the unsigned max() function sign-extends so the negative
number is "larger". The fix is to change max() to imax():
When data has been received into a window beyond what has been advertised to the other side, rcv_nxt > rcv_adv, making this negative. It's clear from the (int) cast that this is intended, but the unsigned max() function sign-extends so the negative number is "larger". The fix is to change max() to imax():
tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt));
tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt));
4.3-Tahoe and before did not have this bug, since it used the
macro MAX() for this calculation.
4.3-Tahoe and before did not have this bug, since it used the macro MAX() for this calculation.
2.13.
2.13.
Name of Problem
Stretch ACK violation
Name of Problem Stretch ACK violation
Paxson, et. al. Informational [Page 40] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 40] RFC 2525 TCP Implementation Problems March 1999
Classification
Congestion Control/Performance
Classification Congestion Control/Performance
Description
To improve efficiency (both computer and network) a data receiver
may refrain from sending an ACK for each incoming segment,
according to [RFC1122]. However, an ACK should not be delayed an
inordinate amount of time. Specifically, ACKs SHOULD be sent for
every second full-sized segment that arrives. If a second full-
sized segment does not arrive within a given timeout (of no more
than 0.5 seconds), an ACK should be transmitted, according to
[RFC1122]. A TCP receiver which does not generate an ACK for
every second full-sized segment exhibits a "Stretch ACK
Violation".
Description To improve efficiency (both computer and network) a data receiver may refrain from sending an ACK for each incoming segment, according to [RFC1122]. However, an ACK should not be delayed an inordinate amount of time. Specifically, ACKs SHOULD be sent for every second full-sized segment that arrives. If a second full- sized segment does not arrive within a given timeout (of no more than 0.5 seconds), an ACK should be transmitted, according to [RFC1122]. A TCP receiver which does not generate an ACK for every second full-sized segment exhibits a "Stretch ACK Violation".
Significance
TCP receivers exhibiting this behavior will cause TCP senders to
generate burstier traffic, which can degrade performance in
congested environments. In addition, generating fewer ACKs
increases the amount of time needed by the slow start algorithm to
open the congestion window to an appropriate point, which
diminishes performance in environments with large bandwidth-delay
products. Finally, generating fewer ACKs may cause needless
retransmission timeouts in lossy environments, as it increases the
possibility that an entire window of ACKs is lost, forcing a
retransmission timeout.
Significance TCP receivers exhibiting this behavior will cause TCP senders to generate burstier traffic, which can degrade performance in congested environments. In addition, generating fewer ACKs increases the amount of time needed by the slow start algorithm to open the congestion window to an appropriate point, which diminishes performance in environments with large bandwidth-delay products. Finally, generating fewer ACKs may cause needless retransmission timeouts in lossy environments, as it increases the possibility that an entire window of ACKs is lost, forcing a retransmission timeout.
Implications
When not in loss recovery, every ACK received by a TCP sender
triggers the transmission of new data segments. The burst size is
determined by the number of previously unacknowledged segments
each ACK covers. Therefore, a TCP receiver ack'ing more than 2
segments at a time causes the sending TCP to generate a larger
burst of traffic upon receipt of the ACK. This large burst of
traffic can overwhelm an intervening gateway, leading to higher
drop rates for both the connection and other connections passing
through the congested gateway.
Implications When not in loss recovery, every ACK received by a TCP sender triggers the transmission of new data segments. The burst size is determined by the number of previously unacknowledged segments each ACK covers. Therefore, a TCP receiver ack'ing more than 2 segments at a time causes the sending TCP to generate a larger burst of traffic upon receipt of the ACK. This large burst of traffic can overwhelm an intervening gateway, leading to higher drop rates for both the connection and other connections passing through the congested gateway.
In addition, the TCP slow start algorithm increases the congestion
window by 1 segment for each ACK received. Therefore, increasing
the ACK interval (thus decreasing the rate at which ACKs are
transmitted) increases the amount of time it takes slow start to
increase the congestion window to an appropriate operating point,
and the connection consequently suffers from reduced performance.
This is especially true for connections using large windows.
In addition, the TCP slow start algorithm increases the congestion window by 1 segment for each ACK received. Therefore, increasing the ACK interval (thus decreasing the rate at which ACKs are transmitted) increases the amount of time it takes slow start to increase the congestion window to an appropriate operating point, and the connection consequently suffers from reduced performance. This is especially true for connections using large windows.
Relevant RFCs
RFC 1122 outlines delayed ACKs as a recommended mechanism.
Relevant RFCs RFC 1122 outlines delayed ACKs as a recommended mechanism.
Paxson, et. al. Informational [Page 41] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 41] RFC 2525 TCP Implementation Problems March 1999
Trace file demonstrating it
Trace file taken using tcpdump at host B, the data receiver (and
ACK originator). The advertised window (which never changed) and
timestamp options have been omitted for clarity, except for the
first packet sent by A:
Trace file demonstrating it Trace file taken using tcpdump at host B, the data receiver (and ACK originator). The advertised window (which never changed) and timestamp options have been omitted for clarity, except for the first packet sent by A:
12:09:24.820187 A.1174 > B.3999: . 2049:3497(1448) ack 1
win 33580 <nop,nop,timestamp 2249877 2249914> [tos 0x8]
12:09:24.824147 A.1174 > B.3999: . 3497:4945(1448) ack 1
12:09:24.832034 A.1174 > B.3999: . 4945:6393(1448) ack 1
12:09:24.832222 B.3999 > A.1174: . ack 6393
12:09:24.934837 A.1174 > B.3999: . 6393:7841(1448) ack 1
12:09:24.942721 A.1174 > B.3999: . 7841:9289(1448) ack 1
12:09:24.950605 A.1174 > B.3999: . 9289:10737(1448) ack 1
12:09:24.950797 B.3999 > A.1174: . ack 10737
12:09:24.958488 A.1174 > B.3999: . 10737:12185(1448) ack 1
12:09:25.052330 A.1174 > B.3999: . 12185:13633(1448) ack 1
12:09:25.060216 A.1174 > B.3999: . 13633:15081(1448) ack 1
12:09:25.060405 B.3999 > A.1174: . ack 15081
12:09:24.820187 A.1174 > B.3999: . 2049:3497(1448) ack 1 win 33580 <nop,nop,timestamp 2249877 2249914> [tos 0x8] 12:09:24.824147 A.1174 > B.3999: . 3497:4945(1448) ack 1 12:09:24.832034 A.1174 > B.3999: . 4945:6393(1448) ack 1 12:09:24.832222 B.3999 > A.1174: . ack 6393 12:09:24.934837 A.1174 > B.3999: . 6393:7841(1448) ack 1 12:09:24.942721 A.1174 > B.3999: . 7841:9289(1448) ack 1 12:09:24.950605 A.1174 > B.3999: . 9289:10737(1448) ack 1 12:09:24.950797 B.3999 > A.1174: . ack 10737 12:09:24.958488 A.1174 > B.3999: . 10737:12185(1448) ack 1 12:09:25.052330 A.1174 > B.3999: . 12185:13633(1448) ack 1 12:09:25.060216 A.1174 > B.3999: . 13633:15081(1448) ack 1 12:09:25.060405 B.3999 > A.1174: . ack 15081
This portion of the trace clearly shows that the receiver (host B)
sends an ACK for every third full sized packet received. Further
investigation of this implementation found that the cause of the
increased ACK interval was the TCP options being used. The
implementation sent an ACK after it was holding 2*MSS worth of
unacknowledged data. In the above case, the MSS is 1460 bytes so
the receiver transmits an ACK after it is holding at least 2920
bytes of unacknowledged data. However, the length of the TCP
options being used [RFC1323] took 12 bytes away from the data
portion of each packet. This produced packets containing 1448
bytes of data. But the additional bytes used by the options in
the header were not taken into account when determining when to
trigger an ACK. Therefore, it took 3 data segments before the
data receiver was holding enough unacknowledged data (>= 2*MSS, or
2920 bytes in the above example) to transmit an ACK.
This portion of the trace clearly shows that the receiver (host B) sends an ACK for every third full sized packet received. Further investigation of this implementation found that the cause of the increased ACK interval was the TCP options being used. The implementation sent an ACK after it was holding 2*MSS worth of unacknowledged data. In the above case, the MSS is 1460 bytes so the receiver transmits an ACK after it is holding at least 2920 bytes of unacknowledged data. However, the length of the TCP options being used [RFC1323] took 12 bytes away from the data portion of each packet. This produced packets containing 1448 bytes of data. But the additional bytes used by the options in the header were not taken into account when determining when to trigger an ACK. Therefore, it took 3 data segments before the data receiver was holding enough unacknowledged data (>= 2*MSS, or 2920 bytes in the above example) to transmit an ACK.
Trace file demonstrating correct behavior
Trace file taken using tcpdump at host B, the data receiver (and
ACK originator), again with window and timestamp information
omitted except for the first packet:
Trace file demonstrating correct behavior Trace file taken using tcpdump at host B, the data receiver (and ACK originator), again with window and timestamp information omitted except for the first packet:
12:06:53.627320 A.1172 > B.3999: . 1449:2897(1448) ack 1
win 33580 <nop,nop,timestamp 2249575 2249612> [tos 0x8]
12:06:53.634773 A.1172 > B.3999: . 2897:4345(1448) ack 1
12:06:53.634961 B.3999 > A.1172: . ack 4345
12:06:53.737326 A.1172 > B.3999: . 4345:5793(1448) ack 1
12:06:53.744401 A.1172 > B.3999: . 5793:7241(1448) ack 1
12:06:53.744592 B.3999 > A.1172: . ack 7241
12:06:53.627320 A.1172 > B.3999: . 1449:2897(1448) ack 1 win 33580 <nop,nop,timestamp 2249575 2249612> [tos 0x8] 12:06:53.634773 A.1172 > B.3999: . 2897:4345(1448) ack 1 12:06:53.634961 B.3999 > A.1172: . ack 4345 12:06:53.737326 A.1172 > B.3999: . 4345:5793(1448) ack 1 12:06:53.744401 A.1172 > B.3999: . 5793:7241(1448) ack 1 12:06:53.744592 B.3999 > A.1172: . ack 7241
Paxson, et. al. Informational [Page 42] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 42] RFC 2525 TCP Implementation Problems March 1999
12:06:53.752287 A.1172 > B.3999: . 7241:8689(1448) ack 1 12:06:53.847332 A.1172 > B.3999: . 8689:10137(1448) ack 1 12:06:53.847525 B.3999 > A.1172: . ack 10137
12:06:53.752287 A.1172 > B.3999: . 7241:8689(1448) ack 1 12:06:53.847332 A.1172 > B.3999: . 8689:10137(1448) ack 1 12:06:53.847525 B.3999 > A.1172: . ack 10137
This trace shows the TCP receiver (host B) ack'ing every second
full-sized packet, according to [RFC1122]. This is the same
implementation shown above, with slight modifications that allow
the receiver to take the length of the options into account when
deciding when to transmit an ACK.
This trace shows the TCP receiver (host B) ack'ing every second full-sized packet, according to [RFC1122]. This is the same implementation shown above, with slight modifications that allow the receiver to take the length of the options into account when deciding when to transmit an ACK.
References
This problem is documented in [Allman97] and [Paxson97].
References This problem is documented in [Allman97] and [Paxson97].
How to detect
Stretch ACK violations show up immediately in receiver-side packet
traces of bulk transfers, as shown above. However, packet traces
made on the sender side of the TCP connection may lead to
ambiguities when diagnosing this problem due to the possibility of
lost ACKs.
How to detect Stretch ACK violations show up immediately in receiver-side packet traces of bulk transfers, as shown above. However, packet traces made on the sender side of the TCP connection may lead to ambiguities when diagnosing this problem due to the possibility of lost ACKs.
2.14.
2.14.
Name of Problem
Retransmission sends multiple packets
Name of Problem Retransmission sends multiple packets
Classification
Congestion control
Classification Congestion control
Description
When a TCP retransmits a segment due to a timeout expiration or
beginning a fast retransmission sequence, it should only transmit
a single segment. A TCP that transmits more than one segment
exhibits "Retransmission Sends Multiple Packets".
Description When a TCP retransmits a segment due to a timeout expiration or beginning a fast retransmission sequence, it should only transmit a single segment. A TCP that transmits more than one segment exhibits "Retransmission Sends Multiple Packets".
Instances of this problem have been known to occur due to
miscomputations involving the use of TCP options. TCP options
increase the TCP header beyond its usual size of 20 bytes. The
total size of header must be taken into account when
retransmitting a packet. If a TCP sender does not account for the
length of the TCP options when determining how much data to
retransmit, it will send too much data to fit into a single
packet. In this case, the correct retransmission will be followed
by a short segment (tinygram) containing data that may not need to
be retransmitted.
Instances of this problem have been known to occur due to miscomputations involving the use of TCP options. TCP options increase the TCP header beyond its usual size of 20 bytes. The total size of header must be taken into account when retransmitting a packet. If a TCP sender does not account for the length of the TCP options when determining how much data to retransmit, it will send too much data to fit into a single packet. In this case, the correct retransmission will be followed by a short segment (tinygram) containing data that may not need to be retransmitted.
A specific case is a TCP using the RFC 1323 timestamp option,
which adds 12 bytes to the standard 20-byte TCP header. On
retransmission of a packet, the 12 byte option is incorrectly
A specific case is a TCP using the RFC 1323 timestamp option, which adds 12 bytes to the standard 20-byte TCP header. On retransmission of a packet, the 12 byte option is incorrectly
Paxson, et. al. Informational [Page 43] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 43] RFC 2525 TCP Implementation Problems March 1999
interpreted as part of the data portion of the segment. A
standard TCP header and a new 12-byte option is added to the data,
which yields a transmission of 12 bytes more data than contained
in the original segment. This overflow causes a smaller packet,
with 12 data bytes, to be transmitted.
interpreted as part of the data portion of the segment. A standard TCP header and a new 12-byte option is added to the data, which yields a transmission of 12 bytes more data than contained in the original segment. This overflow causes a smaller packet, with 12 data bytes, to be transmitted.
Significance
This problem is somewhat serious for congested environments
because the TCP implementation injects more packets into the
network than is appropriate. However, since a tinygram is only
sent in response to a fast retransmit or a timeout, it does not
effect the sustained sending rate.
Significance This problem is somewhat serious for congested environments because the TCP implementation injects more packets into the network than is appropriate. However, since a tinygram is only sent in response to a fast retransmit or a timeout, it does not effect the sustained sending rate.
Implications
A TCP exhibiting this behavior is stressing the network with more
traffic than appropriate, and stressing routers by increasing the
number of packets they must process. The redundant tinygram will
also elicit a duplicate ACK from the receiver, resulting in yet
another unnecessary transmission.
Implications A TCP exhibiting this behavior is stressing the network with more traffic than appropriate, and stressing routers by increasing the number of packets they must process. The redundant tinygram will also elicit a duplicate ACK from the receiver, resulting in yet another unnecessary transmission.
Relevant RFCs
RFC 1122 requires use of slow start after loss; RFC 2001
explicates slow start; RFC 1323 describes the timestamp option
that has been observed to lead to some implementations exhibiting
this problem.
Relevant RFCs RFC 1122 requires use of slow start after loss; RFC 2001 explicates slow start; RFC 1323 describes the timestamp option that has been observed to lead to some implementations exhibiting this problem.
Trace file demonstrating it
Made using tcpdump recording at a machine on the same subnet as
Host A. Host A is the sender and Host B is the receiver. The
advertised window and timestamp options have been omitted for
clarity, except for the first segment sent by host A. In
addition, portions of the trace file not pertaining to the packet
in question have been removed (missing packets are denoted by
"[...]" in the trace).
Trace file demonstrating it Made using tcpdump recording at a machine on the same subnet as Host A. Host A is the sender and Host B is the receiver. The advertised window and timestamp options have been omitted for clarity, except for the first segment sent by host A. In addition, portions of the trace file not pertaining to the packet in question have been removed (missing packets are denoted by "[...]" in the trace).
11:55:22.701668 A > B: . 7361:7821(460) ack 1
win 49324 <nop,nop,timestamp 3485348 3485113>
11:55:22.702109 A > B: . 7821:8281(460) ack 1
[...]
11:55:22.701668 A > B: . 7361:7821(460) ack 1 win 49324 <nop,nop,timestamp 3485348 3485113> 11:55:22.702109 A > B: . 7821:8281(460) ack 1 [...]
11:55:23.112405 B > A: . ack 7821 11:55:23.113069 A > B: . 12421:12881(460) ack 1 11:55:23.113511 A > B: . 12881:13341(460) ack 1 11:55:23.333077 B > A: . ack 7821 11:55:23.336860 B > A: . ack 7821 11:55:23.340638 B > A: . ack 7821 11:55:23.341290 A > B: . 7821:8281(460) ack 1 11:55:23.341317 A > B: . 8281:8293(12) ack 1
11:55:23.112405 B > A: . ack 7821 11:55:23.113069 A > B: . 12421:12881(460) ack 1 11:55:23.113511 A > B: . 12881:13341(460) ack 1 11:55:23.333077 B > A: . ack 7821 11:55:23.336860 B > A: . ack 7821 11:55:23.340638 B > A: . ack 7821 11:55:23.341290 A > B: . 7821:8281(460) ack 1 11:55:23.341317 A > B: . 8281:8293(12) ack 1
Paxson, et. al. Informational [Page 44] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 44] RFC 2525 TCP Implementation Problems March 1999
11:55:23.498242 B > A: . ack 7821 11:55:23.506850 B > A: . ack 7821 11:55:23.510630 B > A: . ack 7821
11:55:23.498242 B > A: . ack 7821 11:55:23.506850 B > A: . ack 7821 11:55:23.510630 B > A: . ack 7821
[...]
[...]
11:55:23.746649 B > A: . ack 10581
11:55:23.746649 B > A: . ack 10581
The second line of the above trace shows the original transmission
of a segment which is later dropped. After 3 duplicate ACKs, line
9 of the trace shows the dropped packet (7821:8281), with a 460-
byte payload, being retransmitted. Immediately following this
retransmission, a packet with a 12-byte payload is unnecessarily
sent.
The second line of the above trace shows the original transmission of a segment which is later dropped. After 3 duplicate ACKs, line 9 of the trace shows the dropped packet (7821:8281), with a 460- byte payload, being retransmitted. Immediately following this retransmission, a packet with a 12-byte payload is unnecessarily sent.
Trace file demonstrating correct behavior
The trace file would be identical to the one above, with a single
line:
Trace file demonstrating correct behavior The trace file would be identical to the one above, with a single line:
11:55:23.341317 A > B: . 8281:8293(12) ack 1
11:55:23.341317 A > B: . 8281:8293(12) ack 1
omitted.
omitted.
References
[Brakmo95]
References [Brakmo95]
How to detect
This problem can be detected by examining a packet trace of the
TCP connections of a machine using TCP options, during which a
packet is retransmitted.
How to detect This problem can be detected by examining a packet trace of the TCP connections of a machine using TCP options, during which a packet is retransmitted.
2.15.
2.15.
Name of Problem
Failure to send FIN notification promptly
Name of Problem Failure to send FIN notification promptly
Classification
Performance
Classification Performance
Description
When an application closes a connection, the corresponding TCP
should send the FIN notification promptly to its peer (unless
prevented by the congestion window). If a TCP implementation
delays in sending the FIN notification, for example due to waiting
until unacknowledged data has been acknowledged, then it is said
to exhibit "Failure to send FIN notification promptly".
Description When an application closes a connection, the corresponding TCP should send the FIN notification promptly to its peer (unless prevented by the congestion window). If a TCP implementation delays in sending the FIN notification, for example due to waiting until unacknowledged data has been acknowledged, then it is said to exhibit "Failure to send FIN notification promptly".
Paxson, et. al. Informational [Page 45] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 45] RFC 2525 TCP Implementation Problems March 1999
Also, while not strictly required, FIN segments should include the
PSH flag to ensure expedited delivery of any pending data at the
receiver.
Also, while not strictly required, FIN segments should include the PSH flag to ensure expedited delivery of any pending data at the receiver.
Significance
The greatest impact occurs for short-lived connections, since for
these the additional time required to close the connection
introduces the greatest relative delay.
Significance The greatest impact occurs for short-lived connections, since for these the additional time required to close the connection introduces the greatest relative delay.
The additional time can be significant in the common case of the
sender waiting for an ACK that is delayed by the receiver.
The additional time can be significant in the common case of the sender waiting for an ACK that is delayed by the receiver.
Implications
Can diminish total throughput as seen at the application layer,
because connection termination takes longer to complete.
Implications Can diminish total throughput as seen at the application layer, because connection termination takes longer to complete.
Relevant RFCs
RFC 793 indicates that a receiver should treat an incoming FIN
flag as implying the push function.
Relevant RFCs RFC 793 indicates that a receiver should treat an incoming FIN flag as implying the push function.
Trace file demonstrating it
Made using tcpdump (no losses reported by the packet filter).
Trace file demonstrating it Made using tcpdump (no losses reported by the packet filter).
10:04:38.68 A > B: S 1031850376:1031850376(0) win 4096
<mss 1460,wscale 0,eol> (DF)
10:04:38.71 B > A: S 596916473:596916473(0) ack 1031850377
win 8760 <mss 1460> (DF)
10:04:38.73 A > B: . ack 1 win 4096 (DF)
10:04:41.98 A > B: P 1:4(3) ack 1 win 4096 (DF)
10:04:42.15 B > A: . ack 4 win 8757 (DF)
10:04:42.23 A > B: P 4:7(3) ack 1 win 4096 (DF)
10:04:42.25 B > A: P 1:11(10) ack 7 win 8754 (DF)
10:04:42.32 A > B: . ack 11 win 4096 (DF)
10:04:42.33 B > A: P 11:51(40) ack 7 win 8754 (DF)
10:04:42.51 A > B: . ack 51 win 4096 (DF)
10:04:42.53 B > A: F 51:51(0) ack 7 win 8754 (DF)
10:04:42.56 A > B: FP 7:7(0) ack 52 win 4096 (DF)
10:04:42.58 B > A: . ack 8 win 8754 (DF)
10:04:38.68 A > B: S 1031850376:1031850376(0) win 4096 <mss 1460,wscale 0,eol> (DF) 10:04:38.71 B > A: S 596916473:596916473(0) ack 1031850377 win 8760 <mss 1460> (DF) 10:04:38.73 A > B: . ack 1 win 4096 (DF) 10:04:41.98 A > B: P 1:4(3) ack 1 win 4096 (DF) 10:04:42.15 B > A: . ack 4 win 8757 (DF) 10:04:42.23 A > B: P 4:7(3) ack 1 win 4096 (DF) 10:04:42.25 B > A: P 1:11(10) ack 7 win 8754 (DF) 10:04:42.32 A > B: . ack 11 win 4096 (DF) 10:04:42.33 B > A: P 11:51(40) ack 7 win 8754 (DF) 10:04:42.51 A > B: . ack 51 win 4096 (DF) 10:04:42.53 B > A: F 51:51(0) ack 7 win 8754 (DF) 10:04:42.56 A > B: FP 7:7(0) ack 52 win 4096 (DF) 10:04:42.58 B > A: . ack 8 win 8754 (DF)
Machine B in the trace above does not send out a FIN notification
promptly if there is any data outstanding. It instead waits for
all unacknowledged data to be acknowledged before sending the FIN
segment. The connection was closed at 10:04.42.33 after
requesting 40 bytes to be sent. However, the FIN notification
isn't sent until 10:04.42.51, after the (delayed) acknowledgement
of the 40 bytes of data.
Machine B in the trace above does not send out a FIN notification promptly if there is any data outstanding. It instead waits for all unacknowledged data to be acknowledged before sending the FIN segment. The connection was closed at 10:04.42.33 after requesting 40 bytes to be sent. However, the FIN notification isn't sent until 10:04.42.51, after the (delayed) acknowledgement of the 40 bytes of data.
Paxson, et. al. Informational [Page 46] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 46] RFC 2525 TCP Implementation Problems March 1999
Trace file demonstrating correct behavior
Made using tcpdump (no losses reported by the packet filter).
Trace file demonstrating correct behavior Made using tcpdump (no losses reported by the packet filter).
10:27:53.85 C > D: S 419744533:419744533(0) win 4096
<mss 1460,wscale 0,eol> (DF)
10:27:53.92 D > C: S 10082297:10082297(0) ack 419744534
win 8760 <mss 1460> (DF)
10:27:53.95 C > D: . ack 1 win 4096 (DF)
10:27:54.42 C > D: P 1:4(3) ack 1 win 4096 (DF)
10:27:54.62 D > C: . ack 4 win 8757 (DF)
10:27:54.76 C > D: P 4:7(3) ack 1 win 4096 (DF)
10:27:54.89 D > C: P 1:11(10) ack 7 win 8754 (DF)
10:27:54.90 D > C: FP 11:51(40) ack7 win 8754 (DF)
10:27:54.92 C > D: . ack 52 win 4096 (DF)
10:27:55.01 C > D: FP 7:7(0) ack 52 win 4096 (DF)
10:27:55.09 D > C: . ack 8 win 8754 (DF)
10:27:53.85 C > D: S 419744533:419744533(0) win 4096 <mss 1460,wscale 0,eol> (DF) 10:27:53.92 D > C: S 10082297:10082297(0) ack 419744534 win 8760 <mss 1460> (DF) 10:27:53.95 C > D: . ack 1 win 4096 (DF) 10:27:54.42 C > D: P 1:4(3) ack 1 win 4096 (DF) 10:27:54.62 D > C: . ack 4 win 8757 (DF) 10:27:54.76 C > D: P 4:7(3) ack 1 win 4096 (DF) 10:27:54.89 D > C: P 1:11(10) ack 7 win 8754 (DF) 10:27:54.90 D > C: FP 11:51(40) ack7 win 8754 (DF) 10:27:54.92 C > D: . ack 52 win 4096 (DF) 10:27:55.01 C > D: FP 7:7(0) ack 52 win 4096 (DF) 10:27:55.09 D > C: . ack 8 win 8754 (DF)
Here, Machine D sends a FIN with 40 bytes of data even before the
original 10 octets have been acknowledged. This is correct
behavior as it provides for the highest performance.
Here, Machine D sends a FIN with 40 bytes of data even before the original 10 octets have been acknowledged. This is correct behavior as it provides for the highest performance.
References
This problem is documented in [Dawson97].
References This problem is documented in [Dawson97].
How to detect
For implementations manifesting this problem, it shows up on a
packet trace.
How to detect For implementations manifesting this problem, it shows up on a packet trace.
2.16.
2.16.
Name of Problem
Failure to send a RST after Half Duplex Close
Name of Problem Failure to send a RST after Half Duplex Close
Classification
Resource management
Classification Resource management
Description
RFC 1122 4.2.2.13 states that a TCP SHOULD send a RST if data is
received after "half duplex close", i.e. if it cannot be delivered
to the application. A TCP that fails to do so is said to exhibit
"Failure to send a RST after Half Duplex Close".
Description RFC 1122 4.2.2.13 states that a TCP SHOULD send a RST if data is received after "half duplex close", i.e. if it cannot be delivered to the application. A TCP that fails to do so is said to exhibit "Failure to send a RST after Half Duplex Close".
Significance
Potentially serious for TCP endpoints that manage large numbers of
connections, due to exhaustion of memory and/or process slots
available for managing connection state.
Significance Potentially serious for TCP endpoints that manage large numbers of connections, due to exhaustion of memory and/or process slots available for managing connection state.
Paxson, et. al. Informational [Page 47] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 47] RFC 2525 TCP Implementation Problems March 1999
Implications
Failure to send the RST can lead to permanently hung TCP
connections. This problem has been demonstrated when HTTP clients
abort connections, common when users move on to a new page before
the current page has finished downloading. The HTTP client closes
by transmitting a FIN while the server is transmitting images,
text, etc. The server TCP receives the FIN, but its application
does not close the connection until all data has been queued for
transmission. Since the server will not transmit a FIN until all
the preceding data has been transmitted, deadlock results if the
client TCP does not consume the pending data or tear down the
connection: the window decreases to zero, since the client cannot
pass the data to the application, and the server sends probe
segments. The client acknowledges the probe segments with a zero
window. As mandated in RFC1122 4.2.2.17, the probe segments are
transmitted forever. Server connection state remains in
CLOSE_WAIT, and eventually server processes are exhausted.
Implications Failure to send the RST can lead to permanently hung TCP connections. This problem has been demonstrated when HTTP clients abort connections, common when users move on to a new page before the current page has finished downloading. The HTTP client closes by transmitting a FIN while the server is transmitting images, text, etc. The server TCP receives the FIN, but its application does not close the connection until all data has been queued for transmission. Since the server will not transmit a FIN until all the preceding data has been transmitted, deadlock results if the client TCP does not consume the pending data or tear down the connection: the window decreases to zero, since the client cannot pass the data to the application, and the server sends probe segments. The client acknowledges the probe segments with a zero window. As mandated in RFC1122 4.2.2.17, the probe segments are transmitted forever. Server connection state remains in CLOSE_WAIT, and eventually server processes are exhausted.
Note that there are two bugs. First, probe segments should be
ignored if the window can never subsequently increase. Second, a
RST should be sent when data is received after half duplex close.
Fixing the first bug, but not the second, results in the probe
segments eventually timing out the connection, but the server
remains in CLOSE_WAIT for a significant and unnecessary period.
Note that there are two bugs. First, probe segments should be ignored if the window can never subsequently increase. Second, a RST should be sent when data is received after half duplex close. Fixing the first bug, but not the second, results in the probe segments eventually timing out the connection, but the server remains in CLOSE_WAIT for a significant and unnecessary period.
Relevant RFCs
RFC 1122 sections 4.2.2.13 and 4.2.2.17.
Relevant RFCs RFC 1122 sections 4.2.2.13 and 4.2.2.17.
Trace file demonstrating it
Made using an unknown network analyzer. No drop information
available.
Trace file demonstrating it Made using an unknown network analyzer. No drop information available.
client.1391 > server.8080: S 0:1(0) ack: 0 win: 2000 <mss: 5b4> server.8080 > client.1391: SA 8c01:8c02(0) ack: 1 win: 8000 <mss:100> client.1391 > server.8080: PA client.1391 > server.8080: PA 1:1c2(1c1) ack: 8c02 win: 2000 server.8080 > client.1391: [DF] PA 8c02:8cde(dc) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 8cde:9292(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9292:9846(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9846:9dfa(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A 9dfa:a3ae(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a3ae:a962(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a962:af16(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A af16:b4ca(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000
client.1391 > server.8080: S 0:1(0) ack: 0 win: 2000 <mss: 5b4> server.8080 > client.1391: SA 8c01:8c02(0) ack: 1 win: 8000 <mss:100> client.1391 > server.8080: PA client.1391 > server.8080: PA 1:1c2(1c1) ack: 8c02 win: 2000 server.8080 > client.1391: [DF] PA 8c02:8cde(dc) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 8cde:9292(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9292:9846(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9846:9dfa(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A 9dfa:a3ae(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a3ae:a962(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a962:af16(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A af16:b4ca(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000
Paxson, et. al. Informational [Page 48] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 48] RFC 2525 TCP Implementation Problems March 1999
client.1391 > server.8080: PA server.8080 > client.1391: [DF] A ba7e:bdfa(37c) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c2 win: 8000 client.1391 > server.8080: PA
client.1391 > server.8080: PA server.8080 > client.1391: [DF] A ba7e:bdfa(37c) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c2 win: 8000 client.1391 > server.8080: PA
[ HTTP client aborts and enters FIN_WAIT_1 ]
[ HTTP client aborts and enters FIN_WAIT_1 ]
client.1391 > server.8080: FPA
client.1391 > server.8080: FPA
[ server ACKs the FIN and enters CLOSE_WAIT ]
[ server ACKs the FIN and enters CLOSE_WAIT ]
server.8080 > client.1391: [DF] A
server.8080 > client.1391: [DF] A
[ client enters FIN_WAIT_2 ]
[ client enters FIN_WAIT_2 ]
server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000
server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000
[ server continues to try to send its data ]
[ server continues to try to send its data ]
client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 >
client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 >
[ ... repeat ad exhaustium ... ]
[ ... repeat ad exhaustium ... ]
Trace file demonstrating correct behavior
Made using an unknown network analyzer. No drop information
available.
Trace file demonstrating correct behavior Made using an unknown network analyzer. No drop information available.
client > server D=80 S=59500 Syn Seq=337 Len=0 Win=8760 server > client D=59500 S=80 Syn Ack=338 Seq=80153 Len=0 Win=8760 client > server D=80 S=59500 Ack=80154 Seq=338 Len=0 Win=8760
client > server D=80 S=59500 Syn Seq=337 Len=0 Win=8760 server > client D=59500 S=80 Syn Ack=338 Seq=80153 Len=0 Win=8760 client > server D=80 S=59500 Ack=80154 Seq=338 Len=0 Win=8760
[ ... normal data omitted ... ]
[ ... normal data omitted ... ]
client > server D=80 S=59500 Ack=14559 Seq=596 Len=0 Win=8760 server > client D=59500 S=80 Ack=596 Seq=114559 Len=1460 Win=8760
client > server D=80 S=59500 Ack=14559 Seq=596 Len=0 Win=8760 server > client D=59500 S=80 Ack=596 Seq=114559 Len=1460 Win=8760
[ client closes connection ]
[ client closes connection ]
client > server D=80 S=59500 Fin Seq=596 Len=0 Win=8760
client > server D=80 S=59500 Fin Seq=596 Len=0 Win=8760
Paxson, et. al. Informational [Page 49] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 49] RFC 2525 TCP Implementation Problems March 1999
server > client D=59500 S=80 Ack=597 Seq=116019 Len=1460 Win=8760
server > client D=59500 S=80 Ack=597 Seq=116019 Len=1460 Win=8760
[ client sends RST (RFC1122 4.2.2.13) ]
[ client sends RST (RFC1122 4.2.2.13) ]
client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=117479 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=118939 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=120399 Len=892 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=121291 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0
client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=117479 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=118939 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=120399 Len=892 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=121291 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0
"client" sends a number of RSTs, one in response to each incoming
packet from "server". One might wonder why "server" keeps sending
data packets after it has received a RST from "client"; the
explanation is that "server" had already transmitted all five of
the data packets before receiving the first RST from "client", so
it is too late to avoid transmitting them.
"client" sends a number of RSTs, one in response to each incoming packet from "server". One might wonder why "server" keeps sending data packets after it has received a RST from "client"; the explanation is that "server" had already transmitted all five of the data packets before receiving the first RST from "client", so it is too late to avoid transmitting them.
How to detect
The problem can be detected by inspecting packet traces of a
large, interrupted bulk transfer.
How to detect The problem can be detected by inspecting packet traces of a large, interrupted bulk transfer.
2.17.
2.17.
Name of Problem
Failure to RST on close with data pending
Name of Problem Failure to RST on close with data pending
Classification
Resource management
Classification Resource management
Description
When an application closes a connection in such a way that it can
no longer read any received data, the TCP SHOULD, per section
4.2.2.13 of RFC 1122, send a RST if there is any unread received
data, or if any new data is received. A TCP that fails to do so
exhibits "Failure to RST on close with data pending".
Description When an application closes a connection in such a way that it can no longer read any received data, the TCP SHOULD, per section 4.2.2.13 of RFC 1122, send a RST if there is any unread received data, or if any new data is received. A TCP that fails to do so exhibits "Failure to RST on close with data pending".
Note that, for some TCPs, this situation can be caused by an
application "crashing" while a peer is sending data.
Note that, for some TCPs, this situation can be caused by an application "crashing" while a peer is sending data.
We have observed a number of TCPs that exhibit this problem. The
problem is less serious if any subsequent data sent to the now-
closed connection endpoint elicits a RST (see illustration below).
We have observed a number of TCPs that exhibit this problem. The problem is less serious if any subsequent data sent to the now- closed connection endpoint elicits a RST (see illustration below).
Paxson, et. al. Informational [Page 50] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 50] RFC 2525 TCP Implementation Problems March 1999
Significance
This problem is most significant for endpoints that engage in
large numbers of connections, as their ability to do so will be
curtailed as they leak away resources.
Significance This problem is most significant for endpoints that engage in large numbers of connections, as their ability to do so will be curtailed as they leak away resources.
Implications
Failure to reset the connection can lead to permanently hung
connections, in which the remote endpoint takes no further action
to tear down the connection because it is waiting on the local TCP
to first take some action. This is particularly the case if the
local TCP also allows the advertised window to go to zero, and
fails to tear down the connection when the remote TCP engages in
"persist" probes (see example below).
Implications Failure to reset the connection can lead to permanently hung connections, in which the remote endpoint takes no further action to tear down the connection because it is waiting on the local TCP to first take some action. This is particularly the case if the local TCP also allows the advertised window to go to zero, and fails to tear down the connection when the remote TCP engages in "persist" probes (see example below).
Relevant RFCs
RFC 1122 section 4.2.2.13. Also, 4.2.2.17 for the zero-window
probing discussion below.
Relevant RFCs RFC 1122 section 4.2.2.13. Also, 4.2.2.17 for the zero-window probing discussion below.
Trace file demonstrating it
Made using tcpdump. No drop information available.
Trace file demonstrating it Made using tcpdump. No drop information available.
13:11:46.04 A > B: S 458659166:458659166(0) win 4096
<mss 1460,wscale 0,eol> (DF)
13:11:46.04 B > A: S 792320000:792320000(0) ack 458659167
win 4096
13:11:46.04 A > B: . ack 1 win 4096 (DF)
13:11.55.80 A > B: . 1:513(512) ack 1 win 4096 (DF)
13:11.55.80 A > B: . 513:1025(512) ack 1 win 4096 (DF)
13:11:55.83 B > A: . ack 1025 win 3072
13:11.55.84 A > B: . 1025:1537(512) ack 1 win 4096 (DF)
13:11.55.84 A > B: . 1537:2049(512) ack 1 win 4096 (DF)
13:11.55.85 A > B: . 2049:2561(512) ack 1 win 4096 (DF)
13:11:56.03 B > A: . ack 2561 win 1536
13:11.56.05 A > B: . 2561:3073(512) ack 1 win 4096 (DF)
13:11.56.06 A > B: . 3073:3585(512) ack 1 win 4096 (DF)
13:11.56.06 A > B: . 3585:4097(512) ack 1 win 4096 (DF)
13:11:56.23 B > A: . ack 4097 win 0
13:11:58.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF)
13:11:58.16 B > A: . ack 4097 win 0
13:12:00.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF)
13:12:00.16 B > A: . ack 4097 win 0
13:12:02.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF)
13:12:02.16 B > A: . ack 4097 win 0
13:12:05.37 A > B: . 4096:4097(1) ack 1 win 4096 (DF)
13:12:05.37 B > A: . ack 4097 win 0
13:12:06.36 B > A: F 1:1(0) ack 4097 win 0
13:12:06.37 A > B: . ack 2 win 4096 (DF)
13:12:11.78 A > B: . 4096:4097(1) ack 2 win 4096 (DF)
13:11:46.04 A > B: S 458659166:458659166(0) win 4096 <mss 1460,wscale 0,eol> (DF) 13:11:46.04 B > A: S 792320000:792320000(0) ack 458659167 win 4096 13:11:46.04 A > B: . ack 1 win 4096 (DF) 13:11.55.80 A > B: . 1:513(512) ack 1 win 4096 (DF) 13:11.55.80 A > B: . 513:1025(512) ack 1 win 4096 (DF) 13:11:55.83 B > A: . ack 1025 win 3072 13:11.55.84 A > B: . 1025:1537(512) ack 1 win 4096 (DF) 13:11.55.84 A > B: . 1537:2049(512) ack 1 win 4096 (DF) 13:11.55.85 A > B: . 2049:2561(512) ack 1 win 4096 (DF) 13:11:56.03 B > A: . ack 2561 win 1536 13:11.56.05 A > B: . 2561:3073(512) ack 1 win 4096 (DF) 13:11.56.06 A > B: . 3073:3585(512) ack 1 win 4096 (DF) 13:11.56.06 A > B: . 3585:4097(512) ack 1 win 4096 (DF) 13:11:56.23 B > A: . ack 4097 win 0 13:11:58.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:11:58.16 B > A: . ack 4097 win 0 13:12:00.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:00.16 B > A: . ack 4097 win 0 13:12:02.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:02.16 B > A: . ack 4097 win 0 13:12:05.37 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:05.37 B > A: . ack 4097 win 0 13:12:06.36 B > A: F 1:1(0) ack 4097 win 0 13:12:06.37 A > B: . ack 2 win 4096 (DF) 13:12:11.78 A > B: . 4096:4097(1) ack 2 win 4096 (DF)
Paxson, et. al. Informational [Page 51] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 51] RFC 2525 TCP Implementation Problems March 1999
13:12:11.78 B > A: . ack 4097 win 0 13:12:24.59 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:24.60 B > A: . ack 4097 win 0 13:12:50.22 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:50.22 B > A: . ack 4097 win 0
13:12:11.78 B > A: . ack 4097 win 0 13:12:24.59 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:24.60 B > A: . ack 4097 win 0 13:12:50.22 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:50.22 B > A: . ack 4097 win 0
Machine B in the trace above does not drop received data when the
socket is "closed" by the application (in this case, the
application process was terminated). This occurred at
approximately 13:12:06.36 and resulted in the FIN being sent in
response to the close. However, because there is no longer an
application to deliver the data to, the TCP should have instead
sent a RST.
Machine B in the trace above does not drop received data when the socket is "closed" by the application (in this case, the application process was terminated). This occurred at approximately 13:12:06.36 and resulted in the FIN being sent in response to the close. However, because there is no longer an application to deliver the data to, the TCP should have instead sent a RST.
Note: Machine A's zero-window probing is also broken. It is
resending old data, rather than new data. Section 3.7 in RFC 793
and Section 4.2.2.17 in RFC 1122 discuss zero-window probing.
Note: Machine A's zero-window probing is also broken. It is resending old data, rather than new data. Section 3.7 in RFC 793 and Section 4.2.2.17 in RFC 1122 discuss zero-window probing.
Trace file demonstrating better behavior
Made using tcpdump. No drop information available.
Trace file demonstrating better behavior Made using tcpdump. No drop information available.
Better, but still not fully correct, behavior, per the discussion
below. We show this behavior because it has been observed for a
number of different TCP implementations.
Better, but still not fully correct, behavior, per the discussion below. We show this behavior because it has been observed for a number of different TCP implementations.
13:48:29.24 C > D: S 73445554:73445554(0) win 4096
<mss 1460,wscale 0,eol> (DF)
13:48:29.24 D > C: S 36050296:36050296(0) ack 73445555
win 4096 <mss 1460,wscale 0,eol> (DF)
13:48:29.25 C > D: . ack 1 win 4096 (DF)
13:48:30.78 C > D: . 1:1461(1460) ack 1 win 4096 (DF)
13:48:30.79 C > D: . 1461:2921(1460) ack 1 win 4096 (DF)
13:48:30.80 D > C: . ack 2921 win 1176 (DF)
13:48:32.75 C > D: . 2921:4097(1176) ack 1 win 4096 (DF)
13:48:32.82 D > C: . ack 4097 win 0 (DF)
13:48:34.76 C > D: . 4096:4097(1) ack 1 win 4096 (DF)
13:48:34.84 D > C: . ack 4097 win 0 (DF)
13:48:36.34 D > C: FP 1:1(0) ack 4097 win 4096 (DF)
13:48:36.34 C > D: . 4097:5557(1460) ack 2 win 4096 (DF)
13:48:36.34 D > C: R 36050298:36050298(0) win 24576
13:48:36.34 C > D: . 5557:7017(1460) ack 2 win 4096 (DF)
13:48:36.34 D > C: R 36050298:36050298(0) win 24576
13:48:29.24 C > D: S 73445554:73445554(0) win 4096 <mss 1460,wscale 0,eol> (DF) 13:48:29.24 D > C: S 36050296:36050296(0) ack 73445555 win 4096 <mss 1460,wscale 0,eol> (DF) 13:48:29.25 C > D: . ack 1 win 4096 (DF) 13:48:30.78 C > D: . 1:1461(1460) ack 1 win 4096 (DF) 13:48:30.79 C > D: . 1461:2921(1460) ack 1 win 4096 (DF) 13:48:30.80 D > C: . ack 2921 win 1176 (DF) 13:48:32.75 C > D: . 2921:4097(1176) ack 1 win 4096 (DF) 13:48:32.82 D > C: . ack 4097 win 0 (DF) 13:48:34.76 C > D: . 4096:4097(1) ack 1 win 4096 (DF) 13:48:34.84 D > C: . ack 4097 win 0 (DF) 13:48:36.34 D > C: FP 1:1(0) ack 4097 win 4096 (DF) 13:48:36.34 C > D: . 4097:5557(1460) ack 2 win 4096 (DF) 13:48:36.34 D > C: R 36050298:36050298(0) win 24576 13:48:36.34 C > D: . 5557:7017(1460) ack 2 win 4096 (DF) 13:48:36.34 D > C: R 36050298:36050298(0) win 24576
In this trace, the application process is terminated on Machine D
at approximately 13:48:36.34. Its TCP sends the FIN with the
window opened again (since it discarded the previously received
data). Machine C promptly sends more data, causing Machine D to
In this trace, the application process is terminated on Machine D at approximately 13:48:36.34. Its TCP sends the FIN with the window opened again (since it discarded the previously received data). Machine C promptly sends more data, causing Machine D to
Paxson, et. al. Informational [Page 52] RFC 2525 TCP Implementation Problems March 1999
Paxson, et. al. Informational [Page 52] RFC 2525 TCP Implementation Problems March 1999
reset the connection since it cannot deliver the data to the
application. Ideally, Machine D SHOULD send a RST instead of
dropping the data and re-opening the receive window.
reset the connection since it cannot deliver the data to the application. Ideally, Machine D SHOULD send a RST instead of dropping the data and re-opening the receive window.
Note: Machine C's zero-window probing is broken, the same as in
the example above.
以下に注意してください。 調べが例と壊れていて、同じであるCの無の窓を機械加工してください。
Trace file demonstrating correct behavior
Made using tcpdump. No losses reported by the packet filter.
tcpdumpを使用することで正しい振舞いMadeのデモをして、ファイルをたどってください。 損失は全くパケットフィルタで報告しませんでした。
14:12:02.19 E > F: S 1143360000:1143360000(0) win 4096
14:12:02.19 F > E: S 1002988443:1002988443(0) ack 1143360001
win 4096 <mss 1460> (DF)
14:12:02.19 E > F: . ack 1 win 4096
14:12:10.43 E > F: . 1:513(512) ack 1 win 4096
14:12:10.61 F > E: . ack 513 win 3584 (DF)
14:12:10.61 E > F: . 513:1025(512) ack 1 win 4096
14:12:10.61 E > F: . 1025:1537(512) ack 1 win 4096
14:12:10.81 F > E: . ack 1537 win 2560 (DF)
14:12:10.81 E > F: . 1537:2049(512) ack 1 win 4096
14:12:10.81 E > F: . 2049:2561(512) ack 1 win 4096
14:12:10.81 E > F: . 2561:3073(512) ack 1 win 4096
14:12:11.01 F > E: . ack 3073 win 1024 (DF)
14:12:11.01 E > F: . 3073:3585(512) ack 1 win 4096
14:12:11.01 E > F: . 3585:4097(512) ack 1 win 4096
14:12:11.21 F > E: . ack 4097 win 0 (DF)
14:12:15.88 E > F: . 4097:4098(1) ack 1 win 4096
14:12:16.06 F > E: . ack 4097 win 0 (DF)
14:12:20.88 E > F: . 4097:4098(1) ack 1 win 4096
14:12:20.91 F > E: . ack 4097 win 0 (DF)
14:12:21.94 F > E: R 1002988444:1002988444(0) win 4096
14:12:02.19Eの>F: S1143360000: 1143360000(0)勝利4096 14:12:02.19F>E: S1002988443: 1002988443(0) ack1143360001はmss1460>(DF)14:12:02.19Eの>Fに4096<に勝ちます: . ack1は4096 14:12:10.43Eの>Fを獲得します: . 1: 513(512) ack1は4096 14:12:10.61F>Eを獲得します: . ack513は3584(DF)14:12:10.61E>Fを獲得します: . 513: 1025(512) ack1は4096 14:12:10.61Eの>Fを獲得します: . 1025: 1537(512) ack1は4096 14:12:10.81F>Eを獲得します: . ack1537は2560(DF)14:12:10.81E>Fを獲得します: . 1537: 2049(512) ack1は4096 14:12:10.81Eの>Fを獲得します: . 2049: 2561(512) ack1は4096 14:12:10.81Eの>Fを獲得します: . 2561: 3073(512) ack1は4096 14:12:11.01F>Eを獲得します: . ack3073は1024(DF)14:12:11.01E>Fを獲得します: . 3073: 3585(512) ack1は4096 14:12:11.01Eの>Fを獲得します: . 3585: 4097(512) ack1は4096 14:12:11.21F>Eを獲得します: . ack4097は0(DF)14:12:15.88E>Fを獲得します: . 4097: 4098(1) ack1は4096 14:12:16.06F>Eを獲得します: . ack4097は0(DF)14:12:20.88E>Fを獲得します: . 4097: 4098(1) ack1は4096 14:12:20.91F>Eを獲得します: . ack4097は0(DF)14:12:21.94F>Eを獲得します: R1002988444: 1002988444(0)勝利4096
When the application terminates at 14:12:21.94, F immediately
sends a RST.
アプリケーションが14:12:21.94に終わると、Fはすぐに、RSTを送ります。
Note: Machine E's zero-window probing is (finally) correct.
以下に注意してください。 マシンEの無の窓の調べは(最終的に)正しいです。
How to detect
The problem can often be detected by inspecting packet traces of a
transfer in which the receiving application terminates abnormally.
When doing so, there can be an ambiguity (if only looking at the
trace) as to whether the receiving TCP did indeed have unread data
that it could now no longer deliver. To provoke this to happen,
it may help to suspend the receiving application so that it fails
to consume any data, eventually exhausting the advertised window.
At this point, since the advertised window is zero, we know that
受信アプリケーションが異常に終わる転送のパケット跡を点検することによって、どう問題を検出するかをしばしば検出できます。 そうするとき、本当に、受信TCPにはそれが現在もう送ることができない読まれていないデータがあったかどうかに関してあいまいさ(跡を見るだけであるなら)があることができます。これが起こることを引き起こすために、少しのデータも消費しないように受信アプリケーションを中断させるのを助けるかもしれません、結局広告を出している窓を消耗させて。 ここに、私たちは、広告を出している窓がゼロであるのでそれを知っています。
Paxson, et. al. Informational [Page 53] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[53ページ]情報のRFC2525TCP実現問題行進
the receiving TCP has undelivered data buffered up. Terminating
the application process then should suffice to test the
correctness of the TCP's behavior.
受信TCPはバッファリングされた「非-渡」されたデータを上がるようにします。 その時アプリケーション・プロセスを終えるのは、TCPの振舞いの正当性をテストするために十分であるべきです。
2.18.
2.18.
Name of Problem
Options missing from TCP MSS calculation
TCP MSS計算によってなくなったProblem Optionsという名前
Classification
Reliability / performance
分類Reliability/性能
Description
When a TCP determines how much data to send per packet, it
calculates a segment size based on the MTU of the path. It must
then subtract from that MTU the size of the IP and TCP headers in
the packet. If IP options and TCP options are not taken into
account correctly in this calculation, the resulting segment size
may be too large. TCPs that do so are said to exhibit "Options
missing from TCP MSS calculation".
パケット単位で送るTCPがどのくらいのデータを決定する記述When、それは経路のMTUに基づくセグメントサイズについて計算します。 それは引かなければならなくて、次に、パケットでそのIPのサイズのMTUとTCPヘッダーから引いてください。 IPオプションとTCPオプションがこの計算で正しく考慮に入れられないなら、結果として起こるセグメントサイズは大き過ぎるかもしれません。 そうするTCPsは「TCP MSS計算によってなくなったオプション」を示すと言われています。
Significance
In some implementations, this causes the transmission of strangely
fragmented packets. In some implementations with Path MTU (PMTU)
discovery [RFC1191], this problem can actually result in a total
failure to transmit any data at all, regardless of the environment
(see below).
意味In、いくつかの実現であり、これは奇妙に断片化しているパケットのトランスミッションを引き起こします。 Path MTU(PMTU)発見[RFC1191]によるいくつかの実現では、この問題は実際に全くどんなデータも送る大失敗をもたらすことができます、環境にかかわらず(以下を見てください)。
Arguably, especially since the wide deployment of firewalls, IP
options appear only rarely in normal operations.
論証上、特にファイアウォールの広い展開以来、IPオプションは通常操作にめったにだけ現れません。
Implications
In implementations using PMTU discovery, this problem can result
in packets that are too large for the output interface, and that
have the DF (don't fragment) bit set in the IP header. Thus, the
IP layer on the local machine is not allowed to fragment the
packet to send it out the interface. It instead informs the TCP
layer of the correct MTU size of the interface; the TCP layer
again miscomputes the MSS by failing to take into account the size
of IP options; and the problem repeats, with no data flowing.
この問題は出力インタフェースには大き過ぎ、IPヘッダーにDF(断片化しない)ビットを設定するパケットをもたらして、含意In実現はPMTU発見を使用できます。 したがって、地方のマシンの上のIP層は、インタフェースからそれを送るためにパケットを断片化できません。 それは代わりにインタフェースの適度のMTUサイズのTCP層を知らせます。 TCP層は再びIPオプションのサイズを考慮に入れないことによって、MSSをmiscomputesします。 そして、データが流れないで、問題は繰り返されます。
Relevant RFCs
RFC 1122 describes the calculation of the effective send MSS. RFC
1191 describes Path MTU discovery.
関連RFCs RFC1122は計算について説明します。有効では、MSSを送ってください。 RFC1191はPath MTU発見について説明します。
Paxson, et. al. Informational [Page 54] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[54ページ]情報のRFC2525TCP実現問題行進
Trace file demonstrating it
Trace file taking using tcpdump on host C. The first trace
demonstrates the fragmentation that occurs without path MTU
discovery:
ホストC.の上でtcpdumpを使用して、Traceファイル魅力的な状態でそれを示すファイルをたどってください。最初の跡は経路MTU探索なしで起こる断片化を示します:
13:55:25.488728 A.65528 > C.discard:
P 567833:569273(1440) ack 1 win 17520
<nop,nop,timestamp 3839 1026342>
(frag 20828:1472@0+)
(ttl 62, optlen=8 LSRR{B#} NOP)
13:55:25.488728A.65528>C.は捨てられます: (1440)ack1はnop、nop、タイムスタンプ3839 1026342>を17520<に獲得します。P、567833:569273、(20828を破片手榴弾で殺傷してください:、 1472@0 +)(ttl62、optlen=8 LSRR B#NOP)
13:55:25.488943 A > C:
(frag 20828:8@1472)
(ttl 62, optlen=8 LSRR{B#} NOP)
13:55: 25.488943 >C: (20828を破片手榴弾で殺傷してください:、 8@1472 ) (ttl62、optlen=8 LSRR B#NOP)
13:55:25.489052 C.discard > A.65528:
. ack 566385 win 60816
<nop,nop,timestamp 1026345 3839> (DF)
(ttl 60, id 41266)
13:55:25.489052C.は>A.65528を捨てます: . ack566385は60816<nop、nop、タイムスタンプ1026345 3839>(DF)を獲得します。(ttl60、イド41266)
Host A repeatedly sends 1440-octet data segments, but these hare
fragmented into two packets, one with 1432 octets of data, and
another with 8 octets of data.
ホストAは繰り返して1440八重奏のデータ・セグメント、2つのパケットに断片化されたこれらの野兎だけ、データの1432の八重奏がある1、およびデータの8つの八重奏がある別のものを送ります。
The second trace demonstrates the failure to send any data
segments, sometimes seen with hosts doing path MTU discovery:
2番目の跡はホストが経路MTU探索をしていて時々見られた少しのデータ・セグメントも送らないことを示します:
13:55:44.332219 A.65527 > C.discard:
S 1018235390:1018235390(0) win 16384
<mss 1460,nop,wscale 0,nop,nop,timestamp 3876 0> (DF)
(ttl 62, id 20912, optlen=8 LSRR{B#} NOP)
13:55:44.332219A.65527>C.は捨てられます: S1018235390: 1018235390(0)勝利16384<mss1460、nop、wscale0、nop、nop、タイムスタンプ3876 0>(DF)(ttl62、イド20912、optlen=8 LSRR B#NOP)
13:55:44.333015 C.discard > A.65527:
S 1271629000:1271629000(0) ack 1018235391 win 60816
<mss 1460,nop,wscale 0,nop,nop,timestamp 1026383 3876> (DF)
(ttl 60, id 41427)
13:55:44.333015C.は>A.65527を捨てます: S1271629000: 1271629000(0) ack1018235391は60816<mss1460、nop、wscale0、nop、nop、タイムスタンプ1026383 3876>(DF)を獲得します。(ttl60、イド41427)
13:55:44.333206 C.discard > A.65527:
S 1271629000:1271629000(0) ack 1018235391 win 60816
<mss 1460,nop,wscale 0,nop,nop,timestamp 1026383 3876> (DF)
(ttl 60, id 41427)
13:55:44.333206C.は>A.65527を捨てます: S1271629000: 1271629000(0) ack1018235391は60816<mss1460、nop、wscale0、nop、nop、タイムスタンプ1026383 3876>(DF)を獲得します。(ttl60、イド41427)
This is all of the activity seen on this connection. Eventually
host C will time out attempting to establish the connection.
この接続に見られて、これは活動のすべてです。 結局、ホストCは接続を確立するのを試みるタイムアウトがそうするでしょう。
How to detect
The "netcat" utility [Hobbit96] is useful for generating source
routed packets:
どう、"netcat"ユーティリティ[Hobbit96]を検出するかはソースの発送されたパケットを発生させることの役に立ちます:
Paxson, et. al. Informational [Page 55] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[55ページ]情報のRFC2525TCP実現問題行進
1% nc C discard
(interactive typing)
^C
2% nc C discard < /dev/zero
^C
3% nc -g B C discard
(interactive typing)
^C
4% nc -g B C discard < /dev/zero
^C
1%のnc C破棄(対話的なタイプ)^C2%が3%の</dev/zero^C nc-g B C破棄(対話的なタイプ)^C4%がncするC破棄をncする、-g B Cは</dev/zero^Cを捨てます。
Lines 1 through 3 should generate appropriate packets, which can
be verified using tcpdump. If the problem is present, line 4
should generate one of the two kinds of packet traces shown.
線1〜3は適切なパケットを発生させるはずです。(tcpdumpを使用することでパケットについて確かめることができます)。 問題が存在しているなら、線4は示されたパケット跡の2種類の1つを発生させるはずです。
How to fix
The implementation should ensure that the effective send MSS
calculation includes a term for the IP and TCP options, as
mandated by RFC 1122.
実現を修理するのが、有効が計算をMSSに送るのをどう確実にするべきであるかがIPとTCPオプションのための用語を含んでいます、RFC1122によって強制されるように。
3. Security Considerations
3. セキュリティ問題
This memo does not discuss any specific security-related TCP implementation problems, as the working group decided to pursue documenting those in a separate document. Some of the implementation problems discussed here, however, can be used for denial-of-service attacks. Those classified as congestion control present opportunities to subvert TCPs used for legitimate data transfer into excessively loading network elements. Those classified as "performance", "reliability" and "resource management" may be exploitable for launching surreptitious denial-of-service attacks against the user of the TCP. Both of these types of attacks can be extremely difficult to detect because in most respects they look identical to legitimate network traffic.
このメモは、別々のドキュメントにそれらを記録しながら、ワーキンググループとしての問題が追求すると決めたどんな特定のセキュリティ関連のTCP実現についても議論しません。 サービス不能攻撃にしかしながら、ここで議論した実現問題のいくつかを使用できます。 ものは輻輳制御として正統のデータ転送に使用されるTCPsを打倒する現在の機会を過度にロードしているネットワーク要素に分類しました。 TCPのユーザに対して秘密のサービス不能攻撃に着手するのに、「性能」、「信頼性」、および「資源管理」として分類されたものは利用可能であるかもしれません。 これらのタイプの攻撃の両方は、検出するのが、ほとんどの点で、正統のネットワークトラフィックと同じに見えるので、非常に難しい場合があります。
4. Acknowledgements
4. 承認
Thanks to numerous correspondents on the tcp-impl mailing list for their input: Steve Alexander, Larry Backman, Jerry Chu, Alan Cox, Kevin Fall, Richard Fox, Jim Gettys, Rick Jones, Allison Mankin, Neal McBurnett, Perry Metzger, der Mouse, Thomas Narten, Andras Olah, Steve Parker, Francesco Potorti`, Luigi Rizzo, Allyn Romanow, Al Smith, Jerry Toporek, Joe Touch, and Curtis Villamizar.
彼らの入力のためのtcp-implメーリングリストで多数の通信員をありがとうございます: 'スティーブ・アレクサンダー、ラリー・バックマン、ジェリー・チュウ、アランはコックスを務めます、ケビンFall、リチャードフォックス、ジムGettys、リック・ジョーンズ、アリソン・マンキン、ニールMcBurnett、Perryメッツガー、derマウス、トーマスNarten、Andrasオラー、スティーブ・パーカー、フランチェスコPotorti'、ルーイジ・リゾー、アリンRomanow、アル・スミス、ジェリーToporek、ジョーTouch、およびカーティスVillamizar。
Thanks also to Josh Cohen for the traces documenting the "Failure to send a RST after Half Duplex Close" problem; and to John Polstra, who analyzed the "Window probe deadlock" problem.
また、「Half Duplex Closeの後にRSTを送らないこと」問題を記録する跡へのジョッシュ・コーエンをありがとうございます。 そして、ジョンPolstraに、だれが「窓の徹底的調査行き詰まり」問題を分析しましたか?
Paxson, et. al. Informational [Page 56] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[56ページ]情報のRFC2525TCP実現問題行進
5. References
5. 参照
[Allman97] M. Allman, "Fixing Two BSD TCP Bugs," Technical Report
CR-204151, NASA Lewis Research Center, Oct. 1997.
http://roland.grc.nasa.gov/~mallman/papers/bug.ps
[Allman97]M.オールマン、「BSD TCPが悩ます修理Two」、技術報告書CR-204151、NASAルイス・リサーチセンター、1997年10月の http://roland.grc.nasa.gov/~mallman/papers/bug.ps
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing
TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC2414、1998年9月。
[RFC1122] Braden, R., Editor, "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月。
[Brakmo95] L. Brakmo and L. Peterson, "Performance Problems in
BSD4.4 TCP," ACM Computer Communication Review,
25(5):69-86, 1995.
[Brakmo95] L.BrakmoとL.ピーターソン、「BSD4.4 TCPのパフォーマンス問題」、ACMコンピュータコミュニケーションレビュー、25(5): 69-86、1995。
[RFC813] Clark, D., "Window and Acknowledgement Strategy in TCP,"
RFC 813, July 1982.
[RFC813] クラークと、D.と、「TCPの窓と承認戦略」、RFC813、7月1982日
[Dawson97] S. Dawson, F. Jahanian, and T. Mitton, "Experiments on
Six Commercial TCP Implementations Using a Software
Fault Injection Tool," to appear in Software Practice &
Experience, 1997. A technical report version of this
paper can be obtained at
ftp://rtcl.eecs.umich.edu/outgoing/sdawson/CSE-TR-298-
96.ps.gz.
[Dawson97]S.ドーソン(F.Jahanian、およびT.ミットン)は、Software Practice&Experience、1997に現れるように「ソフトウェア欠点注射ツールを使用することで6つの商業TCP実現を実験します」。 ftp://rtcl.eecs.umich.edu/outgoing/sdawson/CSE-TR-298- 96.ps.gzでこの紙の技術報告書バージョンを得ることができます。
[Fall96] K. Fall and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP," ACM Computer Communication
Review, 26(3):5-21, 1996.
[Fall96] K.秋とS.フロイド、「タホ、リノ、および袋のTCPのシミュレーションベースの比較」、ACMコンピュータコミュニケーションレビュー、26(3): 5-21、1996。
[Hobbit96] Hobbit, Avian Research, netcat, available via anonymous
ftp to ftp.avian.org, 1996.
[Hobbit96] ホビット、Avian Research、ftp.avian.org、1996へのアノニマスFTPを通して利用可能なnetcat。
[Hoe96] J. Hoe, "Improving the Start-up Behavior of a Congestion
Control Scheme for TCP," Proc. SIGCOMM '96.
[Hoe96] J. Proc、「TCPの輻輳制御計画の始動の振舞いを改良し」て、鍬を入れてください。 SIGCOMM96年。
[Jacobson88] V. Jacobson, "Congestion Avoidance and Control," Proc.
SIGCOMM '88. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
ジェーコブソンと、「輻輳回避とコントロール」に対する[Jacobson88]、Proc。 SIGCOMM88年 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump,
available via anonymous ftp to ftp.ee.lbl.gov, Jun.
1989.
[Jacobson89] ftp.ee.lbl.gov、1989年6月までのアノニマスFTPを通して利用可能なV.ジェーコブソン、C.LeresとS.McCanne、tcpdump。
Paxson, et. al. Informational [Page 57] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[57ページ]情報のRFC2525TCP実現問題行進
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October
1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984.
[RFC896] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
[Paxson97] V. Paxson, "Automated Packet Trace Analysis of TCP
Implementations," Proc. SIGCOMM '97, available from
ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Z.
[Paxson97]V.パクソン、「TCP実現の自動化されたパケット微量成分分析」、Proc。 ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Z から空いているSIGCOMM97年。
[RFC793] Postel, J., Editor, "Transmission Control Protocol," STD
7, RFC 793, September 1981.
[RFC793] ポステル、J.、エディタ、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[RFC2001] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
[Stevens94] W. Stevens, "TCP/IP Illustrated, Volume 1", Addison-
Wesley Publishing Company, Reading, Massachusetts, 1994.
[Stevens94]W.スティーブンス、「TCP/IPはマサチューセッツ、ボリューム1インチ、アディソンウエスリー出版社が読む1994を例証しました」。
[Wright95] G. Wright and W. Stevens, "TCP/IP Illustrated, Volume
2", Addison-Wesley Publishing Company, Reading
Massachusetts, 1995.
[Wright95] G.ライトとW.スティーブンス、「マサチューセッツ、1995を読んで、TCP/IPはアディソン-ウエスリー出版社をボリューム2インチ例証しました」。
6. Authors' Addresses
6. 作者のアドレス
Vern Paxson ACIRI / ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
通りSuite600バークレー、バーンパクソンACIRI / ICSI1947センターカリフォルニア94704-1198
Phone: +1 510/642-4274 x302 EMail: vern@aciri.org
以下に電話をしてください。 +1 510/642-4274x302 EMail: vern@aciri.org
Paxson, et. al. Informational [Page 58] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[58ページ]情報のRFC2525TCP実現問題行進
Mark Allman <mallman@grc.nasa.gov> NASA Glenn Research Center/Sterling Software Lewis Field 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 USA
Allman <mallman@grc.nasa.gov をマークしてください、gt;、おお、NASAグレンリサーチセンタ/英貨のソフトウェアルイス分野21000Brookpark道路MS54-2 44135クリーブランド(米国)
Phone: +1 216/433-6586 Email: mallman@grc.nasa.gov
以下に電話をしてください。 +1 216/433-6586 メールしてください: mallman@grc.nasa.gov
Scott Dawson Real-Time Computing Laboratory EECS Building University of Michigan Ann Arbor, MI 48109-2122 USA
スコット・ドーソンReal-TimeのEECSビルミシガン大学コンピューティング研究所MI48109-2122アナーバー(米国)
Phone: +1 313/763-5363 EMail: sdawson@eecs.umich.edu
以下に電話をしてください。 +1 313/763-5363 メールしてください: sdawson@eecs.umich.edu
William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 USA
ウィリアムC.フェナーゼロックスPARC3333コヨーテヒル・Roadカリフォルニア94304パロアルト(米国)
Phone: +1 650/812-4816 EMail: fenner@parc.xerox.com
以下に電話をしてください。 +1 650/812-4816 メールしてください: fenner@parc.xerox.com
Jim Griner <jgriner@grc.nasa.gov> NASA Glenn Research Center Lewis Field 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 USA
ジム Griner <jgriner@grc.nasa.gov 、gt;、おお、NASAグレンリサーチセンタルイス分野21000Brookpark道路MS54-2 44135クリーブランド(米国)
Phone: +1 216/433-5787 EMail: jgriner@grc.nasa.gov
以下に電話をしてください。 +1 216/433-5787 メールしてください: jgriner@grc.nasa.gov
Paxson, et. al. Informational [Page 59] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[59ページ]情報のRFC2525TCP実現問題行進
Ian Heavens Spider Software Ltd. 8 John's Place, Leith Edinburgh EH6 7EL UK
クモのソフトウェア株式会社8のジョンのところ、イアンHeavensリースエディンバラEH6 7ELイギリス
Phone: +44 131/475-7015 EMail: ian@spider.com
以下に電話をしてください。 +44 131/475-7015 メールしてください: ian@spider.com
Kevin Lahey NASA Ames Research Center/MRJ MS 258-6 Moffett Field, CA 94035 USA
ケビンレーヒー米航空宇宙局エイムズ研究所/MRJ MS258-6モフェット分野、カリフォルニア94035米国
Phone: +1 650/604-4334 EMail: kml@nas.nasa.gov
以下に電話をしてください。 +1 650/604-4334 メールしてください: kml@nas.nasa.gov
Jeff Semke Pittsburgh Supercomputing Center 4400 Fifth Ave Pittsburgh, PA 15213 USA
ジェフ・Semkeピッツバーグスーパーコンピューティングセンター4400黙秘権Ave PA15213ピッツバーグ(米国)
Phone: +1 412/268-4960 EMail: semke@psc.edu
以下に電話をしてください。 +1 412/268-4960 メールしてください: semke@psc.edu
Bernie Volz Process Software Corporation 959 Concord Street Framingham, MA 01701 USA
バーニーフォルツ過程ソフトウェア社959の一致通りMA01701フレイミングハム(米国)
Phone: +1 508/879-6994 EMail: volz@process.com
以下に電話をしてください。 +1 508/879-6994 メールしてください: volz@process.com
Paxson, et. al. Informational [Page 60] RFC 2525 TCP Implementation Problems March 1999
etパクソン、アル。 1999年の[60ページ]情報のRFC2525TCP実現問題行進
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Paxson, et. al. Informational [Page 61]
etパクソン、アル。 情報[61ページ]
一覧
スポンサーリンク
