CSS 432 - Program 3: TCP Analysis

CSS 432
Program 3: TCP Analysis
Professor Dimpsey

1. Purpose

This assignment will focus on the behavior of the TCP protocol through a number of experiments. There are two major sub-tasks that make up the assignment, each of which requires a seperate program. These programs can be found in the /CSSDIV/classes/432/hw3 directory on the UWB Linux lab systems.

First, the hw3 program will be utilized as a basis for drawing the TCP state transition diagram as well as a corresponding timing chart. You will also be required to write your own program mimicing hw3. This will help re-enfore the sequence of system calls underlying the TCP protocol.

Second, you will run the ttcp program with a number of different parameters effecting the message size, the number of messages transfered, the socket buffer size, and the use of Nagle's algorithm. Note that there is also a version of ttcp at /usr/bin/ttcp, but we will not be using that version. Get ttcp from the directory, /CSSDIV/classes/432/hw3, on the UWB Linux lab. Using the tcpdump, netstat, and strace commands you will observe how TCP segments are transmitted.

2. Key TCP Book Sections

Section 5.2.3 Connection Establishment and Termination (pp 402-407)

Review the timeline for the three-way handshake algorithm (page 402). You will draw such a timing chart as part of your assignment work. Trace the TCP state transition diagram (page 405), so that you can draw the diagram corresponding to hw3.

Section 5.2.5 Triggering Transmission (pp 414-417)

Understand when TCP transmits a new segment on the network. This knowledge is necessary to write a program mimicing hw3. Also, review the silly window syndrome and Nagle's algorithm. This will help you interpret the behavior or ttcp.

Sections 6.3.1 AIMD and 6.3.2 Slow Start (pp 500-510)

Review the two algorithms to increase the advertised/congestion window in TCP: additive increase and slow start. You will be asked which of those algorithms is being used, along with other observations in your experiment.

3. Overview of ttcp, tcpdump, netstat, and strace

The following four commands are useful to check the statistics of TCP segments exchanged with a remote computer.

3.1 ttcp

The ttcp utility is a public domain program originally provided from the Ballistics Research Laboratory. It sends arbitrary amounts of data to another machine using TCP or UDP, and collects statistics regarding the transfer. Although this utility has various options, we will focus on only TCP.

Usage: ttcp -t [-options] remotehost
       ttcp -r [-options]
       where:
        -t      transmit data
        -r      receive data
       common options:
        -l#     length of bufs read from or written to network (default 8192)
        -b#     set the socket buffer size if supported (default is 16384)
        -p#     specify another service port (default is 5001)
        -?    print this help
       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)

You will need to start ttcp on the server computer first and then start it on the client computer. Use the -r argument on the server and the -t option on the client. For instance, if we assume csslab2 is the server and csslab1 is the client, the following would be executed:

[user@csslab2]$ ./ttcp -r
[user@csslab1]$ ./ttcp -t

Given the -r option, ttcp will keep running as a server to repeatedly accept a new TCP connection and to sink all data received along the connection until a user specifically terminates it with a "control c" key input. On the other hand, the -t option directs ttcp to make a new TCP connection to a server, to send messages to it, and to terminate the program.

3.2 tcpdump

tcpdump is a network sniffer made available on both Linux and Windows. To run this utility a user must be a super user or an administrator. In the Linux lab permissions have been updated to allow you to use tcpdump with your current permissions.

  
tcpdump -vtt host hostname and port port and tcp

where hostname is a remote IP name and port is the port of the TCP connection to access. Note that the port must be larger than 5000.

If you use csslab1 as a ttcp client and csslab2 as a ttcp server, you should start the server and then open another xterm at the client end to run tcpdump as follows:

Start ttcp receieve on the server
./ttcp -r
Start recording tcp dump on the client
tcpdump -vtt host csslab2 and port 5001 and tcp >& tcpdump.out
Start ./ttcp transmitter in a seperate xterm on the client
/ttcp -t csslab2
When ttcp finishes transmitting on the client, stop tcpdump with a CTRL-C
Stop ttcp on the server as well with a CTRL-C

The trace results are saved in the tcpdump.out file. This file can grow to be quite large and so typical editors like emacs, vi or pico will not work to view it. You should use the more command instead.

3.3 netstat

netstat is a utility that prints network connections, routing tables, interface statistics, masquerade connections, and multicast memberships.

Since the tcpdump displays all exchanged packets, the amoun of data produced is overwhelming. netstat is a much more concise tool which can retreive useful network statistics. In particular, you will be interested in obtaining the summarized statistics of tcp packets. Learn how to use netstat through "man netstat", and confirm that -st is necessary to display the number of tcp packets sent, received, and retransmitted so far.

Invoke netstat right before and after the execution of "ttcp -t". The actual number of tcp packets exchanged can be calculated as a difference in the statistics between those two invocations of netstat.

[user@csslab1 hw3]$ netstat -st | grep segments
[user@csslab1 hw3]$ ttcp -t [-options] csslab2
[user@csslab1 hw3]$ netstat -st | grep segments

3.4 strace

strace traces system calls issued by a user application. We are interested in how long (in microseconds) the OS has spent executing each of the write system calls issued by the client while running "ttcp -t". Learn how to use strace by consulting the man page, "man strace". To utilize strace and direct the trace to a file while ttcp executes you will use the following command: "ttcp -t" as follows:

[user@csslab1 hw3]$ strace -ttT ttcp -t [-options] csslab2 >& results

The traced results are saved in the results file. Note that we are interested in write system calls onto a particular file descriptor, (i.e., a socket opened by ttcp). The file descriptor numbers 0, 1, and 2 are stdin, stdout, and stderr respectively. To view only write system calls onto this socket, you have to invoke the following cat and grep with an appropriate keyword.

[user@csslab1 hw3]$ cat results | grep [keyword]

4. Statement of Work

4.1 Experiments with `hw3` Program

Test 1: Run hw3 on any two of csslab machines, after starting tcpdump on another xterm window.

The general execution format:
xterm 1 (server side):
[user@csslab2 hw3]$ tcpdump -vtt host clientHostName and port portNumber and tcp

xterm 2 (server side):
[user@csslab2 hw3]$ hw3 portNumber                              

xterm 3 (client side):
[user@csslab1 hw3]$ hw3 portNumber serverHostName            

An example:
xterm 1 (server side):
[user@csslab2 hw3]$ tcpdump -vtt host csslab1 and port 12345 and tcp

xterm 2 (server side):
[user@csslab2 hw3]$ hw3 12345

xterm 3 (client side):
[user@csslab1 hw3]$ hw3 12345 csslab2

Analysis 1: Based on your tcpdump results, draw a transition diagram as shown on textbook diagram 5.7. Trace the diagram for the hw3 client and server respectively. (Draw thick red lines along appropriate arrows for the client and think blue lines for the server.)

Draw a timing chart as shown in the textbook diagram 5.6 that corresponds to your tcpdump results from the connection request to the disconnection.
Coding: Code a program that mimics the hw3 program. The tcpdump's results for your program must be the same as those for hw3 in terms of:
- the total number of messages
- the sequence and direction of messages including S, ., P, F, >, and < notations
- the data amount of each message
Of course, timestamps, message sequence numbers, ip addresses, and port numbers may vary for each execution.
Hint: You must use the shutdown system call at the server side.

4.2 Experiments with `ttcp` Program

The ttcp program is available in the /CSSDIV/classes/432/hw3 directory in Linux lab.

Test 2: Run ttcp on any two of csslab machines, (i.e., csslab1 ~ csslab12) in the following test cases without and with -D option.

-l (message length)	-n (# messages)
64	1048576
128	524288
256	262144
512	131072
1024	65536
2048	32768
4096	16384
8192	8192
16384	4096

Test 3: Run ttcp in the following particular test case without -D while you are running tcpdump on another xterm. Determine from the dump file what is the TCP maximum segment size (MSS). Clearly call out this size in your report; also explain why the MSS is this value.

-l (message length)	-n (# messages)
32768	2048

Test 4: Run ttcp tests holding the total amount of data sent constant but the length of the message (-l) being slightly less than the MSS, equal to the MSS and slighlty more than the MSS. Do this with and without the -D option. For instance, if the MSS was 1460 you could do the following experiments:

-l (message length)	-n (# messages), round decimal points
1458	67108864 / 1458 = 46028
1460	67108864 / 1460 = 45965
1462	67108864 / 1462 = 45902

Test 5: Run ttcp in the following particular test case with and without -D option. Run netstat right before and after each execution of ttcp to count the tcp packets sent, received, and retransmitted. Thereafter, run "strace -ttT ttcp" in the following particular test case without and with -D option.

-l (message length)	-n (# messages)
64	1048576

Analysis 2: Make a graph or a table in terms of Mbps for the test 2. Discuss:
1. The effect of buffer length without using -D option
2. The effect of -D option
Analysis 3: Make a graph describing how the advertised window changed on the server side when you ran test 3. Just focus on the first 10 acknowledgments from the server. Make clear:
1. Does the growth of the advertised window follow additive increment, slow start, or perhaps a different algorithm?
2. How large is MSS in TCP?
Analysis 4: Make a graph or a table in terms of Mbps for the test 4. Discuss:
1. The effect of buffer length without using -D option
2. The effect of -D option
3. How the MSS impacts the performance
Analysis 5: Discuss the effect of -D option based on the following results you received from the test 5:
1. the number of TCP packets sent, received, and retransmitted
2. the time required for OS to execute each write system call (focus on the first 20 writes.)

5. What to Turn in

Criteria	Percentage
Test 1 execution: The hw3 tcpdump results as well as your program's tcpdump results.	2pts(10%)
Analysis 1: State transition diagram and timing chart that traces the hw3 program	4pts(20%)
Coding: Source code that adheres good modularization, coding style, and the appropriate amount of comments. The source code is graded in terms of (1) using shutdown, (2) correctness, and (3) coding guidelines.	8pts(40%)
Test 2 ~ 5's performance results: Include (1) test 2's results in Mbps, (2) test 3's results in terms of the advertised window, (3) test 4's results in Mbps, and (4) test 5's results in terms of packets sent, received, and retransmitted; and the time elapsed for each of the first 20 write system calls. Results must be compiled in tables and/or graphs. Don't attach raw data.	3pts(15%)
Discussions: Do all five analsysis.	3pts(15%)
Total	20pts(100%)

6. FAQ

This FAQ page may answer your quetions. Click here