Subjects -> Computer Networks -> Lectures -> Lecture #11

Lecture 11: Reliable Transport -- TCP

Edge Systems and Reliable Transport

Recall from lecture 2:

An edge system is any computer (host, printer, even a toaster...) which is "connected to" the Internet -- that is, it has access to the Internet's packet delivery system, but doesn't itself form part of that delivery system.
A transport service provides communications between application processes running on edge systems. As we have already seen, application processes communicate with each another using application protocols such as HTTP and SMTP. The interface between an application process and the transport service is normally provided using the socket mechanism.

Most application protocols require reliable data transfer, which in the Internet is provided by the TCP transport service/protocol. Note: some applications do not require reliablity^[1], so the unreliable UDP transport service/protocol is also provided as an alternative, see later.

^[1] That is, it's not a problem for some data to fail to be delivered. The DNS is an example of such a protocol.

Characteristics of TCP Reliable Delivery

TCP provides a reliable, byte-stream, full-duplex inter-process communications service to application programs/processes. The service is connection-oriented and uses the concept of port numbers to identify processes.

Reliable: All data will be delivered correctly to the destination process, without errors, even though the underlying packet delivery service (IP) is unreliable -- see later.
Connection-oriented: Two process which desire to communicate using TCP must first request a connection. A connection is closed when communication is no longer desired.
Byte-stream: An application which uses the TCP service is unaware of the fact that data is broken into segments for transmission over the network.
Full-duplex: Once a TCP connection is established, application data can flow in both directions simultaneously -- note, however, that many application protocols do not take advantage of this.
Port Numbers: Port numbers identify processes/connections in TCP.

TCP Segments

TCP slices (dices?) the incoming byte-stream data into segments for transmission across the Internet. A segment is a highly-structured data package consisting of an administrative header and some application data.

Source and Destination Port Numbers: We have already seen that TCP server processes wait for connections at a pre-agreed port number. At connection establishment time, TCP first allocates a client port number -- a port number by which the client, or initiating, process can be identified. Each segment contains both port numbers.
Segment and Acknowledgment Numbers: Every transmitted segment is identified with a 32-bit Sequence number^[2], so that it can be explicitly acknowledged by the receipient. The Acknowledgment Number identifies the last segment recived by the originator of this segment.
Application Data: Optional because some segments convey only control information -- for example, an ACK segment has a valid acknowledgment number field, but no data. The data field can be any size up to the currently configured MSS for the whole segment.

^[2] The sequence number actually identifies the last byte of data contained in this segment.

TCP Operation

When a segment is received correct and intact at its destination, an acknowledgment (ACK) segment is returned to the sending TCP. This ACK contains the sequence number of the last byte correctly received, incremented by 1^[3]. ACKs are cumulative -- a single ACK can be sent for several segments if, for example, they all arrive within a short period of time.

The network service can fail to deliver a segment. If the sending TCP waits for too long^[4] for an acknowledgment, it times out and resends the segment, on the assumption that the datagram has been lost.

In addition, the network can potentially deliver duplicated segments, and can deliver segments out of order. TCP buffers or discards out of order or duplicated segments appropriately, using the byte count for identification.

^[3] In effect, the acknowledging TCP is saying: "I have received all bytes up to and including byte x: I expect that the next byte I received from you will be numbered x+1"

^[4] The TCP timeout algorithm uses observed round trip times, and measures of their variability, to calculate a continuously updated best estimate of when to resend. See the tutorial for a discussion on this.

TCP Connections

An application process requests TCP to establish, or open, a (reliable) connection to a server process running on a specified edge-system, and awaiting connections at a known port number. After allocating an unused client-side port number^[5], TCP initiates an exchange of connection establishment "control segments":

This exchange of segments is called a 3-way handshake (for obvious reasons), and is necessary because any one of the three segments can be lost, etc. The ACK and SYN segment names refer to "control bits" in the TCP header: for example, if the ACK bit is set, then this is an ACK segment.
Each TCP chooses an random initial sequence number (the x and y in this example). This is crucial to the protocol's operation if there's a small chance that "old" segments (from a closed connection) might be interpreted as valid within the current connection.
A connection is closed by another 3-way handshake of control segments. It's possible for a connection to be half open if one end requests close, and the other doesn't respond with an appropriate segment.

^[5] Port numbers less than 1024 are reserved for "well-known" services, so the client port number is always numerically greater than this. NB: this is the "source" port in segments sent from the client process to the server process, and the dest port in segments travelling in the opposite direction.

Optional: TCP Flow Control, Congestion Control and Slow Start

TCP attempts to make the best possible use of the underlying network, by sending data at the highest possible rate that won't cause segment loss. There are two aspects to this:

Flow Control: The two TCPs involved in a connection each maintain a receive window for the connection, related to the size of their receive buffers. For TCP "A", this is the maximum number of bytes that TCP "B" should send to it before "blocking" and waiting for an ACK. All TCP segments contain a window field, which is used to inform the other TCP of the sender's receive window size -- this is called "advertising a window size". At any time, for example, TCP B can have multiple segments "in-flight" -- that is, sent but not yet ACK'd -- up to TCP A's advertised window.
Congestion Avoidance and Control: When a connection is initially established, the TCPs know nothing at all about the speed, or capacity, of the networks which link them. The built-in "slow start" algorithm controls the rate at which segments are initially sent, as TCP tentatively discovers reasonable numbers for the connection's Round Trip Time (RTT) and its variability. TCP also slowly increases the number of segments "in-flight", since this increases the utilisation of the network.
Every TCP in the entire Internet is attempting to make full use of the available network, by increasing the number of "in-flight" segments it has outstanding. Ultimately there will come a point where the sum of the traffic, in some region of the network exceeds one or more router's buffer space, at which time segments will be dropped. When TCP "times out", and has to resend a dropped segment, it takes this as an indication that it (and all the other TCPs) have pushed the network just a little too hard. TCP immediately reduces its congestion window to a low value, and slowly, slowly allows it to increase again as ACKs are received. Congestion control mechanisms are still a hot research topic in the Internet!

User Datagram Protocol

The User Datagram Protocol (UDP) provides an alternative, connectionless, transport service to TCP for applications where reliable stream service is not needed. UDP datagrams can be droppped, duplicated or delivered out of order, exactly as for IP.

The UDP transport service adds to IP the ability to deliver a datagram to a specified destination process using a port abstraction, in an analogous way to that used by TCP.

UDP segments (also commonly called datagrams, see later) have a minimal (8-byte) header. Data transfer with UDP has no initial connection overhead, and (obviously) no waiting for ACK segments as in TCP. Some typical UDP-based services include DNS, streaming multimedia and "Voice over IP" applications. It's also worth noting that an application can elect to use UDP where it's prepared to implement its own reliability -- some proprietory streaming protocols do this, for example.

NB: UDP communications, at the programming level, is based on sockets, as for TCP. However instead of reading from, and writing to, a socket in a stream-based model as for TCP, a UDP socket supports the operations send and receive, which are based on packet-sized chunks of data.

The tutorial for this lecture is Tutorial #11.
La Trobe Uni Logo

[Previous Lecture] [Lecture Index] [Next Lecture]