brian@sdcsvax.UCSD.EDU (Brian Kantor) (08/26/87)
[Page 22]
September 1981
Transmission Control Protocol
Functional Specification
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
[Page 23]
September 1981
Transmission Control Protocol
Functional Specification
3.3. Sequence Numbers
A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number. Since every octet is
sequenced, each of them can be acknowledged. 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 straight-forward duplicate
detection in the presence of retransmission. Numbering of octets
within a segment is that the first data octet immediately following
the header is the lowest numbered, and the following octets are
numbered consecutively.
It is essential to remember that the actual sequence number space is
finite, though very large. 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. There are some subtleties to computer modulo
arithmetic, so great care should be taken in programming the
comparison of such values. The symbol "=<" means "less than or equal"
(modulo 2**32).
The typical kinds of sequence number comparisons which the TCP must
perform include:
(a) Determining that an acknowledgment refers to some sequence
number sent but not yet acknowledged.
(b) Determining that all sequence numbers occupied by a segment
have been acknowledged (e.g., to remove the segment from a
retransmission queue).
(c) Determining that an incoming segment contains sequence numbers
which are expected (i.e., that the segment "overlaps" the
receive window).
[Page 24]
September 1981
Transmission Control Protocol
Functional Specification
In response to sending data the TCP will receive acknowledgments. The
following comparisons are needed to process the acknowledgments.
SND.UNA = oldest unacknowledged sequence number
SND.NXT = next sequence number to be sent
SEG.ACK = acknowledgment from the receiving TCP (next sequence
number expected by the receiving TCP)
SEG.SEQ = first sequence number of a segment
SEG.LEN = the number of octets occupied by the data in the segment
(counting SYN and FIN)
SEG.SEQ+SEG.LEN-1 = last sequence number of a segment
A new acknowledgment (called an "acceptable ack"), is one for which
the inequality below holds:
SND.UNA < SEG.ACK =< SND.NXT
A segment on the retransmission queue is fully acknowledged if the sum
of its sequence number and length is less or equal than the
acknowledgment value in the incoming segment.
When data is received the following comparisons are needed:
RCV.NXT = next sequence number expected on an incoming segments, and
is the left or lower edge of the receive window
RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming
segment, and is the right or upper edge of the receive window
SEG.SEQ = first sequence number occupied by the incoming segment
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
segment
A segment is judged to occupy a portion of valid receive sequence
space if
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
[Page 25]
September 1981
Transmission Control Protocol
Functional Specification
The first part of this test checks to see if the beginning of the
segment falls in the window, the second part of the test checks to see
if the end of the segment falls in the window; if the segment passes
either part of the test it contains data in the window.
Actually, it is a little more complicated than this. Due to zero
windows and zero length segments, we have four cases for the
acceptability of an incoming segment:
Segment Receive Test
Length Window
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Note that when the receive window is zero no segments should be
acceptable except ACK segments. Thus, it is be possible for a TCP to
maintain a zero receive window while transmitting data and receiving
ACKs. However, even when the receive window is zero, a TCP must
process the RST and URG fields of all incoming segments.
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 segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
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 segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length (SEG.LEN) includes both data and sequence
space occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.
[Page 26]
September 1981
Transmission Control Protocol
Functional Specification
Initial Sequence Number Selection
The protocol places no restriction on a particular connection being
used over and over again. A connection is defined by a pair of
sockets. New instances of a connection will be referred to as
incarnations of the connection. The problem that arises from this is
-- "how does the TCP identify duplicate segments from previous
incarnations of the connection?" This problem becomes 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.
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique.
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) is
learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done in
an exchange of connection establishing segments carrying a control bit
called "SYN" (for synchronize) and the initial sequence numbers. As a
shorthand, segments 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.
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
1) A --> B SYN my sequence number is X
2) A <-- B ACK your sequence number is X
3) A <-- B SYN my sequence number is Y
4) A --> B ACK your sequence number is Y
[Page 27]
September 1981
Transmission Control Protocol
Functional Specification
Because steps 2 and 3 can be combined in a single message this is
called the three way (or three message) handshake.
A three way handshake is necessary because sequence numbers are not
tied to a global clock in the network, and TCPs may have different
mechanisms for picking the ISN's. The receiver of the first SYN has
no way of knowing whether the segment 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 [3].
Knowing When to Keep Quiet
To be sure that a TCP does not create a segment that carries a
sequence number which may be duplicated by an old segment remaining in
the network, the TCP must keep quiet for a maximum segment lifetime
(MSL) before assigning any sequence numbers upon starting up or
recovering from a crash in which memory of sequence numbers in use was
lost. For this specification the MSL is taken to be 2 minutes. This
is an engineering choice, and may be changed if experience indicates
it is desirable to do so. Note that if a TCP is reinitialized in some
sense, yet retains its memory of sequence numbers in use, then it need
not wait at all; it must only be sure to use sequence numbers larger
than those recently used.
The TCP Quiet Time Concept
This specification provides that hosts which "crash" without
retaining any knowledge of the last sequence numbers transmitted on
each active (i.e., not closed) connection shall delay emitting any
TCP segments for at least the agreed Maximum Segment Lifetime (MSL)
in the internet system of which the host is a part. In the
paragraphs below, an explanation for this specification is given.
TCP implementors may violate the "quiet time" restriction, but only
at the risk of causing some old data to be accepted as new or new
data rejected as old duplicated by some receivers in the internet
system.
TCPs consume sequence number space each time a segment is formed and
entered into the network output queue at a source host. The
duplicate detection and sequencing algorithm in the TCP protocol
relies on the unique binding of segment data to sequence space to
the extent that sequence numbers will not cycle through all 2**32
values before the segment data bound to those sequence numbers has
been delivered and acknowledged by the receiver and all duplicate
copies of the segments have "drained" from the internet. Without
such an assumption, two distinct TCP segments could conceivably be
[Page 28]
September 1981
Transmission Control Protocol
Functional Specification
assigned the same or overlapping sequence numbers, causing confusion
at the receiver as to which data is new and which is old. Remember
that each segment is bound to as many consecutive sequence numbers
as there are octets of data in the segment.
Under normal conditions, TCPs keep track of the next sequence number
to emit and the oldest awaiting acknowledgment so as to avoid
mistakenly using a sequence number over before its first use has
been acknowledged. This alone does not guarantee that old duplicate
data is drained from the net, so the sequence space has been made
very large to reduce the probability that a wandering duplicate will
cause trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours
to use up 2**32 octets of sequence space. Since the maximum segment
lifetime in the net is not likely to exceed a few tens of seconds,
this is deemed ample protection for foreseeable nets, even if data
rates escalate to l0's of megabits/sec. At 100 megabits/sec, the
cycle time is 5.4 minutes which may be a little short, but still
within reason.
The basic duplicate detection and sequencing algorithm in TCP can be
defeated, however, if a source TCP does not have any memory of the
sequence numbers it last used on a given connection. For example, if
the TCP were to start all connections with sequence number 0, then
upon crashing and restarting, a TCP might re-form an earlier
connection (possibly after half-open connection resolution) and emit
packets with sequence numbers identical to or overlapping with
packets still in the network which were emitted on an earlier
incarnation of the same connection. In the absence of knowledge
about the sequence numbers used on a particular connection, the TCP
specification recommends that the source delay for MSL seconds
before emitting segments on the connection, to allow time for
segments from the earlier connection incarnation to drain from the
system.
Even hosts which can remember the time of day and used it to select
initial sequence number values are not immune from this problem
(i.e., even if time of day is used to select an initial sequence
number for each new connection incarnation).
Suppose, for example, that a connection is opened starting with
sequence number S. Suppose that this connection is not used much
and that eventually the initial sequence number function (ISN(t))
takes on a value equal to the sequence number, say S1, of the last
segment sent by this TCP on a particular connection. Now suppose,
at this instant, the host crashes, recovers, and establishes a new
incarnation of the connection. The initial sequence number chosen is
S1 = ISN(t) -- last used sequence number on old incarnation of
connection! If the recovery occurs quickly enough, any old
[Page 29]
September 1981
Transmission Control Protocol
Functional Specification
duplicates in the net bearing sequence numbers in the neighborhood
of S1 may arrive and be treated as new packets by the receiver of
the new incarnation of the connection.
The problem is that the recovering host may not know for how long it
crashed nor does it know whether there are still old duplicates in
the system from earlier connection incarnations.
One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quite
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quite time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
To summarize: every segment emitted occupies one or more sequence
numbers in the sequence space, the numbers occupied by a segment are
"busy" or "in use" until MSL seconds have passed, upon crashing a
block of space-time is occupied by the octets of the last emitted
segment, if a new connection is started too soon and uses any of the
sequence numbers in the space-time footprint of the last segment of
the previous connection incarnation, there is a potential sequence
number overlap area which could cause confusion at the receiver.
3.4. Establishing a connection
The "three-way handshake" is the procedure used to establish a
connection. This procedure normally is initiated by one TCP and
responded to by another TCP. The procedure also works if two TCP
simultaneously initiate the procedure. When simultaneous attempt
occurs, each TCP receives a "SYN" segment which carries no
acknowledgment after it has sent a "SYN". Of course, the arrival of
an old duplicate "SYN" segment can potentially make it appear, to the
recipient, that a simultaneous connection initiation is in progress.
Proper use of "reset" segments can disambiguate these cases.
Several examples of connection initiation follow. Although these
examples do not show connection synchronization using data-carrying
segments, 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). The three-way handshake
reduces the possibility of false connections. It is the
[Page 30]
September 1981
Transmission Control Protocol
Functional Specification
implementation of a trade-off between memory and messages to provide
information for this checking.
The simplest three-way handshake is shown in figure 7 below. The
figures should be interpreted in the following way. Each line is
numbered for reference purposes. Right arrows (-->) indicate
departure of a TCP segment from TCP A to TCP B, or arrival of a
segment at B from A. Left arrows (<--), indicate the reverse.
Ellipsis (...) indicates a segment which is still in the network
(delayed). An "XXX" indicates a segment which is lost or rejected.
Comments appear in parentheses. TCP states represent the state AFTER
the departure or arrival of the segment (whose contents are shown in
the center of each line). Segment contents are shown in abbreviated
form, with sequence number, control flags, and ACK field. Other
fields such as window, addresses, lengths, and text have been left out
in the interest of clarity.
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Figure 7.
In line 2 of figure 7, TCP A begins by sending a SYN segment
indicating that it will use sequence numbers starting with sequence
number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it
received from TCP A. Note that the acknowledgment field indicates TCP
B is now expecting to hear sequence 101, acknowledging the SYN which
occupied sequence 100.
At line 4, TCP A responds with an empty segment containing an ACK for
TCP B's SYN; and in line 5, TCP A sends some data. Note that the
sequence number of the segment in line 5 is the same as in line 4
because the ACK does not occupy sequence number space (if it did, we
would wind up ACKing ACK's!).
[Page 31]
September 1981
Transmission Control Protocol
Functional Specification
Simultaneous initiation is only slightly more complex, as is shown in
figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to
ESTABLISHED.
TCP A TCP B
1. CLOSED CLOSED
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
Simultaneous Connection Synchronization
Figure 8.
The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal with
this, a special control message, reset, has been devised. If the
receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
If the TCP is in one of the synchronized states (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
aborts the connection and informs its user. We discuss this latter
case under "half-open" connections below.
[Page 32]
September 1981
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. (duplicate) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED
4. SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED
5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
Figure 9.
As a simple example of recovery from old duplicates, consider
figure 9. At line 3, an old duplicate SYN arrives at TCP B. TCP B
cannot tell that this is an old duplicate, so it responds normally
(line 4). TCP A detects that the ACK field is incorrect and returns a
RST (reset) with its SEQ field selected to make the segment
believable. TCP B, on receiving the RST, returns to the LISTEN state.
When the original SYN (pun intended) finally arrives at line 6, the
synchronization proceeds normally. If the SYN at line 6 had arrived
before the RST, a more complex exchange might have occurred with RST's
sent in both directions.
Half-Open Connections and Other Anomalies
An established connection is said to be "half-open" if one of the
TCPs has closed or aborted the connection at its end without the
knowledge of the other, or if the two ends of the connection have
become desynchronized owing to a crash that resulted in loss of
memory. Such connections will automatically become reset if an
attempt is made to send data in either direction. However, half-open
connections are expected to be unusual, and the recovery procedure is
mildly involved.
If at site A the connection no longer exists, then an attempt by the
[Page 33]
September 1981
Transmission Control Protocol
Functional Specification
user at site B to send any data on it will result in the site B TCP
receiving a reset control message. Such a message indicates to the
site B TCP that something is wrong, and it is expected to abort the
connection.
Assume that two user processes A and B are communicating with one
another when a crash occurs causing loss of memory to A's TCP.
Depending on the operating system supporting A's TCP, it is likely
that some error recovery mechanism exists. When the TCP is up again,
A is likely to start again from the beginning or from a recovery
point. As a result, A will probably try to OPEN the connection again
or try to SEND on the connection it believes open. In the latter
case, it receives the error message "connection not open" from the
local (A's) TCP. In an attempt to establish the connection, A's TCP
will send a segment containing SYN. This scenario leads to the
example shown in figure 10. After TCP A crashes, the user attempts to
re-open the connection. TCP B, in the meantime, thinks the connection
is open.
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. CLOSED ESTABLISHED
3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
6. SYN-SENT CLOSED
7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
Half-Open Connection Discovery
Figure 10.
When the SYN arrives at line 3, TCP B, being in a synchronized state,
and the incoming segment outside the window, responds with an
acknowledgment indicating what sequence it next expects to hear (ACK
100). TCP A sees that this segment does not acknowledge anything it
sent and, being unsynchronized, sends a reset (RST) because it has
detected a half-open connection. TCP B aborts at line 5. TCP A will
[Page 34]
September 1981
Transmission Control Protocol
Functional Specification
continue to try to establish the connection; the problem is now
reduced to the basic 3-way handshake of figure 7.
An interesting alternative case occurs when TCP A crashes and TCP B
tries to send data on what it thinks is a synchronized connection.
This is illustrated in figure 11. In this case, the data arriving at
TCP A from TCP B (line 2) is unacceptable because no such connection
exists, so TCP A sends a RST. The RST is acceptable so TCP B
processes it and aborts the connection.
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
3. --> <SEQ=100><CTL=RST> --> (ABORT!!)
Active Side Causes Half-Open Connection Discovery
Figure 11.
In figure 12, we find the two TCPs A and B with passive connections
waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B
into action. A SYN-ACK is returned (line 3) and causes TCP A to
generate a RST (the ACK in line 3 is not acceptable). TCP B accepts
the reset and returns to its passive LISTEN state.
TCP A TCP B
1. LISTEN LISTEN
2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED
3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED
4. --> <SEQ=Z+1><CTL=RST> --> (return to LISTEN!)
5. LISTEN LISTEN
Old Duplicate SYN Initiates a Reset on two Passive Sockets
Figure 12.
[Page 35]
September 1981
Transmission Control Protocol
Functional Specification
A variety of other cases are possible, all of which are accounted for
by the following rules for RST generation and processing.
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
1. If the connection does not exist (CLOSED) then a reset is sent
in response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
2. If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
[Page 36]
September 1981
Transmission Control Protocol
Functional Specification
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window. In the SYN-SENT state (a RST received in response
to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN.
The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state.
3.5. Closing a Connection
CLOSE is an operation meaning "I have no more data to send." The
notion of closing a full-duplex connection is subject to ambiguous
interpretation, of course, since it may not be obvious how to treat
the receiving side of the connection. We have chosen to treat CLOSE
in a simplex fashion. The user who CLOSEs may continue to RECEIVE
until he is told that the other side has CLOSED also. Thus, a program
could initiate several SENDs followed by a CLOSE, and then continue to
RECEIVE until signaled that a RECEIVE failed because the other side
has CLOSED. We assume that the TCP will signal a user, even if no
RECEIVEs are outstanding, that the other side has closed, so the user
can terminate his side gracefully. A TCP will reliably deliver all
buffers SENT before the connection was CLOSED so a user who expects no
data in return need only wait to hear the connection was CLOSED
successfully to know that all his data was received at the destination
TCP. Users must keep reading connections they close for sending until
the TCP says no more data.
[Page 37]
September 1981
Transmission Control Protocol
Functional Specification
There are essentially three cases:
1) The user initiates by telling the TCP to CLOSE the connection
2) The remote TCP initiates by sending a FIN control signal
3) Both users CLOSE simultaneously
Case 1: Local user initiates the close
In this case, a FIN segment can be constructed and placed on the
outgoing segment queue. No further SENDs from the user will be
accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs
are allowed in this state. All segments preceding and including FIN
will be retransmitted until acknowledged. When the other TCP has
both acknowledged the FIN and sent a FIN of its own, the first TCP
can ACK this FIN. Note that a TCP receiving a FIN will ACK but not
send its own FIN until its user has CLOSED the connection also.
Case 2: TCP receives a FIN from the network
If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user will respond with a CLOSE, upon which the TCP can send a FIN to
the other TCP after sending any remaining data. The TCP then waits
until its own FIN is acknowledged whereupon it deletes the
connection. If an ACK is not forthcoming, after the user timeout
the connection is aborted and the user is told.
Case 3: both users close simultaneously
A simultaneous CLOSE by users at both ends of a connection causes
FIN segments to be exchanged. When all segments preceding the FINs
have been processed and acknowledged, each TCP can ACK the FIN it
has received. Both will, upon receiving these ACKs, delete the
connection.
[Page 38]
September 1981
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
Normal Close Sequence
Figure 13.
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close) (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
<-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
<-- <SEQ=301><ACK=101><CTL=ACK> <--
... <SEQ=101><ACK=301><CTL=ACK> -->
4. TIME-WAIT TIME-WAIT
(2 MSL) (2 MSL)
CLOSED CLOSED
Simultaneous Close Sequence
Figure 14.
[Page 39]
September 1981
Transmission Control Protocol
Functional Specification
3.6. Precedence and Security
The intent is that connection be allowed only between ports operating
with exactly the same security and compartment values and at the
higher of the precedence level requested by the two ports.
The precedence and security parameters used in TCP are exactly those
defined in the Internet Protocol (IP) [2]. Throughout this TCP
specification the term "security/compartment" is intended to indicate
the security parameters used in IP including security, compartment,
user group, and handling restriction.
A connection attempt with mismatched security/compartment values or a
lower precedence value must be rejected by sending a reset. Rejecting
a connection due to too low a precedence only occurs after an
acknowledgment of the SYN has been received.
Note that TCP modules which operate only at the default value of
precedence will still have to check the precedence of incoming
segments and possibly raise the precedence level they use on the
connection.
The security paramaters may be used even in a non-secure environment
(the values would indicate unclassified data), thus hosts in
non-secure environments must be prepared to receive the security
parameters, though they need not send them.
3.7. Data Communication
Once the connection is established data is communicated by the
exchange of segments. Because segments may be lost due to errors
(checksum test failure), or network congestion, TCP uses
retransmission (after a timeout) to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission.
As discussed in the section on sequence numbers the TCP performs
certain tests on the sequence and acknowledgment numbers in the
segments to verify their acceptability.
The sender of data keeps track of the next sequence number to use in
the variable SND.NXT. The receiver of data keeps track of the next
sequence number to expect in the variable RCV.NXT. The sender of data
keeps track of the oldest unacknowledged sequence number in the
variable SND.UNA. If the data flow is momentarily idle and all data
sent has been acknowledged then the three variables will be equal.
When the sender creates a segment and transmits it the sender advances
SND.NXT. When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment. When the data sender receives an
[Page 40]
September 1981
Transmission Control Protocol
Functional Specification
acknowledgment it advances SND.UNA. The extent to which the values of
these variables differ is a measure of the delay in the communication.
The amount by which the variables are advanced is the length of the
data in the segment. Note that once in the ESTABLISHED state all
segments must carry current acknowledgment information.
The CLOSE user call implies a push function, as does the FIN control
flag in an incoming segment.
Retransmission Timeout
Because of the variability of the networks that compose an
internetwork system and the wide range of uses of TCP connections the
retransmission timeout must be dynamically determined. One procedure
for determining a retransmission time out is given here as an
illustration.
An Example Retransmission Timeout Procedure
Measure the elapsed time between sending a data octet with a
particular sequence number and receiving an acknowledgment that
covers that sequence number (segments sent do not have to match
segments received). This measured elapsed time is the Round Trip
Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
and based on this, compute the retransmission timeout (RTO) as:
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
where UBOUND is an upper bound on the timeout (e.g., 1 minute),
LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
factor (e.g., 1.3 to 2.0).
The Communication of Urgent Information
The objective of the TCP urgent mechanism is to allow the sending user
to stimulate the receiving user to accept some urgent data and to
permit the receiving TCP to indicate to the receiving user when all
the currently known urgent data has been received by the user.
This mechanism permits a point in the data stream to be designated as
the end of urgent information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
must tell the user to go into "urgent mode"; when the receive sequence
number catches up to the urgent pointer, the TCP must tell user to go
[Page 41]
September 1981
Transmission Control Protocol
Functional Specification
into "normal mode". If the urgent pointer is updated while the user
is in "urgent mode", the update will be invisible to the user.
The method employs a urgent field which is carried in all segments
transmitted. The URG control flag indicates that the urgent field is
meaningful and must be added to the segment sequence number to yield
the urgent pointer. The absence of this flag indicates that there is
no urgent data outstanding.
To send an urgent indication the user must also send at least one data
octet. If the sending user also indicates a push, timely delivery of
the urgent information to the destination process is enhanced.
Managing the Window
The window sent in each segment indicates the range of sequence
numbers the sender of the window (the data receiver) is currently
prepared to accept. There is an assumption that this is related to
the currently available data buffer space available for this
connection.
Indicating a large window encourages transmissions. If more data
arrives than can be accepted, it will be discarded. This will result
in excessive retransmissions, adding unnecessarily to the load on the
network and the TCPs. Indicating a small window may restrict the
transmission of data to the point of introducing a round trip delay
between each new segment transmitted.
The mechanisms provided allow a TCP to advertise a large window and to
subsequently advertise a much smaller window without having accepted
that much data. This, so called "shrinking the window," is strongly
discouraged. The robustness principle dictates that TCPs will not
shrink the window themselves, but will be prepared for such behavior
on the part of other TCPs.
The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when
the window is zero. Two minutes is recommended for the retransmission
interval when the window is zero. This retransmission is essential to
guarantee that when either TCP has a zero window the re-opening of the
window will be reliably reported to the other.
When the receiving TCP has a zero window and a segment arrives it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).
The sending TCP packages the data to be transmitted into segments
[Page 42]
September 1981
Transmission Control Protocol
Functional Specification
which fit the current window, and may repackage segments on the
retransmission queue. Such repackaging is not required, but may be
helpful.
In a connection with a one-way data flow, the window information will
be carried in acknowledgment segments that all have the same sequence
number so there will be no way to reorder them if they arrive out of
order. This is not a serious problem, but it will allow the window
information to be on occasion temporarily based on old reports from
the data receiver. A refinement to avoid this problem is to act on
the window information from segments that carry the highest
acknowledgment number (that is segments with acknowledgment number
equal or greater than the highest previously received).
The window management procedure has significant influence on the
communication performance. The following comments are suggestions to
implementers.
Window Management Suggestions
Allocating a very small window causes data to be transmitted in
many small segments when better performance is achieved using
fewer large segments.
One suggestion for avoiding small windows is for the receiver to
defer updating a window until the additional allocation is at
least X percent of the maximum allocation possible for the
connection (where X might be 20 to 40).
Another suggestion is for the sender to avoid sending small
segments by waiting until the window is large enough before
sending data. If the the user signals a push function then the
data must be sent even if it is a small segment.
Note that the acknowledgments should not be delayed or unnecessary
retransmissions will result. One strategy would be to send an
acknowledgment when a small segment arrives (with out updating the
window information), and then to send another acknowledgment with
new window information when the window is larger.
The segment sent to probe a zero window may also begin a break up
of transmitted data into smaller and smaller segments. If a
segment containing a single data octet sent to probe a zero window
is accepted, it consumes one octet of the window now available.
If the sending TCP simply sends as much as it can whenever the
window is non zero, the transmitted data will be broken into
alternating big and small segments. As time goes on, occasional
pauses in the receiver making window allocation available will
[Page 43]
September 1981
Transmission Control Protocol
Functional Specification
result in breaking the big segments into a small and not quite so
big pair. And after a while the data transmission will be in
mostly small segments.
The suggestion here is that the TCP implementations need to
actively attempt to combine small window allocations into larger
windows, since the mechanisms for managing the window tend to lead
to many small windows in the simplest minded implementations.
3.8. Interfaces
There are of course two interfaces of concern: the user/TCP interface
and the TCP/lower-level interface. We have a fairly elaborate model
of the user/TCP interface, but the interface to the lower level
protocol module is left unspecified here, since it will be specified
in detail by the specification of the lowel level protocol. For the
case that the lower level is IP we note some of the parameter values
that TCPs might use.
User/TCP Interface
The following 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 different TCP
implementations may have different user interfaces. However, all
TCPs must provide a certain minimum set of services to guarantee
that all TCP implementations can support the same protocol
hierarchy. This section specifies the functional interfaces
required of all TCP implementations.
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., SVCs, UUOs,
EMTs).
The user commands described below specify the basic functions the
TCP must perform to support interprocess communication.
Individual implementations must 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 or RECEIVE
issued by the user for a given connection.
[Page 44]
September 1981
Transmission Control Protocol
Functional Specification
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.
Open
Format: OPEN (local port, foreign socket, active/passive
[, timeout] [, precedence] [, security/compartment] [, options])
-> local connection name
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 local network and TCP identifiers
for the source address will either be supplied by the TCP or the
lower level protocol (e.g., IP). 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 the active/passive flag is set to passive, then this is a
call to LISTEN for an incoming connection. A passive open may
have either a fully specified foreign socket to wait for a
particular connection or an unspecified foreign socket to wait
for any call. A fully specified passive call can be made active
by the subsequent execution of a SEND.
A transmission control block (TCB) is created and partially
filled in with data from the OPEN command parameters.
On an active OPEN command, the TCP will begin the procedure to
synchronize (i.e., establish) the connection at once.
The timeout, if present, permits the caller to set up a timeout
for all data submitted to TCP. If data is not successfully
delivered to the destination within the timeout period, the TCP
will abort the connection. The present global default is five
minutes.
The TCP or some component of the operating system will verify
the users authority to open a connection with the specified
[Page 45]
September 1981
Transmission Control Protocol
Functional Specification
precedence or security/compartment. The absence of precedence
or security/compartment specification in the OPEN call indicates
the default values must be used.
TCP will accept incoming requests as matching only if the
security/compartment information is exactly the same and only if
the precedence is equal to or higher than the precedence
requested in the OPEN call.
The precedence for the connection is the higher of the values
requested in the OPEN call and received from the incoming
request, and fixed at that value for the life of the
connection.Implementers may want to give the user control of
this precedence negotiation. For example, the user might be
allowed to specify that the precedence must be exactly matched,
or that any attempt to raise the precedence be confirmed by the
user.
A local connection name will be returned to the user by the TCP.
The local connection name can then be used as a short hand term
for the connection defined by the <local socket, foreign socket>
pair.
Send
Format: SEND (local connection name, buffer address, byte
count, PUSH flag, URGENT 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 PUSH flag is set, the data must be transmitted promptly
to the receiver, and the PUSH bit will be set in the last TCP
segment created from the buffer. If the PUSH flag is not set,
the data may be combined with data from subsequent SENDs for
transmission efficiency.
If the URGENT flag is set, segments sent to the destination TCP
will have the urgent pointer set. The receiving TCP will signal
the urgent condition to the receiving process if the urgent
pointer indicates that data preceding the urgent pointer has not
been consumed by the receiving process. The purpose of urgent
is to stimulate the receiver to process the urgent data and to
indicate to the receiver when all the currently known urgent
[Page 46]
September 1981
Transmission Control Protocol
Functional Specification
data has been received. The number of times the sending user's
TCP signals urgent will not necessarily be equal to the number
of times the receiving user will be notified of the presence of
urgent data.
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 segment arriving for the
local socket), then the designated buffer is sent to the implied
foreign socket. 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, the current user 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 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.
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 segment 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 segments or buffers.
In order for the process to distinguish among error or success