rfc1263.txt

RFC 的详细文档！

   As specified, this algorithm has two related problems: (1) it ignores
   the relative frequencies of delivered and dropped packets, and (2)
   the list provided in the option field is probably too short to do
   much good on networks with large bandwidth-delay products.  In every
   model of high bandwidth networks that we have seen, the packet loss
   rate is very low, and thus, the ratio of dropped packets to delivered
   packets is very low. An algorithm that returns ACKs as proposed is
   simply going to have to send more information than one in which the
   receiver returns NAKs.

   This problem is compounded by the short size of the TCP option field
   (44 bytes). In theory, since we are only worried about high bandwidth
   networks, returning ACKs instead of NAKs is not really a problem; the
   bandwidth is available to send any information that's needed. The
   problem comes when trying to compress the ACK information into the 44
   bytes allowed.  The proposed extensions effectively compresses the
   ACK information by allowing the receiver to ACK byte ranges rather
   than segments, and scaling the relative sequence numbers of the re-
   transmitted segments. This makes it much more difficult for the
   sender to tell which segments should be re-transmitted, and
   complicates the re-transmission code.  More importantly, one should
   never compress small amounts of data being sent over a high bandwidth
   network; it trades a scarce resource for an abundant resource.  On



O'Malley & Peterson                                            [Page 10]

RFC 1263           TCP Extensions Considered Harmful        October 1991


   low bandwidth networks, selective retransmission is not needed and
   the SACK option should be disabled.

   We propose two solutions to this problem. First, the receiver can
   examine its list of out-of-order packets and guess which segments
   have been dropped, and NAK those segments back to the sender. The
   number of NAKs should be low enough that one per TCP packet should be
   sufficient. Note that the receiver has just as much information as
   the sender about what packets should be retransmitted, and in any
   case, the NAKs are simply suggestions which have no effect on
   correctness.

   Our second proposed modification is to increase the offset field in
   the TCP header from 4 bits to 16 bits.  This allows 64k-bytes of TCP
   header, which allows us to radically simplify the selective re-
   transmission algorithm proposed in RFC 1072.  The receiver can now
   simply send a list of 64-bit sequence numbers for the out-of-order
   segments to the sender. The sender can then use this information to
   do a partial retransmission without needing an ouji board to
   translate ACKs into segments.  With the new header size, it may be
   faster for the receiver to send a large list than to attempt to
   aggregate segments into larger blocks.


   3.1.4.  Header Modifications

   The modifications proposed above drastically change the size and
   structure of the TCP header. This makes it a good time to re-think
   the structure of the proposed TCP header. The primary goal of the
   current TCP header is to save bits in the output stream. When TCP was
   developed, a high bandwidth network was 56kbps, and the key use for
   TCP was terminal I/O.  In both situations, minimal header size was
   important.  Unfortunately, while the network has drastically
   increased in performance and the usage pattern of the network is now
   vastly different, most protocol designers still consider saving a few
   bits in the header to be worth almost any price. Our basic goal is
   different: to improve performance by eliminating the need to extract
   information packed into odd length bit fields in the header.  Below
   is our first cut at such a modification.

   The protocol id field is there to make further evolutionary
   modifications to TCP easier. This field basically subsumes the
   protocol number field contained in the IP header with a version
   number.  Each distinct TCP version has a different protocol id and
   this field ensures that the right code is looking at the right
   header.  The offset field has been increased to 16 bits to support
   the larger header size required, and to simplify header processing.
   The code field has been extended to 16 bits to support more options.



O'Malley & Peterson                                            [Page 11]

RFC 1263           TCP Extensions Considered Harmful        October 1991


   The source port and destination port are unchanged. The size of both
   the sequence number and ACK fields have been increased to 64 bits.
   The open window field has been increased to 32 bits. The checksum and
   urgent data pointer fields are unchanged. The echo and echo reply
   fields are added.  The option field remains but can be much larger
   than in the old TCP.  All headers are padded out to 32 bit
   boundaries.  Note that these changes increase the minimum header size
   from 24 bytes (actually 36 bytes if the ECHO and ECHO reply options
   defined in RFC 1072 are included on every packet) to 48 bytes. The
   maximum header size has been increased to the maximum segment size.
   We do not believe that the the increased header size will have a
   measurable effect on protocol performance.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Protocol ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Offset           |              Code             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Source           |              Dest             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Seq                              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Ack                              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Window                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Checksum          |             Urgent            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Echo                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Echo Reply                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Options                                      |     Pad       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   3.1.5.  Backward Compatibility

   The most likely objection to the proposed TCP extension is that it is
   not backward compatible with the current version of TCP, and most
   importantly, TCP's header. In this section we will present three
   versions of the proposed extension with increasing degrees of
   backward compatibility. The final version will combine the same
   degree of backward compatibility found in the protocol described in



O'Malley & Peterson                                            [Page 12]

RFC 1263           TCP Extensions Considered Harmful        October 1991


   RFC's 1072/1185, with the much simpler semantics described in this
   RFC.

   We believe that the best way to preserve backward compatibility is to
   leave all of TCP alone and support the transparent use of a new
   protocol when and where it is needed. The basic scheme is the one
   described in section 2.4. Those machines and operating systems that
   need to support high speed connections should implement some general
   protocol infrastructure that allows them to rapidly evolve protocols.
   Machines that do not require such service simply keep using the
   existing version of TCP. A virtual protocol is used to manage the use
   of multiple TCP versions.

   This approach has several advantages. First, it guarantees backward
   compatibility with ALL existing TCP versions because such
   implementations will never see strange packets with new options.
   Second, it supports further modification of TCP with little
   additional costs. Finally, since our version of TCP will more closely
   resemble the existing TCP protocol than that proposed in RFC's
   1072/1185, the cost of maintaining two simple protocols will probably
   be lower than maintaining one complex protocol.  (Note that with high
   probability you still have to maintain two versions of TCP in any
   case.)  The only additional cost is the memory required for keeping
   around two copies of TCP.

   For those that insist that the only efficient way to implement TCP
   modifications is in a single monolithic protocol, or those that
   believe that the space requirements of two protocols would be too
   great, we simply migrate the virtual protocol into TCP. TCP is
   modified so that when opening a connection, the sender uses the TCP
   VERSION option attached to the SYN packet to request using the new
   version.  The receiver responds with a TCP VERSION ACK in the SYN ACK
   packet, after which point, the new header format described in Section
   3.1.4 is used. Thus, there is only one version of TCP, but that
   version supports multiple header formats. The complexity of such a
   protocol would be no worse than the protocol described in RFC
   1072/1185. It does, however, make it more difficult to make
   additional changes to TCP.

   Finally, for those that believe that the preservation of the TCP's
   header format has any intrinsic value (e.g., for those that don't
   want to re-program their ethernet monitors), a header compatible
   version of our proposal is possible.  One simply takes all of the
   additional information contained in the header given in Section 3.1.4
   and places it into a single optional field. Thus, one could define a
   new TCP option which consists of the top 32 bits of the sequence and
   ack fields, the echo and echo_reply fields, and the top 16 bits of
   the window field. This modification makes it more difficult to take



O'Malley & Peterson                                            [Page 13]

RFC 1263           TCP Extensions Considered Harmful        October 1991


   advantage of machines with 64-bit address spaces, but at a minimum
   will be just as easy to process as the protocol described in RFC
   1072/1185.  The only restriction is that the size of the header
   option field is still limited to 44 bytes, and thus, selective
   retransmission using NAKs rather than ACKs will probably be required.

   The key observation is that one should make a protocol extension
   correct and simple before trying to make it backward compatible.  As
   far as we can tell, the only advantages possessed by the protocol
   described in RFC 1072/1185 is that its typical header, size including
   options, is 8 to 10 bytes shorter. The price for this "advantage" is
   a protocol of such complexity that it may prove impossible for normal
   humans to implement. Trying to maintain backward compatibility at
   every stage of the protocol design process is a serious mistake.


3.2.  TCP Over Extension

   Another potential problem with TCP that has been discussed recently,
   but has not yet resulted in the generation of an RFC, is the
   potential for TCP to grab and hold all 2**16 port numbers on a given
   machine.  This problem is caused by short port numbers, long MSLs,
   and the misuse of TCP as a request-reply protocol. TCP must hold onto
   each port after a close until all possible messages to that port have
   died, about 240 seconds. Even worse, this time is not decreasing with
   increase network performance.  With new fast hardware, it is possible
   for an application to open a TCP connection, send data, get a reply,
   and close the connection at a rate fast enough to use up all the
   ports in less than 240 seconds. This usage pattern is generated by
   people using TCP for something it was never intended to do---
   guaranteeing at-most-once semantics for remote procedure calls.

   The proposed solution is to embed an RPC protocol into TCP while
   preserving backward compatibility. This is done by piggybacking the
   request message on the SYN packet and the reply message on the SYN-
   ACK packet. This approach suffers from one key problem: it reduces
   the probability of a correct TCP implementation to near 0. The basic
   problem has nothing to do with TCP, rather it is the lack of an
   Internet request-reply protocol that guarantees at-most-once
   semantics.

   We propose to solve this problem by the creation of a new protocol.
   This has already been attempted with VMTP, but the size and
   complexity of VMTP, coupled with the process currently required to
   standardize a new protocol doomed it from the start.  Instead of
   solving the general problem, we propose to use Sprite RPC [7], a much
   simpler protocol, as a means of off-loading inappropriate users from
   TCP.



O'Malley & Peterson                                            [Page 14]

RFC 1263           TCP Extensions Considered Harmful        October 1991


   The basic design would attempt to preserve as much of the TCP
   interface as possible in order that current TCP (mis)users could be
   switched to Sprite RPC without requiring code modification on their
   part. A virtual protocol could be used to select the correct protocol
   TCP or Sprite RPC if it exists on the other machine. A backward
   compatible modification to TCP could be made which would simply
   prevent it from grabbing all of the ports by refusing connections.
   This would encourage TCP abusers to use the new protocol.

   Sprite RPC, which is designed for a local area network, has two
   problems when extended into the Internet. First, it does not have a