TCP.

TCP.

The TCP/IP protocol suite includes two transport-level protocols: the Transmission

Control Protocol (TCP), which is connection-oriented, and the User Datagram Protocol

(UDP), which is connectionless. In this section, we look at TCP (specified in

RFC 793)-first at the service it provides to the TS user, and then at the internal

protocol details.

TCP Services

TCP is designed to provide reliable communication between pairs of processes

(TCP users) across a variety of reliable and unreliable networks and internets.

Functionally, it is equivalent to Class 4 IS0 Transport. In contrast to the IS0

model, TCP is stream oriented. That is, TCP users exchange streams of data. The

data are placed in allocated buffers and transmitted by TCP in segments. TCP supports

security and precedence labeling. In addition, TCP provides two useful facilities

for labeling data, push and urgent:

Data stream push. Ordinarily, TCP decides when sufficient data have accumulated

to form a segment for transmission. The TCP user can require TCP

to transmit all outstanding data up to and including those labeled with a push

flag. On the receiving end, TCP will deliver these data to the user in the same

manner; a user might request this if it has come to a logical break in the data.

Urgent data signaling. This provides a means of informing the destination

TCP user that significant or "urgent" data is in the upcoming data stream. It

is up to the destination user to determine appropriate action.

As with IP, the services provided by TCP are defined in terms of primitives

and parameters. The services provided by TCP are considerably richer than those

provided by IP, and, hence, the set of primitives and parameters is more complex.

Table 17.2 lists TCP service request primitives, which are issued by a TCP user to

TCP, and Table 17.3 lists TCP service response primitives, which are issued by TCP

to a local TCP user. Table 17.4 provides a brief definition of the parameters

involved. Several comments are in order.

The two Passive Open commands signal the TCP user's willingness to accept

a connection request. The Active Open with Data allows the user to begin transmitting

data with the opening of the connection.

TCP Header Format

TCP uses only a single type of protocol data unit, called a TCP segment. The header

is shown in Figure 17.14. Because one header must serve to perform all protocol

mechanisms, it is rather large, with a minimum length of 20 octets. The fields are

Source port (16 bits). Source service access point.

Destination port (16 bits). Destination service access point.

Sequence number (32 bits). Sequence number of the first data octet in this

segment except when SYN flag is set. If SYN is set, it is the initial sequence

number (ISN), and the first data octet is ISN + 1.

Acknowledgment number (32 bits). A piggybacked acknowledgment. Contains

the sequence number of the next data octet that the TCP entity expects

to receive.

Data offset (4 bits). Number of 32-bit words in the header.

Reserved (6 bits). Reserved for future use.

Flags (6 bits).

URG: Urgent pointer field significant.

ACK: Acknowledgment field significant.

PSH: Push function.

RST: Reset the connection.

SYN: Synchronize the sequence numbers.

FIN: No more data from sender.

Window (16 bits). Flow control credit allocation, in octets. Contains the number

of data octets beginning with the one indicated in the acknowledgment

field that the sender is willing to accept.

Checksum (16 bits). The one's complement of the sum modulo 216-1 of all the

16-bit words in the segment, plus a pseudo-header. The situation is described

below.

Urgent Pointer (16 bits). Points to the last octet in a sequence of urgent data;

this allows the receiver to know how much urgent data is coming.

Options (Variable). At present, only one option is defined, which specifies the

maximum segment size that will be accepted.

 

Several of the fields in the TCP header warrant further elaboration. The

soztrce port and destination port specify the sending and receiving users of TCP. As

with IP, there are a number of common users of TCP that have been assigned numbers;

these numbers should be reserved for that purpose in any implementation.

Other port numbers must be arranged by agreement between communicating

parties.

The sequence number and acknowledgment number are bound to octets rather

than to entire segments. For example, if a segment contains sequence number 1000

and includes 600 octets of data, the sequence number refers to the first octet in the

data field; the next segment in logical order will have sequence number 1600. Thus,

TCP is logically stream-oriented: It accepts a stream of octets from the user, groups

them into segments as it sees fit, and numbers each octet in the stream.

The checksum field applies to the entire segment, plus a pseudo-header prefixed

to the header at the time of calculation (at both transmission and reception).

The pseudo-header includes the following fields from the IP header: source and

destination internet address and protocol, plus a segment length field (Figure

17.15). By including the pseudo-header, TCP protects itself from misdelivery by IP.

That is, if IP delivers a segment to the wrong host, even if the segment contains no

bit errors, the receiving TCP entity will detect the delivery error. If TCP is used over

IPv6, then the pseudo-header is different, and is depicted in Figure 16.21.

The reader may feel that some items are missing from the TCP header, and

that is indeed the case. TCP is designed specifically to work with IP. Hence, some

 

user parameters are passed down by TCP to IP for inclusion in the IP header. The

relevant ones are

9 Precedence: a 3-bit field

9 Normal-delayllow-delay

Normal-throughputlhigh-throughput

Normal-reliabilitylhigh-reliability

9 Security: an 11-bit field

It is worth observing that this TCPIIP linkage means that the required minimum

overhead for every data unit is actually 40 octets.

TCP Mechanisms

Connection Establishment

Connection establishment in TCP always uses a three-way handshake. When the

SYN flag is set, the segment is essentially a request for connection (RFC), and thus

functions as explained in Section 17.2. To initiate a connection, an entity sends an

RFC X, where Xis the initial sequence number. The receiver responds with RFC

Y, ACK X by setting both the SYN and ACK flags. Finally, the initiator responds

with ACK Y. If both sides issue crossing RFCs, no problem results; both sides

respond with ACKs.

A connection is uniquely determined by the source and destination ports.

Thus, at any one time, there can only be a single TCP connection between a unique

pair of ports. However, a given port can support multiple connections, each with a

different partner port.

Data Transfer

Although data are transferred in segments over a transport connection, data

transfer is viewed logically as consisting of a stream of octets. Hence, every octet is

numbered, modulo 2^23. Each segment contains the sequence number of the first

octet in the data field. Flow control is exercised using a credit allocation scheme in

which the credit is a number of octets rather than a number of segments.

As was mentioned, data are buffered by the transport entity on both transmission

and reception. TCP normally exercises its own discretion as to when to construct

a segment for transmission and when to release received data to the user. The

PUSH flag is used to force the data so-far accumulated to be sent by the transmitter

and passed on by the receiver. This serves an end-of-letter function.

The user may specify a block of data as urgent. TCP will designate the end of

that block with an urgent pointer and send it out in the ordinary data stream. The

receiving user is alerted that urgent data are being received.

If, during data exchange, a segment arrives that is apparently not meant for

the current connection, the RST flag is set on an outgoing segment. Examples of

this situation are delayed duplicate SYNs and an acknowledgment of data not yet

sent.

Connection Termination

The normal means of terminating a connection consists of a graceful close. Each

TCP user must issue a CLOSE primitive. The transport entity sets the FIN bit on

the last segment that it sends out, which also contains the last of the data to be sent

on this connection.

An abrupt termination occurs if the user issues an ABORT primitive. In this

case, the entity abandons all attempts to send or receive data and discards data in

its transmission and reception buffers. An RST segment is sent to the other side.

TCP Implementation Policy Options

The TCP standard provides a precise specification of the protocol to be used

between TCP entities. However, certain aspects of the protocol admit several possible

implementation options. Although two implementations that choose alternative

options will be interoperable, there may be performance implications. The

design-area options are the following:

Send policy

Deliver policy

Accept policy

Retransmit policy

Acknowledge policy

Send Policy

In the absence of pushed data and a closed transmission window (see Figure 17.6a),

a sending TCP entity is free to transmit data at its own convenience. As data are

issued by the user, they are buffered in the transmit buffer. TCP may construct a

segment for each batch of data provided by its user, or it may wait until a certain

amount of data accumulates before constructing and sending a segment. The actual

policy will depend on performance considerations. If transmissions are infrequent

and large, there is low overhead in terms of segment generation and processing. On

the other hand, if transmissions are frequent and small, then the system is providing

quick response.

One danger of frequent, small transmissions is known as the silly window syndrome,

which is discussed in Problem 17.19.

Deliver Policy

In the absence of a push, a receiving TCP entity is free to deliver data to the user at

its own convenience. It may deliver data as each in-order segment is received, or it

may buffer data from a number of segments in the receive buffer before delivery.

The actual policy will depend on performance considerations. If deliveries are infrequent

and large, the user is not receiving data as promptly as may be desirable. On

the other hand, if deliveries are frequent and small, there may be unnecessary processing

both in TCP and in the user software, as well as an unnecessary number of

operating-system interrupts.

Accept Policy

When all data segments arrive in order over a TCP connection, TCP places the data

in a receive buffer for delivery to the user. It is possible, however, for segments to

arrive out of order. In this case, the receiving TCP entity has two options:

In-order. Accept only segments that arrive in order; any segment that arrives

out of order is discarded.

In-window. Accept all segments that are within the receive window (see Figure

17.6b).

The in-order policy makes for a simple implementation but places a burden on

the networking facility, as the sending TCP must time-out and retransmit segments

that were successfully received but discarded because of misordering. Furthermore,

if a single segment is lost in transit, then all subsequent segments must be retransmitted

once the sending TCP times out on the lost segment.

The in-window policy may reduce transmissions but requires a more complex

acceptance test and a more sophisticated data storage scheme to buffer and keep

track of data accepted out of order.

For class 4 IS0 transport (TP4), the in-window policy is mandatory.

Retransmit Policy

TCP maintains a queue of segments that have been sent but not yet acknowledged.

The TCP specification states that TCP will retransmit a segment if it fails to receive

an acknowledgment within a given time. A TCP implementation may employ one

of three retransmission strategies:

First-only. Maintain one retransmission timer for the entire queue. If an

acknowledgment is received, remove the appropriate segment or segments

from the queue and reset the timer. If the timer expires, retransmit the segment

at the front of the queue and reset the timer

Batch. Maintain one retransmission timer for the entire queue. If an acknowledgment

is received, remove the appropriate segment or segments from the

queue and reset the timer. If the timer expires, retransmit all segments in the

queue and reset the timer.

Individual. Maintain one timer for each segment in the queue. If an acknowledgment

is received, remove the appropriate segment or segments from the

queue and destroy the corresponding timer or timers. If any timer expires,

retransmit the corresponding segment individually and reset its timer.

The first-only policy is efficient in terms of traffic generated, as only lost segments

(or segments whose ACK was lost) are retransmitted. Because the timer for

the second segment in the queue is not set until the first segment is acknowledged,

however, there can be considerable delays; the individual policy solves this problem

at the expense of a more complex implementation. The batch policy also reduces

the likelihood of long delays but may result in unnecessary retransmissions.

The actual effectiveness of the retransmit policy depends in part on the accept

policy of the receiver. If the receiver is using an in-order accept policy, then it will

discard segments received after a lost segment; this fits best with batch retransmission.

If the receiver is using an in-window accept policy, then a first-only or individual

retransmission policy is best. Of course, in a mixed network of computers,

both accept policies may be in use.

The IS0 TP4 specification outlines essentially the same options for a retransmit

policy without mandating a particular one.

Acknowledge Policy

When a data segment arrives that is in sequence, the receiving TCP entity has two

options concerning the timing of acknowledgment:

Immediate. When data are accepted, immediately transmit an empty (no

data) segment containing the appropriate acknowledgment number.

Cumulative. When data are accepted, record the need for acknowledgment,

but wait for an outbound segment with data on which to piggyback the

acknowledgment. To avoid a long delay, set a window timer (see Table 17.1);

if the timer expires before an acknowledgment is sent, transmit an empty segment

containing the appropriate acknowledgment number.

The immediate policy is simple and keeps the sending TCP entity fully informed,

which limits unnecessary retransmissions. However, this policy results in

extra segment transmissions, namely, empty segments used only to ACK. Furthermore,

the policy can cause a further load on the network. Consider that a TCP

entity receives a segment and immediately sends an ACK; then the data in the segment

are released to the application, which expands the receive window, triggering

another empty TCP segment to provide additional credit to the sending TCP entity.

Because of the potential overhead of the immediate policy, the cumulative

policy is typically used. Recognize, however, that the use of this policy requires

more processing at the receiving end and complicates the task of estimating roundtrip

delay by the sending TCP entity.

The IS0 TP4 specification outlines essentially the same options for an

acknowledge policy without mandating a particular one.

UDP

In addition to TCP, there is one other transport-level protocol that is in common

use as part of the TCPIIP protocol suite: the user datagram protocol (UDP), specified

in RFC 768.

UDP provides a connectionless service for application-level procedures. Thus,

UDP is basically an unreliable service; delivery and duplicate protection are not

guaranteed. However, the overhead of the protocol is low, which may be adequate

in many cases. An example of the use of UDP is in the context of network management,

as described in Lesson 19.

UDP sits on top of IP. Because it is connectionless, UDP has very little to do.

Essentially, it adds a port addressing capability to IP, best seen by examining the

UDP header, shown in Figure 17.16. The header includes a source port and a destination

port. The length field contains the length of the entire UDP segment, including

header and data. The checksum is the same algorithm used for TCP and IP. For

UDP, the checksum applies to the entire UDP segment plus a pseudo-header prefixed

to the UDP header at the time of calculation and is the same one used for TCP

(Figure 17.15). If an error is detected, the segment is discarded and no further

action is taken.

The checksum field in UDP is optional. If it is not used, it is set to zero. However,

it should be pointed out that the IP checksum applies only to the IP header

and not to the data field, which in this case consists of the UDP header and the user

data. Thus, if no checksum calculation is performed by UDP, then no check is made

on the user data.