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.

Discussion of purpose

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

Transmission Control Protocol (TCP)

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.

User Datagram Protocol (UDP)

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 connectionless-oriented 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.

Chapter 2 PCATTCP

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.

PCATTCP benchmarking tool

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.

Using PCATTCP

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

Advanced use of PCATTCP

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

PCATTCP command line arguments

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

Weaknesses of PCATTCP

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.

Changes made to PCATTCP

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.

Chapter 3 PCATTCP Controller

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.

Installation and setup

Obtaining the software

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)

Installing the program in windows

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.

Installing the program in unix

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/

Using PCATTCP Controller

Once you have the PCATTCP controller download and installed, you can follow these simple steps to get it up and running.

Starting the receiver on a server machine

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]

Starting the transmitter on the client machine

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

*******************************************************************************Insert PCATTCP Controller Examples here, briefly explain and then refer to next sections for more details

Features of PCATTCP Controller

The receiver

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 transmitter

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 131072 packets

128 bytes 65536 packets

256 bytes 32768 packets

512 bytes 16384 packets

1024 bytes 8192 packets

2048 bytes 4096 packets

4096 bytes 2048 packets

8192 bytes 1024 packets

Then UDP +12 has the following trials:

44 bytes 262144 packets

76 bytes 131072 packets

140 bytes 65536 packets

268 bytes 32768 packets

524 bytes 16384 packets

1036 bytes 8192 packets

2060 bytes 4096 packets

4108 bytes 2048 packets

8204 bytes 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 command line arguments

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 silent (only print progress messages)

-t specific options

-F filename set output filename

-N ## number of trials to run

-P ## set minimum packet size

-L ## set minimum number of packets to send

-x shutdown host

Advanced use of PCATTCP Controller

******************************************************************************Add explanations here

The command line arguments are listed in the previous section. This section goes into more depth on how to use those options

Text file produced

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

Generating the graphs

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

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

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

Chapter 4 Data Collection and Analysis

Research Expectations

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.

Connections we tested

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 well-connected 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.

Results

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.

Performance factors

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.

Conclusions

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.

Effective Throughput

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.

Efficiency

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.

Causes of lower throughput with UDP

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.

Chapter 5 Future Research

Future research will be done using wireless technology, modifying Linux kernel implementations of TCP and UDP, and transmitting and tracking larger amounts of data.

Open-ended questions and considerations

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.

Chapter 6: Acknowledgements

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