rfc1263.txt

中、英文RFC文档大全打包下载完全版 .

   usefully flow control algorithm. Second, it lacks the necessary
   semantics to reliably tear down connections. The lack of a tear down
   mechanism needs to be solved, but the flow control problem could be
   dealt with in later iterations of the protocol as Internet blast
   protocols are not yet well understood; for now, we could simple limit
   the size of each message to 16k or 32k bytes. This might also be a
   good place to use a decomposed version of Sprite RPC [2], which
   exposes each of these features as separate protocols. This would
   permit the quick change of algorithms, and once the protocol had
   stabilized, a monolithic version could be constructed and distributed
   to replace the decomposed version.

   In other words, the basic strategy is to introduce as simple of RPC
   protocol as possible today, and later evolve this protocol to address
   the known limitations.


3.3.  Future Modifications

   The header prediction algorithm should be generalized so as to be
   less sensitive to changes in the protocols header and algorithm.
   There almost seems to be as much effort to make all modifications to
   TCP backward compatible with header prediction as there is to make
   them backward compatible with TCP.  The question that needs to be
   answered is: are there any changes we can made to TCP to make header
   prediction easier, including the addition of information into the
   header.  In [6], the authors showed how one might generalize
   optimistic blast from VMTP to almost any protocol that performs
   fragmentation and reassembly.  Generalizing header prediction so that
   it scales with TCP modification would be step in the right direction.

   It is clear that an evolutionary change to increase the size of the
   source and destination ports in the TCP header will eventually be
   necessary.  We also believe that TCP could be made significantly
   simpler and more flexible through the elimination of the pseudo-
   header. The solution to this problem is to simply add a length field
   and the IP address of the destination to the TCP header. It has also



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


   been mentioned that better and simpler TCP connection establishment
   algorithms would be useful.  Some form of reliable record stream
   protocol should be developed.  Performing sliding window and flow
   control over records rather than bytes would provide numerous
   opportunities for optimizations and allow TCP to return to its
   original purpose as a byte-stream protocol. Finally, it has become
   clear to us that the current Internet congestion control strategy is
   to use TCP for everything since it is the only protocol that supports
   congestion control. One of the primary reasons many "new protocols"
   are proposed as TCP options is that it is the only way to get at
   TCP's congestion control. At some point, a TCP-independent congestion
   control scheme must be implemented and one might then be able to
   remove the existing congestion control from TCP and radically
   simplify the protocol.


4.  Discussion

   One obvious side effect of the changes we propose is to increase the
   size of the TCP header. In some sense, this is inevitable; just about
   every field in the header has been pushed to its limit by the radical
   growth of the network. However, we have made very little effort to
   make the minimal changes to solve the current problem. In fact, we
   have tended to sacrifice header size in order to defer future changes
   as long as possible. The problem with this is that one of TCP's
   claims to fame is its efficiency at sending small one byte packets
   over slow networks. Increasing the size of the TCP header will
   inevitably result in some increase in overhead on small packets on
   slow networks. Clark among others have stated that they see no
   fundamental performance limitations that would prevent TCP from
   supporting very high speed networks. This is true as far as it goes;
   there seems to be a direct trade-off between TCP performance on high
   speed networks and TCP performance on slow speed networks. The
   dynamic range is simply too great to be optimally supported by one
   protocol. Hence, in keeping around the old version of TCP we have
   effectively split TCP into two protocols, one for high bandwidth
   lines and the other for low bandwidth lines.

   Another potential argument is that all of the changes mentioned above
   should be packaged together as a new version of TCP. This version
   could be standardized and we could all go back to the status quo of
   stable unchanging protocols.  While to a certain extent this is
   inevitable---there is a backlog of necessary TCP changes because of
   the current logistical problems in modifying protocols---it is only
   begs the question. The status quo is simply unacceptably static;
   there will always be future changes to TCP.  Evolutionary change will
   also result in a better and more reliable TCP.  Making small changes
   and distributing them at regular intervals ensures that one change



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


   has actually been stabilized before the next has been made.  It also
   presents a more balanced workload to the protocol designer; rather
   than designing one new protocol every 10 years he makes annual
   protocol extensions. It will also eventually make protocol
   distribution easier: the basic problem with protocol distribution now
   is that it is done so rarely that no one knows how to do it and there
   is no incentive to develop the infrastructure needed to perform the
   task efficiently.  While the first protocol distribution is almost
   guaranteed to be a disaster, the problem will get easier with each
   additional one. Finally, such a new TCP would have the same problems
   as VMTP did; a radically new protocol presents a bigger target.

   The violation of backward compatibility in systems as complex as the
   Internet is always a serious step. However, backward compatibility is
   a technique, not a religion. Two facts are often overlooked when
   backward compatibility gets out of hand. First, violating backward
   compatibility is always a big win when you can get away with it.  One
   of the key advantages of RISC chips over CISC chips is simply that
   they were not backward compatible with anything. Thus, they were not
   bound by design decisions made when compilers were stupid and real
   men programmed in assembler. Second, one is going to have to break
   backward compatibility at some point anyway. Every system has some
   headroom limitations which result in either stagnation (IBM mainframe
   software) or even worse, accidental violations of backward
   compatibility.

   Of course, the biggest problem with our approach is that it is not
   compatible with the existing standardization process. We hope to be
   able to design and distribute protocols in less time than it takes a
   standards committee to agree on an acceptable meeting time.  This is
   inevitable because the basic problem with networking is the
   standardization process. Over the last several years, there has been
   a push in the research community for lightweight protocols, when in
   fact what is needed are lightweight standards.  Also note that we
   have not proposed to implement some entirely new set of "superior"
   communications protocols, we have simply proposed a system for making
   necessary changes to the existing protocol suites fast enough to keep
   up with the underlying change in the network.  In fact, the first
   standards organization that realizes that the primary impediment to
   standardization is poor logistical support will probably win.


5.  Conclusions

   The most important conclusion of this RFC is that protocol change
   happens and is currently happening at a very respectable clip.  While
   all of the changes given as example in this document are from TCP,
   there are many other protocols that require modification.  In a more



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


   prosaic domain, the telephone company is running out of phone
   numbers; they are being overrun by fax machines, modems, and cars.
   The underlying cause of these problems seems to be an consistent
   exponential increase almost all network metrics: number of hosts,
   bandwidth, host performance, applications, and so on, combined with
   an attempt to run the network with a static set of unchanging network
   protocols.  This has been shown to be impossible and one can almost
   feel the pressure for protocol change building. We simply propose to
   explicitly deal with the changes rather keep trying to hold back the
   flood.

   Of almost equal importance is the observation that TCP is a protocol
   and not a platform for implementing other protocols. Because of a
   lack of any alternatives, TCP has become a de-facto platform for
   implementing other protocols. It provides a vague standard interface
   with the kernel, it runs on many machines, and has a well defined
   distribution path. Otherwise sane people have proposed Bounded Time
   TCP (an unreliable byte stream protocol), Simplex TCP (which supports
   data in only one direction) and Multi-cast TCP (too horrible to even
   consider).  All of these protocols probably have their uses, but not
   as TCP options. The fact that a large number of people are willing to
   use TCP as a protocol implementation platform points to the desperate
   need for a protocol independent platform.

   Finally, we point out that in our research we have found very little
   difference in the actual technical work involved with the three
   proposed methods of protocol modification. The amount of work
   involved in a backward compatible change is often more than that
   required for an evolutionary change or the creation of a new
   protocol.  Even the distribution costs seem to be identical.  The
   primary cost difference between the three approaches is the cost of
   getting the modification approved. A protocol modification, no matter
   how extensive or bizarre, seems to incur much less cost and risk. It
   is time to stop changing the protocols to fit our current way of
   thinking, and start changing our way of thinking to fit the
   protocols.


6.  References


[1]  Cheriton D., "VMTP: Versatile Message Transaction Protocol", RFC
     1045, Stanford University, February 1988.


[2]  Hutchinson, N., Peterson, L., Abbott, M., and S. O'Malley, "RPC in
     the x-Kernel: Evaluating New Design Techniques", Proceedings of the
     12th Symposium on Operating System Principles, Pgs. 91-101,



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


     December 1989.


[3]  Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88,
     August 1988.


[4]  Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
     RFC 1072, LBL, ISI, October 1988.


[5]  Jacobson, V., Braden, R., and L. Zhang, "TCP Extensions for High-
     Speed Paths", RFC 1185, LBL, ISI, PARC, October 1990.


[6]  O'Malley, S., Abbott, M., Hutchinson, N., and L. Peterson, "A Tran-
     sparent Blast Facility", Journal of Internetworking, Vol. 1, No.
     2, Pgs. 57-75, December 1990.


[7]  Welch, B., "The Sprite Remote Procedure Call System", UCB/CSD
     86/302, University of California at Berkeley, June 1988.

7.  Security Considerations

   Security issues are not discussed in this memo.


8.  Authors' Addresses

   Larry L. Peterson
   University of Arizona
   Department of Computer Sciences
   Tucson, AZ 85721

   Phone: [phone]
   EMail: [e-mail]


   Sean O'Malley
   University of Arizona
   Department of Computer Sciences
   Tucson, AZ 85721

   Phone: [phone]
   EMail: [e-mail]





O'Malley & Peterson                                            [Page 19]