Lab 2: Wireshark (TCP)

Emil Burman, Mona Chabokdavan, Chloe Dusén

Task 1
Insert a screenshot of your packet capture and answer the following questions:

(a) How many HTTP GET request messages has your browser sent?
2, one for the favicon and one for the actual website.

(b) Which packet in the trace contains the status code and phrase associated with the response
to the HTTP GET request? Where can you find those information in the HTTP response?

The first of the 2 TCP segments contains the HTTP response, you can see in the screenshot
that the HTTP response is in the first 3750 bytes of the total package and therefore transmitted
in segment 1.

(c) What is the length of the web page in bytes (i.e. length of the HTTP DATA or “Content
Length”)?
In the above mentioned screenshot, you can also see that the content length is 4500 bytes.

(d) How many TCP segments are needed to carry the single HTTP response and the text of the
Bill of Rights? How large is the payload in each of the TCP segments? (Hint: look into the “X
Reassembled TCP Segments” part). Subtract your previous answer from the total TCP payload
to find the length of the HTTP headers.

2 TCP segments are required. The total TCP payload with data is 4861, since the data is 4500
bytes that means that the HTTP headers are 361 bytes.
Task 2
Insert a screenshot of your packet capture and answer the following questions:

(a) Your browser has likely sent a GET request for the favicon.ico. Explore the timeline and
identify if the same TCP connection was re-used for that purpose (persistent HTTP) or a parallel
TCP connection was used (non-persistent HTTP). How can you tell?
The GET request for the favicon.ico and the GET request for the main page have the same
stream index, as well as the same source and destination port, indicating that the connection is
persistent. We can also tell by looking at the initial GET, which shows us that the connection is
set to keep-alive, which also indicates a persistent connection.

(b) What is the source IP address and source port number abcde used by your computer for the
TCP connection with the chalmers gaia web server (for the webpage’s request)?
The source IP address and source port number used by one of our computers are:
192.168.50.7:50725

(c) What is the port number used by the server for the connection?
80

(d) Identify the TCP segments that are used to initiate the TCP connection between the client
computer and the web server. How many segments are used? What is in the TCP header that
identifies each segment as a handshaking segment?
There are three segments, with the following flags in the TCP header:​
SYN-Packet from client -> server, ​ ​ flags SYN = 1, ACK = 0.​
SYN-ACK packet from server -> client,​ flags SYN = 1, ACK = 1​
ACK-packet from client -> server,​ ​ flags SYN = 0, ACK = 1 ​

(e) Identify two different ACK messages.

1.​ The ACK message mentioned above from client -> server at the end of the handshake
segment.
2.​ The final packet in the screenshot above, the ACK message with the ACK number 5346
Task 3
Insert a screenshot of the trace (once filtered with the above tips if needed) and answer the
following questions:

(a) What is usually the packet length of the captured packets transmitted to the server? How
large is usually the TCP payload within these packets?
Since my Operating system morphs packets together the TCP payload that is displayed in
wireshark is between 10000 and 50000 bytes.

(b) What is specified by the value of the Acknowledgement field in any received ACKsegment?
How does cse.chalmers.se GAIA determine this value? (use your own knowledge for this
question!)
It adds the last correctly received packet length to the last correctly received packet number and
therefore also specifies the next expected packet number.

(c) How much data (number of bytes) does the receiver typically acknowledge in one ACK?
(check with what you answered previously!)

Between 10000 and roughly 1300 bytes.

(d) Identify the 4 packets closing the connection. How much time after the last HTTP DATA
segment have they been sent?

It is 5 seconds between the last acknowledgement and the servers FIN ACK which my host
acknowledges pretty quickly, although my host then takes 55 seconds to continue the FIN ACK
handshake.
 Task 4
(a) Reproduce and fill up Table 1. The packets considered are the first six data-carrying
segments in the TCP connection, that are exactly those following right after the handshake took
place (with the first of them containing the HTTP POST and the rest containing HTTP Data).
The different columns correspond to:

1) Sequence Numbers of the TCP segments (only relative numbers here).

2) TCP Payload Length (this is different from the packet length from the Length column!).
3) Time sent: the time that each of the six segments has been sent.
4) Time ACKed: the time when an acknowledgement (for each data-carrying segment) has been
received.
5) RTT: Knowing the time when each TCP segment was sent, and the time when its
acknowledgement was received, we can calculate the sample RTT value.
6) EstimatedRTT: Calculate the EstimatedRTT value using the measured RTT values in the
answer of the previous question. Assume that the initial value of the EstimatedRTT is equal to
the measured RTT for the first (POST) segment, and then as described in Section 3.5.3 in the
course book (using the EstimatedRTT equation on page 270) calculate the EstimatedRTT for
the subsequent segments.

No. Seq. Payload Time sent Time RTT Estimated

Number Length ACKed RTT

4 1 565 0.026477 0.053937 0.02746 0.02746

5 566 1460 0.041737 0.077294 0.035557 0.028472125

7 2026 1460 0.054026 0.120854 0.066828 0.03326660937

8 3486 1460 0.054690 0.169118 0.114428 0.0434117832

10 4946 1460 0.077405 0.217299 0.139894 0.0554720603

11 6406 1460 0.0781570 0.267802 0.189645 0.07224367776

 Table 1

Sample RTT and estimated RTT are calculated based on the formulas below. The
recommended value for α is 0.125 => 1 - α = 0.875, we can also make sure that α = 0.125 by
redoing the calculations for the estimated RTT column after packet nr 5 and making sure we get
the same number.
Sample RTT = Time ACKed - Time Sent
Estimated RTT = (1 - α) * Estimated RTT + α * Sample RTT.

(b) Open the packet trace you saved before Task 3 and calculate the average RTT over the first
3 segments sent to the server with data. Those packets correspond to the HTTP POST and the
beginning of the file upload similarly to the previous question

Using α = 0.125.

No. Seq. Payload Time sent Time RTT Estimated

Number Length ACKed RTT

4 1 721 0.111046 0.228338 0.117292 0.117292

5 722 11250 0.111480 0.228338 0.116858 0.11723775

10 11972 23750 0.228415 0.345741 0.117326 0.11724878125

Task 5
(a) By observing the time/sequence graph, can you see if any re-transmission (due to a packet
loss or timeout) took place during the time covered by the trace? Explain briefly how (think how
a re-transmission will appear in the graph).

The graph indicates an increase in sequence numbers sent by TCP over time. At the beginning
of the process, we can see 2 dots in the same horizontal line that shows a constant sequence
number. This is due to the SYN ACK handshake and the first datafilled packet both having
sequence number 1. There are no retransmissions, a retransmission would be shown as either
a repeating sequence number (if no other packets have been transmitted after the lost one) or a
dip in sequence number (if packets with a larger sequence number have been transmitted
before the loss is detected).

(b) Where is the amount of available buffer space at the receiver (the server) advertised? Does
the lack of receiver buffer space ever throttle the sender? Explain briefly.

The sender initiates the connection with a Window Size of 16384 bytes. If the Window Size
becomes zero, the receiver's buffer is full, and the sender will stop the transmission. Otherwise,
the receiver has sufficient buffer space for the transmission. From the graph, we can also see a
smooth increase after the initial SYN ACK handshake, which means the data was sent without
any delays, and the receiver’s buffer space did not limit the sender.
We can see the TCP slow start, first the server transmits 1 packet at a time then 2 then 3, it then
jumps to 6 and stays there which is peculiar. We can only find 2 reasons why TCP would stop
increasing the transmission rate at 6 packets. Either flow control or congestion control, it is not
congestion control since that only kicks in when there is packet loss we have concluded has not
occurred and flow control seems unlikely since the server consistently has a window size of over
10000 bits and therefore doesn't seem to be overloaded.
Task 6
(a) Can you identify a packet loss in the trace and how? Which sequence number was lost and
at which timestamp does the sender notice the loss? (make use of the below hint!)

The TCP shows duplicate ACKs confirming a packet loss has happened near 0.099 s and the
sequence number 72401 was lost because a fast retransmission is visible. That means that the
lost packet is one of the ones the OS “hides” but the lost transmission happened around 0.082.

(b) Are there cases where the receiver (the web server) is ACKing cumulatively? At which
timestamp does that happen and how many packets are acked at once? (Hint: go quickly
through the acks and check if there are any suspiciously high jump in the amount of data
ACKed, then use the timeline to navigate to the corresponding packet and get the confirmation
that one or more acks were either skipped or lost.)

There seems to be acknowledgments lost between packet no (according to wireshark) 42 and

43 since the acknowledgment number jumps from 23169 to 57921 which is abnormal. The last
normally acked packet is 17, after that 13 packets are acked cumulatively with packet 43.
Task 7
Insert your Stevens graph and of your throughput graph in your report, and answer the following
questions:
We used the provided packet capture in canvas for this task.

(a) What was the overall throughput in bit/s (the average number of bits transferred per time
unit) for the whole session of transferring the file? Explain how you calculate these values.

The first packet after the TCP connection is established in packet 4, it is sent 0.003742688. The
last data packet before the requests to close the TCP connection is packet 1248, it is sent at
7.106908688. The total transmission time is therefore 7.106908688 - 0.003742688 = 7.103166.
The file is 14.5 MiB which is 15.204352 MB which is 121634816 bits. 121634816 bits / 7.103166
seconds = 17124028.3558 bits/s.

(b) How did the throughput evolve through the transfer?

The throughput increases rapidly in the beginning of the transfer in the first 1.2 seconds. After
that follows by a drop in segment lengths between 1.9 - 4 seconds. One can see TCP flow
control in action, the server stops sending packets when it receives an alert that the client's
window is full. At the end it will reach zero which indicates the end of the transfer.

(c) Describe your Stevens graph, eg can you easily identify approximately the main TCP
phases, “slow start” and “congestion avoidance” phases, on your graph?
From 0s to around 1.6s, we can see a faster growth of the graph, but even if we zoom in we
can't find the exponential growth typical of TCP slow start, but since the growth slows down after
this phase we are classifying it as slow start. From here on, we see the congestion avoidance
phase (slightly slower linear growth).
(d) Comment on ways in which the measured data differs from the idealized behavior of TCP
that we’ve studied in the text. Consider for instance in your answer the main TCP phases and
TCP events triple duplicate ACK and timeout.
The measured data differs a bit from idealized TCP behavior since the slow start phase isn’t
exponential as expected. The congestion avoidance at around 1.6s looks normal however.
There is no triple duplicate ACK or timeout since there is no packet loss.