Network Working Group S. O’Malley Request for Comments: 1263 L. Peterson University of Arizona October 1991
TCP EXTENSIONS CONSIDERED HARMFUL
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this document is
unlimited.
Abstract
This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions propod in RFC’s 1072 and 1185
should not be pursued, and propos an alternative way to evolve the Internet protocol suite. Its purpo is to stimulate discussion in
the Internet community.
1. Introduction
The rapid growth of the size, capacity, and complexity of the
Internet has led to the need to change the existing protocol suite.
多肉怎么繁殖For example, the maximum TCP window size is no longer sufficient to
efficiently support the high capacity links currently being planned
淘宝开店心得and constructed. One is then faced with the choice of either leaving the protocol alone and accepting the fact that TCP will run no faster on high capacity links than on low capacity links, or changing TCP.
This is not an isolated incident. We have counted at least eight
other propod changes to TCP (some to be taken more riously than
others), and the question is not whether to change the protocol
suite, but what is the most cost effective way to change it.
This RFC compares the costs and benefits of three approaches to
making the changes: the creation of new protocols, backward
猪蹄黄豆汤
compatible protocol extensions, and protocol evolution. The next
ction introduces the three approaches and enumerates the
strengths and weakness of each. The following ction describes
how we believe the three approaches are best applied to the many
propod changes to TCP. Note that we have not written this RFC as an academic exerci. It is our intent to argue against acceptance of
the various TCP extensions, most notably RFC’s 1072 and 1185 [4,5],
by describing a more palatable alternative.
O’Malley & Peterson [Page 1]
2. Creation vs. Extension vs. Evolution
2.1. Protocol Creation
Protocol creation involves the design, implementation,
standardization, and distribution of an entirely new protocol. In
this context, there are two basic reasons for creating a new
protocol. The first is to replace an old protocol that is so outdated that it can no longer be effectively extended to perform its original function. The cond is to add a new protocol becau urs are
making demands upon the original protocol that were not envisioned by the designer and cannot be efficiently handled in terms of the
original protocol. For example, TCP was designed as a reliable
byte-stream protocol but is commonly ud as both a reliable record- stream protocol and a reliable
request-reply protocol due to the lack of such protocols in the Internet protocol suite. The performance
demands placed upon a byte-stream protocol in the new Internet
environment makes it difficult to extend TCP to meet the new
application demands.
The advantage of creating a new protocol is the ability to start with a clean sheet of paper when attempting to solve a complex network
problem. The designer, free from the constraints of an existing
protocol, can take maximum advantage of modern network rearch in
the basic algorithms needed to solve the problem. Even more
importantly, the implementor is free to steal from a large number of existing academic protocols that have been developed over the years. In some cas, if truly new functionality is desired, creating a new protocol is the only viable approach.
The most obvious disadvantage of this approach is the high cost of
standardizing and distributing an entirely new protocol. Second,
there is the issue of making the new protocol reliable. Since new
protocols have not undergone years of network stress testing, they
often contain bugs which require backward compatible fixes, and
hence, the designer is back where he or she started. A third
disadvantage of introducing new protocols is that they generally have new interfaces which require significant effort on the part of the
Internet community to u. This alone is often enough to kill a new
protocol.
Finally, there is a subtle problem introduced by the very freedom
provided by this approach. Specifically, being able to introduce a
new protocol often results in protocols that go far beyond the basic needs of the situation. New protocols remble Senate appropriations bills; they tend to accumulate many amendments that have nothing to
do with the original problem. A good example of this phenomena is the attempt to standardize VMTP [1] as the Internet RPC protocol. While O’Malley & Peterson [Page 2]
VMTP was a large protocol to begin with, the clor it got to
standardization the more features were added until it esntially
collapd under its own weight. As we argue below, new protocols
should initially be minimal, and then evolve as the situation
dictates.
2.2. Backward Compatible Extensions
报与桃花一处开
In a backward compatible extension, the protocol is modified in such a fashion that the new version of the protocol can transparently
inter-operate with existing versions of the protocol. This generally implies no changes to the protocol’s header. TCP slow start [3] is an example of such a change. In a slightly more relaxed version of
backward compatibility, no changes are made to the fixed part of a
protocol’s header. Instead, either some fields are added to the
variable length options field found at the end of the header, or
existing header fields are overloaded (i.e., ud for multiple
purpos). However, we can find no real advantage to this technique
over simply changing the protocol.
Backward compatible extensions are widely ud to modify protocols
becau there is no need to synchronize the distribution of the new
version of the protocol. The new version is esntially allowed to
diffu through the Internet at its own pace, and at least in theory, the Internet will continue to function as before. Thus, the explicit distribution costs are limited. Backward compatible extensions also
avoid the bureaucratic costs of standardizing a new protocol. TCP is still TCP and the approval cost of a modification to an existing
protocol is much less than that of a new protocol. Finally, the very difficulty of making such changes tends to restrict the changes to
the minimal t needed to solve the current problem. Thus, it is rare to e unneeded changes made when using this technique.
Unfortunately, this approach has veral drawbacks. First, the time
to distribute the new version of the protocol to all hosts can be
鞋的成语quite long (forever in fact). This leaves the network in a
heterogeneous state for long periods of time. If there is the
slightest incompatibly between old and new versions, chaos can
result. Thus, the implicit cost of this type of distribution can be
quite high. Second, designing a backward compatible change to a new
蒋丞选手protocol is extremely difficult, and the implementations "tend toward complexity and ugliness" [5]. The need for backward compatibility
ensures that no code can every really be eliminated from the
protocol, and since such vestigial code is rarely executed, it is
often wrong. Finally, most protocols have limits, bad upon the
design decisions of it inventors, that simply cannot be side-stepped in this fashion.
O’Malley & Peterson [Page 3]
2.3. Protocol Evolution
Protocol evolution is an approach to protocol change that attempts to escape the limits of backward compatibility without incurring all of the costs of creating new protocols. The basic idea is for the
protocol designer to take an existing protocol that requires
modification and make the desired changes without maintaining
backward compatibility. This drastically simplifies the job of the
protocol designer. For example, the limited TCP window size could be fixed by changing the definition of the window size in the header
from 16-bits to 32-bits, and re-compiling the protocol. The effect of backward compatibility would be ensured by simply keeping both the
new and old version of the protocol running until most machines u
the new version. Since the change is small and invisible to the ur interface, it is a trivial problem to dynamically lect the correct TCP version at runtime. How this is done is discusd in the next
ction.
Protocol evolution has veral advantages. First, it is by far the
simplest type of modification to make to a protocol, and hence, the
modifications can be made faster and are less likely to contain bugs. There is no need to worry about the effects of the change on all
previous versions of the protocol. Also, most of the protocol is
carried over into the new version unchanged, thus avoiding the design and debugging cost of creating an entirely new protocol. Second,
there is no artificial limit to the amount of change that can be made to a protocol, and as a conquence, its uful lifetime can be
extended indefinitely. In a ries of evolutionary steps, it is
possible to make fairly radical changes to a protocol without
uptting the Internet community greatly. Specifically, it is
possible to both add new features and remove features that are no
longer required for the current environment. Thus, the protocol is
not condemned to grow without bound. Finally, by keeping the old
version of the protocol around, backward compatibility is guaranteed. The old code will work as well as it ever did.
Assuming the infrastructure described in the following subction,
the only real disadvantage of protocol evolution is the amount of
memory required to run veral versions of the same protocol.
Fortunately, memory is not the scarcest resource in modern
workstations (it may, however, be at a premium in the BSD kernel and its derivatives). Since old versions may rarely if ever be executed, the old versions can be swapped out to disk with little performance
loss. Finally, since this cost is explicit, there is a huge incentive to eliminate old protocol versions from the network.
O’Malley & Peterson [Page 4]
2.4. Infrastructure Support for Protocol Evolution
The effective u of protocol evolution implies that each protocol is considered a vector of implementations which share the same top level interface, and perhaps not much el. TCP[0] is the current
implementation of TCP and exists to provide backward compatibility
with all existing machines. TCP[1] is a version of TCP that is
optimized for high-speed networks. TCP[0] is always prent; TCP[1] may or may not be. Treating TCP as a vector of protocols requires
only three changes to the way protocols are designed and implemented. First, each version of TCP is assigned a unique id, but this id is
not given as an IP protocol number. (This is becau IP’s protocol
number field is only 8 bits long and could easily be exhausted.) The "obvious" solution to this limitation is to increa IP’s protocol
number field to 32 bits. In this ca, however, the obvious solution is wrong, not becau of the difficultly of changing IP, but simply
becau there is a better approach. The best way to deal with this
problem is to increa the IP protocol number field to 32 bits and
move it to the very end of the IP header (i.e., the first four bytes of the TCP header). A backward compatible modification would be made to IP such that for all packets with a special protocol number, say
77, IP would look into the four bytes following its header for its
de-multiplexing information. On systems which do not support a
modified IP, an actual protocol 77 would be ud to perform the de-
multiplexing to the correct TCP version.
Second, a version control protocol, called VTCP, is ud to lect
the appropriate version of TCP for a particular connection. VTCP is
an example of a virtual protocol as introduced in [2]. Application
programs access the various versions of TCP through VTCP. When a TCP connection is opened to a specific machine, VTCP checks its local
属虎女最佳婚配cache to determine the highest common version shared by the two
machines. If the target machine is in the cache, it opens that
version of TCP and returns the connection to the protocol above and
does not effect performance. If the target machine is not found in
the cache, VTCP nds a UDP packet to the other machine asking what
versions of TCP that machine supports. If it receives a respon, it us that information to lect 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 u. 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]
System. It is also possible that VTCP might take the performance
characteristics of the network into consideration when lecting a
version; TCP[0] may in fact turn out to be the correct choice for a
low-bandwidth network.
Third, becau 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 addresd in stages.
More importantly, we believe this problem can be addresd 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 bad 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 ts, tho that can quickly be updated with new protocols and tho that cannot. High
performance machines that can u 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 the three methods has its advantages. When ud in
combination, the result is better protocols at a lower overall cost. Backward compatible changes are best rerved 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 ur demands on existing protocols, or better yet, to
O’Malley & Peterson [Page 6]
