Lecture 10: Reliable Transport -- TCP
Edge Systems and Reliable TransportRecall from lecture
- 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
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
so the unreliable UDP transport service/protocol is also
provided as an alternative, see later.
 That is, it's not a problem for
some data to fail to be delivered. The DNS is an example of such a
Characteristics of TCP Reliable DeliveryTCP 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.
- All data will be delivered correctly to the destination process, without
errors, even though the underlying packet delivery service (IP) is unreliable
-- see later.
- Two process which desire to communicate using TCP must first request a
connection. A connection is closed when communication is no
- An application which uses the TCP service is unaware of the fact that data
is broken into segments for transmission over the network.
- 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 SegmentsTCP 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
- Segment and Acknowledgment Numbers
- Every transmitted segment is identified with a 32-bit Sequence
so that it can be explicitly acknowledged by the receipient. The
Acknowledgment Number identifies the last segment recived by the originator of
- 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.
 The sequence number actually
identifies the last byte of data contained in this
TCP OperationWhen 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.
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
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.
 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
 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 ConnectionsAn 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,
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
segment names refer to "control bits" in the TCP header: for example, if the
ACK bit is set, then this is an
- Each TCP chooses an random initial sequence number (the
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
- 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
 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 StartTCP
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 ProtocolThe 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
are based on packet-sized chunks of data.
Copyright © 2004 by Philip
Scott, La Trobe University.