GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1106

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1106.txt · Last modified: 1989/06/26 23:10 (external edit)