📄 rfc889.txt
字号:
D.L. Millscolumn indicates the efficiency, computed as the ratio of the total timeaccumulated while sending good data to this time plus the lost-packet andrtx-packet time. Complete sets of runs were made for each of the hosts in the table belowfor each of several selections of algorithm parameters. The table itselfreflects values, selected as described later, believed to be a good compromisefor use on existing paths in the Internet system.Internet Delay Experiments Page 8D.L. MillsHost Total Lost Packets RTX Packets Mean CoV EffID Time Time Time -------------------------------------------------------------------DCN1 to nearby local-net hosts (calibration)DCN5 5 0 0 0 0 11 .15 1DCN8 8 0 0 0 0 16 .13 1IMP17 19 0 0 0 0 38 .33 1FORD1 86 0 0 1 .2 167 .33 .99UMD1 135 0 0 2 .5 263 .45 .99DCN6 177 0 0 0 0 347 .34 1FACC 368 196 222.1 6 9.2 267 1.1 .37FOE 670 3 7.5 21 73.3 1150 .69 .87FOE-1 374 0 0 26 61.9 610 .75 .83FOE-2 1016 3 16.7 10 47.2 1859 .41 .93DCN1 to ARPANET hosts and local netsMILARP 59 0 0 2 .5 115 .39 .99ISID 163 0 0 1 1.8 316 .47 .98ISID-1 84 0 0 2 1 163 .18 .98ISID-2 281 0 0 3 17 516 .91 .93ISID * 329 0 0 5 12.9 619 .81 .96SCORE 208 0 0 1 .8 405 .46 .99RVAX 256 1 1.3 0 0 499 .42 .99AJAX 365 0 0 0 0 713 .44 1WASH 494 0 0 2 2.8 960 .39 .99WASH-1 271 0 0 5 8 514 .34 .97WASH-2 749 1 9.8 2 17.5 1411 .4 .96BERK 528 20 50.1 4 35 865 1.13 .83DCN1 to MILNET/MINET hosts and local netsISIA 436 4 7.4 2 15.7 807 .68 .94ISIA-1 197 0 0 0 0 385 .27 1ISIA-2 615 0 0 2 15 1172 .36 .97ISIA * 595 18 54.1 6 33.3 992 .77 .85BRL 644 1 3 1 1.9 1249 .43 .99BRL-1 318 0 0 4 13.6 596 .68 .95BRL-2 962 2 8.4 0 0 1864 .12 .99LON 677 0 0 3 11.7 1300 .51 .98LON-1 302 0 0 0 0 589 .06 1LON-2 1047 0 0 0 0 2044 .03 1HAWAII 709 4 12.9 3 18.5 1325 .55 .95OFFICE3 856 3 12.9 3 10.3 1627 .54 .97OFF3-1 432 2 4.2 2 6.9 823 .31 .97OFF3-2 1277 7 39 3 41.5 2336 .44 .93KOREA 1048 3 14.5 2 18.7 1982 .48 .96KOREA-1 506 4 8.6 1 2.2 967 .18 .97KOREA-2 1493 6 35.5 2 19.3 2810 .19 .96DCN1 to TELENET hosts via ARPANETRICE 677 2 6.8 3 12.1 1286 .41 .97Internet Delay Experiments Page 9D.L. MillsRICE-1 368 1 .1 3 2.3 715 .11 .99RICE-2 1002 1 4.4 1 9.5 1930 .19 .98DCN1 to SATNET hosts and local nets via ARPANETUCL 689 9 26.8 0 0 1294 .21 .96UCL-1 623 39 92.8 2 5.3 1025 .32 .84UCL-2 818 4 13.5 0 0 1571 .15 .98NTA 779 12 38.7 1 3.7 1438 .24 .94NTA-1 616 24 56.6 2 5.3 1083 .25 .89NTA-2 971 19 71.1 0 0 1757 .2 .92NTA to SATNET hosts and local netsTANUM 110 3 1.6 0 0 213 .41 .98GOONY 587 19 44.2 1 2.9 1056 .23 .91ETAM 608 32 76.3 1 3.1 1032 .29 .86UCL 612 5 12.6 2 8.5 1154 .24 .96Note: * indicates randomly distributed packets during periods of high ARPANETactivity. The same entry without the * indicates randomly distributed packetsduring periods of low ARPANET activity.Internet Delay Experiments Page 10D.L. Mills3.2 Discussion of Results It is immediately obvious from visual inspection of the bit-map displaythat the delay distribution is more-or-less Poissonly distributed about arelatively narrow range with important exceptions. The exceptions arecharacterized by occasional spasms where one or more packets can be delayedmany times the typical value. Such glitches have been commonly noted beforeon paths involving ARPANET and SATNET, but the true impact of their occuranceon the timeout algorithm is much greater than I expected. What commonlyhappens is that the algorithm, when confronted with a short burst oflong-delay packets after a relatively long interval of well-mannered behavior,takes much too long to adapt to the spasm, thus inviting many superfluousretransmissions and leading to congestion. The incidence of long-delay bursts, or glitches, varied widely during theexperiments. Some of them were glitch-free, but most had at least one glitchin 512 echo/reply volleys. Glitches did not seem to correlate well withincreases in baseline delay, which occurs as the result of traffic surges, nordid they correlate well with instances of packet loss. I did not notice anyparticular periodicity, such as might be expected with regular pinging, forexample; however, I did not process the data specially for that. There was no correction for packet length used in any of theseexperiments, in spite of the results of the first set of experiments describedpreviously. This may be done in a future set of experiments. The algorithmdoes cope well in the case of constant-length packets and in the case ofrandomly distributed packet lengths between 40 and 256 octets, as indicated inthe table. Future experiments may involve bursts of short packets followed bybursts of longer ones, so that the speed of adaptation of the algorithm can bedirectly deterimend. One particularily interesting experiment involved the FOE host(FORD-FOE), which is located in London and reached via a 14.4-Kbps underseacable and statistical multiplexor. The multiplexor introduces a moderate meandelay, but with an extremely large delay dispersion. The specifiedretransmission-timeout algorithm had a hard time with this circuit, as mightbe expected; however, with the improvments described below, TCP performancewas acceptable. It is unlikely that many instances of such ornery circuitswill occur in the Internet system, but it is comforting to know that thealgorithm can deal effectively with them.3.3. Improvments to the Algorithm The specified retransmission-timeout algorithm, really a first-orderlinear recursive filter, is characterized by two parameters, a weightingfactor F and a threshold factor G. For each measured delay sample R the delayestimator E is updated: E = F*E + (1 - F)*R .Internet Delay Experiments Page 11D.L. MillsThen, if an interval equal to G*E expires after transmitting a packet, thepacket is retransmitted. The current TCP specification suggests values in therange 0.8 to 0.9 for F and 1.5 to 2.0 for G. These values have been believedreasonable up to now over ARPANET and SATNET paths. I found that a simple change to the algorithm made a worthwhile change inthe efficiency. The change amounts to using two values of F, one (F1) when R< E in the expression above and the other (F2) when R >= E, with F1 > F2. Theeffect is to make the algorithm more responsive to upward-going trends indelay and less respnsive to downward-going trends. After a number of trials Iconcluded that values of F1 = 15/16 and F2 = 3/4 (with G = 2) gave the bestall-around performance. The results on some paths (FOE, ISID, ISIA) werebetter by some ten percent in efficiency, as compared to the values now usedin typical implementations where F = 7/8 and G = 2. The results on most pathswere better by five percent, while on a couple (FACC, UCL) the results wereworse by a few percent. There was no clear-cut gain in fiddling with G. The value G = 2 seemedto represent the best overall compromise. Note that increasing G makessuperfluous retransmissions less likely, but increases the total delay whenpackets are lost. Also, note that increasing F2 too much tends to causeovershoot in the case of network glitches and leads to the same result. Thetable above was constructed using F1 = 15/16, F2 = 3/4 and G = 2. Readers familiar with signal-detection theory will recognize mysuggestion as analogous to an ordinary peak-detector circuit. F1 representsthe discharge time-constant, while F2 represents the charge time-constant. Grepresents a "squelch" threshold, as used in voice-operated switches, forexample. Some wag may be even go on to suggest a network glitch should becalled a netspurt.Internet Delay Experiments Page 12D.L. MillsAppendix. Index of Test HostsName Address NIC Host Name-------------------------------------DCN1 to nearby local-net hosts (calibration)DCN5 128.4.0.5 DCN5DCN8 128.4.0.8 DCN8IMP17 10.3.0.17 DCN-GATEWAYFORD1 128.5.0.1 FORD1UMD1 128.8.0.1 UMD1DCN6 128.4.0.6 DCN6FACC 128.5.32.1 FORD-WDL1FOE 128.5.0.15 FORD-FOEDCN1 to ARPANET hosts and local netsMILARP 10.2.0.28 ARPA-MILNET-GWISID 10.0.0.27 USC-ISIDSCORE 10.3.0.11 SU-SCORERVAX 128.10.0.2 PURDUE-MORDREDAJAX 18.10.0.64 MIT-AJAXWASH 10.0.0.91 WASHINGTONBERK 10.2.0.78 UCB-VAXDCN1 to MILNET/MINET hosts and local netsISIA 26.3.0.103 USC-ISIABRL 192.5.21.6 BRL-VGRLON 24.0.0.7 MINET-LON-EMHAWAII 26.1.0.36 HAWAII-EMHOFFICE3 26.2.0.43 OFFICE-3KOREA 26.0.0.117 KOREA-EMHDCN1 to TELENET hosts via ARPANETRICE 14.0.0.12 RICEDCN1 to SATNET hosts and local nets via ARPANETUCL 128.16.9.0 UCL-SAMNTA 128.39.0.2 NTARE1NTA to SATNET hosts and local netsTANUM 4.0.0.64 TANUM-ECHOGOONY 4.0.0.63 GOONHILLY-ECHOETAM 4.0.0.62 ETAM-ECHO
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -