CSUMB Networking Research Presents

by Kevan Riley



















Table of Contents
Introduction ................................................................................................................................................. 3
Goals for Lab 2 .............................................................................................................................................. 3
TCP and UDP in the OSI Model ..................................................................................................................... 4
Features of TCP and UDP ............................................................................................................................. 6
Use Cases For TCP and UDP ......................................................................................................................... 7
Opening the Lab ........................................................................................................................................... 9
Understanding the Task Definition ............................................................................................................ 12
Adding Devices ........................................................................................................................................... 12
Configuring the Devices ............................................................................................................................. 16
Associating the Profile with the Devices .................................................................................................... 18
Choosing Statistics to Gather ..................................................................................................................... 22
Duplicate the Scenario ............................................................................................................................... 24
Running the Simulation / Viewing Results ................................................................................................. 26
Final Thoughts ............................................................................................................................................ 29



























Introduction
Computers on the Internet communicate via a large number of protocols which are sometimes
cumulatively referred to as a "stack". The OSI reference model is often used to describe the
layers of the stack and their functions. One section of the OSI model is referred to as layer 4, or
the Transport Layer, and its primary function is to provide end-to-end communication services
for applications. The two most commonly known protocols in the Transport Layer are TCP
(Transmission Control Protocol) and UDP (User Datagram Protocol). TCP is reliable and
connection-oriented, while UDP is an unreliable, connectionless protocol. That being the case,
you might be wondering why the unreliable UDP protocol is even used at all. In this lab, we will
look at the characteristics of both TCP and UDP, and then create a scenario within IT Guru that
will help us visualize why using UDP might be a good idea in some instances.


Goals for Lab 2
In this lab, you will look at the characteristics of the TCP and UDP transport layer protocols, how
they work, how they are different, and why they are used in different instances. You will also
create a scenario to demonstrate one of the differences of TCP and UDP, and why that
difference would impact a decision to use one protocol over the other.
















TCP and UDP in the OSI Model
In most networking classes, the OSI reference model is used to describe the protocols that
allow computers to communicate across networks like the Internet. It is sometimes a confusing
concept, so let's try to understand it a bit better so that we can have an idea of what we mean
when we say that TCP and UDP are Transport Layer protocols. First, take a look at the OSI
reference model:

The protocols that make networks run are sometimes referred to as a "stack". You may have
heard someone refer to the "TCP/IP stack". The stack analogy works because the protocols in
one layer depend on the protocols of the layer above/below it in order for communication to
happen. The OSI model describes the different layers of the stack and their purpose.
The layer on the bottom is the Physical Layer, and it is referred to as Layer 1. The Physical Layer
is comprised of the electrical wires and hardware that all of the other layers of the stack run on.
An Ethernet cable or a network card in your PC is a good example of a Physical Layer device.
The top-most layer is the Application Layer, or Layer 7. In this layer are the actual apps that
people use on their computers, like Internet Explorer, or AOL Instant Messenger.
Layers 2 through 6 of the OSI model contain all the other protocols that make it possible for
your computer to communicate on the Internet. Here is a good picture to describe how the
protocol stack works:




Transmitted data is passed through the various protocols in the stack, eventually making their
way to the physical wires. When they reach their destination, the protocol stack on the
receiving computer is able to reverse the process, and the proper application receives its data.

Now, each stack has a purpose, and the main purpose of the Transport Layer is to provide
communication services directly to the application processes running on different hosts. As the
application passes it's data off to the other layers (see left side of the image), it expects that
when the data gets to the Transport Layer, it will be encapsulated by a transport protocol
before passing it on to the Network Layer. It' s important to understand that while the Network
layer provides logical communication between hosts, the Transport layer provides logical
communication between processes. The Network layer can get the data to a different
computer, but it's up to the Transport layer to get it to the proper application once it has
arrived. There are a number of protocols within the Transport Layer that do this, but the two
most common protocols are TCP and UDP.

Features of TCP and UDP
Both TCP and UDP are Transport layer protocols, but they behave quite differently from one
another. TCP is a connection oriented protocol, which means that before it starts transmitting,
TCP will set up a connection between the two hosts. This connection allows TCP to do reliable
data transfer, using congestion control, flow control, sequence numbers, acknowledgements,
and timers. Entire books have been written about these techniques, but for the time being, just
know that TCP's two main features are that it is connection oriented, and it does reliable data
transfer. These are important, of course, for most of what we do with the Internet. When you
hop on your web browser, you expect the pages to be displayed properly, and when you
download a song from iTunes, you would hope that it doesn't skip or become garbled while you
listen. TCP and reliable data transfer makes this possible.

UDP stands for "User Datagram Protocol", and while TCP is connection oriented, UDP is
connectionless. This means that UDP does not wait to create a connection to send data; it just
sends it on out to its destination and lets the stack take care of the rest. In fact, aside from a
simple checksum for error checking, UDP does almost nothing to the data besides encapsulate
it and send it along. It is focused on sending the data as fast as possible, and that is all. UDP is
an unreliable protocol; any reliability efforts rest on the applications themselves. That doesn't
mean that UDP can't send and receive reliable transfers, it just means that it doesn't guarantee
it.


Use Cases For TCP and UDP
Now that you know the difference between TCP and UDP, you might be wondering: "Why
anyone would anyone want to use a connectionless protocol that cannot guarantee reliable
delivery of its packets?". For one thing, there is a measurable amount of overhead that is
associated with TCP. The TCP encapsulation has to have a lot more information in it to set up
the initial connection between hosts. Also, TCP requires a handshake process between hosts to
initialize the connection, as well as another handshake to terminate it. UDP, on the other hand,
hardly has to do anything, and doesn't suffer from additional overhead. It doesn't establish any
connections or do anything to ensure reliable communication (except a checksum to check for
errors). Take a look the packet structure for each protocol:





See? The TCP segment has a lot more information and fields, and most of this extra information
is used to create the TCP connection with the target host. So, you can see that the reliable data
transfer comes with a cost, and that cost is additional overhead. This overhead doesn't just
apply to your computer, it also affects the server that your computer is communicating with.
The overhead on your PC alone might not be that bad, but when a server is attempting to
maintain hundreds of different TCP connections and their associated buffers, parameters, etc...,
it can run out of resources quickly.

On the other hand, UDP is connectionless, and maintains no connection state on the
communicating hosts. So, there is reduced overhead to your computer, and reduced usage of
resources on the server. UDP also sends out data right away, because it doesn't have to wait for
a connection to be established. Hopefully, you are starting to see that the different properties
of TCP and UDP make them suited for different purposes. These purposes can be loosely
summarized as follows:

When data needs to be reliably transferred from one host to another, TCP is used. Data that
needs to be transferred in real-time and with low overhead requires UDP.

So what kinds of applications use TCP and UDP? Well, earlier we discussed HTTP traffic and web
pages using TCP. Other TCP users include most of the file transfer protocols (like FTP) and email
protocols (like SMTP). These are all applications in which data loss is not acceptable. Who wants
an e-mail with some of the text missing? Of a file download that's corrupted? In these cases,
the additional overhead of TCP is acceptable because the communication requires reliable data
transfer.

What applications use UDP? One of the best examples is DNS (Domain Name System), the
service that allows us to type domain names into our browsers instead of IP addresses. A DNS
query is a very small exchange of information, and it doesn't make sense to establish a separate
connection for each individual request that a DNS server receives. The DNS response will be
faster for the same reason. Many other protocols that send small messages or queries utilize
UDP, such as the SNMP network management protocol.

Other applications that require a real-time data stream use UDP, like certain implementations
of VoIP and streaming video. The problem with using TCP for these applications is that when
you are an application that is decoding audio or video as it comes in off the Internet, you don't
have any use for a protocol like TCP that retransmits packets and induces delay for things like
flow control. You need a protocol like UDP that is all about transmitting bits as fast as possible
with no overhead. An audio or video stream can cope with a lost packet or two. Your e-mail to
your grandma cannot.










Opening the Lab
So now we know that TCP is a connection oriented protocol that can ensure reliable delivery at
the cost of some overhead, and UDP is a connectionless protocol that cares only about sending
packet out as fast as it can. Let's set up an IT Guru scenario that can demonstrate this. We will
establish a long distance PPP link, then send traffic from a client to a server via TCP and UDP.
We will compare the results, and makes some observations.
STEP 1: Open IT Guru Academic Edition.

You will likely be prompted to click through a Restricted Use Agreement each time you run IT
guru. Just click the "I have read..." button. The main window will open. We now need to load
the files that came with this lab document.






STEP 2: Click "File", then "Model Files", then "Add Model Directory". In the explorer window
that appears, select the "lab2_files" folder that came with this document.



You will be prompted to make a choice about setting the working directory. Choose the
"Source Directory" option. This will keep your saved work in the "lab2_files" folder in case you
need to copy it to a flash drive later or something like that.






STEP 3: Click "File", then "Open". In the window that appears, select the "CSUMB_Lab2"
project, then click OK.



When the project opens, you will see an image of the United States, as well as three
"definitions" icons: task, application, and profile.





Understanding the Task Definition
You will notice that the "Task Definition" icon is new; we didn't discuss it in Lab 1. This is
because task configuration in IT Guru can be a little complicated, and the goal of this lab was to
teach you about TCP and UDP, not confuse you with tricky configurations. You might recall that
in Lab 1, we created a Profile Definition that we assigned to the workstations in the scenario.
This profile told the workstations what applications to use. Well, in IT Guru, a Task Definition
can be used to tell the applications specifically what to do, as opposed to just running
generically. You can think of it this way:
1. The Task controls the behavior of the Application.
2. The Application is incorporated into the Profile.
3. The Profile is bound to a workstation or device.
4. The device will run the Application, but only in the way that is defined by the task.
So, in our case, we will have one workstation and one server. The Application will be regular IP
traffic, using TCP and then UDP. The Task has been preconfigured (along with the Application
and the Profile) to do a number of things:

The client will send one request packet every second.
Each request will use a separate connection (this won't make a difference with UDP, as
it does not establish connections).
The server will immediately send back a single response packet.



Adding Devices
Now let's configure the devices and connections for our scenario. Once that's done, we can add
the Profile to the devices and run our simulation

STEP 4: Open the Object Palette by clicking the palette button, or clicking "Topology", then
"Open Object Palette". Click the "Configure Palette..." button, then click "Node Models".


A window will appear with a long list of devices. Scroll down until you see "ppp_wkstn_adv".
Click "not included" once to change it to "included". Click OK to close the window, then OK
again to close the "Configure Palette" window. (If you are prompted to save the palette, go
ahead and click OK to do so). This will allow the "ppp_wkstn_adv" device to show up in our
palette.




STEP 5: Select the "ip32_cloud" from the palette, and place one in the center of the map.



The IP cloud supports many protocols, including TCP and UDP, which is perfect for our
simulation. Essentially, it simulates the various networks that separate our two devices. We will
now set down these two devices, and connect them over the IP cloud.


STEP 6: Select the "ppp_wkstn_adv" from the palette, and place one on the left side of the
map. Then select the "ppp_server" and place one on the right side of the map.










STEP 7: Select the "PPP_DS1" from the palette. Click and drag connections from the
workstation and the server to the IP cloud.





In case you are wondering, DS1 is a fairly typical long distance telecommunications line, and it is
sometimes referred to as a T1. We now have a workstation that is communicating with a server
from across the country, via a standard long distance connection.






Configuring the Devices
Now we need to setup our devices to use the application task and profile that we already have
preconfigured.

STEP 8: Right click the "ppp_wkstn_adv", and choose "Edit Attributes". Change the name
attribute to "Source". Modify the Client Address to be "Source" as well. Click OK to close the
window.










STEP 9: Right click the "ppp_server", and choose "Edit Attributes". Change the name attribute
to "Destination Server". Modify the Server Address to be "Destination Server" as well. Click OK
to close the window.




Make sure that you have these names correct. If either the workstation or the server has the
wrong name, the simulation will not run correctly.






Associating the Profile with the Devices
Now we need to associate the custom task/application profile with our client and server.

STEP 10: Right click the workstation (which should now be labeled "Source"), and choose "Edit
Attributes". Edit the "Application: Supported Profiles" attribute, and set the rows to "1". Expand
"row 0", and you will see the "Profile Name" attribute. Click "None", and you will see the
"mainprofile" value, which you should select. See the screenshot below:











STEP 11: In the same window, edit the "Application: Destination Preferences" attribute. A
rectangular window will appear. Set the rows to "1", and edit the Symbolic Name to
"Destination Server".

Then click to edit the "Actual Name", and another rectangular window will appear. Set the rows
to "1", and edit the Name to "Destination Server". Click OK twice to close both windows.




Go ahead and click OK to close the "Source" attributes window. We are going to edit it again in
the next step but if we don't close it first, there is a glitch in IT Guru that will not allow us to
complete the next step properly.









STEP 12: Right click "Source", and choose "Edit Attributes". Expand the "Application: Source
Preferences" attribute. Set the rows to "1", and expand "row 0". Click to edit the Symbolic
Name to "Source". Click OK to close the window.















STEP 13: Right click the server (which should be named "Destination Server"), and choose "Edit
Attributes". Under the "Application: Supported Services" attribute, click "None", then "Edit"
and a rectangular window will appear. Set the rows to "1". Click to edit the Name to "mainapp".
Click OK to close the window, then OK again to close the server attributes window.





Ok, the configuration is complete! These steps can get a little confusing, so it you have any
trouble, go back and move carefully through the steps, making sure that you don't miss
anything. If you are still lost, be sure to check out the supplemental video to see the process.





Choosing Statistics to Gather
Now we need to select which statistics we will gather. For our purposes, we will be looking at
the overall response time of the custom task, and the traffic received by the two nodes.
STEP 14: Click "Simulation", then "Choose Individual Statistics". Under Global, expand Custom
Application, then select "Task Response Time (seconds)".









STEP 15: Under Node, expand IP, then select "Traffic Received (packets/sec)". Click OK to close.



Now that we have chosen the statistics to gather, we need to duplicate the scenario. We will
change the duplicated scenario to run UDP instead of TCP.



Duplicate the Scenario
The scenario that we now have is running TCP. We need to duplicate it, and set up the new one
to run UDP. That way we can run both scenarios and compare results.
STEP 16: Click "Scenarios", then "Duplicate Scenario...". Name the new scenario "UDP".

Now that we have a duplicated scenario, we need to change the application to run over UDP
instead of TCP.

STEP 17: Right click the "App Configuration" icon, and select "Edit Attributes". Expand
"Application Definitions", then row 0, then "Description". You will see a window just like the
one below:





STEP 18: Click to edit the "Custom" attribute. In the window that opens, change the Transport
Protocol to UDP. Click OK twice to close both windows.




Now we have completed our configuration. In the previous steps, we have accomplished the
following:

Associated the profile with the source.
Configured the server to accept the application traffic from the source.
Changed the Names, and Symbolic Names.
Chosen the statistics we want to gather.
Created a duplicate scenario to run UDP.

Now, all we need to do is run the simulation!








Running the Simulation / Viewing Results

STEP 19: Click "Scenarios", then "Manage Scenarios..." In the window that appears, change the
"Results" from uncollected to "<collect>". By default, the Sim Duration should be set to 1.0
hours, but if it isn't, change it so that it is. Click OK to close.



STEP 20: Click "Scenarios", then "Manage Scenarios..." In the window that appears, change the
"Results" from uncollected to "<collect>". By default, the Sim Duration should be set to 1.0
hours, but if it isn't, change it so that it is. Click OK to close.

The simulations will automatically run and collect the results. Close the window.


STEP 21: Click "Results", then "Compare Results". Expand "Custom Application", and select
"Task Response Time (seconds)". Beneath the graph, change "As Is" to "Average". Click "Show"
to display the full graph.



As you can see, when the application ran on TCP, the response time was higher, meaning that
UDP completed the task more quickly. Now, remember that our task was to send a single
request, and to receive a single response back. To do this, TCP had to create and tear down a
connection every time it transferred the packets. This created overhead in the form of response
time delay. UDP, on the other hand, did not have to do this because it is a connectionless
protocol. Thus, it was able to transfer the packets more quickly than TCP.










STEP 22: Expand "Object Statistics", then "Source", then "IP". Select "Traffic Received
(packets/sec)". Click "Show" to display the full graph.



You can see that the average traffic received by the source workstation was higher when using
TCP. As you might have guessed, this is also due to the extra overhead that is created by TCP.
The UDP protocol does little more than send packets from point A to B. The TCP protocol
establishes a connection complete with different parameters and buffers. The establishment
and teardown of the TCP connection results in more overall data travelling back and forth
between endpoints, and thus you see a higher average traffic for TCP in the graph.

UDP is fast, but it's not suitable for applications that need data reliability. Your e-mails and web
pages won't benefit from the speed increase if they are broken and distorted from lost or
dropped packets. The speedy delivery and low overhead of UDP make it perfect for tasks that
require quick communication without waiting for connections or retransmissions. Streaming
media, DNS servers, and SMTP all benefit from the unique properties of the UDP protocol.



Final Thoughts
Lab 2 is now complete. Hopefully, you now have a better understanding of the TCP and UDP
protocols, and how they are different. In the lab, we set up a simulation in IT Guru that
demonstrated one of these differences, and we discussed how that impacted the way that both
protocols are used.
In Lab 3, we will look at (INSERT HERE)...