rfc1263.txt

RFC 的详细文档！

   versions of TCP that machine supports. If it receives a response, it
   uses that information to select a version and puts the information in
   the cache.  If no reply is forthcoming, it assumes that the other
   machine does not support VTCP and attempts to open a TCP[0]
   connection. VTCP's cache is flushed occasionally to ensure that its
   information is current.

   Note that this is only one possible way for VTCP to decide the right
   version of TCP to use. Another possibility is for VTCP to learn the
   right version for a particular host when it resolves the host's name.
   That is, version information could be stored in the Domain Name



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


   System. It is also possible that VTCP might take the performance
   characteristics of the network into consideration when selecting a
   version; TCP[0] may in fact turn out to be the correct choice for a
   low-bandwidth network.

   Third, because our proposal would lead to a more dynamically changing
   network architecture, a mechanism for distributing new versions will
   need to be developed. This is clearly the hardest requirement of the
   infrastructure, but we believe that it can be addressed in stages.
   More importantly, we believe this problem can be addressed after the
   decision has been made to go the protocol evolution route.  In the
   short term, we are considering only a single new version of TCP---
   TCP[1]. This version can be distributed in the same ad hoc way, and
   at exactly the same cost, as the backward compatible changes
   suggested in RFC's 1072 and 1185.

   In the medium term, we envision the IAB approving new versions of TCP
   every year or so. Given this scenario, a simple distribution
   mechanism can be designed based on software distribution mechanisms
   that have be developed for other environments; e.g., Unix RDIST and
   Mach SUP.  Such a mechanism need not be available on all hosts.
   Instead, hosts will be divided into two sets, those that can quickly
   be updated with new protocols and those that cannot.  High
   performance machines that can use high performance networks will need
   the most current version of TCP as soon as it is available, thus they
   have incentive to change.  Old machines which are too slow to drive a
   high capacity lines can be ignored, and probably should be ignored.

   In the long term, we envision protocols being designed on an
   application by application basis, without the need for central
   approval. In such a world, a common protocol implementation
   environment---a protocol backplane---is the right way to go.  Given
   such a backplane, protocols can be automatically installed over the
   network. While we claim to know how to build such an environment,
   such a discussion is beyond the scope of this paper.


2.5.  Remarks

   Each of these three methods has its advantages.  When used in
   combination, the result is better protocols at a lower overall cost.
   Backward compatible changes are best reserved for changes that do not
   affect the protocol's header, and do not require that the instance
   running on the other end of the connection also be changed.  Protocol
   evolution should be the primary way of dealing with header fields
   that are no longer large enough, or when one algorithm is substituted
   directly for another.  New protocols should be written to off load
   unexpected user demands on existing protocols, or better yet, to



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


   catch them before they start.

   There are also synergistic effects. First, since we know it is
   possible to evolve a newly created protocol once it has been put in
   place, the pressure to add unnecessary features should be reduced.
   Second, the ability to create new protocols removes the pressure to
   overextend a given protocol. Finally, the ability to evolve a
   protocol removes the pressure to maintain backward compatibility
   where it is really not possible.


3.  TCP Extensions: A Case Study

   This section examines the effects of using our proposed methodology
   to implement changes to TCP. We will begin by analyzing the backward
   compatible extensions defined in RFC's 1072 and 1185, and proposing a
   set of much simpler evolutionary modifications. We also analyze
   several more problematical extensions to TCP, such as Transactional
   TCP. Finally, we point our some areas of TCP which may require
   changes in the future.

   The evolutionary modification to TCP that we propose includes all of
   the functionality described in RFC's 1072 and 1185, but does not
   preserve the header format.  At the risk of being misunderstood as
   believing backward compatibility is a good idea, we also show how our
   proposed changes to TCP can be folded into a backward compatible
   implementation of TCP.  We do this as a courtesy for those readers
   that cannot accept the possibility of multiple versions of TCP.


3.1.  RFC's 1072 and 1185

   3.1.1.  Round Trip Timing

   In RFC 1072, a new ECHO option is proposed that allows each TCP
   packet to carry a timestamp in its header.  This timestamp is used to
   keep a more accurate estimate of the RTT (round trip time) used to
   decide when to re-transmit segments. In the original TCP algorithm,
   the sender manually times a small number of sends. The resulting
   algorithm was quite complex and does not produce an accurate enough
   RTT for high capacity networks. The inclusion of a timestamp in every
   header both simplifies the code needed to calculate the RTT and
   improves the accuracy and robustness of the algorithm.

   The new algorithm as proposed in RFC 1072 does not appear to have any
   serious problems. However, the authors of RFC 1072 go to great
   lengths in an attempt to keep this modification backward compatible
   with the previous version of TCP. They place an ECHO option in the



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


   SYN segment and state, "It is likely that most implementations will
   properly ignore any options in the SYN segment that they do not
   understand, so new initial options should not cause problems" [4].
   This statement does not exactly inspire confidence, and we consider
   the addition of an optional field to any protocol to be a de-facto,
   if not a de-jure, example of an evolutionary change. Optional fields
   simply attempt to hide the basic incompatibility inside the protocol,
   it does not eliminate it.  Therefore, since we are making an
   evolutionary change anyway, the only modification to the proposed
   algorithm is to move the fields into the header proper.  Thus, each
   header will contain 32-bit echo and echo reply fields. Two fields are
   needed to handle bi-directional data streams.


   3.1.2.  Window Size and Sequence Number Space

   Long Fat Networks (LFN's), networks which contain very high capacity
   lines with very high latency, introduce the possibility that the
   number of bits in transit (the bandwidth-delay product) could exceed
   the TCP window size, thus making TCP the limiting factor in network
   performance.  Worse yet, the time it takes the sequence numbers to
   wrap around could be reduced to a point below the MSL (maximum
   segment lifetime), introducing the possibility of old packets being
   mistakenly accepted as new.

   RFC 1072 extends the window size through the use of an implicit
   constant scaling factor. The window size in the TCP header is
   multiplied by this factor to get the true window size.  This
   algorithm has three problems. First, one must prove that at all times
   the implicit scaling factor used by the sender is the same as the
   receiver.  The proposed algorithm appears to do so, but the
   complexity of the algorithm creates the opportunity for poor
   implementations to affect the correctness of TCP.  Second, the use of
   a scaling factor complicates the TCP implementation in general, and
   can have serious effects on other parts of the protocol.

   A final problem is what we characterize as the "quantum window
   sizing" problem. Assuming that the scaling factors will be powers of
   two, the algorithm right shifts the receiver's window before sending
   it.  This effectively rounds the window size down to the nearest
   multiple of the scaling factor. For large scaling factors, say 64k,
   this implies that window values are all multiples of 64k and the
   minimum window size is 64k; advertising a smaller window is
   impossible. While this is not necessarily a problem (and it seems to
   be an extreme solution to the silly window syndrome) what effect this
   will have on the performance of high-speed network links is anyone's
   guess. We can imagine this extension leading to future papers
   entitled "A Quantum Mechanical Approach to Network Performance".



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


   RFC 1185 is an attempt to get around the problem of the window
   wrapping too quickly without explicitly increasing the sequence
   number space.  Instead, the RFC proposes to use the timestamp used in
   the ECHO option to weed out old duplicate messages. The algorithm
   presented in RFC 1185 is complex and has been shown to be seriously
   flawed at a recent End-to-End Research Group meeting.  Attempts are
   currently underway to fix the algorithm presented in the RFC. We
   believe that this is a serious mistake.

   We see two problems with this approach on a very fundamental level.
   First, we believe that making TCP depend on accurate clocks for
   correctness to be a mistake. The Internet community has NO experience
   with transport protocols that depend on clocks for correctness.
   Second, the proposal uses two distinct schemes to deal with old
   duplicate packets: the sliding window algorithm takes care of "new"
   old packets (packets from the current sequence number epoch) and the
   timestamp algorithm deals with "old" old packets (packets from
   previous sequence number epochs). It is hard enough getting one of
   these schemes to work much less to get two to work and ensure that
   they do not interfere with one another.

   In RFC 1185, the statement is made that "An obvious fix for the
   problem of cycling the sequence number space is to increase the size
   of the TCP sequence number field." Using protocol evolution, the
   obvious fix is also the correct one. The window size can be increased
   to 32 bits by simply changing a short to a long in the definition of
   the TCP header. At the same time, the sequence number and
   acknowledgment fields can be increased to 64 bits.  This change is
   the minimum complexity modification to get the job done and requires
   little or no analysis to be shown to work correctly.

   On machines that do not support 64-bit integers, increasing the
   sequence number size is not as trivial as increasing the window size.
   However, it is identical in cost to the modification proposed in RFC
   1185; the high order bits can be thought of as an optimal clock that
   ticks only when it has to.  Also, because we are not dealing with
   real time, the problems with unreliable system clocks is avoided.  On
   machines that support 64-bit integers, the original TCP code may be
   reused.  Since only very high performance machines can hope to drive
   a communications network at the rates this modification is designed
   to support, and the new generation of RISC microprocessors (e.g.,
   MIPS R4000 and PA-RISC) do support 64-bit integers, the assumption of
   64-bit arithmetic may be more of an advantage than a liability.








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


   3.1.3.  Selective Retransmission

   Another problem with TCP's support for LFN's is that the sliding
   window algorithm used by TCP does not support any form of selective
   acknowledgment. Thus, if a segment is lost, the total amount of data
   that must be re-transmitted is some constant times the bandwidth-
   delay product, despite the fact that most of the segments have in
   fact arrived at the receiver.  RFC 1072 proposes to extend TCP to
   allow the receiver to return partial acknowledgments to the sender in
   the hope that the sender will use that information to avoid
   unnecessary re-transmissions.

   It has been our experience on predictable local area networks that
   the performance of partial re-transmission strategies is highly non-
   obvious, and it generally requires more than one iteration to find a
   decent algorithm. It is therefore not surprising that the algorithm
   proposed in RFC 1072 has some problems.  The proposed TCP extension
   allows the receiver to include a short list of received fragments
   with every ACK.  The idea being that when the receiver sends back a
   normal ACK, it checks its queue of segments that have been received
   out of order and sends the relative sequence numbers of contiguous
   blocks of segments back to the sender. The sender then uses this
   information to re-transmit the segments transmitted but not listed in
   the ACK.