# TCP Wireshark Lab
> [name=Aneesh Melkot (1001750503)] [color=#4D92B8]

<!--  -->

## 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.

The following image shows the UMASS website where we will upload the text file.

> Packet capture is started before uploading.[color=#4D92B8]


The following image shows the success message after the file was uploaded.

> 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

#### Provided Trace in Zip File

### 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


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.


### 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.


### Q6 POST Request

The POST request has a sequence number `164041`. This can be seen in the image below.


### 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.


Lets try the same thing using my own packet capture.



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**

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**

#### 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


### Q8 Length of TCP segments

Since we took an arbitrary Packet to find the trace, these packet's sizes are `1460` bytes each.


On the other hand, length of the first HTTP Post request's TCP segment is `50` bytes.


### 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/


Max window size highlighted

:::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

> 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.


#### Cumulative ACK

In the below image `43241` and `44701` have been ACK'd once by packet `69` which is ACKing only `44701`.


### 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.


> 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.


As can be seen below, the slow start ends much earlier in my trace at only **0.05** seconds.


> 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]