Obsoleted by: 7805 HISTORIC

Errata Exist

Network Working Group Vinton Cerf Request for Comments: 675 Yogen Dalal NIC: 2 Carl Sunshine INWG: 72 December 1974 SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM December 1974 Version 1 . INTRODUCTION Cerf, Dalal & Sunshine [Page 1]

RFC 675 Specification of Internet TCP December 1974 Section 2.2]. Processes exchange finite length LETTERS as a way of communicating; thus, letter boundaries are significant. However, the length of a letter may be such that it must be broken into FRAGMENTS before it can be transmitted to its destination. We assume that the fragments will normally be reassembled into a letter before being passed to the receiving process. Throughout this document, it is legitimate to assume that a fragment contains all or a part of a letter, but that a fragment never contains parts of more than one letter. We specifically assume that fragments are transmitted from Host to Host through means of a PACKET SWITCHING NETWORK [PSN] [ROWE70, POUZ73]. This assumption is probably unnecessary, since a circuit switched network 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 [HEKA7O, POUZ74, SCWI71]. Processes make use of the TCP by handing it letters. The TCP breaks these into fragments, if necessary, and then embeds each fragment 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 PS. The packet switches may perform further formatting 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 origin PSN with an intermediate or 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 Implementation. 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. Cerf, Dalal & Sunshine [Page 2]

RFC 675 Specification of Internet TCP December 1974 Section 4.3. The TCP performs retransmission, duplicate detection, sequencing, and flow control on all communication among the processes it serves. 2 . The TCP INTERFACE to the USER 2.1 The TCP as a POST OFFICE Cerf, Dalal & Sunshine [Page 3]

RFC 675 Specification of Internet TCP December 1974 2.2 Sockets and Addressing section 2.3.2], the TCP supplies a [short] Local Connection Name by which the user refers to the connection in subsequent commands. In particular 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 an implementation. There must be well known sockets [WKS] 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 call, 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, 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 will be signaled as an error by the TCP. This prevents stealing data from or inserting data into another process' data stream. 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, INTERPUPT, or RECEIVE call [see section 2.3]. 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.3.2. Cerf, Dalal & Sunshine [Page 4]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 5]

RFC 675 Specification of Internet TCP December 1974 2.3 TCP USER CALLS 2.3.1 A Note on Style section 2.4. With respect to error messages, references to "local" and "foreign" are ambiguous unless it is known whether these refer to the world as seen by the sender or receiver of the error message. The authors attempted several different approaches and finally settled on the convention that these references would be as seen by the receiver of the message. 2.3.2 OPEN CONNECTION Cerf, Dalal & Sunshine [Page 6]

RFC 675 Specification of Internet TCP December 1974 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.2.2. No network traffic is generated by the OPEN command. The first SEND or INTERRUPT by the local user or the foreign user will cause the TCP to synchronize the connection. The timeout, if present, permits the caller to set up a timeout for all letters transmitted on the connection. If a letter is not successfully transmitted within the timeout period, the user is notified and may ignore the condition [TCP will continue trying to transmit] or direct the TCP to close the connection. The present global default is 30 seconds, and connections which are set up without specifying another timeout will retransmit every letter for at least 30 seconds before notifying the user. The 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 to return from letters sent. 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 section 2.4. 2.3.3 SEND LETTER Cerf, Dalal & Sunshine [Page 7]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 8]

RFC 675 Specification of Internet TCP December 1974 section 2.4, showing the information which should be returned to the calling process. The semantics of the INTERRUPT call are described later, but this call can have an effect on letters which have been given to the TCP but not yet sent. In particular, all such letters are flushed by the source TCP. Thus one of the responses to a SEND may be "flushed due to interrupt." Responses from the TCP which may occur as a result of this call are detailed in section 2.4. 2.3.4 RECEIVE LETTER section 2.3.3]. A more sophisticated implementation would permit several RECEIVE's to be outstanding at once, These would be filled as letters 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. If insufficient buffer space is given to reassemble a complete letter, an indication that the buffer holds a partial letter will be given; the buffer will be filled with as much data as it can hold. 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. 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. Cerf, Dalal & Sunshine [Page 9]

RFC 675 Specification of Internet TCP December 1974 2.4.2 MESSAGE FORMAT [notional] section 4.3.6] Number of letters awaiting acknowledgment Number of letters awaiting receipt Retransmission timeout Cerf, Dalal & Sunshine [Page 12]

RFC 675 Specification of Internet TCP December 1974 2.4.3 EVENT CODES Cerf, Dalal & Sunshine [Page 13]

RFC 675 Specification of Internet TCP December 1974 3.3 RECONNECTION PROTOCOL (RCP) Cerf, Dalal & Sunshine [Page 15]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 16]

RFC 675 Specification of Internet TCP December 1974 section 2.4.3. 010: Special Functions 011: Reject (codes as yet undefined) 1XX: Unused 8 bits: Control Data Octet If CD is 000 then this octet is to be ignored. Cerf, Dalal & Sunshine [Page 18]

RFC 675 Specification of Internet TCP December 1974 section 2.4.3 If CD is 010, this octet contains a special function code as defined below: 0: RESET all connections between Source and Destination TCPs l: RESET the specific connection referenced in this packet 2: ECHO return packet to sender with the special function code ECHOR (Echo Reply). 3: QUERY Query status of connection referenced in this packet 4: STATUS Reply to QUERY with requested status. 5: ECHOR Echo Reply 6: TRASH Discard packet without acknowledgment >6: Unused Note: Special function packets not pertaining to a particular connection [RESET all, ECHO, ECHOR, and TRASH] are normally sent using socket zero as described in section 3.2. If CD is 01l, this octet contains an as yet undefined REJECT code. If CD is 1XX, this octet is undefined. 4 bits: Length of destination network address in 4 bit units (current value is 1) 4 bits: Destination network address 1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and EPSS respectively. 16 bits: Destination TCP address 8 bits: Padding 4 bits: length of source network address in 4 bit units (current value is 1) 4 bits: source network address (as for destination address) Cerf, Dalal & Sunshine [Page 19]

RFC 675 Specification of Internet TCP December 1974 4.2.2 TRANSMISSION CONTROL BLOCK Cerf, Dalal & Sunshine [Page 20]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 21]

RFC 675 Specification of Internet TCP December 1974 4.3 CONNECTION MANAGEMENT 4.3.1 INITIAL SEQUENCE NUMBER SELECTION Cerf, Dalal & Sunshine [Page 22]

RFC 675 Specification of Internet TCP December 1974 4.3.2 ESTABLISHING A CONNECTION Cerf, Dalal & Sunshine [Page 23]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 24]

RFC 675 Specification of Internet TCP December 1974 4.3.3 HALF-OPEN CONNECTIONS Cerf, Dalal & Sunshine [Page 25]

RFC 675 Specification of Internet TCP December 1974 4.3.4 RESYNCHRONIZING A CONNECTION 4.3.5 CLOSING A CONNECTION Cerf, Dalal & Sunshine [Page 26]

RFC 675 Specification of Internet TCP December 1974 section 4.3.3. When the acknowledging FIN arrives after the connection state bits are set (F=1, C=1), then the TCB can be deleted. Case 2: TCP receives a FIN from the network First of all, a FIN must have a sequence number which lies in the valid receive window. If not, it is discarded and the left window edge is sent as acknowledgment. If the FIN can be processed, it is handled (possibly out of order, since it is taken as an imperative to shut down the connection). All pending RECEIVES and SENDS are responded to by showing that they were terminated by the other side's close request (i.e. "connection closing"). The user is also told by an unsolicited event or signal that the connection has been closed (in some systems, the user might have to request STATUS to get this information). Finally, the TCP sends FIN in response. Thus, because a FIN arrived, a FIN is sent back, so the F bit is set. However, the TCB stays around until the local user does a CLOSE in acknowledgment of the unsolicited signal that the Cerf, Dalal & Sunshine [Page 27]

RFC 675 Specification of Internet TCP December 1974 4.3.6 . CONNECTION STATE and its relation to USER and INCOMING CONTROL REQUESTS In order to formalize the action taken by the TCP when it receives commands from the User, or Control information from the network, we define a connection to be in one of 7 states at any instant. These are known as the TCB Major States. Each Major State is simply a convenient name for a particular setting or group of settings of the state bits, as follows: S1 S2 R U F C # name - - - - - - 0 no TCB 0 0 0 0/1 0 0 1 unsync 1 0 0 0 0 0 2 SYN sent 1 0 1 0/1 0 0 3 SYN received 1 1 1 0 0 0 4 established 1 0/1 1 0/1 1 1 5 FIN wait 1 1 1 0 1 0 6 FIN received Cerf, Dalal & Sunshine [Page 28]

RFC 675 Specification of Internet TCP December 1974 Section 4.4.6 and section 4.4.7 fully specify the effect of all User commands and Control information arriving from the network. [0,l] <OPEN> <create TCB> [1,2] <SEND,INTERRUPT, or collision timeout> <send SYN> [1,3] <SYN arrives> <send SYN,ACK> [1,0] <CLOSE> <remove TCB> [2,1] <SYN arrives (collision)> <set timeout, forget SYNs> [2,0] <CLOSE> <remove TCB> [2,4] <appropriate SYN,ACK arrives> <send ACK> [3,4] <appropriate ACK arrives> <none> [3,1] <error arrives or timeout> <(forget SYN)> [3,5] <CLOSE> <send FIN> [4,5] <CLOSE> <send FIN> [4,6] <appropriate FIN arrives> <send FIN, inform user> [5,0] <FIN or error arrives, or timeout> <remove TCB> [6,0] <CLOSE> <remove TCB> 4.4 STRUCTURE 0F THE TCP Cerf, Dalal & Sunshine [Page 29]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 30]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 31]

RFC 675 Specification of Internet TCP December 1974 4.4.2 INPUT PACKET HANDLER [See figure 2.2] Cerf, Dalal & Sunshine [Page 32]

RFC 675 Specification of Internet TCP December 1974 Section 4.4.7 discusses this in greater detail, but as an example, if the incoming packet is a RESET request of any kind (i.e. all connections from designated TCP or given connection), and is believable, then the input packet handler clears out the related TCB(s), empties the send and receive packet queues, and prepares error returns for outstanding user SEND(s) and RECEIVE(s) on each reset TCB. The TCB's are marked unused and returned to storage. If the RESET refers to an unknown connection, it is ignored. Any ACK's contained in incoming packets are used to update the send left window edge, and to remove the ACK'ed packets from the TCB retransmit packet queue. If the packet being removed was the end of a user buffer, then the buffer must be dequeued from the packetized buffer queue, and the User informed. The packetizer is also signaled. Only one signal, or one for each packet, will have to be sent, depending on the scheduling scheme for the processes. See section 4.4.7 for a detailed discussion. The packet sequence number, the current receive window size, and the receive left window edge determine whether the packet lies within the window or outside of it. Let W = window size S = size of sequence number space L = left window edge R = L+W-1 = right window edge x = sequence number to be tested For any sequence number, x, if (R-x) mod S <= W then x is within the window. A packet should be rejected only if all of it lies outside the window. This is easily tested by letting x be, first the packet sequence number, and then the sum of packet sequence number and packet text length, less one. If the packet lies outside the window, and there are no packets waiting to be sent, then the input packet handler should construct a dummy ACK and queue it for output on the Cerf, Dalal & Sunshine [Page 33]

RFC 675 Specification of Internet TCP December 1974 4.4.3 REASSEMBLER [See figure 2.3] section 2.4. In every case when a packet is delivered to a buffer, the receive left window edge is updated, and the packetizer is signaled. This updating must take account of the extra octet included in the sequencing for certain control functions [SYN, INT, FIN, DSN]. If the send packet queue is empty then the reassembler must create a packet to carry the ACK, and place it on the send packet queue. Cerf, Dalal & Sunshine [Page 34]

RFC 675 Specification of Internet TCP December 1974 4.4.4 PACKETIZER [See figure 2.4] section 4.4.3. When the packetizer is awakened it looks at the SEND buffer queue for each TCB. If there is a new or partial letter awaiting packetization, it tries to packetize the letter, TCB buffer and window permitting. It packetizes no more than one letter for a TCB before servicing another TCB. For every packet produced it signals the output packet handler (to prevent deadlock in a time sliced scheduling scheme). If a 'run till completion' scheme is used then one signal only need be produced, the first time a packet is produced since awakening. If packetization is not possible the packetizer goes on to the next TCB. If a partial buffer was transferred then the packetizer must mark progress in the SEND buffer queue. Completely packetized buffers are dequeued from the SEND buffer queue, and placed on a Packetized buffer queue, so that the buffer can be returned to the user when an ACK for the last bit is received. When the packetizer packetizes a letter it must see whether it is the first piece of data being sent on the connection, in which case it must include the SYN bit. Some implementations may not permit data to be sent with SYN and others may discard any data received with SYN. Cerf, Dalal & Sunshine [Page 35]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 37]

RFC 675 Specification of Internet TCP December 1974 4.4.7 NETWORK CONTROL PROCESSING section 4.4.2 and figure 2.2], control and error packets are processed as shown in figures 4.l-4.7. [ACK and data processing is done within the IPC.] Cerf, Dalal & Sunshine [Page 38]

RFC 675 Specification of Internet TCP December 1974 4.5.3 The RECEIVE Side Cerf, Dalal & Sunshine [Page 40]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 41]

RFC 675 Specification of Internet TCP December 1974 5 . NETWORK MEASUREMENT PLANS FOR TCP 5.1 USERLEVEL DIAGNOSTICS 5.2 SINGLE CONNECTION MEASUREMENTS Cerf, Dalal & Sunshine [Page 42]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 43]

RFC 675 Specification of Internet TCP December 1974 5.3 MULTICONNECTION MEASUREMENTS 5.4 MEASUREMENT IMPLEMENTATION PHILOSOPHY Cerf, Dalal & Sunshine [Page 44]

RFC 675 Specification of Internet TCP December 1974 6 . SCHEDULE OF IMPLEMENTATION 7 . REFERENCES Cerf, Dalal & Sunshine [Page 45]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 46]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 47]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 48]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 49]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 50]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 51]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 52]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 53]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 54]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 55]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 56]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 57]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 58]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 59]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 60]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 61]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 62]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 63]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 64]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 65]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 66]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 67]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 68]

RFC 675 Specification of Internet TCP December 1974 Cerf, Dalal & Sunshine [Page 69]

RFC 675 Specification of Internet TCP December 1974