HW3 -- Packet Analysis

Version 1.0. 1/25/05. 11.11am.
Out: Wed 1/25/06
Due Back: Fri 2/3/06 11.59 PM

Background

In class, we've been talking about the behavior of sliding window. TCP is a protocol that uses sliding window aggressively. And, as you know from the first two asssignments, tcpdump is a program that lets us monitor network activity at the packet level.

For this assignment, you will be analyzing some packet traces produced by tcpdump. For some of the questions, you may need to write a program. You may use any programming language you like, including shell scripts, or existing Unix tools. For others, you can probably just eyeball the output from tcpdump. To be clear, this is not a programming assignment, but you may use your programming skills to help you complete it.

A few details about tcpdump and tcp

For this assignment, you can use the standard tcpdump program, rather than tcpdump461. This is because you are working on a pre-existing trace file, so there are no privacy policy issues involved in using the program. Use tcpdump -r tracefile to look at packets in file tracefile.

There are two things to keep in mind about the output of tcpdump. The first are that some options are generic to all protocols and have to with how information is formatted as it is printed. These are set by command line flags. Here are some ones that you might find useful.

The second is that tcpdump includes a powerful expression-based filtering language that can be used to extract only certain packets from a trace. For example, to extract only those packets sent from www.cs.washington.edu, one would say tcpdump -r tracefile src host wwww.cs.washington.edu

TCP is bi-directional, meaning that any given packet can both carry data intended for the peer, as well as an acknowledgement for data sent from the peer. For many of the questions, you will want to look at data sent in only one direction.

TCP

A TCP sequence number refers to a byte, not a packet. Hence, any given packet is described by a pair of sequence numbers: the first and the last. For example, 1:1184 are the start and end in the following packet:

20:32:35.437157 IP www.cs.washington.edu.http > 10.0.1.4.60258: P 1:1184(1183) ack 202 win 1716

The difference is the size of the tcp portion of the packet. Questions that refer to packet size refer to just this portion.

A packet may also include an acknowledgement, where the acknowledgement contains a sequence number that describes the largest byte received such that all bytes of smaller sequence number have also been received. In the above example, the ack is for sequence number 202, which is the sequence number of the last in-order byte received. So, for example, if three packets are received in order with sequence numbers [1,100], [200,215], [216,220], then the TCP receiver does not generate an ack having a sequence number in excess of 100 until it receives a data packet with a sequence number of at least 101. It may however generate acks for sequence numbers 100 as a "signal" to the sender that something is quite literally "out of sorts" with the packets that have been received.

By default, tcpdump displays the true sequence number for the first packet in a conversation, and then reverts to a delta for subsequent packets. This makes the trace easier to read. You can use the -S option to change this behavior.

Here's the output of running tcpdump -r smalltrace.raw. I recommend that you open in a new window and STRETCH it in order to look at it. You won't need to know what all the fields are. The most important ones are the timestamp, src and destination host, sequence number, and ack (with sequence number).

The Assignment

There are two parts to this assignment. The first part involves answering a few questions about a very short packet trace representing a brief conversation between my home computer and a computer somewhere on the internet. The entire conversation fits on half a screen, and you should be able to answer all the questions about the first using tcpdump on the raw packet trace directly.

The second part involves analyzing a much longer packet trace, again between my home computer and a server on the internet. This file is too large for you to "eyeball" the results, so you will need to process it somehow.

The way in which you answer each question is just as important as your answer. That means that you should answer each question by providing the information being asked for, as well as an explanation for how you produced the answer. Your explanation should make clear strategy and mechanics. Strategy says "what to look for." Mechanics says "how to look for it."

For example, suppose the question was "A pure-ack packet is a packet that carries no data. It contains only an ack. How many pure ack packets are reflected in the trace file to www.cs.washington.edu?" A good answer would be:

Strategy: A pure-ack packet has no sequence number for data. In terms of the tcpdump default output, it's a packet that has an "ack" in the 7th field. Count the number of times that "ack" occurs in the seventh field of packets sent from www.cs.washington.edu
Mechanics: Filter the trace file for packets from www.cs.washington.edu, print the seventh field one per line, filter for "ack," and count the number of lines printed. Then, do the same thing for packets to www.cs.washington.edu. For example:
```
    tcpdump -r bigtrace.raw dst host www.cs.washington.edu | awk '{print $7}' | grep 'ack' | wc -l  
  
```
Answer: TO www.cs.washington.edu: 3365

Alternatively, you could write a program that computed this directly in any programming language you like.

Or, even more alternatively, you could use a combination of simple tools to extract portions of the data and put it an easy-to-use format, and then write a program that produces the final result. The choice is yours. You will not be graded on the basis of your choice of mechanics, but some choices will be much more time-consuming than others. You will find this assignment easiest if you first think about each question carefully in order to convince yourself that you can answer it easily without a lot of mechanics. None of the questions require much.

The Traces

You can get both the short and long trace files here.

Part A: Short Trace File

These questions can be answered with the data in smalltrace.raw.

Questions

These questions shouldn't require that you do anything more than look at the trace file. In some cases, you may need to use tcpdump to look at the raw trace file. In others, you can get the answer from the text dump above. For all questions, your solution should follow the strategy/mechanics/answer format.

A1. What is the IP address of my computer?
A2. What is the ethernet address of my computer?
A3. What is the destination ethernet address used to send a packet to the cs web site
A4. What is the largest packet size that is reported?
A5. Draw a timeline of packet transfers between my host and the server. Make sure you label (as best as you can) the time at which a packet was sent and received.
A6. What is the round trip time in microseconds between my home machine and www.cs.washington.edu.
A7. What web page was I fetching?
A8. In total, how much data did the server send me?

Part B: The Big Trace File

Now that you've gotten your feet wet, it's time to tackle a larger trace (bigtrace.raw) and some more difficult questions. This file shows my network activity while I was fetching a pdf file.

Questions

In addition to using the strategy/mechanics/answer format, in a few cases, I ask you to also discuss the meaning of the answer. Please be brief and thoughtful.

B1. How many pure ack packets are sent to www.cs.washington.edu?
B2. How much data is transferred in each direction?
B3. On average, how many bytes of data does my home computer receive for each ack it generates?"
B4. A delayed packet is one that is either lost, or is received out of order. How many packets sent from www.cs.washington.edu have been delayed?
B5. What is the client's response to determining that a packet has been delayed? (you may find that visual inspection gives you a handy "strategy" and "mechanics" for this question).
B6. Once the delayed packet has arrived, the receiving TCP sends an ack with substantially reduced window size. You should look at the trace file to prove to yourself that this is happening. Why is the window size substantially reduced? (Again, visual inspection works for strategy/mechanics).
B7. Produce a histogram of the client's advertised window size. Discuss what the distribution tells you about the client application behavior (the application, not the protocol).
B8. A packet train is a sequence of packets sent without waiting for an acknowledgement. Eg, if the packet sequence is p,p,p,p,p,a,p,p,a, where p is an arriving packet and a is a departing acknowledgement, then there are two packet trains, one of length 5 and one of length 2. Make a histogram of the packet train size. Discuss the meaning of the histogram in terms of the goals of sliding window.

B9. Consider this sequence of packets from the large trace:

000767 IP www.cs.washington.edu.http > 10.0.1.5.52593: . 4264521:4265969(1448) ack 198 win 1716 
142937 IP 10.0.1.5.52593 > www.cs.washington.edu.http: . ack 4265969 win 0 
184583 IP 10.0.1.5.52593 > www.cs.washington.edu.http: . ack 4265969 win 16384 
004061 IP 10.0.1.5.52593 > www.cs.washington.edu.http: . ack 4265969 win 32768 
000375 IP 10.0.1.5.52593 > www.cs.washington.edu.http: . ack 4265969 win 49152 
000582 IP 10.0.1.5.52593 > www.cs.washington.edu.http: . ack 4265969 win 65535

Here, 5 acks are sent with the same sequence number but with an increasing window size. Why is this happening? (again, go with "visual inspection").

B10. What was the actual delivered TCP bandwidth for this session?
B11. What would the actual TCP bandwidth have been without windowing?

What to turn in

You should turnin a directory called HW3 that contains an html file called "index.html." Turnin instructions will be posted before the due date. Please use this template. The name of the game for the html is SIMPLE SIMPLE SIMPLE. Look at the source for this page to get an idea of what I mean by simple. I use fewer than half a dozen html features, and while it doesn't look great, it does the job.

If you need to include any out of line figures (pdf or gif only), or shell scripts, or program source code do so by including them as links in your hw3.html file. If you want to include them in line in your web page, know how, and they don't distract too much from the flow, go ahead. But, don't worry if you don't know how.

Finally, make sure your web page works before you turn it in. We're not going to be able to debug your html

Last modified: Wed Jan 25 11:22:32 PST 2006