# 3rd Assignment

Group: Monday 2-4 - Group 1

Ana Tomi: 413117
Fabian Wagner: 349330
Lukas Hoffmann: 415442
Yasin Kilic: 371955

## Question 1

### (a) Describe briefly how TCP reacts to packet loss.
When a TCP receiver signals that a packet was not received (, or if an acknowledgment is not received at all, the TCP sender assumes the packet was lost, and resends the packet.
### (b) Assume a Voice over IP (VoIP) session was established over TCP and a packet gets lost.

### What will happen?
If no acknowledgement packet is received after a certain amount of time, the original packet is retransmitted. This guarantees that all data sent is without error and in the correct order. It can sometimes take a little bit more time for a packet to be fully successfully transmitted.

### How would the user experience be affected?
If TCP constantly retransmits lost packets, the actual conversation would overlap or arrive delayed, so the two parties would not understand each other or have to "wait" until the packet arrived.

### (c ) In your opinion, is TCP the best choice for VoIP?
No because if you have a conversation it is more important to hear what the person on the other side is saying in real time instead of having a delay or overlapping noices in your conversation.
Also TCP generates more traffic than UDP, because TCP constantly sends ACKs to notify that its availble.

## Question 2

### (a) What is the EstimatedRTTnew after the arrival of the third packet? Justify your answer with short calculations.

According to section 2 of the RFC on the TCP Retransmission Timer (https://tools.ietf.org/html/rfc6298) the formular provided on the task sheet is used from the second measuring onwards since it needs two consecutive values.

We have no idea what you wanted to tell us with the "Note" therefore we ignored it and sticked to the process described in the RFC.

For the first calculation EstimatedRTT_old is set to the first measured value (40ms) while SampleRTT_new is set to the second measurement (42).

EstimatedRTTnew = (1-0.125) * 40ms + 0.125 * 42ms 
EstimatedRTTnew = 40.25ms

For the second calculation EstimatedRTT_old is set to 40.25 and SampleRTT_new is set to 38 according to the third measurement

EstimatedRTTnew = (1-0.125) * 40.25ms + 0.125 * 38ms 
EstimatedRTTnew = 39.96875ms

The EstimatedRTTnew after the arrival of the third packet is 39.97ms

### (b) Why is this averaging procedure called an exponential weighted moving average?
The older a samples is the more the influence of that given sample is decreasing. This process happens exponentially fast.

### (c ) Why does TCP not use a simple arithmetic average?
Because of the acknowledge packets a simple arithmetic average is not possible.

Since the connection quality can degrade or improve during a long lasting connection the arithemtic average would be a bad estimate to predict the near future. The best informations that we have about the current quality of the connection is the quality of the connection in the immediate past. By using a moving average we take that into consideration. By using a exponential weighted moving average we devalue the information when its getting older.

### (d) Why does TCP avoid measuring the SampleRTT for retransmitted segments?
If the SampleRTT for retransmitted segments would be measured the source will mistakenly take the acknowledgement from the delayed segment as the acknowledgement from the retransmitted segment. This leads to an incorrect calculation of the SampleRTT.

## Question 3

### (a) What is the maximum value of *L* (the maximum file size) such that TCP sequence numbers do not need to wrap around? How many GB is this.

Assuming host A uses 0 as his starting sequence number.
The field for the TCP sequence number is a unsigned 32 bit integer field. Therefore after excactly 4294967295 bytes the ack response would be 0 again.
Locking form the sender perspective the rollover would happen at 4294967296 Bytes
4294967296/1024/1024/1024 would be exactly 4 GB.

### (b) For the *L* just obtained, indicate how long it takes to transmit the file.
60 Mbit/s = 7,5 Mbyt/s = 7864320 bytes/s
7864320/(1434+66) = 5242,88 Segments / s
4294967296 / 1434 = 2995095.74 Segments
2995095,74 / 5242,88 = 571,269 s

It would take at little more then 571 seconds.
## Question 4

### (a) How much data (in bytes) is in the first segment
The starting sequence number of A seems to be 3851. That is also the number of the first byte of the first segment. Since the second segment uses the byte number of the first byte of the second segment the sequence number of the last byte of the first segment would be 4316
Therefore the first segment contains the bytes with the number 3851..4316.
-> The first segment contains 466 Bytes

### (b) Suppose the first segment is lost but the second segment arrives at B. In the acknowledgment that B sends to A, what will be the acknowledgment number? Please briefly explain why.

Assumed that there was a sucessfull handshake right before A sends the first segment B knows that there is a segment missing.
Therefore B would resend the acknowledgment for the last in-order byte of data it has recieved. In that case that would be 3851 since the connection was just established and the previous recieved segment was the ACK message (Size 1).

## Question 5

### (a) Enter a successful connection setup into a diagram as presented above. Label the arrows with the relevant parts of the TCP header (flags, sequence number, acknowledgment number). The initial (randomly chosen) sequence numbers of client and server are 73541 (Client) and 28400 (Server).

### (b) Enter the successful connection teardown into another diagram as the one presented above. Assume that the client closes the connection first and that the server does not send any additional data after that.