Problem Solved by SACK

When the SACK is not supported by either the Client or Server the SACK feature is not used throughout the Connection.

The Problem that the SACK resolves is that when the Client sends as stream of data (Transport layer is responsible for splitting up the larger chunk of data to MSS value) and if any of the intermediate bytes lost then the Server will send the ACK a byte before the lost bytes.. even though it receives the next set of bytes it is not able to ACK them since SACK is not suppported.

Since the Server doesn't sent the ACK for 3 set of bytes even though it received the last 2 set of bytes. The client will wait for the retransmission to be triggered.

if SACK is supported

SACK acknowledges the all the data before the point of loss and all the data after the point of loss.

SACK is done by the duplicate ACKs. Because the ACK number will be the Seq number that is before any point of loss. And the last two set of bytes (after the point of loss) is ACK by SACK meaning the ACK number will be the same Seq number of data before the point of loss but in the TCP options we could see the SACK ranges for the Seq number the Server received.

DSACK

This SACK makes that data to be fast retransmitted... Since the packet is delaying but not lost

Congestion Control

Reference

The Endpoints that uses TCP were smart but not the Network

Core Components

There are lots of Congestion control algorithms out there.

Initial window

At first the sender will send the 2 full size MSS packet and waits for the receiver to ACK that. Once the reciever ACks then it starts sending the data

The Number of packets that put into the wire initially that depends on the Congestion control algorithm

Slow Start

After the intial data transfer, the sender then doubles the packet count that have sent in the initial window and waits for the acks and then doubles the packets and so on...

*cwnd - Congestion Window

Note: The Congestion Window size is never put into the wire. We can't find whats the value of the Congestion window.

*ssthresh - Slow Start Threshold.

Once the Slow Start threshold is met the Congestion window mechanism is changed from Slow Start to the Congestion Avoidance.

Congestion Avoidance

In the Congestion Avoidance state the packects stops doubling (seen in slow start) and increments one packet each time it got success ACKs

Timeout (Packet Loss)

We send the packet but we haven't received the response

When the Congestion algorithm detects the packet loss it just halves the current size, moves to the Slow start and then sets new Slow start threshold and then again moves to the Congestion Avoidance state gradually.

The Congestion window size will be halfed even for one packet loss.. so this is not the efficient way to handle the scenario so comes the Fast Recovery

Fast Recovery

In the Fast recovery instead of backing off to half of the current size of the congestion window, it will be backed off to little lower size(not halfed can be 1/4th kindoff)

Again from there it will start the Slow Start and then move the Congestion Avoidance state..

Flavors of Congestion Algorithms

All these values, initial window size, slow start threshold, backoff size all depends on the flavor of TCP used

*LFN - Long Fat networks (High bandwidth and High latency - 10Gbps,150ms) CTCP - Compund TCP

Receive Window

The Sender is limited to send the data not beyond the receive window

Eventhough the recieve window is at its max (1GB) the sender will decide how much data should i send.

Its depends on the the congestion window or the receive window value which is smaller then thats the max data in flight.

Also the max data in flight is depends on the Bandwidth Delay Product(BDP)

Receive window VS Congestion Control

Congestion Detection

Packet Loss

When it saws the packet loss then it sticks with the previous congestion window size where it get the success ACKs

Latency

The sender will calculate the latency and tries to adjust the congestion window based on that to avoid the congestion.

Measuring Bytes in Flight

Since the COngestion window size is not advertised we need to calculate that. We could calculate that successfuly only when the packet capture is done at the sender side.

In the Below image u could see the maximum receiver window size of the receiver is 212992. So the Sender will not have the congestion window greater than this or the bytes in flight won't be greater than this.

From the below image u could see that the slow start happens after the congestion window collapse.

Sender sends some data waits for ACK, then increases the size and waits for ACK.......

Below is the throughput graph which is used to see how the Congestion window build and rebuilds

Statistics -> TCP Stream Graphs -> Throughput

TCP Analysis feature - Wireshark

Whenever in the Wireshark packet if we see [] then it is calculted by the Wireshark

TCP Window update

Here in the image, packet number 229 and 232 is same except the TCP window size. The Ack number is same for the both packets.