⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2525.txt

📁 中、英文RFC文档大全打包下载完全版 .
💻 TXT
📖 第 1 页 / 共 5 页
字号:
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 + -