rfc1106.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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].