As per Relevance of the word consider, we have this rfc below:
Network Working Group S. O'
Request for Comments: 1263 L.
University of
October 1991
TCP EXTENSIONS CONSIDERED
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this document
unlimited
This RFC comments on recent proposals to extend TCP. It argues
the backward compatible extensions proposed in RFC's 1072 and 1185
should not be pursued, and proposes an alternative way to evolve
Internet protocol suite. Its purpose is to stimulate discussion
the Internet community
1.
The rapid growth of the size, capacity, and complexity of
Internet has led to the need to change the existing protocol suite
For example, the maximum TCP window size is no longer sufficient
efficiently support the high capacity links currently being
and constructed. One is then faced with the choice of either
the protocol alone and accepting the fact that TCP will run no
on high capacity links than on low capacity links, or changing TCP
This is not an isolated incident. We have counted at least
other proposed changes to TCP (some to be taken more seriously
others), and the question is not whether to change the
suite, but what is the most cost effective way to change it
This RFC compares the costs and benefits of three approaches
making these changes: the creation of new protocols,
compatible protocol extensions, and protocol evolution. The
section introduces these three approaches and enumerates
strengths and weaknesses of each. The following section
how we believe these three approaches are best applied to the
proposed changes to TCP. Note that we have not written this RFC as
academic exercise. It is our intent to argue against acceptance
the various TCP extensions, most notably RFC's 1072 and 1185 [4,5],
by describing a more palatable alternative
O'Malley & Peterson [Page 1]
RFC 1263 TCP Extensions Considered Harmful October 1991
2. Creation vs. Extension vs.
2.1. Protocol
Protocol creation involves the design, implementation
standardization, and distribution of an entirely new protocol.
this context, there are two basic reasons for creating a
protocol. The first is to replace an old protocol that is so
that it can no longer be effectively extended to perform its
function. The second is to add a new protocol because users
making demands upon the original protocol that were not envisioned
the designer and cannot be efficiently handled in terms of
original protocol. For example, TCP was designed as a
byte-stream protocol but is commonly used as both a reliable record
stream protocol and a reliable request-reply protocol due to the
of such protocols in the Internet protocol suite. The
demands placed upon a byte-stream protocol in the new
environment makes it difficult to extend TCP to meet these
application demands
The advantage of creating a new protocol is the ability to start
a clean sheet of paper when attempting to solve a complex
problem. The designer, free from the constraints of an
protocol, can take maximum advantage of modern network research
the basic algorithms needed to solve the problem. Even
importantly, the implementor is free to steal from a large number
existing academic protocols that have been developed over the years
In some cases, if truly new functionality is desired, creating a
protocol is the only viable approach
The most obvious disadvantage of this approach is the high cost
standardizing and distributing an entirely new protocol. Second
there is the issue of making the new protocol reliable. Since
protocols have not undergone years of network stress testing,
often contain bugs which require backward compatible fixes,
hence, the designer is back where he or she started. A
disadvantage of introducing new protocols is that they generally
new interfaces which require significant effort on the part of
Internet community to use. This alone is often enough to kill a
protocol
Finally, there is a subtle problem introduced by the very
provided by this approach. Specifically, being able to introduce
new protocol often results in protocols that go far beyond the
needs of the situation. New protocols resemble Senate
bills; they tend to accumulate many amendments that have nothing
do with the original problem. A good example of this phenomena is
attempt to standardize VMTP [1] as the Internet RPC protocol.
O'Malley & Peterson [Page 2]
RFC 1263 TCP Extensions Considered Harmful October 1991
VMTP was a large protocol to begin with, the closer it got
standardization the more features were added until it
collapsed under its own weight. As we argue below, new
should initially be minimal, and then evolve as the
dictates
2.2. Backward Compatible
In a backward compatible extension, the protocol is modified in
a fashion that the new version of the protocol can
inter-operate with existing versions of the protocol. This
implies no changes to the protocol's header. TCP slow start [3] is
example of such a change. In a slightly more relaxed version
backward compatibility, no changes are made to the fixed part of
protocol's header. Instead, either some fields are added to
variable length options field found at the end of the header,
existing header fields are overloaded (i.e., used for
purposes). However, we can find no real advantage to this
over simply changing the protocol
Backward compatible extensions are widely used to modify
because there is no need to synchronize the distribution of the
version of the protocol. The new version is essentially allowed
diffuse through the Internet at its own pace, and at least in theory
the Internet will continue to function as before. Thus, the
distribution costs are limited. Backward compatible extensions
avoid the bureaucratic costs of standardizing a new protocol. TCP
still TCP and the approval cost of a modification to an
protocol is much less than that of a new protocol. Finally, the
difficulty of making such changes tends to restrict the changes
the minimal set needed to solve the current problem. Thus, it is
to see unneeded changes made when using this technique
Unfortunately, this approach has several drawbacks. First, the
to distribute the new version of the protocol to all hosts can
quite long (forever in fact). This leaves the network in
heterogeneous state for long periods of time. If there is
slightest incompatibly between old and new versions, chaos
result. Thus, the implicit cost of this type of distribution can
quite high. Second, designing a backward compatible change to a
protocol is extremely difficult, and the implementations "tend
complexity and ugliness" [5]. The need for backward
ensures that no code can every really be eliminated from
protocol, and since such vestigial code is rarely executed, it
often wrong. Finally, most protocols have limits, based upon
design decisions of it inventors, that simply cannot be side-
in this fashion
O'Malley & Peterson [Page 3]
RFC 1263 TCP Extensions Considered Harmful October 1991
2.3. Protocol
Protocol evolution is an approach to protocol change that attempts
escape the limits of backward compatibility without incurring all
the costs of creating new protocols. The basic idea is for
protocol designer to take an existing protocol that
modification and make the desired changes without
backward compatibility. This drastically simplifies the job of
protocol designer. For example, the limited TCP window size could
fixed by changing the definition of the window size in the
from 16-bits to 32-bits, and re-compiling the protocol. The effect
backward compatibility would be ensured by simply keeping both
new and old version of the protocol running until most machines
the new version. Since the change is small and invisible to the
interface, it is a trivial problem to dynamically select the
TCP version at runtime. How this is done is discussed in the
section
Protocol evolution has several advantages. First, it is by far
simplest type of modification to make to a protocol, and hence,
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
previous versions of the protocol. Also, most of the protocol
carried over into the new version unchanged, thus avoiding the
and debugging cost of creating an entirely new protocol. Second
there is no artificial limit to the amount of change that can be
to a protocol, and as a consequence, its useful lifetime can
extended indefinitely. In a series of evolutionary steps, it
possible to make fairly radical changes to a protocol
upsetting the Internet community greatly. Specifically, it
possible to both add new features and remove features that are
longer required for the current environment. Thus, the protocol
not condemned to grow without bound. Finally, by keeping the
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 subsection
the only real disadvantage of protocol evolution is the amount
memory required to run several versions of the same protocol
Fortunately, memory is not the scarcest resource in
workstations (it may, however, be at a premium in the BSD kernel
its derivatives). Since old versions may rarely if ever be executed
the old versions can be swapped out to disk with little
loss. Finally, since this cost is explicit, there is a huge
to eliminate old protocol versions from the network
O'Malley & Peterson [Page 4]
RFC 1263 TCP Extensions Considered Harmful October 1991
2.4. Infrastructure Support for Protocol
The effective use of protocol evolution implies that each protocol
considered a vector of implementations which share the same top
interface, and perhaps not much else. TCP[0] is the
implementation of TCP and exists to provide backward
with all existing machines. TCP[1] is a version of TCP that
optimized for high-speed networks. TCP[0] is always present; TCP[1]
may or may not be. Treating TCP as a vector of protocols
only three changes to the way protocols are designed and implemented
First, each version of TCP is assigned a unique id, but this id
not given as an IP protocol number. (This is because IP's
number field is only 8 bits long and could easily be exhausted.)
"obvious" solution to this limitation is to increase IP's
number field to 32 bits. In this case, however, the obvious
is wrong, not because of the difficultly of changing IP, but
because there is a better approach. The best way to deal with
problem is to increase the IP protocol number field to 32 bits
move it to the very end of the IP header (i.e., the first four
of the TCP header). A backward compatible modification would be
to IP such that for all packets with a special protocol number,
77, IP would look into the four bytes following its header for
de-multiplexing information. On systems which do not support
modified IP, an actual protocol 77 would be used to perform the de
multiplexing to the correct TCP version
Second, a version control protocol, called VTCP, is used to
the appropriate version of TCP for a particular connection. VTCP
an example of a virtual protocol as introduced in [2].
programs access the various versions of TCP through VTCP. When a
connection is opened to a specific machine, VTCP checks its
cache to determine the highest common version shared by the
machines. If the target machine is in the cache, it opens
version of TCP and returns the connection to the protocol above
does not effect performance. If the target machine is not found
the cache, VTCP sends a UDP packet to the other machine asking
versions of TCP that machine supports. If it receives a response,
uses that information to select a version and puts the information
the cache. If no reply is forthcoming, it assumes that the
machine does not support VTCP and attempts to open a TCP[0]
connection. VTCP's cache is flushed occasionally to ensure that
information is current
Note that this is only one possible way for VTCP to decide the
version of TCP to use. Another possibility is for VTCP to learn
right version for a particular host when it resolves the host's name
That is, version information could be stored in the Domain
O'Malley & Peterson [Page 5]
RFC 1263 TCP Extensions Considered Harmful October 1991
System. It is also possible that VTCP might take the
characteristics of the network into consideration when selecting
version; TCP[0] may in fact turn out to be the correct choice for
low-bandwidth network
Third, because our proposal would lead to a more dynamically
network architecture, a mechanism for distributing new versions
need to be developed. This is clearly the hardest requirement of
infrastructure, but we believe that it can be addressed in stages
More importantly, we believe this problem can be addressed after
decision has been made to go the protocol evolution route. In
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,
at exactly the same cost, as the backward compatible
suggested in RFC's 1072 and 1185.
In the medium term, we envision the IAB approving new versions of
every year or so. Given this scenario, a simple
mechanism can be designed based on software distribution
that have be developed for other environments; e.g., Unix RDIST
Mach SUP. Such a mechanism need not be available on all hosts
Instead, hosts will be divided into two sets, those that can
be updated with new protocols and those that cannot.
performance machines that can use high performance networks will
the most current version of TCP as soon as it is available, thus
have incentive to change. Old machines which are too slow to drive
high capacity lines can be ignored, and probably should be ignored
In the long term, we envision protocols being designed on
application by application basis, without the need for
approval. In such a world, a common protocol
environment---a protocol backplane---is the right way to go.
such a backplane, protocols can be automatically installed over
network. While we claim to know how to build such an environment
such a discussion is beyond the scope of this paper
2.5.
Each of these three methods has its advantages. When used
combination, the result is better protocols at a lower overall cost
Backward compatible changes are best reserved for changes that do
affect the protocol's header, and do not require that the
running on the other end of the connection also be changed.
evolution should be the primary way of dealing with header
that are no longer large enough, or when one algorithm is
directly for another. New protocols should be written to off
unexpected user demands on existing protocols, or better yet,
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
possible to evolve a newly created protocol once it has been put
place, the pressure to add unnecessary features should be reduced
Second, the ability to create new protocols removes the pressure
overextend a given protocol. Finally, the ability to evolve
protocol removes the pressure to maintain backward
where it is really not possible
3. TCP Extensions: A Case
This section examines the effects of using our proposed
to implement changes to TCP. We will begin by analyzing the
compatible extensions defined in RFC's 1072 and 1185, and proposing
set of much simpler evolutionary modifications. We also
several more problematical extensions to TCP, such as
TCP. Finally, we point our some areas of TCP which may
changes in the future
The evolutionary modification to TCP that we propose includes all
the functionality described in RFC's 1072 and 1185, but does
preserve the header format. At the risk of being misunderstood
believing backward compatibility is a good idea, we also show how
proposed changes to TCP can be folded into a backward
implementation of TCP. We do this as a courtesy for those
that cannot accept the possibility of multiple versions of TCP
3.1. RFC's 1072 and 1185
3.1.1. Round Trip
In RFC 1072, a new ECHO option is proposed that allows each
packet to carry a timestamp in its header. This timestamp is used
keep a more accurate estimate of the RTT (round trip time) used
decide when to re-transmit segments. In the original TCP algorithm
the sender manually times a small number of sends. The
algorithm was quite complex and does not produce an accurate
RTT for high capacity networks. The inclusion of a timestamp in
header both simplifies the code needed to calculate the RTT
improves the accuracy and robustness of the algorithm
The new algorithm as proposed in RFC 1072 does not appear to have
serious problems. However, the authors of RFC 1072 go to
lengths in an attempt to keep this modification backward
with the previous version of TCP. They place an ECHO option in
O'Malley & Peterson [Page 7]
RFC 1263 TCP Extensions Considered Harmful October 1991
SYN segment and state, "It is likely that most implementations
properly ignore any options in the SYN segment that they do
understand, so new initial options should not cause problems" [4].
This statement does not exactly inspire confidence, and we
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
simply attempt to hide the basic incompatibility inside the protocol
it does not eliminate it. Therefore, since we are making
evolutionary change anyway, the only modification to the
algorithm is to move the fields into the header proper. Thus,
header will contain 32-bit echo and echo reply fields. Two fields
needed to handle bi-directional data streams
3.1.2. Window Size and Sequence Number
Long Fat Networks (LFN's), networks which contain very high
lines with very high latency, introduce the possibility that
number of bits in transit (the bandwidth-delay product) could
the TCP window size, thus making TCP the limiting factor in
performance. Worse yet, the time it takes the sequence numbers
wrap around could be reduced to a point below the MSL (
segment lifetime), introducing the possibility of old packets
mistakenly accepted as new
RFC 1072 extends the window size through the use of an
constant scaling factor. The window size in the TCP header
multiplied by this factor to get the true window size.
algorithm has three problems. First, one must prove that at all
the implicit scaling factor used by the sender is the same as
receiver. The proposed algorithm appears to do so, but
complexity of the algorithm creates the opportunity for
implementations to affect the correctness of TCP. Second, the use
a scaling factor complicates the TCP implementation in general,
can have serious effects on other parts of the protocol
A final problem is what we characterize as the "quantum
sizing" problem. Assuming that the scaling factors will be powers
two, the algorithm right shifts the receiver's window before
it. This effectively rounds the window size down to the
multiple of the scaling factor. For large scaling factors, say 64k
this implies that window values are all multiples of 64k and
minimum window size is 64k; advertising a smaller window
impossible. While this is not necessarily a problem (and it seems
be an extreme solution to the silly window syndrome) what effect
will have on the performance of high-speed network links is anyone'
guess. We can imagine this extension leading to future
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
wrapping too quickly without explicitly increasing the
number space. Instead, the RFC proposes to use the timestamp used
the ECHO option to weed out old duplicate messages. The
presented in RFC 1185 is complex and has been shown to be
flawed at a recent End-to-End Research Group meeting. Attempts
currently underway to fix the algorithm presented in the RFC.
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
correctness to be a mistake. The Internet community has NO
with transport protocols that depend on clocks for correctness
Second, the proposal uses two distinct schemes to deal with
duplicate packets: the sliding window algorithm takes care of "new
old packets (packets from the current sequence number epoch) and
timestamp algorithm deals with "old" old packets (packets
previous sequence number epochs). It is hard enough getting one
these schemes to work much less to get two to work and ensure
they do not interfere with one another
In RFC 1185, the statement is made that "An obvious fix for
problem of cycling the sequence number space is to increase the
of the TCP sequence number field." Using protocol evolution,
obvious fix is also the correct one. The window size can be
to 32 bits by simply changing a short to a long in the definition
the TCP header. At the same time, the sequence number
acknowledgment fields can be increased to 64 bits. This change
the minimum complexity modification to get the job done and
little or no analysis to be shown to work correctly
On machines that do not support 64-bit integers, increasing
sequence number size is not as trivial as increasing the window size
However, it is identical in cost to the modification proposed in
1185; the high order bits can be thought of as an optimal clock
ticks only when it has to. Also, because we are not dealing
real time, the problems with unreliable system clocks is avoided.
machines that support 64-bit integers, the original TCP code may
reused. Since only very high performance machines can hope to
a communications network at the rates this modification is
to support, and the new generation of RISC microprocessors (e.g.,
MIPS R4000 and PA-RISC) do support 64-bit integers, the assumption
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
Another problem with TCP's support for LFN's is that the
window algorithm used by TCP does not support any form of
acknowledgment. Thus, if a segment is lost, the total amount of
that must be re-transmitted is some constant times the bandwidth
delay product, despite the fact that most of the segments have
fact arrived at the receiver. RFC 1072 proposes to extend TCP
allow the receiver to return partial acknowledgments to the sender
the hope that the sender will use that information to
unnecessary re-transmissions
It has been our experience on predictable local area networks
the performance of partial re-transmission strategies is highly non
obvious, and it generally requires more than one iteration to find
decent algorithm. It is therefore not surprising that the
proposed in RFC 1072 has some problems. The proposed TCP
allows the receiver to include a short list of received
with every ACK. The idea being that when the receiver sends back
normal ACK, it checks its queue of segments that have been
out of order and sends the relative sequence numbers of
blocks of segments back to the sender. The sender then uses
information to re-transmit the segments transmitted but not listed
the ACK
As specified, this algorithm has two related problems: (1) it
the relative frequencies of delivered and dropped packets, and (2)
the list provided in the option field is probably too short to
much good on networks with large bandwidth-delay products. In
model of high bandwidth networks that we have seen, the packet
rate is very low, and thus, the ratio of dropped packets to
packets is very low. An algorithm that returns ACKs as proposed
simply going to have to send more information than one in which
receiver returns NAKs
This problem is compounded by the short size of the TCP option
(44 bytes). In theory, since we are only worried about high
networks, returning ACKs instead of NAKs is not really a problem;
bandwidth is available to send any information that's needed.
problem comes when trying to compress the ACK information into the 44
bytes allowed. The proposed extensions effectively compresses
ACK information by allowing the receiver to ACK byte ranges
than segments, and scaling the relative sequence numbers of the re
transmitted segments. This makes it much more difficult for
sender to tell which segments should be re-transmitted,
complicates the re-transmission code. More importantly, one
never compress small amounts of data being sent over a high
network; it trades a scarce resource for an abundant resource.
O'Malley & Peterson [Page 10]
RFC 1263 TCP Extensions Considered Harmful October 1991
low bandwidth networks, selective retransmission is not needed
the SACK option should be disabled
We propose two solutions to this problem. First, the receiver
examine its list of out-of-order packets and guess which
have been dropped, and NAK those segments back to the sender.
number of NAKs should be low enough that one per TCP packet should
sufficient. Note that the receiver has just as much information
the sender about what packets should be retransmitted, and in
case, the NAKs are simply suggestions which have no effect
correctness
Our second proposed modification is to increase the offset field
the TCP header from 4 bits to 16 bits. This allows 64k-bytes of
header, which allows us to radically simplify the selective re
transmission algorithm proposed in RFC 1072. The receiver can
simply send a list of 64-bit sequence numbers for the out-of-
segments to the sender. The sender can then use this information
do a partial retransmission without needing an ouji board
translate ACKs into segments. With the new header size, it may
faster for the receiver to send a large list than to attempt
aggregate segments into larger blocks
3.1.4. Header
The modifications proposed above drastically change the size
structure of the TCP header. This makes it a good time to re-
the structure of the proposed TCP header. The primary goal of
current TCP header is to save bits in the output stream. When TCP
developed, a high bandwidth network was 56kbps, and the key use
TCP was terminal I/O. In both situations, minimal header size
important. Unfortunately, while the network has
increased in performance and the usage pattern of the network is
vastly different, most protocol designers still consider saving a
bits in the header to be worth almost any price. Our basic goal
different: to improve performance by eliminating the need to
information packed into odd length bit fields in the header.
is our first cut at such a modification
The protocol id field is there to make further
modifications to TCP easier. This field basically subsumes
protocol number field contained in the IP header with a
number. Each distinct TCP version has a different protocol id
this field ensures that the right code is looking at the
header. The offset field has been increased to 16 bits to
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
the sequence number and ACK fields have been increased to 64 bits
The open window field has been increased to 32 bits. The checksum
urgent data pointer fields are unchanged. The echo and echo
fields are added. The option field remains but can be much
than in the old TCP. All headers are padded out to 32
boundaries. Note that these changes increase the minimum header
from 24 bytes (actually 36 bytes if the ECHO and ECHO reply
defined in RFC 1072 are included on every packet) to 48 bytes.
maximum header size has been increased to the maximum segment size
We do not believe that the the increased header size will have
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
The most likely objection to the proposed TCP extension is that it
not backward compatible with the current version of TCP, and
importantly, TCP's header. In this section we will present
versions of the proposed extension with increasing degrees
backward compatibility. The final version will combine the
degree of backward compatibility found in the protocol described
O'Malley & Peterson [Page 12]
RFC 1263 TCP Extensions Considered Harmful October 1991
RFC's 1072/1185, with the much simpler semantics described in
RFC
We believe that the best way to preserve backward compatibility is
leave all of TCP alone and support the transparent use of a
protocol when and where it is needed. The basic scheme is the
described in section 2.4. Those machines and operating systems
need to support high speed connections should implement some
protocol infrastructure that allows them to rapidly evolve protocols
Machines that do not require such service simply keep using
existing version of TCP. A virtual protocol is used to manage the
of multiple TCP versions
This approach has several advantages. First, it guarantees
compatibility with ALL existing TCP versions because
implementations will never see strange packets with new options
Second, it supports further modification of TCP with
additional costs. Finally, since our version of TCP will more
resemble the existing TCP protocol than that proposed in RFC'
1072/1185, the cost of maintaining two simple protocols will
be lower than maintaining one complex protocol. (Note that with
probability you still have to maintain two versions of TCP in
case.) The only additional cost is the memory required for
around two copies of TCP
For those that insist that the only efficient way to implement
modifications is in a single monolithic protocol, or those
believe that the space requirements of two protocols would be
great, we simply migrate the virtual protocol into TCP. TCP
modified so that when opening a connection, the sender uses the
VERSION option attached to the SYN packet to request using the
version. The receiver responds with a TCP VERSION ACK in the SYN
packet, after which point, the new header format described in
3.1.4 is used. Thus, there is only one version of TCP, but
version supports multiple header formats. The complexity of such
protocol would be no worse than the protocol described in
1072/1185. It does, however, make it more difficult to
additional changes to TCP
Finally, for those that believe that the preservation of the TCP'
header format has any intrinsic value (e.g., for those that don'
want to re-program their ethernet monitors), a header
version of our proposal is possible. One simply takes all of
additional information contained in the header given in Section 3.1.4
and places it into a single optional field. Thus, one could define
new TCP option which consists of the top 32 bits of the sequence
ack fields, the echo and echo_reply fields, and the top 16 bits
the window field. This modification makes it more difficult to
O'Malley & Peterson [Page 13]
RFC 1263 TCP Extensions Considered Harmful October 1991
advantage of machines with 64-bit address spaces, but at a
will be just as easy to process as the protocol described in
1072/1185. The only restriction is that the size of the
option field is still limited to 44 bytes, and thus,
retransmission using NAKs rather than ACKs will probably be required
The key observation is that one should make a protocol
correct and simple before trying to make it backward compatible.
far as we can tell, the only advantages possessed by the
described in RFC 1072/1185 is that its typical header, size
options, is 8 to 10 bytes shorter. The price for this "advantage"
a protocol of such complexity that it may prove impossible for
humans to implement. Trying to maintain backward compatibility
every stage of the protocol design process is a serious mistake
3.2. TCP Over
Another potential problem with TCP that has been discussed recently
but has not yet resulted in the generation of an RFC, is
potential for TCP to grab and hold all 2**16 port numbers on a
machine. This problem is caused by short port numbers, long MSLs
and the misuse of TCP as a request-reply protocol. TCP must hold
each port after a close until all possible messages to that port
died, about 240 seconds. Even worse, this time is not decreasing
increase network performance. With new fast hardware, it is
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
ports in less than 240 seconds. This usage pattern is generated
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
preserving backward compatibility. This is done by piggybacking
request message on the SYN packet and the reply message on the SYN
ACK packet. This approach suffers from one key problem: it
the probability of a correct TCP implementation to near 0. The
problem has nothing to do with TCP, rather it is the lack of
Internet request-reply protocol that guarantees at-most-
semantics
We propose to solve this problem by the creation of a new protocol
This has already been attempted with VMTP, but the size
complexity of VMTP, coupled with the process currently required
standardize a new protocol doomed it from the start. Instead
solving the general problem, we propose to use Sprite RPC [7], a
simpler protocol, as a means of off-loading inappropriate users
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
interface as possible in order that current TCP (mis)users could
switched to Sprite RPC without requiring code modification on
part. A virtual protocol could be used to select the correct
TCP or Sprite RPC if it exists on the other machine. A
compatible modification to TCP could be made which would
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
problems when extended into the Internet. First, it does not have
usefully flow control algorithm. Second, it lacks the
semantics to reliably tear down connections. The lack of a tear
mechanism needs to be solved, but the flow control problem could
dealt with in later iterations of the protocol as Internet
protocols are not yet well understood; for now, we could simple
the size of each message to 16k or 32k bytes. This might also be
good place to use a decomposed version of Sprite RPC [2],
exposes each of these features as separate protocols. This
permit the quick change of algorithms, and once the protocol
stabilized, a monolithic version could be constructed and
to replace the decomposed version
In other words, the basic strategy is to introduce as simple of
protocol as possible today, and later evolve this protocol to
the known limitations
3.3. Future
The header prediction algorithm should be generalized so as to
less sensitive to changes in the protocols header and algorithm
There almost seems to be as much effort to make all modifications
TCP backward compatible with header prediction as there is to
them backward compatible with TCP. The question that needs to
answered is: are there any changes we can made to TCP to make
prediction easier, including the addition of information into
header. In [6], the authors showed how one might
optimistic blast from VMTP to almost any protocol that
fragmentation and reassembly. Generalizing header prediction so
it scales with TCP modification would be step in the right direction
It is clear that an evolutionary change to increase the size of
source and destination ports in the TCP header will eventually
necessary. We also believe that TCP could be made
simpler and more flexible through the elimination of the pseudo
header. The solution to this problem is to simply add a length
and the IP address of the destination to the TCP header. It has
O'Malley & Peterson [Page 15]
RFC 1263 TCP Extensions Considered Harmful October 1991
been mentioned that better and simpler TCP connection
algorithms would be useful. Some form of reliable record
protocol should be developed. Performing sliding window and
control over records rather than bytes would provide
opportunities for optimizations and allow TCP to return to
original purpose as a byte-stream protocol. Finally, it has
clear to us that the current Internet congestion control strategy
to use TCP for everything since it is the only protocol that
congestion control. One of the primary reasons many "new protocols
are proposed as TCP options is that it is the only way to get
TCP's congestion control. At some point, a TCP-independent
control scheme must be implemented and one might then be able
remove the existing congestion control from TCP and
simplify the protocol
4.
One obvious side effect of the changes we propose is to increase
size of the TCP header. In some sense, this is inevitable; just
every field in the header has been pushed to its limit by the
growth of the network. However, we have made very little effort
make the minimal changes to solve the current problem. In fact,
have tended to sacrifice header size in order to defer future
as long as possible. The problem with this is that one of TCP'
claims to fame is its efficiency at sending small one byte
over slow networks. Increasing the size of the TCP header
inevitably result in some increase in overhead on small packets
slow networks. Clark among others have stated that they see
fundamental performance limitations that would prevent TCP
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
speed networks and TCP performance on slow speed networks.
dynamic range is simply too great to be optimally supported by
protocol. Hence, in keeping around the old version of TCP we
effectively split TCP into two protocols, one for high
lines and the other for low bandwidth lines
Another potential argument is that all of the changes mentioned
should be packaged together as a new version of TCP. This
could be standardized and we could all go back to the status quo
stable unchanging protocols. While to a certain extent this
inevitable---there is a backlog of necessary TCP changes because
the current logistical problems in modifying protocols---it is
begs the question. The status quo is simply unacceptably static
there will always be future changes to TCP. Evolutionary change
also result in a better and more reliable TCP. Making small
and distributing them at regular intervals ensures that one
O'Malley & Peterson [Page 16]
RFC 1263 TCP Extensions Considered Harmful October 1991
has actually been stabilized before the next has been made. It
presents a more balanced workload to the protocol designer;
than designing one new protocol every 10 years he makes
protocol extensions. It will also eventually make
distribution easier: the basic problem with protocol distribution
is that it is done so rarely that no one knows how to do it and
is no incentive to develop the infrastructure needed to perform
task efficiently. While the first protocol distribution is
guaranteed to be a disaster, the problem will get easier with
additional one. Finally, such a new TCP would have the same
as VMTP did; a radically new protocol presents a bigger target
The violation of backward compatibility in systems as complex as
Internet is always a serious step. However, backward compatibility
a technique, not a religion. Two facts are often overlooked
backward compatibility gets out of hand. First, violating
compatibility is always a big win when you can get away with it.
of the key advantages of RISC chips over CISC chips is simply
they were not backward compatible with anything. Thus, they were
bound by design decisions made when compilers were stupid and
men programmed in assembler. Second, one is going to have to
backward compatibility at some point anyway. Every system has
headroom limitations which result in either stagnation (IBM
software) or even worse, accidental violations of
compatibility
Of course, the biggest problem with our approach is that it is
compatible with the existing standardization process. We hope to
able to design and distribute protocols in less time than it takes
standards committee to agree on an acceptable meeting time. This
inevitable because the basic problem with networking is
standardization process. Over the last several years, there has
a push in the research community for lightweight protocols, when
fact what is needed are lightweight standards. Also note that
have not proposed to implement some entirely new set of "superior
communications protocols, we have simply proposed a system for
necessary changes to the existing protocol suites fast enough to
up with the underlying change in the network. In fact, the
standards organization that realizes that the primary impediment
standardization is poor logistical support will probably win
5.
The most important conclusion of this RFC is that protocol
happens and is currently happening at a very respectable clip.
all of the changes given as example in this document are from TCP
there are many other protocols that require modification. In a
O'Malley & Peterson [Page 17]
RFC 1263 TCP Extensions Considered Harmful October 1991
prosaic domain, the telephone company is running out of
numbers; they are being overrun by fax machines, modems, and cars
The underlying cause of these problems seems to be an
exponential increase almost all network metrics: number of hosts
bandwidth, host performance, applications, and so on, combined
an attempt to run the network with a static set of unchanging
protocols. This has been shown to be impossible and one can
feel the pressure for protocol change building. We simply propose
explicitly deal with the changes rather keep trying to hold back
flood
Of almost equal importance is the observation that TCP is a
and not a platform for implementing other protocols. Because of
lack of any alternatives, TCP has become a de-facto platform
implementing other protocols. It provides a vague standard
with the kernel, it runs on many machines, and has a well
distribution path. Otherwise sane people have proposed Bounded
TCP (an unreliable byte stream protocol), Simplex TCP (which
data in only one direction) and Multi-cast TCP (too horrible to
consider). All of these protocols probably have their uses, but
as TCP options. The fact that a large number of people are willing
use TCP as a protocol implementation platform points to the
need for a protocol independent platform
Finally, we point out that in our research we have found very
difference in the actual technical work involved with the
proposed methods of protocol modification. The amount of
involved in a backward compatible change is often more than
required for an evolutionary change or the creation of a
protocol. Even the distribution costs seem to be identical.
primary cost difference between the three approaches is the cost
getting the modification approved. A protocol modification, no
how extensive or bizarre, seems to incur much less cost and risk.
is time to stop changing the protocols to fit our current way
thinking, and start changing our way of thinking to fit
protocols
6.
[1] Cheriton D., "VMTP: Versatile Message Transaction Protocol",
1045, Stanford University, February 1988.
[2] Hutchinson, N., Peterson, L., Abbott, M., and S. O'Malley, "RPC
the x-Kernel: Evaluating New Design Techniques", Proceedings of
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/
86/302, University of California at Berkeley, June 1988.
7. Security
Security issues are not discussed in this memo
8. Authors'
Larry L.
University of
Department of Computer
Tucson, AZ 85721
Phone: (602) 621-4231
EMail: llp@cs.arizona.
Sean O'
University of
Department of Computer
Tucson, AZ 85721
Phone: 602-621-8373
EMail: sean@cs.arizona.
O'Malley & Peterson [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
