CSS 432
Program 3: TCP Anaysis
Instructor: Joe McCarthy
Due date: See the syllabus

1. Purpose

Through this assignment you are to analyze the behavior of the TCP protocol. Your analysis includes two sub tasks.
  1. You will run the instructor's hw3 program so as to draw its TCP state transition diagram as well as the corresponding timing chart, and write your own program mimicking the instructor's in order to understand what sequence of system calls generates the TCP behavior you observed.
  2. You will run the instructor's ttcp program, manipulating its parameters such as the message size, the number of messages transfered, the socket buffer size, and Nagle's algorithm on/off switch. [Note that there is also a version at /usr/bin/ttcp, but we will not be using that version.] Using tcpdump, ttcp, netstat, and strace, you will observe how TCP segments are actually transmitted and how the OS interferes with the transmission.

2. Required Knowledge on TCP

Read the following sections of your textbook to review TCP's typical behavior:

Section 5.2.3 Connection Establishment and Termination (pp 390-394)

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

Section 5.2.5 Triggering Transmission (pp 414-418)

Understand when TCP transmits a new segment on the network. This knowledge is necessary to write a program mimicikng the instructor's hw3 program. Review the silly window syndrome and Nagle's algorithm so as to reason about ttcp's behavior in these contexts.

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

Review two algorithms to increase the advertized/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 Test TCP (ttcp) utility is a public domain program written in the 1980s by Mike Muuss and Terry Slattery at 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 TCP and a subset of the original options. 
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 need to start ttcp on a server computer first and then start it on a client computer. If, for example, you are using UW1-320-01 as a client (sender) and UW-320-02 as a server (receiver), and have copied the instructor's ttcp executable to your hw3 directory, the invocations might look like the following: 
[user@uw1-320-02 hw3]$ ./ttcp -r

[user@uw1-320-01 hw3]$ ./ttcp -t uw1-320-02
Given the -r option, ttcp will keep running as a server to repeatedly accept a new TCP connection and to sink (discard) all data received along the connection until a user specifically terminates it with CTRL-C. On the client side, the -t option directs ttcp to make a new TCP connection to a server, to send messages to it, and then terminate the program.

3.2 tcpdump

tcpdump is a network sniffer or analyzer made available on both Linux and Windows. To run this utility, you must be a superuser or an administrator, because tcpdump reveals all network transactions. In our class, you will use sudo to temporarily invoke superuser status while executing the /usr/bin/dumptcp.sh shell script to run tcpdump with limited parameters such as: 
 tcpdump -vtt host $1 and port $2 and tcp
where $1 is a remote IP name and $2 is the port of the TCP connection you would like to access. The port must be larger than 5000.

Following the previous example, if you use uw1-320-01 as a ttcp client (transmitter) and uw1-320-02 as a ttcp server (receiver), you should start the server, then open another xterm on the client end (at uw1-320-01) to run dumptcp.sh as follows:

  1. Start the ttcp receiver on uw1-320-02 by typing
    ./ttcp -r
  2. Start recording the tcp dump on the client (uw1-320-01) by typing
    sudo /usr/bin/dumptcp.sh uw1-320-02 5001 >& dumptcp.output
  3. Start the ttcp transmitter in a separate xterm on uw1-320-01 by typing
    ./ttcp -t uw1-320-02
  4. When the ttcp transmitter finishes, stop recording the tcp dump by typing CTRL-C in that xterm
  5. Stop the server by typing CTRL-C in the xterm on uw1-320-02

An enormous amount of data is generated by this command, so the results should always be saved in a file using the Linux stderr redirect operator (>&). Note that this file might be too big to view using an editor like emacs or pico. Instead, use the more command, or better yet, the less command. Learn the output formats of the version of tcpdump installed on our system by using man tcpdump.

3.3 netstat

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

tcpdump displays all exchanged packets, which can provide an overwhelming amount of information; some of this information can be more easily retrieved with the netstat command with appropriate options. We are interested in obtaining summarized statistics of tcp packets. Learn how to use the version of netstat installed on our system by using man netstat, and confirm that the -st option is necessary to display the number of tcp packets sent, received, and retransmitted so far.

In this case, invoke netstat right before and after the execution of ttcp -t in the same xterm on the client side. The actual number of tcp packets exchanged can be calculated as a difference in the statistics between those two invocations of netstat. 

[user@uw1-320-01 hw3]$ netstat -st | grep segments
[user@uw1-320-01 hw3]$ ttcp -t [-options] uw1-320-02
[user@uw1-320-01 hw3]$ netstat -st | grep segments

3.4 strace

Most operating systems provide a command to trace system calls issued by a user application. In Linux, it is strace. We are interested in how long (in microseconds) the Linux OS has spent executing each of write() system calls issued by ttcp -t on the client side. Learn how to use strace through man strace. To store the traced results in a file, you might want to execute ttcp -t as follows: 
[user@uw1-320-01 hw3]$ strace -ttT ttcp -t [-options] uw1-320-02 >& strace.output
The traced results are saved in the results file. Note that we are interested in write() system calls using 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 determine what number this socket is allocated, you may want to invoke grep with an appropriate keyword, for example 
[user@uw1-320-01 hw3]$ grep [keyword] < results

4. Statement of Work

4.1 Experiments with hw3 Program

The instructor's hw3 program is located at ~css432/hw3/hw3 on the Linux Lab network (uw1-320-lab.uwb.edu).

4.2 Experiments with ttcp Program

The instructor's ttcp is available at ~css432/hw3/ttcp on the Linux Lab network (uw1-320-lab.uwb.edu).

5. What to Turn in

The homework is due at the beginning of class on the due date and must be submitted via Catalyst.
Criteria Points (pct)
Test 1's execution results: the instructor's hw3's dumptcp.sh results as well as your program's dumptcp results. 2 pts (10%)
Analysis 1's documents: your state transition diaggram and timing chart that traces the hw3 program 4 pts (20%)
Coding: your source code that demonstrates good modularization, coding style, and an appropriate amount of comments. The source code is graded in terms of
  1. using shutdown (1 pt)
  2. correctness (3 pts)
  3. comments (1 pt)
5 pts (25%)
Tests 2, 3, 4 & 5 performance results: all results must be represented in tables and/or graphs rather than raw data.
  1. Test 2's results in Mbps (1 pt)
  2. Test 3's results in terms of the advertised window (1 pt)
  3. Test 4's results in Mbps (1 pt)
  4. Test 5's results in terms of packets sent, received, and retransmitted, the time elapsed for each of the first 20 write() system calls, and each size of the first 20 packets sent. (1 pt)
4 pts (20%)
Discussion:
  1. Analysis 1 (1 pt)
  2. Analysis 2 (1 pt)
  3. Analysis 3 (1 pt)
  4. Analysis 4 (1 pt)
  5. Analysis 5 (1 pt)
5 pts (25%)
Total 20 pts (100%)

6. FAQ

This FAQ page may address some of your questions. Click here

7. Acknowledgment

This assignment is closely modeled on an assignment earlier specified by Professor Fukuda.