SPECIFICATION OF INTERNETWORK
TRANSMISSION CONTROL PROGRAM

TCP
Version 3

Vinton G. Cerf
Advanced Research Projects Agency

Jonathan B. Postel
Information Sciences Institute

January 1978

Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California  90291

(213) 822-1511

TABLE OF CONTENTS

PREFACE	iii

1. INTRODUCTION	1

2. THE TCP INTERFACE TO THE USER	4
2.1 The TCP as a Post Office	4
2.2 Sockets and Addressing	4
2.3 What is a Letter?	6
2.4 TCP User Commands	7
2.4.1 Open	7
2.4.2 Send	8
2.4.3 Receive	10
2.4.4 Close	11
2.4.5 Urgent	11
2.4.6 Status	12
2.4.7 Abort	13
2.5 TCP-to-User Messages	13
2.5.1 Type Codes	13
2.5.2 Message Formats	13
2.5.3 Event Codes	14

3. HIGHER LEVEL PROTOCOLS	16
3.1 Introduction	16
3.2 Well Known Sockets	16
3.3 Reconnection Protocol	16

4. TCP DESIGN	19
4.1 Introduction	19
4.2 Connection Management	23
4.2.1 Initial Sequence Number Selection	23
4.2.2 Establishing a connection	23
4.2.3 Half-Open Connections and Other Anomalies	27
4.2.4 Knowing When to Keep Quiet	29
4.2.5 Closing a Connection	30
4.2.6 End of Letter Sequence Number Adjustments	31
4.2.7 The Communication of Urgent Information	32
4.2.8 The Possibility of Less than Reliable Communication	32
4.2.9 TCP Connection State Transitions	33
4.3 TCP Data Structures	54
4.3.1 Internetwork Packet Format	54
4.3.2 TCP Packet Format	56
4.3.3 Transmission Control Block	60
4.4 Structure of the TCP	62
4.4.1 Introduction	62
4.4.2 Input Packet Handler	64
4.4.3 Reassembler	66
4.4.4 Packetizer	68
4.4.5 Output Packet Handler	69
4.4.6 Retransmitter	69
4.5 Buffer and Window Allocation	69
4.5.1 Introduction	69
4.5.2 The SEND Side	70
4.5.3 The RECEIVE Side	70

BIBLIOGRAPHY	73

PREFACE

This document describes the functions to be performed by the Internetwork Transmission Control Program (TCP) and its interface to programs or users that require its services. There have been three previous TCP specifications: The first [CDS74] defined version 1 of TCP. A second [PGR76a] was written for the Defense Communications Agency in connection with its AUTODIN II project. The third [Cerf77] defined version 2, for use in the ARPA internetwork research projects.

The AUTODIN II version differed from the original version in the following ways:

Specification of a resynchronization mechanism was included, and fields for security and priority, which were known requirements of AUTODIN II, were added.

The Internet version 2 differed from the original version in the following ways:

A different resynchronization procedure was introduced; an “option” field was defined for the TCP header to accommodate not only security and priority but other special features concerned with, for example, packet speech services, diagnostic timestamping, and so on.

This version eliminated all error messages but for RESET and thus simplified the header format. There are still many local errors which can be reported to the user, but none of these need cross the network(s) between TCP’s.

Connection closing was slightly more elaborate in Version 2 than in version 1 because the FIN signals had to be acknowledged. Furthermore, the INT and FIN facilities no longer caused flushing of the data stream. (A separate “flush” facility was tested, but eliminated, in the end.) Dealing with flow-control windows that have gone to zero was a new feature of version 2, and, finally, the reassembly of fragments into segments was more carefully specified.

In version 3 specified in this document, TCP has further evolved. The primary changes from version 2 are:

The resynchronization mechanism has been eliminated in favor of a quiet period on initialization of the TCP.

Buffer management and letters are more tightly coupled by the coupling of the end of letter flag to a receive buffer size.

The interrupt signal has been eliminated in favor of an urgent pointer.

A further separation of the internet and TCP specific information in the packet format has been achieved, with provision for variable length addresses in the internet header.

The evolution from TCP version 2 to version 3 was influenced by many people, but special mention should be made of the work at MIT’s Laboratory for Computer Science on the Data Stream Protocol (DSP) by Dave Clark and Dave Reed. Many of the specific changes introduced in version 3 were first described by Ray Tomlinson of BBN [Tomlinson77].

Although the list of participants in the TCP work is very long (see [CEHKKS77]—the final TCP project report), special acknowledgements are due to R. Kahn, R. Tomlinson, Y. Dalal, R. Karp and C. Sunshine for their active participation in the design of TCP.

This edition of the specification benefited from the comments of the following reviewers: Michael Padlipsky, Carl Sunshine, John Day, Gary Grossman, and Ray Tomlinson.

Transmission Control Protocol

Version 3

1. INTRODUCTION

The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and especially in interconnected systems of such networks. This section introduces some of the terminology used in the remainder of the document and some of the assumptions made in the design of the protocol.

Several basic assumptions are made about process to process communication and these are listed here without further justification. The interested reader is referred to [CK74, Tomlinson74, Belsnes74, Dalal74, Dalal75, Sunshine76, CEHKKS77] for further discussion. HOSTs are computers attached to a network, and from the communication network’s point of view are the sources and destinations of messages. PROCESSES are viewed as the active elements of all host computers in a network (in accordance with the fairly common definition of a process as a program in execution). Even terminals and files or other I/O media are viewed as communicating through the use of processes. Thus, all network communication is viewed as inter-process communication.

Since a process may need to distinguish among several communication streams between itself and another process [or processes], we imagine that each process may have a number of PORTs through which it communicates with the ports of other processes.

Since port names are selected independently by each operating system, TCP, or user, they may not be unique. To provide for unique names at each TCP, we concatenate an internet ADDRESS specific to the TCP level with a port name to create a SOCKET name which will be unique throughout all networks connected together.

For example:
Network = ARPANET (number 12),
Host = ISI-TENEXA (imp 22, host 1),
Port = FTP-Server (port 3);
or
00001010-00010110-000000000000000-1
000000000000000000000000000011.

A pair of sockets form a CONNECTION which can be used to carry data in either direction (i.e. “full duplex”). The connection is uniquely identified by the <local socket, foreign socket> address pair, and the same local socket name can participate in multiple connections to different foreign sockets (see section 2.2).

Processes exchange finite length LETTERS as a way of communicating; thus, letter boundaries might be significant in some process-to-process communications. However, the length of a letter may be such that it must be broken into SEGMENTS before it can be transmitted to its destination. We assume that the segments will normally be reassembled into a letter before being passed to the receiving process. A segment may contain all or a part of a letter, but that a segment never contains parts of more than one letter.

Furthermore, there is no restriction on the length of a letter. A connection might be formed to send a single long letter (a stream of bytes, in effect). In fact, processes can communicate via TCP without ever marking the end of a letter, but we think this is atypical of most anticipated use.

There is, however, a coupling between letters as transmitted and the use of buffers of data that cross the TCP/user interface. Each time an end of letter (EOL) signal is associated with data placed into the receiving user’s buffer, the buffer is returned to the user for processing even if the buffer is not filled.

We specifically assume that segments are transmitted from Host to Host through means of a PACKET SWITCHING NETWORK (PSN) [RW70, Pouzin73]. This assumption is probably unnecessary, since a circuit switched network or a hybrid combination of the two, could also be used, but for concreteness, we explicitly assume that the hosts are connected to one or more PACKET SWITCHES [PS] of a PSN [HKOCW70, Pouzin74, SW71].

Processes make use of the TCP by handing it letters (or buffers filled with parts of a letter). The TCP breaks these into segments, if necessary, and then embeds each segment in an INTERNETWORK PACKET. Each internetwork packet is in turn embedded in a LOCAL PACKET suitable for transmission from the host to one of its serving PSs. The packet switches may perform further formatting, fragmentation, or other operations to achieve the delivery of the local packet to the destination Host.

The term LOCAL PACKET is used generically here to mean the formatted bit string exchanged between a host and a packet switch. The format of bit strings exchanged between the packet switches in a PSN will generally not be of concern to us. If an internetwork packet is destined for a TCP in a foreign PSN, the packet is routed to a gateway which connects the originating PSN with an intermediate PSN or with the destination PSN. Routing of internetwork packets to the gateway may be the responsibility of the source TCP or the local PSN, depending upon the PSN services available.

One model of TCP operation is to imagine that there is a basic gateway associated with each TCP which provides an interface to the local network. This basic gateway performs routing and packet reformatting or embedding, and may also implement congestion and error control between the TCP and gateways at or intermediate to the destination TCP.

At a gateway between networks, the internetwork packet is “unwrapped” from its local packet format and examined to determine through which network the internetwork packet should travel next. The internetwork packet is then “wrapped” in a local packet format suitable to the next network and passed on to a new packet switch.

A gateway is permitted to break up a segment carried by an internetwork packet into smaller FRAGMENTS if this is necessary for transmission through the next network. To do this, the gateway produces a set of internetwork packets, each carrying a fragment. Fragments may be broken into smaller ones at intermediate gateways. The packet format is designed so that the destination TCP can reassemble fragments into segments and verify the end-to-end checksum associated with the segment. Segments, of course, can be reassembled into letters.

Note that the design of fragmentation procedures is still an active area and this function may in the future be removed from TCP’s concerns and become entirely a gateway-to-gateway issue.

The TCP is responsible for regulating the flow of internetwork packets to and from the processes it serves, as a way of preventing its host from becoming saturated or overloaded with traffic. The TCP is also responsible for retransmitting unacknowledged packets, and for detecting duplicates. A consequence of this error detection/retransmission scheme is that the order of letters received on a given connection can also be maintained [CK74, Sunshine75]. To perform these functions, the TCP opens and closes connections between ports as described in section 4.2.

2. THE TCP INTERFACE TO THE USER

The functional description of user commands to the TCP is, at best, fictional, since every operating system will have different facilities. Consequently, we must warn readers that various TCP implementations may have different user interfaces. These will all be TCP’s, as long as control messages are properly interpreted or emitted, as required. In spite of this caveat, it appears useful to have at least one concrete view of a user interface to aid in thinking about TCP-derived services.

2.1 The TCP as a Post Office

The TCP acts in many ways like a postal service since it provides a way for processes to exchange letters with each other. It sometimes happens that a process may offer some service, but not know in advance what its correspondents’ addresses are. The analogy can be drawn with a mail order house which opens a post office box which can accept mail from any source. Unlike the post box, however, once a letter from a particular correspondent arrives, the resulting connection becomes specific to the correspondents until the correspondents declare otherwise—thus making the TCP more like a telephone service. Without this particularization, the TCP could not perform its flow control, sequencing, duplicate detection, end-to-end acknowledgement, and error control services.

2.2 Sockets and Addressing

We have borrowed the term SOCKET from the ARPANET terminology [CCC70, DCA76]. In general, a socket is the concatenation of an internetwork ADDRESS and a PORT identifier. A CONNECTION is fully specified by the pair of SOCKETS at each end since the same local socket name may participate in many connections to different foreign sockets.

Once the connection is specified in the OPEN command (see section 2.4.2), the TCP supplies a (short) local connection name by which the user refers to the connection in subsequent commands. As will be seen, this facilitates using connections with initially unspecified foreign sockets.

TCP’s are free to associate ports with processes however they choose. However, several basic concepts seem necessary in any implementation. There must be well known sockets which the TCP associates only with the “appropriate” processes by some means. We envision that processes may “own” sockets, and that processes can only initiate connections on the sockets they own. (Means for implementing ownership is a local issue, but we envision a Request Port user command, or a method of uniquely allocating a group of ports to a given process, e.g. by associating the high order bits of a port name with a given process.)

Once initiated, a connection may be passed to another process that does not own the local socket (e.g. from “logger” to service process). Strictly speaking this is a reconnection issue which might be more elegantly handled by a general reconnection protocol as discussed in section 3.3. To simplify passing a connection within a single TCP, however, such “invisible” switches may be allowed, as in TENEX systems.

Of course, each connection is associated with exactly one process, and any attempt to reference that connection by another process should be treated as an error by the TCP. This prevents another process from stealing data from or inserting data into another process’ data stream, and also prevents masquerading, spoofing, or other forms of malicious mischief (given a correct implementation of TCP in a protective operating system environment).

A connection is “initiated” by the rendezvous of an arriving internetwork packet and a waiting Transmission Control Block (TCB) created by a user OPEN, SEND, URGENT, or RECEIVE command (see section 2.4). The matching of local and foreign socket identifiers determines when a successful connection has been initiated. The connection becomes “established” when sequence numbers have been synchronized in both directions as described in section 4.2.2.

It is possible to specify a socket only partially by setting the PORT identifier to zero or setting both the TCP and PORT identifiers to zero. A socket of all zero is called UNSPECIFIED. The purpose behind unspecified sockets is to provide a sort of “general delivery” facility (useful for processes offering services on “well known” sockets).

There are bounds on the degree of unspecificity of socket identifiers. TCB’s must have fully specified local sockets, although the foreign socket may be fully or partly unspecified. Arriving packets must have fully specified sockets.

We employ the following notation:

x.y.z = fully specified socket with x=net, y=TCP, z=port
x.y.u = as above, but unspecified port
x.u.u = as above, but unspecified TCP and port
u.u.u = completely unspecified
with respect to implementation, u = 0 [zero]

We illustrate the principles of matching by giving all cases of incoming packets which match with existing TCB’s. Generally, both the local socket field of the TCB and the destination socket field of the arriving packet must match, and the foreign field of the TCB and the source socket field of the arriving packet must match.

	TCB-local	TCB-foreign	Packet-source	Packet-destination	
(a)	a.b.c	e.f.g	e.f.g	a.b.c	
(b)	a.b.c	e.f.u	e.f.g	a.b.c	
(c)	a.b.c	e.u.u	e.f.g	a.b.c	
(d)	a.b.c	u.u.u	e.f.g	a.b.c	

There are no other legal combinations of socket identifiers which match. Case (d) is typical of the ARPANET well known socket idea in which the well known socket (a.b.c) LISTENS for a connection from any (u.u.u) socket. Cases (b) and (c) can be used to restrict matching to a particular TCP or net. More elaborate masking facilities could be implemented without adverse effects, so this matching facility could be considered the minimum acceptable for TCP operation.

2.3 What is a Letter?

A letter is a sequence of one or more successive octets (8-bit bytes) on a TCP connection. The beginning of a letter is marked by a BOL control flag in a packet. The end of a letter is marked by the appearance of an EOL control flag in a packet. A letter is the minimum unit of information which must be passed from a receiving TCP to a receiving process. A TCP may pass less information to the receiving program, or it may pass more, but when a TCP has a complete letter it must not wait for more data from the remote process before passing the letter to the receiving process if the receiving process is ready to accept it.

Generally, the locations of letter boundaries are not passed to the receiving program. The exception is for non-reliable transmission (see section 4.2.8). In this case, when a section of data is missing, the data which follows must either begin on a letter boundary or contain an indication that the data does not begin on a letter boundary.

The sequence number of the first octet of data in any letters on a given connection is always equal to zero, modulo the receive buffer size. That is, whenever an EOL is transmitted, the sender advances his send sequence number by an amount (in the range 0 to buffersize–l) sufficient to consume all the unused space in the receiver’s buffer. The amount of space consumed in this fashion is accounted for in the flow control mechanism in the same way as space is consumed by real data (see section 4.5). The size of the receive buffer is communicated between the TCPs in the connection establishing exchange.

The EOL interpretation permits the receiving TCP to discard letter boundary information. Higher level protocols are required to provide their own mechanism for parsing the data stream and cannot depend on the EOL mechanism. EOL also has the property that it consumes all the unused space in a buffer (as specified in the buffer size option).

2.4 TCP User Commands

The following sections functionally characterize a USER/TCP interface. The notation used is similar to most procedure or function calls in high level languages, but this usage is not meant to rule out trap type service calls [e.g., SVC’s, UUO’s, EMT’s,…].

The user commands described below specify the basic functions the TCP will perform to support interprocess communication. Individual implementations should define their own exact format, and may provide combinations or subsets of the basic functions in single calls. In particular, some implementations may wish to automatically OPEN a connection on the first SEND, RECEIVE, or URGENT issued by the user for a given connection.

In providing interprocess communication facilities, the TCP must not only accept commands, but must also return information to the processes it serves. The latter consists of:

(a)	general information about a connection [e.g., interrupts, remote close, binding of unspecified foreign socket].

(b)	replies to specific user commands indicating success or various types of failure.

Although the means for signalling user processes and the exact format of replies will vary from one implementation to another, it would promote common understanding and testing if a common set of codes were adopted. Such a set of event codes is described in section 2.5.

2.4.1 Open

Format: OPEN (local port, foreign socket [, buffer size] [, timeout])

We assume that the local TCP is aware of the identity of the processes it serves and will check the authority of the process to use the connection specified. Depending upon the implementation of the TCP, the source network and TCP identifiers will either be supplied by the TCP or by the processes that serve it [e.g. the program which interfaces the TCP to its packet switch or the packet switch itself]. These considerations are the result of concern about security, to the extent that no TCP be able to masquerade as another one, and so on. Similarly, no process can masquerade as another without the collusion of the TCP.

If no foreign socket is specified (i.e. the foreign socket parameter is 0), then this constitutes a LISTENING local socket which can accept communication from any foreign socket. Provision is also made for partial specification of foreign sockets as described in section 2.2.

If the specified connection is already OPEN, an error is returned, otherwise a full-duplex transmission control block (TCB) is created and partially filled in with data from the OPEN command parameters. The TCB format is described in more detail in section 4.3.2.

No network traffic need be generated by the OPEN command. The first SEND or URGENT by the local user or the foreign user will typically cause the TCP to synchronize (i.e. establish) the connection, although synchronization could be immediately initiated on non-listening opens.

The buffer size, if present, indicates that the caller will always receive data from the connection in that size of buffers.

The timeout, if present, permits the caller to set up a timeout for all buffers transmitted on the connection. If a buffer is not successfully delivered to the destination within the timeout period, the TCP will abort the connection. The present global default is 30 seconds. The buffer retransmission rate may vary, and is the responsibility of the TCP and not the user. Most likely, it will be related to the measured time for responses from the remote TCP.

Depending on the TCP implementation, either a local connection name will be returned to the user by the TCP, or the user will specify this local connection name (in which case another parameter is needed in the call). The local connection name can then be used as a short hand term for the connection defined by the <local socket, foreign socket> pair.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

2.4.2 Send

Format: SEND(local connection name, buffer address, byte count, EOL flag [, timeout])

This call causes the data contained in the indicated user buffer to be sent on the indicated connection. If the connection has not been opened, the SEND is considered an error. Some implementations may allow users to SEND first, in which case an automatic OPEN would be done. If the calling process is not authorized to use this connection, an error is returned.

If the EOL flag is set, the data is the End Of a Letter, and the EOL bit will be set in the last internetwork packet created from the buffer (see section 4.3.2—TCP packet format). If the EOL flag is not set, subsequent SENDs will appear to be part of the same letter.

If no foreign socket was specified in the OPEN, but the connection is established (e.g. because a LISTENing connection has become specific due to a foreign packet arriving for the local socket) then the designated buffer is sent to the implied foreign socket. In general, users who make use of OPEN with an unspecified foreign socket can make use of SEND without ever explicitly knowing the foreign socket address.

However, if a SEND is attempted before the foreign socket becomes specified, an error will be returned. Users can use the STATUS call to determine the status of the connection. In some implementations the TCP may notify the user when an unspecified socket is bound.

If a timeout is specified, then the current timeout for this connection is changed to the new one.

In the simplest implementation, SEND would not return control to the sending process until either the transmission was complete or the timeout had been exceeded. However, this simple method is both highly subject to deadlocks (for example, both sides of the connection might try to do SENDs before doing any RECEIVEs) and offers poor performance, so it is not recommended. A more sophisticated implementation would return immediately to allow the process to run concurrently with network I/O, and, furthermore, to allow multiple SENDs to be in progress. Multiple SENDs are served in first come, first served order, so the TCP will queue those it cannot service immediately.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

We have implicitly assumed an asynchronous user interface in which a SEND later elicits some kind of SIGNAL or pseudo-interrupt from the serving TCP. An alternative is to return a response immediately. For instance, SENDs might return immediate local acknowledgment, even if the packet sent had not been acknowledged by the distant TCP. We could optimistically assume eventual success. If we are wrong, the connection will close, anyway, due to the timeout. In implementations of this kind (synchronous), there will still be some asynchronous signals, but these will deal with the connection itself, and not with specific packets or letters.

NOTA BENE: In order for the process to distinguish among error or success indications for different SENDs, it might be appropriate for the buffer address to be returned along with the coded response to the SEND request. We will offer an example event code format in section 2.5, showing the information which should be returned to the calling process.

2.4.3 Receive

Format: RECEIVE (local connection name, buffer address, byte count)

This command allocates a receiving buffer associated with the specified connection. If no OPEN precedes this command or the calling process is not authorized to use this connection, an error is returned.

In the simplest implementation, control would not return to the calling program until either the buffer was filled, or some error occurred, but this scheme is highly subject to deadlocks (see section 2.4.2). A more sophisticated implementation would permit several RECEIVEs to be outstanding at once. These would be filled as letters, segments or fragments arrive. This strategy permits increased throughput, at the cost of a more elaborate scheme (possibly asynchronous) to notify the calling program that a letter has been received or a buffer filled.

If insufficient buffer space is given to reassemble a complete letter, the EOL flag will not be set in the response to the RECEIVE. The buffer will be filled with as much data as it can hold (see section 2.5.2).

The remaining parts of a partly delivered letter will be placed in buffers as they are made available via successive RECEIVES. If a number of RECEIVES are outstanding, they may be filled with parts of a single long letter or with at most one letter each. The event codes associated with each RECEIVE will indicate what is contained in the buffer.

If a buffer size was given in the OPEN call, then all buffers presented in RECEIVE calls must be of exactly that size, or an error indication will be returned.

To distinguish among several outstanding RECEIVES, and to take care of the case that a letter is smaller than the buffer supplied, the event code is accompanied by both a buffer pointer and a byte count indicating the actual length of the letter received.

Responses from the TCP which may occur as a result of this command are detailed in sections 2.5 and 4.2.9.

Alternative implementations of RECEIVE might have the TCP allocate buffer storage, or the TCP might share a ring buffer with the user. Variations of this kind will produce obvious variation in user interface to the TCP.

2.4.4 Close

Format: CLOSE(local connection name)

This command causes the connection specified to be closed. If the connection is not open or the calling process is not authorized to use this connection, an error is returned. Closing connections is intended to be a graceful operation in the sense that outstanding SENDs will be transmitted (and retransmitted), as flow control permits, until all have been serviced. Thus, it should be acceptable to make several SEND calls, followed by a CLOSE, and expect all the data to be sent to the destination. It should also be clear that users should continue to RECEIVE on CLOSING connections, since the other side may be trying to transmit the last of its data. Thus, CLOSE means “I have no more to send” but does not mean “I will not receive any more.” It may happen (if the user level protocol is not well thought out) that the closing side is unable to get rid of all its data before timing out. In this event, CLOSE turns into ABORT, and the closing TCP gives up.

The user may CLOSE the connection at any time on his own initiative, or in response to various prompts from the TCP (e.g., remote close executed, transmission timeout exceeded, destination inaccessible).

Because closing a connection requires communication with the foreign TCP, connections may remain in the closing state for a short time. Attempts to reopen the connection before the TCP replies to the CLOSE command will result in error responses.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

2.4.5 Urgent

Format: URGENT(local connection name)

Special control information is sent to the destination indicating that urgent processing is appropriate. This facility can be used to simulate “break” signals from terminals or error or completion codes from I/O devices, for example. The semantics of this signal to the receiving process are unspecified. The receiving TCP will signal the urgent condition to the receiving process as long as the urgent pointer indicates data preceding the urgent pointer has not been consumed by the receiving process.

If the connection is not open or the calling process is not authorized to use this connection, an error is returned.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

2.4.6 Status

Format: STATUS(local connection name)

This is an implementation dependent user command and could be excluded without adverse effect. Information returned would typically come from the TCB (see section 4.3.3) associated with the connection.

This command returns a data block containing the following information:

local socket, foreign socket, local connection name, receive window, send window, connection state, number of buffers awaiting acknowledgement, number of buffers pending receipt (including partial ones), receive buffer size, urgent state, and default transmission timeout.

Depending on the state of the connection, on or the implementation itself, some of this information may not be available or meaningful. If the calling process is not authorized to use this connection, an error is returned. This prevents unauthorized processes from gaining information about a connection.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

2.4.7 Abort

Format: ABORT (local connection name)

This commend causes all pending SENDs, URGENTs, and RECEIVES to be aborted, the TCB to be removed, and a special RESET message to be sent to the TCP on the other side of the connection. Depending on the implementation, users may receive abort indications for each outstanding SEND, RECEIVE, or URGENT, or may simply receive an ABORT-acknowledgment. The mechanism of resetting a connection is discussed in sections 4.2.3 and 4.2.9.

Responses from the TCP which may occur as a result of this call are detailed in sections 2.5 and 4.2.9.

2.5 TCP-to-User Messages

2.5.1 Type Codes

All messages include a type code which identifies the type of user call to which the message applies. Types are:

	0	—	General message, spontaneously sent to user
	1	—	Applies to OPEN
	2	—	Applies to CLOSE
	3	—	Applies to URGENT
	4	—	Applies to ABORT
	10	—	Applies to SEND
	20	—	Applies to RECEIVE
	30	—	Applies to STATUS

2.5.2 Message Formats

All messages include the following three fields:

Type code
Local connection name
Event code

For message types 0–4 (General, Open, Close, Urgent, Abort) only these three fields are necessary.

For message type 10 (Send) one additional field is necessary:

Buffer address

For message type 20 (Receive) three additional fields are necessary:

Buffer address
Byte count (counts bytes received)
End-of-Letter flag

For message type 30 (Status) additional data might include:

Local socket, foreign socket
Send window (measures buffer space at foreign TCP)
Receive window (measures buffer space at local TCP)
Connection state (see section 4.2.9)
Number of buffers awaiting acknowledgement
Number of buffers awaiting receipt
Receive buffer size
Urgent State (urgent or not urgent)
User timeout

Once more, it is important to note that these formats are notional. Implementations which deal with buffering in different ways may or may not need to include buffer addresses in some responses, for example.

2.5.3 Event Codes

The event code specifies the particular event that the TCP wishes to communicate to the user. Generally speaking, non-zero event codes indicate important state changes or errors.

In addition to the event code, two flags may be useful to classify the event into major categories and facilitate event processing by the user:

E flag: set if event is an error
P flag: set if permanent error (otherwise, retry may succeed).

Events are encoded in 8 bits, the two high order bits being reserved for E and P flags, respectively.

Events specified so far are listed below with their codes and flag settings.

flags	code	meaning	
	0	general success	
E,P	1	connection illegal for this process	
	2	unspecified foreign socket has become bound	
E,P	3	connection not OPEN	
	4	insufficient resources	
E	5	foreign socket not specified	
E,P	6	connection already OPEN	
E	7	buffer size not acceptable	
	8	unused	
E,P	9	user timeout, connection aborted	
	10	unused	
	11	user urgent indication received	
P	12	connection closing	
E	13	general error	
P	14	connection reset	

Possible responses to each of the user commands are listed below. Section 4.2.9 offers substantially more detail.

Type 0	[general]:			2,							9,		11,	12,		14	
Type 1	[open]:	0,	1,			4,		6,							13		
Type 2	[close]:	0,	1,		3,						9,				13,	14	
Type 3	[urgent]:	0,	1,		3,	4,	5,				9,			12,	13,	14	
Type 4	[Abort]:	0,	1,		3,										13		
Type 10	[send]:	0,	1,		3,	4,	5,				9,			12,	13,	14	
Type 20	[receive]:	0,	1,		3,	4,			7,		9,			12,	13,	14	
Type 30	[status]:	0,	1,		3,										13		

3. HIGHER LEVEL PROTOCOLS

3.1 Introduction

It is expected that the TCP will be able to support higher level protocols efficiently. It should be easy to interface existing ARPANET protocols like TELNET [DCA76] and FTP [DCA76] to the TCP. Support of Network Voice Protocol, and broadcast protocols, for example, has been left to version 4 TCP.

3.2 Well Known Sockets

Well known sockets are a convenient mechanism for a priori associating a socket name with a standard service. For instance, the “telnet-server” process might be permanently assigned to a particular socket, and other sockets might be reserved for File Transfer, Remote Job Entry, text generator, reflector, and sink (the three being for test purposes). A socket name might be reserved for access to a “look-up” service which would return the specific socket at which a newly created service would be provided.

For compatibility with ARPANET socket naming conventions, we refer to the list of assigned sockets in RFC 739 [Postel77].

TCP implementors should note, however, that the gender and directionality of NCP sockets do not apply to TCP sockets, so that even numbered as well as odd ones can serve as well known sockets.

3.3 Reconnection Protocol

Port identifiers fall into two categories: permanent and transient. For example, a Telnet-server process is generally assigned a port identifier that is fixed and well known. Transient processes will in general have port identifiers which are dynamically assigned.

In a distributed processing environment, two processes that don’t have well known port identifiers may often wish to communicate. This can be achieved with the help of a well known process using a reconnection protocol. Such a protocol is briefly outlined using the communication facilities provided by the TCP. It essentially provides a mechanism by which port identifiers are exchanged in order to establish a connection between a pair of sockets.

Such a protocol can be used to achieve the dynamic establishment of new connections in order to have multiple processes solving a problem co-operatively, or to provide a user process access to a server-application process via a server-exec process, when the server-exec’s end of the connection can not be invisibly passed to the server-application process.

A paper on this subject by R. Schantz [Schantz74] discusses some of the issues associated with reconnection, and some of the ideas contained therein went into the design of the protocol outlined below.

In the ARPANET, a protocol (called the Initial Connection Protocol [Postel72]) was implemented which would allow a process to connect to a well known socket, thus making an implicit request for service, and then be switched to another socket so that the well known socket could be freed for use by others. Since sockets in our TCP are permitted to participate in more than one connection name, this facility may not be explicitly needed (i.e. connections <A,B> and <A,C> are distinguishable).

However, the well known socket may be in one network and the actual service socket(s) may be in another network (or at least in another TCP). Thus, the invisible switching of a connection from one port to another within a TCP may not be sufficient as an “Initial Connection Protocol”. Let Nx be a network identifier, and Tx be a TCP identifier. We imagine that a process wishes to use socket N1.T1.Q to access well known socket N2.T2.P. However, the process associated with socket N2.T2.P will actually start up a new process somewhere which will use N3.T3.S as its server socket. The N(i) and T(i) may be distinct or the same. The user will send to N2.T2.P the relevant user information such as user name, password, and account. This intermediate server will start up the actual server process and send to Nl.Tl.Q the actual service socket identifier: N3.T3.S. The connection (N1.T1.Q,N2.T2.P) can then be closed, and the user can do a RECEIVE on (Nl.Tl.Q,N3.T3.S). The serving process can SEND on (N3.T3.S,Nl.Tl.Q). There are many variations on this scheme, some involving the user process doing a RECEIVE on a different socket (e.g. (Nl.Tl.X,U.U.U)) with the server doing SEND on (N3.T3.S,Nl.Tl.X).

Without showing all the detail of synchronization of sequence numbers and the like, we can illustrate the exchange as shown below.

USER			SERVER
		1. RECEIVE(N2.T2.P,U.U.U)
1. SEND(N1.T1.Q,N2.T2.P)	==>
	<==	2. SEND(N2.T2.P,N1.T1.Q) with “N3.T3.S” as data
2. RECEIVE(N1.T1.Q,N2.T2.P)
3. CLOSE(N1.T1.Q,N2.T2.P)	==>
	<==	3. CLOSE(N2.T2.P,N1.T1.Q)
4. RECEIVE(N1.T1.Q,N3.T3.S)
	<==	4. SEND(N3.T3.S,N1.T1.Q)

Reconnection Protocol Example
Figure 3.3-1

At this point, a connection is open between N1.T1.Q and N3.T3.S. A variation might be to have the user do an extra RECEIVE on (Nl.T1.X,U.U.U) and have the data “N1.T1.X” be sent in the first user SEND. Then, the server can start up the real serving process and do a SEND on (N3.T3.S,N1.T1.X) without having to send the “N3.T3.S” data to the user. Or perhaps both server and receiver exchange this data, to assure security of the ultimate connection (i.e. some wild process might try to connect to N1.T1.X if it is merely RECEIVING on foreign socket U.U.U).

We do not propose any specific reconnection protocol here, but leave this to further deliberation, since it is really a user level protocol issue.

Further work on reconnection is in progress and version 4 of TCP may include provisions for reconnection via TCP control exchanges.

4. TCP DESIGN

4.1 Introduction

The TCP is designed to offer highly reliable, sequenced, and flow-controlled interprocess communication across network boundaries. A fundamental notion in the design is that every octet (8 bit byte) of data in an internetwork packet has a sequence number. Since every octet is sequenced, each of them can be acknowledged individually or collectively. In particular, the acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. This mechanism allows for straightforward duplicate detection in the presence of retransmission.

This also permits gateways to fragment packets as needed to get them across networks with short packet sizes. There is current discussion of how and where fragmentation should be done, and it may be that in version 4 TCP fragmentation is removed with the view that it is an internet function not specific to TCP.

It is essential to remember that the actual sequence number space is finite, though very large. In the current design, this space ranges from 0 to 2**32–1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32–1 to 0 again. The typical kinds of sequence number comparisons which the TCP must perform include:

(a)	determining that an acknowledgement refers to some sequence number sent but not yet acknowledged.

(b)	determining that all sequence numbers occupied by a packet have been acknowledged (e.g. to remove the packet from a retransmission queue).

(c)	determining that an incoming packet contains sequence numbers which are expected (i.e. that the packet “overlaps” the receive window).

The TCP typically maintains status information about each connection, as is illustrated in figure 4.1-1, below.

TCP State Information for Sending Sequence Space
Figure 4.1-1

L = oldest, unacknowledged sequence number
S = next sequence number to be sent
A = acknowledgement (next sequence number expected by the acknowledging TCP)
H(i) = first sequence number of the i-th packet
T(i) = last sequence number of the i-th packet

An acceptable acknowledgement, A, is one for which the inequality below holds:

0 < (A – L) <= (S – L)	(4.1-1)

We will often write equation (4.1-1) in the form below:

L < A <= S	(4.1-1')

Note that all arithmetic is modulo 2**32 and that comparisons are unsigned. “<=” means “less than or equal.”

Similarly, the determination that a particular packet has been fully acknowledged can be made if the equation below holds:

0 < (T(i) – L) < (A – L)	(4.1-2)

In this instance, H(i) and T(i) are related by the equation:

T(i) = H(i) + n(i) – 1	(4.1-3)

where n(i) = the number of octets occupied by the data in the packet. It is important to note that n(i) must be non-zero; packets which do not occupy any sequence space (e.g. empty acknowledgement packets) are never placed on the retransmission queue, so would not go through this particular test.

Finally, a packet is judged to occupy a portion of valid receive sequence space if

0 <= (T – N) < (R – N)	(4.1-4)

Where T is the last sequence number occupied by the packet, N is the next sequence number expected on an incoming packet, and R is the right edge of the receive window, as shown in figure 4.1-2.

Receive Sequence State Information
Figure 4.1-2

N = next sequence number expected on incoming packets
R = last sequence number expected on incoming packets, plus one
H(i) = first sequence number occupied by the i-th incoming packet
T(i) = last sequence number occupied by the i-th incoming packet

R and N in figure 4.1-2 are related by the equation:

R = N + W	(4.1-5)

Where W = the receive window size.

Note that the acceptance test for a packet, since it requires the end of a packet to lie in the window, is somewhat more restrictive than is absolutely necessary. If at least the first sequence number of the packet lies in the receive window, or if some part of the packet lies in the receive window, then the packet might be judged acceptable. Thus, in figure 4.1-2, at least packets 1 (H(l)–T(l)) and 2 (H(2)–T(2)) are acceptable by the strict rule and packet 3 (H(3)–T(3)) may or may not be, depending on the strictness of interpretation of the rule.

Note that when R = N, the receive window is zero and no packets should be acceptable except ACK packets. Thus, it should be possible for a TCP to maintain a zero receive window while transmitting data and receiving ACKs on a non-zero send window.

We have taken advantage of the numbering scheme to protect certain control information as well. This is achieved by implicitly including some control flags in the sequence space so they can be retransmitted and acknowledged without confusion (i.e. one and only one copy of the control will be acted upon). Control information is not physically carried in the packet  data space (see section 4.3.2 for typical internet TCP packet format). Consequently, we must adopt rules for implicitly assigning sequence numbers to control. In version 3 these sequenced controls have been reduced to only the SYN and FIN controls which are used only at connection opening and closing. For sequence number purposes, the SYN is considered to occur before the first actual data octet of the packet in which it occurs, while the FIN is considered to occur after the last actual data octet in a packet in which it occurs. The packet length includes both data and sequence-space-occupying controls.

The main jobs of the TCP are:

a.	Connection management (establishing and closing full-duplex connections)

b.	“Packetizing” of user letters into segments for internet transmission

c.	Reassembly of fragments into segments and segments into letters. (Note that the reassembly of fragments into segments may become an internet protocol function and of no concern to TCP in version 4.)

d.	Flow control, sequencing, duplicate detection, and retransmission for each connection.

e.	Reacting to user requests for service

In the sections which follow, we elaborate on the way in which the TCP is designed to carry out each of these tasks.

4.2 Connection Management

4.2.1 Initial Sequence Number Selection

The protocol places no restriction on a particular connection being used over and over again. Now instances of a connection will be referred to as incarnations of the connection. The problem that arises owing to this is, “how does the TCP identify duplicate packets from previous incarnations of the connection?”. This problem becomes harmfully apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.

The essence of the solution [Tomlinson74] is that the initial sequence number [ISN] must be chosen so that a particular sequence number can never refer to an “old” octet. Once the connection is established the sequencing mechanism provided by the TCP filters out duplicates.

For a connection to be established or initialized, the two TCP’s must synchronize on each other’s initial sequence numbers. This is done in an exchange of connection establishing messages carrying a control bit called “SYN” (for synchronize) and the initial sequence numbers, as a shorthand messages carrying the SYN bit are also called “SYNs”. Hence the solution requires a suitable mechanism for picking an initial sequence number, and a slightly involved handshake to exchange the ISN’s. A “three way handshake” is necessary because sequence numbers are not tied to a global clock in the network, and TCP’s may have different mechanisms for picking the ISN’s. The receiver of the first SYN has no way of knowing whether the packet was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN.

The “three way handshake” and the advantages of a “clock-driven” scheme are discussed in [Tomlinson74]. More on the subject, and algorithms for implementing the clock-driven scheme can be found in [Dalal74, Dalal75, Cerf76b].

4.2.2 Establishing a connection

The “three-way handshake” is essentially a unidirectional attempt to establish a connection, i.e. there is an initiator and a responder. The TCP can also establish a connection when a simultaneous initiation occurs. A simultaneous attempt occurs when one TCP receives a “SYN” packet which carries no acknowledgement after having sent a “SYN” earlier. Of course, the arrival of an old duplicate “SYN” packet can potentially make it appear, to the recipient, that a simultaneous connection initiation is in progress. Proper use of “reset” packets can disambiguate these cases. Several examples of connection initiation are offered below, using a notation due to Tomlinson. Although these examples do not show connection synchronization using data-carrying packets, this is perfectly legitimate, so long as the receiving TCP doesn’t deliver the data to the user until it is clear the data is valid (i.e. the data must be buffered at the receiver until the connection reaches the ESTABLISHED state (see figure 4.2-1)).