diff options
Diffstat (limited to 'doc/rfc/rfc1106.txt')
| -rw-r--r-- | doc/rfc/rfc1106.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc1106.txt b/doc/rfc/rfc1106.txt new file mode 100644 index 0000000..95fb0f5 --- /dev/null +++ b/doc/rfc/rfc1106.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group R. Fox +Request for Comments: 1106 Tandem + June 1989 + + + TCP Big Window and Nak Options + +Status of this Memo + + This memo discusses two extensions to the TCP protocol to provide a + more efficient operation over a network with a high bandwidth*delay + product. The extensions described in this document have been + implemented and shown to work using resources at NASA. This memo + describes an Experimental Protocol, these extensions are not proposed + as an Internet standard, but as a starting point for further + research. Distribution of this memo is unlimited. + +Abstract + + Two extensions to the TCP protocol are described in this RFC in order + to provide a more efficient operation over a network with a high + bandwidth*delay product. The main issue that still needs to be + solved is congestion versus noise. This issue is touched on in this + memo, but further research is still needed on the applicability of + the extensions in the Internet as a whole infrastructure and not just + high bandwidth*delay product networks. Even with this outstanding + issue, this document does describe the use of these options in the + isolated satellite network environment to help facilitate more + efficient use of this special medium to help off load bulk data + transfers from links needed for interactive use. + +1. Introduction + + Recent work on TCP has shown great performance gains over a variety + of network paths [1]. However, these changes still do not work well + over network paths that have a large round trip delay (satellite with + a 600 ms round trip delay) or a very large bandwidth + (transcontinental DS3 line). These two networks exhibit a higher + bandwidth*delay product, over 10**6 bits, than the 10**5 bits that + TCP is currently limited to. This high bandwidth*delay product + refers to the amount of data that may be unacknowledged so that all + of the networks bandwidth is being utilized by TCP. This may also be + referred to as "filling the pipe" [2] so that the sender of data can + always put data onto the network and the receiver will always have + something to read, and neither end of the connection will be forced + to wait for the other end. + + After the last batch of algorithm improvements to TCP, performance + + + +Fox [Page 1] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + over high bandwidth*delay networks is still very poor. It appears + that no algorithm changes alone will make any significant + improvements over high bandwidth*delay networks, but will require an + extension to the protocol itself. This RFC discusses two possible + options to TCP for this purpose. + + The two options implemented and discussed in this RFC are: + + 1. NAKs + + This extension allows the receiver of data to inform the sender + that a packet of data was not received and needs to be resent. + This option proves to be useful over any network path (both high + and low bandwidth*delay type networks) that experiences periodic + errors such as lost packets, noisy links, or dropped packets due + to congestion. The information conveyed by this option is + advisory and if ignored, does not have any effect on TCP what so + ever. + + 2. Big Windows + + This option will give a method of expanding the current 16 bit (64 + Kbytes) TCP window to 32 bits of which 30 bits (over 1 gigabytes) + are allowed for the receive window. (The maximum window size + allowed in TCP due to the requirement of TCP to detect old data + versus new data. For a good explanation please see [2].) No + changes are required to the standard TCP header [6]. The 16 bit + field in the TCP header that is used to convey the receive window + will remain unchanged. The 32 bit receive window is achieved + through the use of an option that contains the upper half of the + window. It is this option that is necessary to fill large data + pipes such as a satellite link. + + This RFC is broken up into the following sections: section 2 will + discuss the operation of the NAK option in greater detail, section 3 + will discuss the big window option in greater detail. Section 4 will + discuss other effects of the big windows and nak feature when used + together. Included in this section will be a brief discussion on the + effects of congestion versus noise to TCP and possible options for + satellite networks. Section 5 will be a conclusion with some hints + as to what future development may be done at NASA, and then an + appendix containing some test results is included. + +2. NAK Option + + Any packet loss in a high bandwidth*delay network will have a + catastrophic effect on throughput because of the simple + acknowledgement of TCP. TCP always acks the stream of data that has + + + +Fox [Page 2] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + successfully been received and tells the sender the next byte of data + of the stream that is expected. If a packet is lost and succeeding + packets arrive the current protocol has no way of telling the sender + that it missed one packet but received following packets. TCP + currently resends all of the data over again, after a timeout or the + sender suspects a lost packet due to a duplicate ack algorithm [1], + until the receiver receives the lost packet and can then ack the lost + packet as well as succeeding packets received. On a normal low + bandwidth*delay network this effect is minimal if the timeout period + is set short enough. However, on a long delay network such as a T1 + satellite channel this is catastrophic because by the time the lost + packet can be sent and the ack returned the TCP window would have + been exhausted and both the sender and receiver would be temporarily + stalled waiting for the packet and ack to fully travel the data pipe. + This causes the pipe to become empty and requires the sender to + refill the pipe after the ack is received. This will cause a minimum + of 3*X bandwidth loss, where X is the one way delay of the medium and + may be much higher depending on the size of the timeout period and + bandwidth*delay product. Its 1X for the packet to be resent, 1X for + the ack to be received and 1X for the next packet being sent to reach + the destination. This calculation assumes that the window size is + much smaller than the pipe size (window = 1/2 data pipe or 1X), which + is the typical case with the current TCP window limitation over long + delay networks such as a T1 satellite link. + + An attempt to reduce this wasted bandwidth from 3*X was introduced in + [1] by having the sender resend a packet after it notices that a + number of consecutively received acks completely acknowledges already + acknowledged data. On a typical network this will reduce the lost + bandwidth to almost nil, since the packet will be resent before the + TCP window is exhausted and with the data pipe being much smaller + than the TCP window, the data pipe will not become empty and no + bandwidth will be lost. On a high delay network the reduction of + lost bandwidth is minimal such that lost bandwidth is still + significant. On a very noisy satellite, for instance, the lost + bandwidth is very high (see appendix for some performance figures) + and performance is very poor. + + There are two methods of informing the sender of lost data. + Selective acknowledgements and NAKS. Selective acknowledgements have + been the object of research in a number of experimental protocols + including VMTP [3], NETBLT [4], and SatFTP [5]. The idea behind + selective acks is that the receiver tells the sender which pieces it + received so that the sender can resend the data not acked but already + sent once. NAKs on the other hand, tell the sender that a particular + packet of data needs to be resent. + + There are a couple of disadvantages of selective acks. Namely, in + + + +Fox [Page 3] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + some of the protocols mentioned above, the receiver waits a certain + time before sending the selective ack so that acks may be bundled up. + This delay can cause some wasted bandwidth and requires more complex + state information than the simple nak. Even if the receiver doesn't + bundle up the selective acks but sends them as it notices that + packets have been lost, more complex state information is needed to + determine which packets have been acked and which packets need to be + resent. With naks, only the immediate data needed to move the left + edge of the window is naked, thus almost completely eliminating all + state information. + + The selective ack has one advantage over naks. If the link is very + noisy and packets are being lost close together, then the sender will + find out about all of the missing data at once and can send all of + the missing data out immediately in an attempt to move the left + window edge in the acknowledge number of the TCP header, thus keeping + the data pipe flowing. Whereas with naks, the sender will be + notified of lost packets one at a time and this will cause the sender + to process extra packets compared to selective acks. However, + empirical studies has shown that most lost packets occur far enough + apart that the advantage of selective acks over naks is rarely seen. + Also, if naks are sent out as soon as a packet has been determined + lost, then the advantage of selective acks becomes no more than + possibly a more aesthetic algorithm for handling lost data, but + offers no gains over naks as described in this paper. It is this + reason that the simplicity of naks was chosen over selective acks for + the current implementation. + +2.1 Implementation details + + When the receiver of data notices a gap between the expected sequence + number and the actual sequence number of the packet received, the + receiver can assume that the data between the two sequence numbers is + either going to arrive late or is lost forever. Since the receiver + can not distinguish between the two events a nak should be sent in + the TCP option field. Naking a packet still destined to arrive has + the effect of causing the sender to resend the packet, wasting one + packets worth of bandwidth. Since this event is fairly rare, the + lost bandwidth is insignificant as compared to that of not sending a + nak when the packet is not going to arrive. The option will take the + form as follows: + + +========+=========+=========================+================+ + +option= + length= + sequence number of + number of + + + A + 7 + first byte being naked + segments naked + + +========+=========+=========================+================+ + + This option contains the first sequence number not received and a + + + +Fox [Page 4] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + count of how many segments of bytes needed to be resent, where + segments is the size of the current TCP MSS being used for the + connection. Since a nak is an advisory piece of information, the + sending of a nak is unreliable and no means for retransmitting a nak + is provided at this time. + + When the sender of data receives the option it may either choose to + do nothing or it will resend the missing data immediately and then + continue sending data where it left off before receiving the nak. + The receiver will keep track of the last nak sent so that it will not + repeat the same nak. If it were to repeat the same nak the protocol + could get into the mode where on every reception of data the receiver + would nak the first missing data frame. Since the data pipe may be + very large by the time the first nak is read and responded to by the + sender, many naks would have been sent by the receiver. Since the + sender does not know that the naks are repetitious it will resend the + data each time, thus wasting the network bandwidth with useless + retransmissions of the same piece of data. Having an unreliable nak + may result in a nak being damaged and not being received by the + sender, and in this case, we will let the tcp recover by its normal + means. Empirical data has shown that the likelihood of the nak being + lost is quite small and thus, this advisory nak option works quite + well. + +3. Big Window Option + + Currently TCP has a 16 bit window limitation built into the protocol. + This limits the amount of outstanding unacknowledged data to 64 + Kbytes. We have already seen that some networks have a pipe larger + than 64 Kbytes. A T1 satellite channel and a cross country DS3 + network with a 30ms delay have data pipes much larger than 64 Kbytes. + Thus, even on a perfectly conditioned link with no bandwidth wasted + due to errors, the data pipe will not be filled and bandwidth will be + wasted. What is needed is the ability to send more unacknowledged + data. This is achieved by having bigger windows, bigger than the + current limitation of 16 bits. This option to expands the window + size to 30 bits or over 1 gigabytes by literally expanding the window + size mechanism currently used by TCP. The added option contains the + upper 15 bits of the window while the lower 16 bits will continue to + go where they normally go [6] in the TCP header. + + A TCP session will use the big window options only if both sides + agree to use them, otherwise the option is not used and the normal 16 + bit windows will be used. Once the 2 sides agree to use the big + windows then every packet thereafter will be expected to contain the + window option with the current upper 15 bits of the window. The + negotiation to decide whether or not to use the bigger windows takes + place during the SYN and SYN ACK segments of the TCP connection + + + +Fox [Page 5] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + startup process. The originator of the connection will include in + the SYN segment the following option: + + 1 byte 1 byte 4 bytes + +=========+==========+===============+ + +option=B + length=6 + 30 bit window + + +=========+==========+===============+ + + + If the other end of the connection wants to use big windows it will + include the same option back in the SYN ACK segment that it must + send. At this point, both sides have agreed to use big windows and + the specified windows will be used. It should be noted that the SYN + and SYN ACK segments will use the small windows, and once the big + window option has been negotiated then the bigger windows will be + used. + + Once both sides have agreed to use 32 bit windows the protocol will + function just as it did before with no difference in operation, even + in the event of lost packets. This claim holds true since the + rcv_wnd and snd_wnd variables of tcp contain the 16 bit windows until + the big window option is negotiated and then they are replaced with + the appropriate 32 bit values. Thus, the use of big windows becomes + part of the state information kept by TCP. + + Other methods of expanding the windows have been presented, including + a window multiple [2] or streaming [5], but this solution is more + elegant in the sense that it is a true extension of the window that + one day may easily become part of the protocol and not just be an + option to the protocol. + +3.1 How does it work + + Once a connection has decided to use big windows every succeeding + packet must contain the following option: + + +=========+==========+==========================+ + +option=C + length=4 + upper 15 bits of rcv_wnd + + +=========+==========+==========================+ + + With all segments sent, the sender supplies the size of its receive + window. If the connection is only using 16 bits then this option is + not supplied, otherwise the lower 16 bits of the receive window go + into the tcp header where it currently resides [6] and the upper 15 + bits of the window is put into the data portion of the option C. + When the receiver processes the packet it must first reform the + window and then process the packet as it would in the absence of the + option. + + + +Fox [Page 6] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + +3.2 Impact of changes + + In implementing the first version of the big window option there was + very little change required to the source. State information must be + added to the protocol to determine if the big window option is to be + used and all 16 bit variables that dealt with window information must + now become 32 bit quantities. A future document will describe in + more detail the changes required to the 4.3 bsd tcp source code. + Test results of the window change only are presented in the appendix. + When expanding 16 bit quantities to 32 bit quantities in the TCP + control block in the source (4.3 bsd source) may cause the structure + to become larger than the mbuf used to hold the structure. Care must + be taken to insure this doesn't occur with your system or + undetermined events may take place. + +4. Effects of Big Windows and Naks when used together + + With big windows alone, transfer times over a satellite were quite + impressive with the absence of any introduced errors. However, when + an error simulator was used to create random errors during transfers, + performance went down extremely fast. When the nak option was added + to the big window option performance in the face of errors went up + some but not to the level that was expected. This section will + discuss some issues that were overcome to produce the results given + in the appendix. + +4.1 Window Size and Nak benefits + + With out errors, the window size required to keep the data pipe full + is equal to the round trip delay * throughput desired, or the data + pipe bandwidth (called Z from now on). This and other calculations + assume that processing time of the hosts is negligible. In the event + of an error (without NAKs), the window size needs to become larger + than Z in order to keep the data pipe full while the sender is + waiting for the ack of the resent packet. If the window size is + equaled to Z and we assume that the retransmission timer is equaled + to Z, then when a packet is lost, the retransmission timer will go + off as the last piece of data in the window is sent. In this case, + the lost piece of data can be resent with no delay. The data pipe + will empty out because it will take 1/2Z worth of data to get the ack + back to the sender, an additional 1/2Z worth of data to get the data + pipe refilled with new data. This causes the required window to be + 2Z, 1Z to keep the data pipe full during normal operations and 1Z to + keep the data pipe full while waiting for a lost packet to be resent + and acked. + + If the same scenario in the last paragraph is used with the addition + of NAKs, the required window size still needs to be 2Z to avoid + + + +Fox [Page 7] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + wasting any bandwidth in the event of a dropped packet. This appears + to mean that the nak option does not provide any benefits at all. + Testing showed that the retransmission timer was larger than the data + pipe and in the event of errors became much bigger than the data + pipe, because of the retransmission backoff. Thus, the nak option + bounds the required window to 2Z such that in the event of an error + there is no lost bandwidth, even with the retransmission timer + fluctuations. The results in the appendix shows that by using naks, + bandwidth waste associated with the retransmission timer facility is + eliminated. + +4.2 Congestions vs Noise + + An issue that must be looked at when implementing both the NAKs and + big window scheme together is in the area of congestion versus lost + packets due to the medium, or noise. In the recent algorithm + enhancements [1], slow start was introduced so that whenever a data + transfer is being started on a connection or right after a dropped + packet, the effective send window would be set to a very small size + (typically would equal the MSS being used). This is done so that a + new connection would not cause congestion by immediately overloading + the network, and so that an existing connection would back off the + network if a packet was dropped due to congestion and allow the + network to clear up. If a connection using big windows loses a + packet due to the medium (a packet corrupted by an error) the last + thing that should be done is to close the send window so that the + connection can only send 1 packet and must use the slow start + algorithm to slowly work itself back up to sending full windows worth + of data. This algorithm would quickly limit the usefulness of the + big window and nak options over lossy links. + + On the other hand, if a packet was dropped due to congestion and the + sender assumes the packet was dropped because of noise the sender + will continue sending large amounts of data. This action will cause + the congestion to continue, more packets will be dropped, and that + part of the network will collapse. In this instance, the sender + would want to back off from sending at the current window limit. + Using the current slow start mechanism over a satellite builds up the + window too slowly [1]. Possibly a better solution would be for the + window to be opened 2*Rlog2(W) instead of R*log2(W) [1] (open window + by 2 packets instead of 1 for each acked packet). This will reduce + the wasted bandwidth by opening the window much quicker while giving + the network a chance to clear up. More experimentation is necessary + to find the optimal rate of opening the window, especially when large + windows are being used. + + The current recommendation for TCP is to use the slow start mechanism + in the event of any lost packet. If an application knows that it + + + +Fox [Page 8] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + will be using a satellite with a high error rate, it doesn't make + sense to force it to use the slow start mechanism for every dropped + packet. Instead, the application should be able to choose what + action should happen in the event of a lost packet. In the BSD + environment, a setsockopt call should be provided so that the + application may inform TCP to handle lost packets in a special way + for this particular connection. If the known error rate of a link is + known to be small, then by using slow start with modified rate from + above, will cause the amount of bandwidth loss to be very small in + respect to the amount of bandwidth actually utilized. In this case, + the setsockopt call should not be used. What is really needed is a + way for a host to determine if a packet or packets are being dropped + due to congestion or noise. Then, the host can choose to do the + right thing. This will require a mechanism like source quench to be + used. For this to happen more experimentation is necessary to + determine a solid definition on the use of this mechanism. Now it is + believed by some that using source quench to avoid congestion only + adds to the problem, not help suppress it. + + The TCP used to gather the results in the appendix for the big window + with nak experiment, assumed that lost packets were the result of + noise and not congestion. This assumption was used to show how to + make the current TCP work in such an environment. The actual + satellite used in the experiment (when the satellite simulator was + not used) only experienced an error rate around 10e-10. With this + error rate it is suggested that in practice when big windows are used + over the link, TCP should use the slow start mechanism for all lost + packets with the 2*Rlog2(W) rate discussed above. Under most + situations when long delay networks are being used (transcontinental + DS3 networks using fiber with very low error rates, or satellite + links with low error rates) big windows and naks should be used with + the assumption that lost packets are the result of congestion until a + better algorithm is devised [7]. + + Another problem noticed, while testing the affects of slow start over + a satellite link, was at times, the retransmission timer was set so + restrictive, that milliseconds before a naked packet's ack is + received the retransmission timer would go off due to a timed packet + within the send window. The timer was set at the round trip delay of + the network allowing no time for packet processing. If this timer + went off due to congestion then backing off is the right thing to do, + otherwise to avoid the scenario discovered by experimentation, the + transmit timer should be set a little longer so that the + retransmission timer does not go off too early. Care must be taken + to make sure the right thing is done in the implementation in + question so that a packet isn't retransmitted too soon, and blamed on + congestion when in fact, the ack is on its way. + + + + +Fox [Page 9] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + +4.3 Duplicate Acks + + Another problem found with the 4.3bsd implementation is in the area + of duplicate acks. When the sender of data receives a certain number + of acks (3 in the current Berkeley release) that acknowledge + previously acked data before, it then assumes that a packet has been + lost and will resend the one packet assumed lost, and close its send + window as if the network is congested and the slow start algorithm + mention above will be used to open the send window. This facility is + no longer needed since the sender can use the reception of a nak as + its indicator that a particular packet was dropped. If the nak + packet is lost then the retransmit timer will go off and the packet + will be retransmitted by normal means. If a senders algorithm + continues to count duplicate acks the sender will find itself + possibly receiving many duplicate acks after it has already resent + the packet due to a nak being received because of the large size of + the data pipe. By receiving all of these duplicate acks the sender + may find itself doing nothing but resending the same packet of data + unnecessarily while keeping the send window closed for absolutely no + reason. By removing this feature of the implementation a user can + expect to find a satellite connection working much better in the face + of errors and other connections should not see any performance loss, + but a slight improvement in performance if anything at all. + +5. Conclusion + + This paper has described two new options that if used will make TCP a + more efficient protocol in the face of errors and a more efficient + protocol over networks that have a high bandwidth*delay product + without decreasing performance over more common networks. If a + system that implements the options talks with one that does not, the + two systems should still be able to communicate with no problems. + This assumes that the system doesn't use the option numbers defined + in this paper in some other way or doesn't panic when faced with an + option that the machine does not implement. Currently at NASA, there + are many machines that do not implement either option and communicate + just fine with the systems that do implement them. + + The drive for implementing big windows has been the direct result of + trying to make TCP more efficient over large delay networks [2,3,4,5] + such as a T1 satellite. However, another practical use of large + windows is becoming more apparent as the local area networks being + developed are becoming faster and supporting much larger MTU's. + Hyperchannel, for instances, has been stated to be able to support 1 + Mega bit MTU's in their new line of products. With the current + implementation of TCP, efficient use of hyperchannel is not utilized + as it should because the physical mediums MTU is larger than the + maximum window of the protocol being used. By increasing the TCP + + + +Fox [Page 10] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + window size, better utilization of networks like hyperchannel will be + gained instantly because the sender can send 64 Kbyte packets (IP + limitation) but not have to operate in a stop and wait fashion. + Future work is being started to increase the IP maximum datagram size + so that even better utilization of fast local area networks will be + seen by having the TCP/IP protocols being able to send large packets + over mediums with very large MTUs. This will hopefully, eliminate + the network protocol as the bottleneck in data transfers while + workstations and workstation file system technology advances even + more so, than it already has. + + An area of concern when using the big window mechanism is the use of + machine resources. When running over a satellite and a packet is + dropped such that 2Z (where Z is the round trip delay) worth of data + is unacknowledged, both ends of the connection need to be able to + buffer the data using machine mbufs (or whatever mechanism the + machine uses), usually a valuable and scarce commodity. If the + window size is not chosen properly, some machines will crash when the + memory is all used up, or it will keep other parts of the system from + running. Thus, setting the window to some fairly large arbitrary + number is not a good idea, especially on a general purpose machine + where many users log on at any time. What is currently being + engineered at NASA is the ability for certain programs to use the + setsockopt feature or 4.3bsd asking to use big windows such that the + average user may not have access to the large windows, thus limiting + the use of big windows to applications that absolutely need them and + to protect a valuable system resource. + +6. References + + [1] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 88, + Stanford, Ca., August 1988. + + [2] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay + Paths", LBL, USC/Information Sciences Institute, RFC 1072, + October 1988. + + [3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC + 1045, Stanford University, February 1988. + + [4] Clark, D., M. Lambert, and L. Zhang, "NETBLT: A Bulk Data + Transfer Protocol", RFC 998, MIT, March 1987. + + [5] Fox, R., "Draft of Proposed Solution for High Delay Circuit File + Transfer", GE/NAS Internal Document, March 1988. + + [6] Postel, J., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, DARPA, September 1981. + + + +Fox [Page 11] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + [7] Leiner, B., "Critical Issues in High Bandwidth Networking", RFC + 1077, DARPA, November 1989. + +7. Appendix + + Both options have been implemented and tested. Contained in this + section is some performance gathered to support the use of these two + options. The satellite channel used was a 1.544 Mbit link with a + 580ms round trip delay. All values are given as units of bytes. + + + TCP with Big Windows, No Naks: + + + |---------------transfer rates----------------------| + Window Size | no error | 10e-7 error rate | 10e-6 error rate | + ----------------------------------------------------------------- + 64K | 94K | 53K | 14K | + ----------------------------------------------------------------- + 72K | 106K | 51K | 15K | + ----------------------------------------------------------------- + 80K | 115K | 42K | 14K | + ----------------------------------------------------------------- + 92K | 115K | 43K | 14K | + ----------------------------------------------------------------- + 100K | 135K | 66K | 15K | + ----------------------------------------------------------------- + 112K | 126K | 53K | 17K | + ----------------------------------------------------------------- + 124K | 154K | 45K | 14K | + ----------------------------------------------------------------- + 136K | 160K | 66K | 15K | + ----------------------------------------------------------------- + 156K | 167K | 45K | 14K | + ----------------------------------------------------------------- + Figure 1. + + + + + + + + + + + + + + + +Fox [Page 12] + +RFC 1106 TCP Big Window and Nak Options June 1989 + + + TCP with Big Windows, and Naks: + + + |---------------transfer rates----------------------| + Window Size | no error | 10e-7 error rate | 10e-6 error rate | + ----------------------------------------------------------------- + 64K | 95K | 83K | 43K | + ----------------------------------------------------------------- + 72K | 104K | 87K | 49K | + ----------------------------------------------------------------- + 80K | 117K | 96K | 62K | + ----------------------------------------------------------------- + 92K | 124K | 119K | 39K | + ----------------------------------------------------------------- + 100K | 140K | 124K | 35K | + ----------------------------------------------------------------- + 112K | 151K | 126K | 53K | + ----------------------------------------------------------------- + 124K | 160K | 140K | 36K | + ----------------------------------------------------------------- + 136K | 167K | 148K | 38K | + ----------------------------------------------------------------- + 156K | 167K | 160K | 38K | + ----------------------------------------------------------------- + Figure 2. + + With a 10e-6 error rate, many naks as well as data packets were + dropped, causing the wild swing in transfer times. Also, please note + that the machines used are SGI Iris 2500 Turbos with the 3.6 OS with + the new TCP enhancements. The performance associated with the Irises + are slower than a Sun 3/260, but due to some source code restrictions + the Iris was used. Initial results on the Sun showed slightly higher + performance and less variance. + +Author's Address + + Richard Fox + 950 Linden #208 + Sunnyvale, Cal, 94086 + + EMail: rfox@tandem.com + + + + + + + + + + +Fox [Page 13] +
\ No newline at end of file |