HW3 Solutions
Part A: Short Trace File
A1. What is the IP address of my computer?
Strategy:
Visual inspection
Mechanics:
Look at the packet flow, there are two hosts 128.208.3.88 and 10.0.1.4.
10.0.1.4 connects to 128.208.3.88.
Answer:
10.0.1.4
A2. What is the ethernet address of my computer?
Strategy:
Visual inspection
Mechanics:
According to the man page, tcpdump will print out link level headers if supplied with the –e flag. Look after the address of 10.0.1.4
Answer:
00:0a:95:c9:34:0a
A3. What is the destination ethernet address used to send a packet to the cs web site
Strategy: Visual inspection
Mechanics:
Look at the destination Ethernet address of the first packet.
Answer:
00:03:93:e7:3f:30
A4. What is the largest packet size that is reported?
Strategy:
Look at the ip length field in all packets, sort the in packet size order, verify result with visual inspection
Mechanics:
tcpdump flags:
-n: numeric, donÕt resolve hostnames or port numbers to names
-v: verbose output, print more information
awk:
filter out the ip length column
{print $16}
sort flags:
-n: use numeric sort, so 10 is more than 2
/usr/sbin/tcpdump -n -v -r smalltrace.raw | awk '{print $16}' | sort –n
Answer
935 bytes
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.
Strategy:
Visual inspection, look at the timestamp for the arrival time of each packet
Mechanics:
/usr/sbin/tcpdump -n -r smalltrace.raw
Answer
A6. What is the round trip time in microseconds between my home machine and www.cs.washington.edu.
Strategy:
Visual inspection, the round trip time is at most the time from the first SYN to the SYN-ACK response.
Mechanics:
look at the time between the first syn packet and the synack responce.
1138240576.010007 s - 1138240576.020659 s = 0.010652 s = 10.652 ms
Answer:
11 ms
A7. What web page was I fetching?
Strategy:
the packet should have something with GET in the data field
Mechanics:
look in the packet data field, try to find GET
use tcpdump –x to show the packet contents as ASCII
packet 4 contains
GET /homes/bershad/Web461/index.html HTTP/1.1
Answer:
/homes/bershad/Web461/index.html
A8. In total, how much data did the server send me?
Strategy:
Look at the relative sequence number, the last packet in the stream will show the total.
Mechanics:
Visual inspection, the last packet has relative sequence number 884, which means that the server sent 883 bytes of data. (the relative sequence number goes from 1 to one more than the last byte received). This can also be found by summing up all of the byte count fields for the packets sent by the server.
Answer:
883 bytes
Part B:
B1. How many pure ack packets are sent to www.cs.washington.edu?
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 to www.cs.washington.edu
Mechanics:
Filter the trace file for packets to www.cs.washington.edu, print the seventh field one per line, filter for "ack," and count the number of lines printed.
tcpdump -r bigtrace.raw dst host www.cs.washington.edu | awk '{print $7}' | grep 'ack' | wc -l
Answer:
3365
B2. How much data is transferred in each direction?
Strategy:
Look at the relative sequence number, the last packets in the stream will show the total.
Mechanics:
Visual inspection, the last packet to 128.208.3.88 has sequence number 198, which means that 197 bytes were sent to 128.208.3.88
Visual inspection, the last packet to 10.0.1.5 has sequence number 10982551, which means that 10982550 bytes were sent to 10.0.1.5.
Answer
From 128.208.3.88: 10982550 Bytes (10.5 MBytes)
From 10.0.1.5: 197 Bytes
B3. On average, how many bytes of data does my home computer receive for each ack it generates?"
Strategy: Simple cartons of egg math, divide total data transferred by the total number of acks.
Mechanics:
10982550 Bytes / 3365 acks = 3263 Bytes / ack
Answer
3263 Bytes / ack
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?
Strategy:
look at the incoming sequence numbers, they should increase. If not the packet has been delayed or retransmitted
Mechanics:
Loop through all lines, remember the biggest sequence number seen so far. If a packet has lower sequence number than the biggest seen so far, the packet has been delayed or retransmitted.
tcpdump:
-S: Use real sequence numbers, relative will give strange results
filter: ip src 128.208.3.88 – only show packets from www.cs.washington.edu
awk:
BEGIN { seq = 0; previous_line = ""; count = 0; }
{
if($7 != "ack"){
split($7,new_seq,":");
if(seq > new_seq[1]){
printf("delayed packet\n");
printf("prev pkt: %s\n",previous_line);
printf("curr pkt: %s\n",$0);
count++;
} else {
seq = new_seq[1];
}
previous_line = $0;
}
}
END { printf("number of late packets=%d\n",count); }
/usr/sbin/tcpdump -nS -r bigtrace.raw ip src 128.208.3.88 | awk -f find_out_of_order_packets.awk
Answer:
11 packets
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).
Answer: When the client sees that a packet has been lost, it will send back acks with the sequence number of the lost packet every time it receives a packet until it receives the retransmission of the lost packet. It will then send an ack for all the packets received
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).
Answer: The advertised window size is based off of the buffer size and the last byte acked. In the case of delayed packets, the receiver stores the out-of-order bytes that it receives (as long as they are within the window), but it doesn't change the advertised window size. But when the delayed packet arrives, it will ack up through the the highest sequence number of the bytes it has received which results in the window size being (temporarily) drastically reduced because it now includes all the bytes that it has already stored.
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).
Strategy:
Count the number of times each window size is advertised by the client.
Mechanics:
tcpdump:
filter: ip src 10.0.1.5 –-only packets from the client
awk:
{
win_size = -1;
for(i = 1; i <= NF;i++){
if($i == "win"){
win_size = $(i+1)
}
}
if(win_size == -1) {
print "\nUNRECOGNISED LINE!";
printf("%s\n",$0);
}
size_count[win_size]++;
}
END {
printf("Window size,Count\n");
for(size in size_count){
printf("%d,%d\n",size,size_count[size]);
}
}
/usr/sbin/tcpdump -r bigtrace.raw ip src 10.0.1.5 | awk -f count_advertised_window_sizes.awk | sort -n > B7_histogram.csv
Answer:
This shows that the majority of the time, the window size
maintains the largest value possible.
ItÕs hard to see the values to the left of the 64kÉ here
they are in raw form:
Window size,Count
0,1
1448,3
8688,1
16384,1
17832,3
18824,1
25072,1
26064,1
32768,1
34216,3
35208,1
37648,2
38104,1
39096,1
41456,1
42448,2
43896,1
45344,1
46336,2
47784,1
48240,1
49152,1
49232,1
49688,1
50144,1
50600,3
51592,1
52128,1
52584,2
53450,1
53576,1
54032,2
55480,1
56472,2
56928,2
57384,1
57840,1
57920,2
58376,1
58832,1
59824,3
60280,1
60816,2
61272,2
61728,2
62264,3
62720,3
63392,1
63712,4
64168,4
64624,1
65160,8
65535,327
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.
Strategy
Count the number of packets appear before an ack is sent by the client.
Mechanics
tcpdump:
awk:
BEGIN { ind = 1; num_lines = 0; t_size[ind] =
0;}
{
while(NR > num_lines){
if($3 == "128.208.3.88.http"){
t_size[ind]++;
}
if($3 == "10.0.1.5.52593" &&
$7 == "ack"){
if(0 != t_size[ind]){
size_count[t_size[ind]]++;
}
ind++;
t_size[ind] = 0;
}
num_lines = NR;
}
}
END {
for(size in size_count){
if(size_count[size] > 0){
printf("%d\t%d\n",size,size_count[size]);
}
}
}
/usr/sbin/tcpdump -r bigtrace.raw ip src 10.0.1.5 | awk -f count_packet_train_sizes.awk | sort -n > B8_histogram.csv
Answer:
That many trains are short, yet some are large, indicates that TCPÕs sliding window is able to keep the network busy whether or not the receiver acknowledges right away.
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").
Answer: In this
example, the server sends a large packet of data which fills up the buffer
(there is likely already data in the buffer). The Receiver sends back an ack
saying that it can no longer accept any more data. Then it sequentially reads
data off of its buffer and advertises its increasing window size. The server is
waiting until the window size is at its maximum so that it can send a packet
train.
B10. What was the actual
delivered TCP bandwidth for this session?
Strategy:
This is simply the amount of
data sent divided by the time.
Mechanics:
Visual inspection of the last
packet for the sequence number and timestamp reveals that 10982551 bytes of
data were received by 21:15:26.026008. and by looking at the first packet we
see that the first packet was sent at 21:15:05.535914 for a total time
difference of 20.490094 s
(10982551 bytes / 1024 bytes)
/ 1024 kilobytes = 10.473777 Mbytes
Answer
10.473777 Mbytes /
20.490094 s = 0.51116296 Mbytes/s
0.51116296 Mbytes/s * (8
bits/byte) = 4.1 Mbits/s
B11. What would the actual
TCP bandwidth have been without windowing?
Strategy
Without windowing, every
packet sent must be acked, this doesnÕt change the number of bytes sent, but we
must add in the time it takes for the all of the acks to be received.
Mechanics
Calculate the number of acks
that would be sent from the answer for the packet train question:
3293 acks to be added
Use visual inspection to
determine the RTT:
.013s
add this time into the total
time and simply recalculate the solution to the previous problem.
3293 * .013 = 42.809s
Total time = 20.490094 +
42.809 = 63.299094s
Answer
10.473777 Mbytes /
63.299094 s = 0.16546488 Mbytes/s
0.16546488 Mbytes/s *
(8bits/byte) = 1.3 Mbits/s
Size Count
1 347
2 2636
3 122
4 62
5 30
6 29
7 26
8 18
9 5
10 12
11 3
12 2
13 3
14 6
15 3
16 1
17 3
18 2
19 1
20 1
21 2
22 1
24 1
29 1
31 1
33 1