WIRESHARK LAB: TCP

se22ucse100-GAYATRI K NAYAK

1. What is the IP address and TCP port number used by the client
computer (source) that is transferring the file to gaia.cs.umass.edu? To
answer this question, it’s probably easiest to select an HTTP message and
explore the details of the TCP packet used to carry this HTTP message,
using the “details of the selected packet header window” (refer to Figure 2
in the “Getting Started with Wireshark” Lab if you’re uncertain about the
Wireshark windows).
A1. Solution: Client computer (source)
IP address: 10.70.12.213
TCP port number: 42878

2. What is the IP address of gaia.cs.umass.edu? On what port number is it

sending
and receiving TCP segments for this connection?

A2. Destination computer: gaia.cs.umass.edu

IP address: 128.119.245.12
TCP port number: 80
4. What is the sequence number of the TCP SYN segment that is used to
initiate the TCP connection between the client computer and
gaia.cs.umass.edu? What is it in the segment that identifies the segment
as a SYN segment?
A4.
Sequence Number (raw): 4056113273
The SYN flag is set to 1 and it indicates that this segment is a SYN
segment.
5. What is the sequence number of the SYNACK segment sent by
gaia.cs.umass.edu to the client computer in reply to the SYN? What is the
value of the ACKnowledgement field in the SYNACK segment? How did
gaia.cs.umass.edu determine that value? What is it in the segment that
identifies the segment as a SYNACK segment?
A5.
Sequence Number (raw): 1442409379
Acknowledgment number (raw): 1375675295
The value of the ACKnowledgement field in the SYNACK segment is 1.
The value of the ACKnowledgement field in the SYNACK segment is
determined by gaia.cs.umass.edu by adding 1 to the initial sequence
number of SYN segment from the client computer (i.e.the sequence
number of the SYN segment initiated by the client computer is 0.).
The SYN flag and Acknowledgement flag in the segment are set to 1 and
they indicate that this segment is a SYNACK segment.
6. What is the sequence number of the TCP segment containing the HTTP
POST command? Note that in order to find the POST command, you’ll
need to dig into the packet content field at the bottom of the Wireshark
window, looking for a segment with a “POST” within its DATA field.
A6.
Sequence Number (raw): 4056113274
7. Consider the TCP segment containing the HTTP POST as the first
segment in the TCP connection. What are the sequence numbers of the
first six segments in the TCP connection (including the segment containing
the HTTP POST)? At what time was each segment sent? When was the
ACK for each segment received? Given the difference between when each
TCP segment was sent, and when its acknowledgement was received,
what is the RTT value for each of the six segments? What is the
EstimatedRTT value (see page 249 in text) after the receipt of each ACK?
Assume that the value of the EstimatedRTT is equal to the measured RTT
for the first segment, and then is computed using the EstimatedRTT
equation on page 249 for all subsequent segments.
Note: Wireshark has a nice feature that allows you to plot the RTT for
each of the TCP segments sent. Select a TCP segment in the “listing of
captured packets” window that is being sent from the client to the
gaia.cs.umass.edu server. Then select: Statistics->TCP Stream Graph-
>Round Trip Time Graph.
A7.
Segment 1 sequence number: 4056113274
Time:10.429340481
Segment 2 sequence number: 4056116038
Time:10.429401283
Segment 3 sequence number: 4056118802
Time:10.433978020
Segment 4 sequence number: 4056121566
Time:10.434017678
Segment 5 sequence number: 4056124330
Time:10.435644316
Segment 6 sequence number: 4056127094
Time:10.696507401

ACK for Segment 1: Ack=16585 at time 11.003306171

ACK for Segment 2: Ack=17967 at time 11.003306462
ACK for Segment 3: Ack=19349 at time 11.003306517
ACK for Segment 4: Ack=22113 at time 11.003306569
ACK for Segment 5: Ack=23495 at time 11.003306618
ACK for Segment 6: Ack=24877 at time 11.003306670

RTT = Time ACK received - Time segment sent

● RTT for Segment 1: 11.003306171 - 10.429340481 = 0.57396569 s

● RTT for Segment 2: 11.003306462 - 10.429401283 = 0.573905179s
● RTT for Segment 3: 11.003306517 - 10.433978020 = 0.569328497s
● RTT for Segment 4: 11.003306569 - 10.434017678 = 0.569288891s
● RTT for Segment 5: 11.003306618 - 10.435644316 = 0.567662302s
● RTT for Segment 6: 11.003306670 - 10.696507401 = 0.306799269s

Using the formula from the textbook:

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT

● EstimatedRTT after Segment 1: Just the RTT of the first segment =

0.57396569 s
● EstimatedRTT after Segment 2:
0.875×0.57396569+0.125×0.573905179=0.57395848
 ● EstimatedRTT after Segment 3:
0.875×0.57395848+0.125×0.569328497=0.57338542
● EstimatedRTT after Segment 4:
0.875×0.57338542+0.125×0.569288891=0.57288863
● EstimatedRTT after Segment 5:
0.875×0.57288863+0.125×0.567662302=0.57224871
● EstimatedRTT after Segment 6:
0.875×0.57224871+0.125×0.306799269=0.53959913

8. What is the length of each of the first six TCP segments?

A8.
Length of all the TCP segments:2764
9. What is the minimum amount of available buffer space advertised at the
received for the entire trace? Does the lack of receiver buffer space ever
throttle the sender?
A9.
The minimum amount of buffer space (receiver window) advertised at
gaia.cs.umass.edu for the entire trace is 29200 bytes, which shows in the
first acknowledgement from the server. This receiver window grows
steadily until a maximum receiver buffer size of 183296 bytes. The sender
is never throttled due to lacking of receiver buffer space by inspecting this
trace.

10. Are there any retransmitted segments in the trace file? What did you
check for (in the trace) in order to answer this question?
A10.
There are no retransmitted segments in the trace file. We can verify this
by checking the sequence numbers of the TCP segments in the trace file.
In the Time-Sequence-Graph (Stevens) of this trace, all sequence numbers
from the source to the destination (128.119.245.12) are increasing
monotonically with respect to time. If there is a retransmitted segment, the
sequence number of this retransmitted segment should be smaller than
those of its neighboring segments.
11. How much data does the receiver typically acknowledge in an ACK?
Can you identify cases where the receiver is ACKing every other received
segment (see Table 3.2 on page 257 in the text).
A11.
● Packet 73: Ack=16585
● Packet 74: Ack=17967 (Difference: 1382 bytes)
● Packet 75: Ack=19349 (Difference: 1382 bytes)
● Packet 76: Ack=22113 (Difference: 2764 bytes)
● Packet 77: Ack=23495 (Difference: 1382 bytes)
● Packet 78: Ack=24877 (Difference: 1382 bytes)
● Packet 79: Ack=26259 (Difference: 1382 bytes)

the receiver is typically acknowledging 1382 bytes of data in most ACKs,

except for Packet 76, where it acknowledges 2764 bytes at once.

This is a clear case of the receiver ACKing every other segment instead
of each one individually.
12. What is the throughput (bytes transferred per unit time) for the TCP
connection?
Explain how you calculated this value.
A12
The first data segment is sent at 10.429340481 seconds.The last
acknowledgement is received at 11.003306719 seconds.

So, the total time for the data transfer is:

Time=11.003306719−10.429340481=0.573966238
From the sequence numbers in the provided segments:

Initial sequence number: 1

Final acknowledgment number: 26259

The total data transferred is:26259−1=26258 bytes

Throughput=Total Data Transferred/Total Time Taken

So after doing the calculations we get 45726.3 bytes/second

13. Use the Time-Sequence-Graph(Stevens) plotting tool to view the

sequence number versus time plot of segments being sent from the client
to the gaia.cs.umass.edu server. Can you identify where TCP’s slowstart
phase begins and ends, and where congestion avoidance takes over?
Comment on ways in which the measured data differs from the idealized
behavior of TCP that we’ve studied in the text.
A13.
The slow start phase begins at the very start (0s) with the sequence
number rising exponentially in the first 0.25 seconds.
Notice how the graph shows steep upward slopes with small flat sections,
indicating multiple segments being sent rapidly as TCP increases its
congestion window exponentially.
Around 0.5s, the exponential growth stops, and the sequence numbers
start to increase more linearly, which is where congestion avoidance kicks
in.
This transition is typically triggered by either reaching the slow start
threshold (ssthresh) or a packet loss event, though here it seems like it hit
the threshold.

Differences from Ideal TCP Behavior:

In an ideal TCP scenario, you'd expect perfectly smooth exponential

growth during slow start and linear growth during congestion
avoidance.
Here, we see short flat segments indicating that some data was held
back, possibly due to:

Delayed ACKs from the receiver.

Network latency causing some segments to arrive slightly late.

Congestion window adjustments based on actual network

feedback.

Around 0.75s to 1s, you see a rapid jump, possibly indicating a fast
retransmit or a temporary window size increase before stabilizing
again.

Post 1s, the graph flattens, showing that the connection likely
reached a steady state or the maximum congestion window allowed
by the network conditions.