# TCP Wireshark Lab
> [name=Aneesh Melkot (1001750503)] [color=#4D92B8]
<!-- ![](https://i.imgur.com/R4XMaA3.png) -->
![](https://i.imgur.com/8Tx6jR0.png)
## Contents
[TOC]
## Packet Capture
In this exercise we are uploading a `TXT` file to the UMASS website and capturing and analyzing the TCP packets in this process.
### Setup
The following Image shows a text file that we will upload.
![](https://i.imgur.com/EG7LtrA.png)
The following image shows the UMASS website where we will upload the text file.
> Packet capture is started before uploading.[color=#4D92B8]
![](https://i.imgur.com/rtOpQsz.png)
The following image shows the success message after the file was uploaded.
![](https://i.imgur.com/2RZqj96.png)
> We will stop the packet capture now.[color=#4D92B8]
## Wireshark output capture
The Wireshark capture output shortly after capturing the file transfer. The output is filtered to show only TCP messages. I will analyze this and the trace in the zip file and answer the given questions.
#### My Trace
![](https://i.imgur.com/jbsRvcj.png)
#### Provided Trace in Zip File
![](https://i.imgur.com/U7hGZhE.png)
### Q1 Client Info
The client IP is `192.168.1.102` and the source port is `1161`.
### Q2 Destination Info
The destination info can be seen in the image above as well.
The destination `gaia.cs.umass.edu` has an IP address `128.119.245.12` and is transmitting and receiving data on port `80`.
### Q3 Client Info in my own trace
![](https://i.imgur.com/lQEYf6x.png)
In my own trace, the client IP is `128.119.245.12` and the source port is `80`.
### Q4 TCP SYN
The sequence number is `0`. The `Syn` flag is set to `1`. This identifies it as a SYN Segment. Can be seen in below image.
![](https://i.imgur.com/fwF0gWW.png)
### Q5 SYNACK
The ACK number in the response is `1`. The server, in this case `gaia.cs.umass.edu` just adds `1` to the requestor's SYN. We know this is a SYNACK segement as bit the SYN & ACK flags are set to `1`. Can be seen in below image.
![](https://i.imgur.com/bMn0Ukz.png)
### Q6 POST Request
The POST request has a sequence number `164041`. This can be seen in the image below.
![](https://i.imgur.com/c1MpAas.png)
### Q7 HTTP POST RTT
Segment # | Packet # | Sequence #
:---:|:---:|:---:|
1 | 199 | 164041
2 | 206 | 164091
From the given trace file I am able to find only 2 consecutive segments keeping the HTTP post segment as the first.
![](https://i.imgur.com/0r3VmXy.png)
Lets try the same thing using my own packet capture.
![](https://i.imgur.com/9dytaam.png)
![](https://i.imgur.com/KfaTCPb.png)
Segment # | Packet # | Sequence #
:---:|:---:|:---:|
1 | 216 | 152517
2 | 248 | 153000
This sequence terminates here as well as its next SEQ number is same as its own SEQ number.
Will try to find some arbitrary TCP packet which has 6 segments.
<!-- Consider the below image starting from **#200**
![](https://i.imgur.com/2JJ5HHD.png)
Segment # | Packet # | Sequence # | Next SEQ #
:---:|:---:|:---:|:---:|
1 | 200 | 131429 | 131753
2 | 201 | 131753 | 133213
3 | 202 | 133213 | 134673
4 | 203 | 134673 | 136133
5 | 204 | 136133 | 137592
6 | 205 | 137593 | 139053 (Don't care)
Segment # | ACK Sent | ACK Rcvd | RTT
:---:|:---:|:---:|:---:|
-->
Consider the below image starting from packet **#5**
![](https://i.imgur.com/jCPyNOm.png)
#### Segments with Sequence numbers
Segment # | Packet # | Sequence # | Next SEQ #
:---:|:---:|:---:|:---:|
1 | 5 | 566 | 2026
2 | 7 | 2026 | 3486
3 | 8 | 3486 | 4946
4 | 10 | 4946 | 6406
5 | 11 | 6406 | 7866
6 | 13 | 7866 | Don't care
#### Segments with ACK RTT
Segment # | ACK Sent Time | ACK Rcvd Time | RTT
:---:|:---:|:---:|:---:|
1| 0.015260 | 0.012200 | 0.00306
2| 0.000089 | 0.022604 | 0.022515
3| 0.000664 | 0.045928 | 0.045264
4| 0.000111 | 0.044933 | 0.044822
5| 0.000752 | 0.048181 | 0.047429
6| 0.000100 | 0.050503 | 0.050403
#### Estimated RTT
`EstimatedRTT` = 0.875 * `EstimatedRTT` + 0.125 * `SampleRTT`
> Estimated RTT for `Sequence 1` is the Observed RTT. [color=#4D92B8]
Segment # | Estimated RTT
:---:|:---:|
1| 0.00306
2| 0.00549
3| 0.01046
4| 0.01475
5| 0.01883
6| 0.02233
#### RTT Graph
Here is the RTT Graph between Client and umass server
![](https://i.imgur.com/8LO6Rt7.png)
### Q8 Length of TCP segments
Since we took an arbitrary Packet to find the trace, these packet's sizes are `1460` bytes each.
![](https://i.imgur.com/MoRroKu.png)
On the other hand, length of the first HTTP Post request's TCP segment is `50` bytes.
![](https://i.imgur.com/YlKutNj.png)
### Q9 Minimum buffer space
The minimum buffer space at the server for the trace is `5840` bytes which can be seen below.
This window grows to a max of about `62780` over the lifetime of this connection/
![](https://i.imgur.com/w5uJaY7.png)
Max window size highlighted
![](https://i.imgur.com/WDATTEk.png)
:::info
:warning: **The sender is never throttled due to lack of receiver buffer.**
:::
### Q10 Retransmitted Segments
There seems to be no retransmitted segments in the Trace file as all sequence numbers are in ascending order and increasing consequtively. If there is a retransmission then the consequtive Sequence number would be lesser than the previous sequence number.
#### Time/Sequence graph of the trace
![](https://i.imgur.com/Z6fo6B4.png)
> Notice that sequence numbers are continually increasing from `0` to `16XXXX`.[color=#4D92B8]
### Q11 ACK Data
The receiver is typically ACKing `1460` bytes of data.
![](https://i.imgur.com/GrranYt.png)
#### Cumulative ACK
In the below image `43241` and `44701` have been ACK'd once by packet `69` which is ACKing only `44701`.
![](https://i.imgur.com/f41ghM4.png)
### Q12 Throughput
This can be calculated as the ratio of Total data transmitted over total time of transmission.
`Total Data Transmitted` = `Seq # of last segment` - `Seq # of 1st segment`
`Total Data Transmitted` = `164091` - `1` = **`164090 bytes`**
<br>
`Total Time` = `Time of last segment` - `Time of 1st segment`
`Total Time` = `5.65114` - `0.23172` = **`5.41942 seconds`**
<br>
`Throughput` = `Total Data Transmitted` / `Total Time`
`Throughput` = `164090` / `5.41942` = **`30278.14785 bytes/sec`**
<br>
> **Throughput = 30.2781 KBytes/sec**[color=#4D92B8]
### Q13 Slowstart
The slowstart phase begins at `0` seconds and ends at around `0.125` seconds according to the stevens graph. After this the congestion avoidance takes over and gradually increases TX rate till network limit is reached.
![](https://i.imgur.com/TSUZChn.png)
> The measured data uses only a small fraction of the window size as opposed to using `1/3` to half.[color=#4D92B8]
### Q14 Slowstart in own trace
This is the Stevens graph of my trace file.
![](https://i.imgur.com/VVJXrEX.png)
As can be seen below, the slow start ends much earlier in my trace at only **0.05** seconds.
![](https://i.imgur.com/4P8s8At.png)
> Same as before, the measured data uses only a small fraction of the window size as opposed to using `1/3` to half. [color=#4D92B8]