📄 rfc2525.txt
字号:
Paxson, et. al. Informational [Page 17]RFC 2525 TCP Implementation Problems March 1999 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. 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. 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. 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. 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. 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.Paxson, et. al. Informational [Page 18]RFC 2525 TCP Implementation Problems March 1999 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.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.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)Paxson, et. al. Informational [Page 19]RFC 2525 TCP Implementation Problems March 1999 11:42:07.722918 A > B: . 2641726:2646038(4312) 11:42:07.769248 B > A: . ack 2512366 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. 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. 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. 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. 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). 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)Paxson, et. al. Informational [Page 20]RFC 2525 TCP Implementation Problems March 1999 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.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 5384407Paxson, et. al. Informational [Page 21]RFC 2525 TCP Implementation Problems March 1999 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) **** "***" 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. 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. 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].Paxson, et. al. Informational [Page 22]RFC 2525 TCP Implementation Problems March 1999 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. 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). 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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -