diff options
Diffstat (limited to 'doc/rfc/rfc1263.txt')
| -rw-r--r-- | doc/rfc/rfc1263.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc1263.txt b/doc/rfc/rfc1263.txt new file mode 100644 index 0000000..55b6e39 --- /dev/null +++ b/doc/rfc/rfc1263.txt @@ -0,0 +1,1067 @@ + + + + + + +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 proposed in RFC's 1072 and 1185 + should not be pursued, and proposes an alternative way to evolve the + Internet protocol suite. Its purpose 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 proposed changes to TCP (some to be taken more seriously 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 these changes: the creation of new protocols, backward + compatible protocol extensions, and protocol evolution. The next + section introduces these three approaches and enumerates the + strengths and weaknesses of each. The following section describes + how we believe these three approaches are best applied to the many + proposed changes to TCP. Note that we have not written this RFC as an + academic exercise. 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] + +RFC 1263 TCP Extensions Considered Harmful October 1991 + + +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 second is to add a new protocol because users 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 used 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 these 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 research 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 cases, 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 use. 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 resemble 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] + +RFC 1263 TCP Extensions Considered Harmful October 1991 + + + VMTP was a large protocol to begin with, the closer it got to + standardization the more features were added until it essentially + collapsed 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., used for multiple + purposes). However, we can find no real advantage to this technique + over simply changing the protocol. + + Backward compatible extensions are widely used to modify protocols + because there is no need to synchronize the distribution of the new + version of the protocol. The new version is essentially allowed to + diffuse 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 set needed to solve the current problem. Thus, it is rare + to see unneeded changes made when using this technique. + + Unfortunately, this approach has several 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, based upon the + design decisions of it inventors, that simply cannot be side-stepped + in this fashion. + + + +O'Malley & Peterson [Page 3] + +RFC 1263 TCP Extensions Considered Harmful October 1991 + + +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 use + the new version. Since the change is small and invisible to the user + interface, it is a trivial problem to dynamically select the correct + TCP version at runtime. How this is done is discussed in the next + section. + + Protocol evolution has several 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 consequence, its useful lifetime can be + extended indefinitely. In a series of evolutionary steps, it is + possible to make fairly radical changes to a protocol without + upsetting 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 subsection, + the only real disadvantage of protocol evolution is the amount of + memory required to run several 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] + +RFC 1263 TCP Extensions Considered Harmful October 1991 + + +2.4. Infrastructure Support for Protocol Evolution + + The effective use of protocol evolution implies that each protocol is + considered a vector of implementations which share the same top level + interface, and perhaps not much else. 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 present; 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 because IP's protocol + number field is only 8 bits long and could easily be exhausted.) The + "obvious" solution to this limitation is to increase IP's protocol + number field to 32 bits. In this case, however, the obvious solution + is wrong, not because of the difficultly of changing IP, but simply + because there is a better approach. The best way to deal with this + problem is to increase 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 used to perform the de- + multiplexing to the correct TCP version. + + Second, a version control protocol, called VTCP, is used to select + 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 sends a UDP packet to the other machine asking what + 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. + + 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 + 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: (602) 621-4231 + EMail: llp@cs.arizona.edu + + + Sean O'Malley + University of Arizona + Department of Computer Sciences + Tucson, AZ 85721 + + Phone: 602-621-8373 + EMail: sean@cs.arizona.edu + + + + + +O'Malley & Peterson [Page 19] +
\ No newline at end of file |