Introduction

The focus of the network layer is to transfer packets from one point of a network to another using the
best route. But modern systems don't simply communicate with one another singularly; each device
has multiple network processes and applications that each send and receive their own data. A PC, for
example, might have a browser and an email client running at the same time, and both of these
applications have their own unique data transmissions. Considering that the network layer only
transfers packets from one device to another, how does the network distinguish between email data
and browser data? This is one of the primary functions of the transport layer.

The transport layer is the the �rst layer that is found completely on individual machines, rather than
network devices. Typically, the transport layer functions are executed by a so-called ,
which is usually part of an operating system's kernel. This means that all applications that have
network access must connect to the network through the operating system. As such, the transport
layer has to be capable of providing a reliable service to the upper levels, and must also be able to
function on a software level.

With this in mind, we will be looking at the following in this study unit:

• Sockets: Sockets, simply stated, are connection points where the higher levels can connect to in
order to use Transport layer functions.
• Addressing: Each of the di�erent layers that support multiple destinations have some kind of
addressing scheme. The Data-Link layer has MAC addresses, for instance, and the Network Layer
has IP addresses. The Transport layer, as it needs to be capable of funnelling data to a particular
application, also has addresses. These addresses are called .
• Elements of Transport protocols: All Transport protocols have to address the same issues in some
way, which means that there are elements to all Transport protocols that can be used to compare
then. We will be looking at each of these elements.
• Common Transport Protocols: When it comes to extant Transport protocols, we will be focussing
our attention on the three most commonly used protocols, namely TCP (connection-oriented), UDP
(connectionless), and RTP (media focussed).
 (connectionless), and RTP (media focussed).

The transport layer is the lowest layer that a typical software developer is likely to encounter, as
everything from the network layer down is found on network hardware. It is therefore helpful to
understand what sockets are, how you would use them, and how you would select a transport
protocol. However, as the Transport Layer is typically built into the operating system of a device, we
will not be discussing it in as much detail as in the textbook. If you are interested in more information,
you are welcome to consult the textbook on the relevant topics.

A note before we begin in earnest: each layer up to the Transport layer splits the data into sections
that can be more easily managed on that layer, and each section has its own layer speci�c name. On
the physical layer, data is transmitted as bits, whereas frames are transmitted on the data-link layer.
On the network layer, we refer to the sections of data as packets. In keeping with this pattern, the
transport layer has its own term for sections of data that are transmitted over the network: .
Thus:

• The application sends data to the transport layer, where it is split into ;
• The transport layer sends the data to the network layer, where each segment is split into ;
• The network layer sends data to the data-link layer, where each packet is split into ; and
• The data-link layer sends the frames to the physical layer, where they are transmitted bit-by-bit to
the receiver. From there, the process is reversed until the original data has been obtained (i.e. the
bits are combined to make frames, the frames are combined to make packets, the packets are
combined to make segments, and the segments are combined to make the original data).

A good place to start our overview of the Transport Layer is a quick discussion on how it will typically
be used in software. As mentioned, the Transport Layer usually runs in the operating system kernel,
which means that it is accessible using code. One of the primary implications of this is that the
Transport Layer needs to be accessible to all applications using a standardised scheme. This is where
sockets come in. In simple terms, a is a connection point where an application can connect to
the transport layer. More speci�cally, sockets are service primitives that applications can employ in
order to use the services of the Transport layer. If you, for example, want to send data over the
network from an application, the application will make use of a SEND socket. In a sense, the
application "plugs into" a socket on the transport layer that allows for data to be sent. If the goal is to
receive data, then the application can "plug into" a RECEIVE socket in order to receive the data.

The original version of this socket scheme is known as , and it is still used in UNIX
based systems. Windows also has a socket scheme, which is known as . Any di�erences
between these two schemes are mostly immaterial, as the most important part of the socket
primitives is that they are the same for all applications. This allows for any application that needs to
send data over the network to be able to access the Transport layer in a known and standardised way.

Some examples of socket primitives are shown in "Figure 5" below. You'll note that the names of these
sockets are quite descriptive, and should help in understanding their purpose when interacting with
the transport layer.
Addressing is a key component of any Transport protocol (and thus will be revisited brie�y in the next
section), and as such deserves special attention. As mentioned earlier, the Transport layer is, among
other things, responsible for ensuring that data that is transmitted to a particular application (or vice
versa) is received by the appropriate application. This means that the Transport layer must be able to
distinguish between the data meant for di�erent applications . This, as with the network and data-link
layers, requires the use of some form of addressing. Luckily, because the number of network
connected applications that are likely to be running on a machine is much smaller than the number of
network connected devices in the world, the Transport layer does need a complex addressing scheme
like those found on the network and data-link layers. Whereas a MAC address has a 12-digit colon-
hexadecimal format (e.g. 00:12:ef:48:00:48), and an IPv4 address has a 32-bit dotted decimal format
(e.g. 192.168.1.1), the Transport layer has a single 16-bit integer value that it uses for addressing.
These are called and, as the value is a 16-bit integer, can have a value between 0 and 65535. The
functioning of these ports is the same as one would expect on the lower layers: whenever an
application needs to send data, it will send that data to a particular port. The exact port number is
determined either by the protocol, or arbitrarily based on the ports that are available. Ports can only
be used for one thing at a time. The video on ports below contain a very thorough explanation on
ports, so we will not be going into greater depth at this stage.

The Transport layer has a number of similarities with the data-link layer. The primary reason for this is
that both the data-link layer and the transport layer are responsible for providing a clean interface to
physical hardware. The data-link layer provides clean and managed access to the physical layer, which
deals with the bit-by-bit transmission of data over a physical medium, whereas the transport layer
provides clean and managed access to the network layer, which is the highest layer that runs on
network hardware rather than in software. As a result, both of these layers will have similar functions
when it comes to certain aspects, such as �ow control, error detection and correction,
acknowledgements, etc. Where the two layers di�er is in the simple reality that the "physical
mediums" they use are di�erent: the data-link layer only has to deal with a physical layer where two
hosts are directly connected to each other, whereas the transport layer needs to function in an
environment where there is an entire network between the hosts. This means, among other aspects,
that the process of transmitting data could include unpredictable delays as the data is routed trough
the network, and that the data could be received out of order even though the segments were sent in
order and there were no transmission errors. Another di�erence is that the massive number of hosts
that could potentially use the shared network, in addition to the fact that each host could have any
number of active connections to other hosts, will cause �uctuations in the bandwidth available for any
single connection. This means that bu�ers need to be carefully managed for multiple connections, a
task which is signi�cantly more complex than the bu�ers used in the data-link layer. The di�erences
between the operating environment of the data-link layer and the transport layer are shown in the
�gure below.

What this means is that a transport protocol has a lot more issues to address than a data-link layer
protocol. However, just like with the data-link layer protocols such as the Utopian simplex, transport
protocols can be designed to deal with some of these issues by simply ignoring them. The following 6
topics are the elements that each transport protocol has to address in some way. We will discuss each
of these elements brie�y before looking at some of the most common transport protocols. While you
will not be required to list these 6 elements in tests or exams, they are excellent points of comparison
to use when comparing transport protocols to one another. Take not that the textbook contains a lot
of information on the transport layer; you do not need to know all of the theory in the textbook. The 6
elements of Transport Protocols are:

• One of the primary functions of the transport layer is that it allows an application on a
local machine to send data to an application on a remote machine. Even if the local machine is set
up to only allow for one application to use the network at a time, the issue remains of who to send
the data to. After all, the remote machine is under no obligation to also restrict its network to one
application at a time. Even if it did, how could either of the machines be sure that the correct
application is running on the target machine when the data is received? The only way to be sure
that the correct data reaches the correct application is to implement some kind of identi�cation or
addressing method on the transport layer that the applications can use. This is where ports, which
we discussed earlier, come in.

• One of the key factors that will determine how a transport protocol
functions and what services it will provide is whether it is a connection oriented or connectionless
transport protocol. Connectionless protocols, for instance, do not have to deal with connections
and connection states, and can simply transmit data as it wishes. A connection oriented protocol,
on the other hand, has to deal with setting up a connection beforehand. This can get tricky on the
transport layer for a number of reasons, not least of which has to do with the transmission of
duplicate segments. When setting up a connection initially, one way to ensure that the receiving
host does not set up a connection based on a duplicate connection request is to use a
. With this technique the sending host sends a sequence number x to the receiving
host. The receiver host, upon receipt of the sequence number x, acknowledges the original
transmission and sends its own sequence number y. Once the sending host has received the
sequence number y and the acknowledgement for x, it can then acknowledge y and start to
transmit. This three-way handshake ensures that any new connection request is legitimate before
 transmit. This three-way handshake ensures that any new connection request is legitimate before
the connection is established, as there is no opening for a duplicate segment to accidentally initiate
a new connection.

• : As with connection establishment, only connection oriented protocols need

to be concerned with how and when to release a connection. While seemingly a simple issue,
determining when to release a connection can be more complex than it seems. To illustrate this,
consider the . The two army problem is as follows: consider the existence of
two armies, one called the "white army" and the other the "blue army". The blue army is stronger in
numbers than the white army, but their forces are split with one half on either side of the white
army. This split in forces is such that the white army is superior to either half of the blue army, and
would win if the white army should engage in battle with either half of the blue army. The
implication of this is that, in order for the blue army to win, they have to coordinate their attacks
and attack the white army at the same time. So how does the blue army coordinate the attack
between its two halves? Obviously they would have to communicate with each other somehow but,
as part of this problem, they are incapable of communicating directly and need to send messengers
with the messages. The messengers would need to move through the white army's territory, which
means that there is a chance that the message never arrives. So, in order to guarantee that the
message is received, the two halves have to make use of acknowledgements. With this in mind,
consider the following occurrence: the commander of blue army #1 sends a message to the
commander of blue army #2 with instructions for when to launch the attack, but gives his
messenger the explicit instruction that he has to return with an message from the commander of
blue army #2 to acknowledge that the message was received. After all, if blue army #1 were to
launch and assault without the support of blue army #2, they would end up defeated. The
messenger arrives at the camp of blue army #2 and delivers the message. The commander of blue
army #2 gives the messenger the exact same instruction as the commander of blue army #1 did -
he has to return with an acknowledgement to con�rm that the message was received by the
commander of blue army #1. The messenger returns to the commander of blue army #1, who
takes receipt of the acknowledgement but wants to ensure that the commander of blue army #2 is
aware that the acknowledgement was received (after all, if the acknowledgement was not received
then it means blue army #1 won't attack, and thus blue army #2 cannot attack either). Thus, the
messenger sets o� for the camp of blue army #2 with the acknowledgement acknowledging receipt
of the acknowledgement. The commander of blue army #2 then responds by sending an
acknowledgement acknowledging the receipt of the acknowledgement. You can see where this is
going: in order to verify that the message was received and both halves of the blue army attack at
the same time, the commanders of both halves will continue to send acknowledgements to each
other ad in�nitum, as stopping to send the messages at any time would mean that the message
was not received and that the two armies are not coordinated for the attack. This situation is valid
for releasing connections as well: at which point should the hosts of a connection release the
connection? What if it is too early to release the transmission as there might be more data to be
transmitted? In practice, the best solution to this problem is to let the hosts decide independently if
they are done with the connection. If it should happen that there is still more data to be
transmitted, a new connection can be established for the remaining data.
 • The mechanisms for introducing error and �ow control in the transport
layer are essentially the same as those used in the data-link layer. It is important for these types of
mechanisms to be used on the transport layer as well as on the data-link layer, as it is possible for a
segment to be corrupted without any of the frames being broken in transit. Consider, as an
example, a router with faulty memory. The frames that arrive at the router will be �ne, as will the
frames that are transmitted, but the data-link layer has not way to ensure that the frames being
forwarded to the next router are the same as the ones that were received. Thus, it is possible for
the data in a segment to be corrupted without any of the individual frames being corrupted. In a
similar fashion, if any packets become lost due to a server malfunction or incredibly long delays, it
can also lead to a segment becoming corrupted. Thus, in those transport protocols where data has
to be delivered correctly, error detection has to be present. The same holds true for �ow control: it
is entirely possible and feasible that some of the paths between the sender and the receiver will
have bandwidth large enough that the receiver can be overwhelmed. The data-link layer has no
way of ensuring that the sender - which is ignorant of the route - does not send too much data over
the link. Thus, the transport protocol (should it allow for this) has to control for the �ow over the
connection.

• Multiplexing allows for a single network connection to be shared amongst many

applications. This goes hand-in-hand with addressing: unless only one application is running on
both the sending and receiving machines, and those are the two applications that communicate,
the transport protocol has to be able to di�erentiate between the various data transmissions
meant for the various di�erent applications. In the same way that multiple hosts sharing the
bandwidth of the same channel on the physical layer is called multiplexing, this manner of sharing
the same network connection amongst multiple applications is also called multiplexing.

• Any transport protocol can deal with segment loss due to router failures, as it is
an accepted fact that data loss occurs from time to time. Some transport protocols will simply
ignore the issue, whilst other protocols will attempt to have the lost segments retransmitted. But
what if the remote host itself goes o�ine? What if the segments cannot be retransmitted because
the entity that has to provide that data is not longer online? There are at least three thing you can
do in this case: wait inde�nitely for the remote host to come back online and just send
retransmission requests until it does; wait for a limited time for the remote host to come back
online before timing out, or; immediately cut your losses and purge the bu�ers containing the
received data and then retry from the beginning once the remote host comes back online. These
are possible approaches for if the sending machine goes o�ine, but what if it's the receiver?
Suddenly you have a di�erent set of issues: consider, as an example, that you are committing data
to a database on the remote host, and the remove transport entity acknowledges the receipt of the
data just before the host goes o�ine and before it had time to commit the data to the database.
The sender will receive the acknowledgement and assume that the data was correctly committed to
the database, and will only notice an issue on the next commit (if the remote host is still o�ine).
This is an issue that the transport protocol also has to address, as it can lead to signi�cant issues if
the protocol does not have an appropriate response to these situations.

These are the six elements that can be used to describe and compare transport protocols. In the next
section we will be taking a brief look at some of the most commonly used transport protocols, namely
TCP, UDP and RTP. You will need to be able to compare and contrast the two primary ones (TCP and
 TCP, UDP and RTP. You will need to be able to compare and contrast the two primary ones (TCP and
UDP), and will need to be capable of proposing the best one to use in given scenarios.

While the three we will be looking at here are not the only transport protocols in existence, they the
most common ones. In the case of RTP, they also serve as a good example of how some transport
protocols can be based on others in order to provide a customised transport service to the application
layer. The three protocols of note are:

• The is the standard protocol for most communication over

the Internet. This protocol, which is connection oriented, is considered one of the most reliable
transport protocols in existence. The application layer protocols HTTP and HTTPs run on TCP.
• The is used in instances where data loss is not a signi�cant
issue, and is used where speed is more crucial than data quality. UDP is a connectionless protocol,
and has almost none of the features that TCP has. UDP is used for communication with web
services such as DNS and DHCP.
• The is an extension of UDP that is speci�cally focussed
on streaming multimedia, such as video and audio. RTP is also used with VoIP as the transport
protocol for the audio data.

For a more detailed comparison between the protocols, see the "Transport protocol comparisons.pdf"
under Study Materials & Resources below.

Outcomes

After successful completion of this study unit, you should be able to:

• describe the services provided to the higher layers;

• describe the Berkeley/Winsock sockets;
• describe the di�erent elements of transport protocols;
• describe a simple transport protocol; and
• Compare TCP, UDP, and RTP.

Estimated Study Time

This study unit should take an estimated to complete.