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)...