1
2
3
1 Class of 2003, Software Engineering major and McNair Scholar, Clarkson University
2 Class of 2003, Software Engineering major and McNair Scholar, Clarkson University
3 Project Faculty Mentor, Department of Computer Science, Clarkson University

CHAPTER 1 INTRODUCTION ..................................................................................... 4
D
ISCUSSION OF PURPOSE
.................................................................................................. 4
T
RANSMISSION
C
ONTROL
P
ROTOCOL
(TCP) .................................................................... 4
U SER D ATAGRAM P ROTOCOL (UDP) ............................................................................... 5
CHAPTER 2 PCATTCP .................................................................................................. 6
PCATTCP
BENCHMARKING TOOL
................................................................................... 6
U SING PCATTCP ............................................................................................................ 6
A DVANCED USE OF PCATTCP ........................................................................................ 9
PCATTCP
COMMAND LINE ARGUMENTS
....................................................................... 10
W
EAKNESSES OF
PCATTCP .......................................................................................... 11
C HANGES MADE TO PCATTCP...................................................................................... 11
CHAPTER 3 PCATTCP CONTROLLER ................................................................... 12
I
NSTALLATION AND SETUP
............................................................................................. 12
Obtaining the software .............................................................................................. 12
Installing the program .............................................................................................. 12
U
SING
PCATTCP C
ONTROLLER
.................................................................................... 12
Starting the receiver on a server machine ................................................................ 13
Starting the transmitter on the client machine .......................................................... 13
**********************************************************************
*********I
NSERT
PCATTCP C
ONTROLLER
E
XAMPLES HERE
,
BRIEFLY EXPLAIN AND
THEN REFER TO NEXT SECTIONS FOR MORE DETAILS ...................................................... 14
F
EATURES OF
PCATTCP C
ONTROLLER
......................................................................... 15
The receiver .............................................................................................................. 15
The transmitter .......................................................................................................... 15
PCATTCP C ONTROLLER COMMAND LINE ARGUMENTS ................................................ 17
A
DVANCED USE OF
PCATTCP C
ONTROLLER
................................................................ 17
**********************************************************************
********A DD EXPLANATIONS HERE ............................................................................. 17
T
EXT FILE PRODUCED
..................................................................................................... 18
G
ENERATING THE GRAPHS
............................................................................................. 18
CHAPTER 4 DATA COLLECTION AND ANALYSIS ............................................. 20
R
ESEARCH
E
XPECTATIONS
............................................................................................. 20
C
ONNECTIONS WE TESTED
............................................................................................. 20
R ESULTS ........................................................................................................................ 21
Performance factors.................................................................................................. 21
C
ONCLUSIONS
................................................................................................................ 22
Effective Throughput ................................................................................................. 22
Efficiency................................................................................................................... 22
Causes of lower throughput with UDP ..................................................................... 22
CHAPTER 5 FUTURE RESEARCH ........................................................................... 23
O PEN ENDED QUESTIONS AND CONSIDERATIONS ........................................................... 23

CHAPTER 6: ACKNOWLEDGEMENTS .................................................................. 26
CHAPTER 7: REFERENCES ....................................................................................... 27
W
EBSITES
...................................................................................................................... 27
W
ORK
C
ITED
................................................................................................................. 27
APPENDIX A: GRAPHS ............................................................................................... 28
APPENDIX B: CONNECTION DETAILS .................................................................. 29
APPENDIX C: TESTS PERFORMED ........................................................................ 30
APPENDIX D: FIGURE INDEX .................................................................................. 31

The Internet rapidly becoming the most widely used method of connection. The two main protocols used for data transfer on the Internet are Transmission Control
Protocol (TCP) and User Datagram Protocol (UDP). Our research is one of the most exhaustive studies comparing the two protocols on many different types of network connections.
Everyday tons of packages get sent through the mail. These packages come in many sizes and are transported by different methods. They travel on planes, trucks, or may simply be carried by a postman. Packages usually make stops at post offices where they are directed toward their destination. Some packages get held up or lost before delivery. Now, consider an analogous example, a packet (small piece of a internet message) that travels over the Internet, packets come in many sizes and, like packages, get sent across different types of connections. Packets make stops at routers where they are directed to their destinations. Like packages, packets may be slowed down or get lost during the trip. Our research is an attempt to explain how different sizes and types of packets perform over different connections. We have done a thorough investigation of two types of packets, using many different packet sizes and tested over many different connections.
The two types of packets we will focus on are Transmission Control Protocol
(TCP) and User Datagram Protocol (UDP). TCP and UDP are the two primary protocols that are used to send data across the Internet. They function at the Transport layer and handle the transfer of packets from a transmitting machine (client) to the receiving machine (server). The packets themselves are guaranteed to get across in one piece by the Network layer, which is the layer directly below the Transport Layer. The protocol used at the network layer is the Internet Protocol (IP). The details of TCP and UDP will be discussed in the next two sections
The TCP protocol is stream-oriented, meaning that a connection or stream is always open as long as a connection exists. TCP is also a connection-oriented service. A connection-oriented service means that the client and server sides both do a handshake before sending the real data. This handshake not only allows the server to make sure the client is listening for data, but also prepares the client for incoming packets.
This connection-oriented TCP service also provides the capability for reliable data transfer, flow control, and congestion control. Reliable data transfer means that a connection will deliver all of its data without error and in the proper order. Any email or instant messaging application can understand the importance of this! Flow control makes sure that too many packets do not overwhelm the receiving side of a data transfer.
This is necessary because some applications can receive data faster than they can process

it. Finally, congestion control ensures that the Internet is prevented from a state of gridlock, thus never reaching complete congestion where no network traffic would be possible.
Another responsibility TCP takes on is to figure out the Maximum Transmission
Unit (MTU). The MTU is the largest physical packet size, measured in bytes that a network can transmit. Any messages larger than the MTU are divided into smaller packets before being sent
Because of these features, TCP can ensure 100% data transfer in the proper order.
This makes the TCP protocol very marketable and is the dominant protocol used in the
Transport Layer. Most applications on the Internet use TCP, including email clients,
Telnet, FTP, and web browsing clients.
The User Datagram Protocol (UDP) is based on a connectionless-oriented service . This service, as opposed to the connection-oriented one (TCP), simply sends the packets (datagrams) of data without any prior handshaking routines.
There is no flow control or congestion control associated with a connectionlessoriented service, so data travels much faster from the transmitting end to the receiving end. But since there is no reliable data transfer, data may not arrive. Even if the data arrives, there is no method to ensure that it will arrive in the same order it was sent.
UDP, unlike TCP, does not figure out the MTU of the underlying network, instead it relies on IP layer to fragment the packets.
UDP, even with its many drawbacks, has its uses. Many multimedia applications, such as video conferencing applications and Internet phone applications use UDP for its quick data transfer time.

As we began our research, we needed a way to measure the performance of TCP and UDP. We were currently involved in a network course and had exposed us to both network programming and networking tools. So we could either write are own software program from scratch or use the tools that were readily available to us. To save time and effort we decided upon a readily available, open source utility called PCATTCP. The fact that it was open source allowed us to see exactly what they did and make changes if necessary.
Test TCP (TTCP), originally developed for the BSD operating system, is a benchmarking tool used to measure TCP and UDP performance between two systems.
PCATTCP, PCAUSA’s (Printing Communications Association) port of TTCP from the
BSD operating system to Windows, is the program we used as our benchmarking tool.
PCATTCP sends packets of data from a transmitting machine to a receiving machine and measures statistics. The user at the transmitting end can pick the number of packets to be sent, and the size of those packets. This seemed to be exactly the type of tool we were looking for. We could vary the packet size and test over different connections easily.
To use PCATTCP you simply setup a receiver (server) and then run a transmitter
(client) to send TCP or UDP packets as specified on the command line. A few simple examples follow
This example shows how to send TCP packets.
Setup a TCP receiver
C:\PCATTCP> pcattcp –r (this is done on the computer acting as a receiver whose
IP address is 128.153.140.153)
Then, setup the transmitter to send to TCP packets.
C:\PCATTCP> pcattcp –t 128.153.140.153
(this is done from an arbitrary computer that is connected to the Internet.)
This example shows how to send UDP packets.
Setup a UDP receiver
C:\PCATTCP> pcattcp –r –u (again done on the computer that will act as the receiver whose IP address is 128.153.140.153)
Then, setup the transmitter to send UDP packets
C:\PCATTCP> pcattcp –t –u 128.153.140.153

On the receiver:
Figure 1: The PCATTCP Receiver, receiving TCP packets
On the transmitter:
Figure 2: The PCATTCP Transmitter, transmitting TCP packets

On the receiver:
Figure 3: On The PCATTCP Receiver, receiving UDP packets
On the transmitter:
Figure 4: On The PCATTCP Transmitter, transmitting UDP packets

The output shown above is from two tests, the first a transmission of TCP packets output is shown for both the receiver and the transmitter. And the second is the output of a UDP transmission, again from both receiver and transmitter perspectives. The outputs shown above are for a default buffer (packet) size of 8192 bytes and a default number of buffers (packets) 2048. So a total of 16777216 bytes are sent. PCATTCP allows the user to specify the number of packets and packet size on the command line with the –n and –l flags. So we used this feature to vary packet size and also vary the number of packets accordingly to send 8MB of data in each test. We varied the packet size from 32 bytes to
8 KB by powers of 2 and varied the number of packets accordingly so that the total data sent per test was 8MB. Example command lines would be:
On the receiver specify the maximum packet size to receive
C:\PCATTCP>pcattcp –l 32 –r
On the tramitter specify the packet size to send and the number of packets to send
C:\PCATTCP>pcattcp –t –l 32 –n 262144 128.153.140.153
So for this process to run from 32 byte to 8 KB packet sizes, we need to run the program nine times, coordinating the packet sizes each time and recording statistics by hand.
Then repeat the process and transmit identical combinations with UDP packets. You can see how this quickly became a lengthy process

The command line arguments of PCATTCP are shown below.
PCAUSA Test TCP Utility
Usage: pcattcp -t [-options] host [ < in ]
pcattcp -r [-options > out]
Common options:
–h display this help message
-l ## length of bufs read from or written to network
(default 8192)
-u use UDP instead of TCP
-p ## port number to send to or listen at
(default 5001)
-s toggle sinkmode (enabled by default) sinkmode enabled:
-t: source (transmit) fabricated pattern
-r: sink (discard) all received data
sinkmode disabled:
-t: reads data to be transmitted from stdin
-r: writes received data to stdout
-r: sink (discard) all data from network
-A align the start of buffers to this modulus
(default 16384)
-O start buffers at this offset from the modulus
(default 0)
-v verbose: print more statistics
-d set SO_DEBUG socket option
-b ## set socket buffer size (if supported)
-f X format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga
-c -t: send continuously
-r: accept multiple connections sequentially
Options specific to -t:
-n ## number of source bufs written to network
(default 2048)
-D don't buffer TCP writes (sets TCP_NODELAY socket option)
Options specific to -r:
-B for -s, only output full blocks as specified by -l
(for TAR)
-T "touch": access each byte as it's read
-R concurrent TCP/UDP multithreaded receiver

PCATTCP measured the things we wanted but did not completely meet all of our needs. It required too much manual presence and required the user of the transmitter and server to coordinate what packet sizes to send. Also once a test completed, statistics would have to be manually recorded. This was not a good way to gather a considerable amount of data quickly and efficiently. Another problem we found in PCATTCP was that in the case of UDP tests it failed far too often. During a failure, the receiver would hang waiting for more data, however the transmitter had already finished. The fix at the time would be to restart the server and run the test over again. We had to do something to lessen the amount of manual presence that was required.
In order for our research to cover a lot of ground in a short period of time we needed the process to be automated. We created a PCATTCP Controller that changes
PCATTCP so it requires no manual presence at all (just the initial installation and running of the program). The transmitting side and the receiving side communicate by the means of a 2 nd
connection. This connection, which is always a TCP service, enables the transmitting side to “handshake” with the receiving side. This connection is always open, and is used for purposes such as letting the receiving side know how much data is incoming, making sure the receiver is ready to receive the data, etc.
PCATTCP also now runs 9 times, each with varying amounts of packet sizes and numbers of packets. The total data being sent still remains the same. This “9 test run” is itself run 5 times, to check for consistency in the data transfer rates of each of the different runs. The user can also change many parameters. ( Explained in detail in the section on: Advanced use of PCATTCP Controller )
We had mentioned before that UDP tests had failed at various points. This was due to the fact that UDP has no flow control, so a UDP transfer overwhelms the receiving computer. The reason it was failing was that the end marker of the data transfer was getting lost in the network while the receiving computer was being overwhelmed with data. This would cause the receiving computer to hang, waiting for more data, but the transmitting computer had already finished sending all the data along with the end markers. A simple pause by the transmitter before the end markers were sent would allow the receiving computer time to free its internal receiving buffers and obtain an end marker.
Our PCATTCP Controller also generates a tabulated text file that imports easily into a spreadsheet program (i.e. Microsoft Excel). This text file contains the total data sent, packet size, number of packets, effective throughput, elapsed time, total data received, total data lost, number of packets lost, percent received, and the header size that the TCP/UDP protocols add on to each packet (in bytes). We have also created a template, Microsoft Excel workbook, that you can import the text files to and create effective throughput and efficiency graphs.

Our PCATTCP Controller is available for download for most versions of
Windows, Linux and Unix operating systems. The source code is also openly available.
This chapter explains how obtain and use our PCATTCP Controller.
Download the current version of PCATTCP Controller from http://www.clarkson.edu/projects/itl/HOWTOS/mcnair_summer2002/Code/ caveat: the unix version 7_23_02_UNIX_PCATTCP reports incorrect elapsed times (bug that is yet to be worked out)
Once you have downloaded the program on your computer extract the
Date _PCATTCP_CONTROLLER.zip file into a new directory called PCATTCPC
(located in the root level of your C: drive)
NOTE: You can put your executable anywhere you like, but this manual assumes it is in the location specified above.
Once you have downloaded the program on your computer extract the
Date _UNIX_PCATTCP_CONTROLLER.tar.gz file into a new directory called
PCATTCPC (located in the root level of your home directory)
NOTE: You can put your executable anywhere you like, but this manual assumes it is in the location specified above.
after you have install either version, use this manual to obtain results. Then compare your results to ours. Our results can be found at the following address. http://www.clarkson.edu/projects/itl/HOWTOS/mcnair_summer2002/Results/

Once you have the PCATTCP controller download and installed, you can follow these simple steps to get it up and running.
Before any data is sent you must first start the receiver. To start the receiver, open a command prompt and change directory to C:\PCATTCPC (in UNIX
$HOME/PCATTCPC) at the prompt type: pcattcpc –r
Example: C:\PCATTCP> pcattcpc –r
[UNIX: ~crux> pcattcpc –r]
Before you start the transmitter the receiver must be running. Once the receiver is running, start the transmitter by typing: pcattcpc –t host
Example: C:\PCATTCP> pcattcpc –t 128.153.140.153
[UNIX: ~crux> pcattcpc –t 128.153.140.153]
(To use more options, see the section on PCATTCP Controller command line arguments .)

The PCATTCP Controller receiver is setup to run until it is explicitly shutdown.
It is in an infinite loop waiting for a PCATTCP transmitter to initiate contact and begin a trial. The receiver can only be connected to one transmitter at a time.
The PCATTCP Controller receiver by default (only the required arguments) will run 5 identical trials. Each trial consists of sending TCP packets and UDP packets.
There is also a third test that sends UDP+12 packets, what that means is that we simply added 12 to the packet sizes. This in an attempt to take away the disadvantage TCP has with a header size that is 20 (12 more than UDP). The UDP+12 trials will be compared to TCP. The tests that are we ran had the following packet sizes and number of packets.
Both TCP and UDP have the following trials that are run:
32 bytes 26214 packets
64 bytes
128 bytes
256 bytes
131072 packets
65536 packets
32768 packets
512 bytes
1024 bytes
2048 bytes
4096 bytes
16384 packets
8192 packets
4096 packets
2048 packets
8192 bytes 1024 packets
Then UDP +12 has the following trials:
44 bytes
76 bytes
140 bytes
268 bytes
524 bytes
1036 bytes
262144 packets
131072 packets
65536 packets
32768 packets
16384 packets
8192 packets
2060 bytes
4108 bytes
8204 bytes
4096 packets
2048 packets
1024 packets

In order run the above trials with the original PCATTCP program you would need to use the following command lines: computer 1 : IP address: 128.153.140.153 (receiver) command lines in red computer 2 : some computer connected to internet (transmitter) command lines in blue
1. start receiver pcattcp -r –l 32
2. transmit packets pcattcp –t –l 32 –n 262144 128.153.140.153
3. start receiver again pcattcp –r –l 64
4. transmit packets again pcattcp –t –l 64 –n 131072 128.153.140.153
5. start receiver again pcattcp –r –l 128
6. transmit packets again pcattcp –t –l 128 –n 65536 128.153.140.153
7. start receiver again pcattcp –r –l 256
8. transmit packets again pcattcp –t –l 256 –n 32768 128.153.140.153
9. start receiver again pcattcp –r –l 512
10. transmit packets again pcattcp –t –l 512 –n 16384 128.153.140.153
11. start receiver again pcattcp –r –l 1024
12. transmit packets again pcattcp –t –l 1024 –n 8192 128.153.140.153
13. start receiver again pcattcp –r –l 2048
14. transmit packets again pcattcp –t –l 2048 –n 4096 128.153.140.153
15. start receiver again pcattcp –r –l 4096
16. transmit packets again pcattcp –t –l 4096 –n 2048 128.153.140.153
17. start receiver again pcattcp –r – l 8192
18. transmit packets again pcattcp –t –l 8192 –n 2048 128.153.140.153

After running those 18 commands, you would need to do the same for UDP with a
–u flag on each command line. Followed by 18 more command lines with a different number for the packet size (specified by the –l option). So altogether 56 command lines!
(28 per computer) Not to mention the 56 times you will have to stop and keep track of the statistics, then make sure the server is ready before transmitting again. Not a very fun or efficient process. Our PCATTCP Controller does all this work for you and more! You can specify how many times to do this process and also many parameters.
PCATTCP Controller Test TCP Utility
Usage: pcattcpc -r [-options]
pcattcpc -t [-options] host
NOTE: some functionality has not yet been ported to the unix version
-r specific options
-S
-t specific options
-F filename
-N ##
-P ##
-L ##
-x silent (only print progress messages) set output filename number of trials to run set minimum packet size set minimum number of packets to send shutdown host
The command line arguments are listed in the previous section. This section goes into more depth on how to use those options

The text file must be specified with the –F option. (See above section on
Command line arguments)
The text file contains the following attributes:
Protocol type (TCP or UDP)
Header size (bytes)
Packet size (bytes)
Number of packets sent (int)
Total sent (bytes)
Total received (bytes)
Elapsed time (sec)
Effective throughput (KB/sec)
Effective throughput (Mbit/sec)
Total lost (bytes)
Packets Lost (int)
Percent Received
Once you have successfully produced a text file, you will be able to import to automagically create the graphs that will be discussed in the next section. To generate the graphs:
(1) Open the templatePCATTCPC.xls file that can be downloaded here: http://www.clarkson.edu/projects/itl/HOWTOS/mcnair_summer2002/Results/tem plate.xls
(2) Click on cell A64, then go to Data

Get External Data

Import Text File.
(3) Navigate to the file that you created with PCATTCP Controller and click
Import.
(4) Click Finish. You’re done! Check out the graphs that were created for you.
(See next section on Graphs produced)

Once you have successfully imported the text file and the graphs were automagically created, you are now ready to analyze the results. The excel spreadsheet should now contain the following information:
(1) Three graphs that are an average of the results from the individual trials. The three graphs are:
(a) Effective Throughput vs. Packet Size
(b) Effective Throughput vs. Elapsed Time
(c) Percent Received vs. Packet Size
(2) The raw data that is an average of the individual trials
(3) The same three graphs for each trial (1 a, b, and c)
(4) The raw data for each trial
The graphs we obtained during our research can be found in Appendix A.

Once we were able to use our PCATTCP Controller, we did. We used it to test over many connections. We had some ideas about what to expect. Conventional wisdom suggests that UDP is much faster than TCP. TCP on the other hand has some very nice features. How much of a penalty to we pay to use TCP and get all these nice, in order reliable, good citizen features? Can we quantify the differences between TCP and UDP.
These were the types of questions that we wanted to answer as we moved forward we our research, PCATTCP Controller in hand.
We ran our PCATTCP Controller on six different types of connections. These connections were Same Host, Same Switch, Same LAN, LAN to Road Runner, LAN to
LAN, and Wireless to Wireless. The exact details of these connections are discussed in detail in Appendix B.
Same Host (loopback) – We sent data from a computer to itself.
Same Switch – We sent data between two computers connected to the same physical switch. A switch a device that filters and forwards packets between
LAN segments, several computer, or other network devices can be connected to the same switch. Computers in a computer lab, for example, are usually on the same switch.
Same LAN – We sent data between two computers on the same LAN. A Local
Area Network (LAN) is a group of computers linked together that can communicate with other devices on that network. One possible way to assemble a
LAN is to link together many different switches within a small area such as a college campus. To accomplish this test, we used two computers at different locations at the Clarkson University campus.
LAN to Road Runner – We sent data from a computer connected to a LAN to a computer connected by a Road Runner service. This experiment symbolizes the connection between a well-connected, high bandwidth network, such as Clarkson
University, to a lower bandwidth home connection that uses an Internet Service
Provider (ISP), such as Road Runner.
LAN to LAN – We sent data from a computer connected to a LAN to another connected to another LAN. This connection is the connection between two wellconnected networks with high bandwidth. For our purposes, we used a connection between Clarkson University and SUNY Potsdam.

Wireless to Wireless – We sent data between two laptop connected (through the air) to a wireless router, both laptops in the same room within 5 feet of the router.
This connection symbolizes two well-connected wireless connections.
If we looked only at the Same LAN graphs and assumed that since we consistently got about 6 times better throughput out of UDP, and so that was the cost we paid to use the nice features of TCP, that would have been a tremendous oversimplification of the problem. When we realized there was much more to the story, we were able to expand our research and broaden our study of the two protocols. As our summer research program got nearer to its end, we realized that it would be best to lay the foundation for future work that will be done. We did not hastily run some trials just to get results, we went through the painstaking process of perfecting our PCATTCP
Controller and clearer document the work that we were doing and that should be done.
The two main factors that cause the difference and performance are the underlying network environment and the sizes of packets that are being sent across that network. The details of the underlying network of primary concern are available bandwidth, amount of traffic on the network, and the hardware used in the network.
Details of all the connections we tested are in Appendix B. The other factor, packet size, goes hand in hand with the network environment. If the network cannot handle packet sizes that are trying to be sent through, then there is the overhead of fragmenting the packets or worse yet packets may be dropped. On the hand, if the packet sizes are small and the network could handle more, you pay a performance cost by not sending big enough packets. And to complicate things even more, TCP and UDP have different methods to handle such things as fragmentation, and these and other factors affect the performances of TCP and UDP.
Note: All the result graphs can be found in Appendix A. Due to time constraints, we did not get to analyze them as much as we wanted.

We found that UDP has higher effective throughput in many, but not all, common environments. The most unexpected result was that TCP is better in all recorded statistical categories on the same switch. We attribute this to the fragmentation done at the IP layer in the implementation of UDP. As expected, UDP performs better within a
Local Area Network (LAN) and outside of a single LAN. Within a LAN, UDP has low drop rates and much better effective throughput than TCP. However, outside the LAN,
UDP has excessive loss rates.

In terms of effective throughput we found, as expected, that UDP is usually faster.
It was about 6 times faster on the same LAN and 2 times faster from LAN to LAN.
However, TCP was actually faster in a couple of cases. It was 2 times faster on the same switch and slightly faster from LAN to Road Runner for large packet sizes.
In terms of efficiency, we found, as expected, TCP to be 100%. UDP on the other hand was not as good. On the same switch and same LAN it was near 100%, but from
LAN to LAN it was for the most part below 50%, and from LAN to Road Runner it was for the most part less than 10% or worst.
As mentioned before, we would expect UDP to always be faster, since TCP has a lot of overhead. Two of the main causes for lower throughput were the fact that UDP does not have flow control, and also does not retransmit lost packets. On the same switch, the most unexpected results, the reason UDP had lower throughput was because
UDP relied on the IP layer to fragment the packets that were bigger than the Maximum
Transmission Unit (MTU), the biggest packet size that the underlying network can handle, while TCP calculates the MTU itself and does fragmenting ahead of time.

Future research will be done using wireless technology, modifying Linux kernel implementations of TCP and UDP, and transmitting and tracking larger amounts of data.
As mentioned before, we did not get to finish everything we wanted to in the limited time we had so we have many ideas for future research, questions left unanswered and so important things to take into consideration as future research takes place.
An easy experiment would be to try the same number of packets with a large packet size and a small packet size. We hypothesize that the throughput of the large packet size would be a lot better.
A factor to consider is how much network bandwidth do we have and how much of it do we actually get with each protocol. Should TCP and UDP really get the full amount?
TCP has connection setup time
Header overhead for both
TCP response time
TCP slow start (handshaking)
Add transmitting throughput to graph to see the difference between how much someone can send over how much someone can receive?
On the same switch, the maximum is a 100MBit/sec switch, CISCO 2900 series 100 mbit/sec switch
On the same LAN, the maximum is 100 Mbits/sec
On a T3, the maximum seems to be 45 Mbits/sec
The max for TCP was at packet size 64 bytes and the max for UDP was at 8KB.
In general bigger packets means more throughput explain in general why - amortize overhead same header, same ACK overhead. For UDP this is strictly true, for TCP is it best at smaller packet sizes then gets worse
We cannot fully explain this but we note that the TCP layer in the kernel does not try to send in units of the applications writes, it tries to figure out the best maximum segment size and may delay sending until it gets it etc. We suspect this is an interaction with the maximum sending size

Note the UDP layer will send in units of the application writes even if they are too big to send out on the underlying network
Ex. Ethernet max is 1500 (20 bytes IP, X bytes UDP, blah bytes data) - so UDP will experience fragmentation overheads
Another difference between TCP and UDP is the amount of data that reaches the destination. Even on a local network UDP is losing up to X % of the data, why?
TCP interprets all losses, as due to congestion - is this true in this case?
Use TCPTRACE on local network and find if TCP retransmissions are low.
TCP didn't experience those losses why?
UDP did, very little network traffic if any, collisions not likely then why?
UDP's lack of good manners hurts it, so its not just on the network because its lack of flow control over whelmed the receiver, find evidence of this.
We can't be sure that we experienced no congestion in the LAN path
Same switch - we know there is no congestion there; look at the two sets of results.
UDP still seeing losses
Take an Ethereal trace on a dedicated tracer machine near the receiver - did it see it all?
What about the same host?
Illustrate the effect of lack of flow control
Look at what happens as we change the characteristics of the underlying network.
We expect that within the Clarkson network there will be relatively little congestions and therefore packet loss due to congestion.
LAN, ROAD Runner, Potsdam state case to show varying networks
When UDP is faster, how much is due to less header overhead?
Not much
LAN, add in UDP+12
When UDP is faster, how much is due to the connection establishment measure RTT - subtract from the TCP elapsed times
UDP, UDP+12, UDP+12+RTT each vs. TCP
What differences are left? Slow start… time out… go back to slow start.

What happens in a wireless environment?
Future work:
More modeling
More correlation of Ethereal traces to measurements
- Nail down the fragmentation overhead
Noticed some combinations especially bad - use ethereal traces to understand why
Run with larger amounts of data - would like to see trials all have elapsed times greater than 10 seconds. Hazard encountered: uses up Clarkson’s T3 and potentially making people fear hackers or getting mad because they have poor
Internet connection.

First and foremost, we would like to thank the wonderful staff of the Ronald E.
McNair program. This includes Cathy Clark, Dave Falvo, Luz Castillo, and Tammy
Kunz. We would like to thank them for funding our research project, and also for their guidance and support.
Also, we would like to thank Dr. Jeanna Matthews, the faculty mentor guiding our research project, for her tremendous efforts, they were extremely helpful. She first guided us through a course in computer networks, and then gave us idea after idea on experiments for our research.
Last, but not least, we would like to thank Alex Deshane, Romeyn Prescott, and
Matt Keller, the people at SUNY Potsdam, for giving us access to their computer facilities and network bandwidth for our research

PCATTCP utility from PCAUSA http://www.pcausa.com/Utilities/pcattcp.htm
Using TTCP or PCATTCP http://www.clarkson.edu/projects/itl/HOWTOS/PCATTCP-jnm-20011113.htm
dictionary.com http://www.dictionary.com
Merriam-Webster OnLine http://m-w.com/home.htm
Webopedia.com http://www.webopedia.com
Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach
Featuring the Internet. Addison Wesley. 2001.
TCP RFC
UDP RFC

see: http://www.clarkson.edu/projects/itl/HOWTOS/mcnair_summer2002/Results/8MB_7_12
.xls

which machines we used to transmit and receive in each case need to run a traceroute to each and put it in an appendix
On the same LAn, the path took four hops
Document all wireless stuff lan to wireless, or wireless to wireless? how close were the comps to the hub?
On the same host, document how much memory, CPU, and all that stuff

F
IGURE
1: T
HE
PCATTCP R
ECEIVER
,
RECEIVING
TCP
PACKETS
........................................ 7
F IGURE 2: T HE PCATTCP T RANSMITTER , TRANSMITTING TCP PACKETS ........................... 7
F
IGURE
3: O
N
T
HE
PCATTCP R
ECEIVER
,
RECEIVING
UDP
PACKETS
.................................. 8
F
IGURE
4: O
N
T
HE
PCATTCP T
RANSMITTER
,
TRANSMITTING
UDP
PACKETS
.................... 8