Impact of Three-way Handshake and Slow Start Algorithm

Internet became something without which our lives are incomplete. Every day each internet user makes 100s of queries on the internet, be it a simple google search or visiting any website and no one likes the delay in the response. In this article, we will discuss time delay that affects internet speed. A three-way handshake was introduced in the initial time of the internet when TCP was just introduced. Over the period of time, the 3-way handshake is avoided completely using TCP FastOpen. But still, one very infamous congestion control algorithm is there which always invokes when TCP flow starts, this is a slow-start restart algorithm. This takes huge time before it starts sending buffer size worth of packets into the network, even if the bandwidth is totally available.

Slow Start:

The purpose of the slow start restart process is to ‘estimate’ cwnd and quickly arrive at a ‘decent estimate’. This algorithm by default gets invoked when a new TCP flow starts or when the link is idle for 1 RTO time. The cwnd value slowly increases from 10 to 20, 40, 80 and so on per RTT. The cwnd is increased by 1 when one new ACK arrives at the sender. The sender sends 2 new packets into the link on receiving one ACK. 1 packet is sent to compensate for the delivered packet, another is sent in accordance with the increased value of congestion window size.

Impact of Slow Start algorithm

Every TCP connection must go through the slow start phase. It means we cannot utilize the ‘available capacity on the link ‘immediately’ after the connection is established. The data transfer begins with ‘initcwnd’ and doubles in (approximately) every RTT. Assume that sender is limited by the receiver’s advertised window which is 64KB. The sender cannot start directly sending 64KB; it starts with Slow Start and increases sending rate. 

The time needed by the sender to grow its congestion window (cwnd) such that it can transmit 64KB at a time, can be calculated using the given formula.

where, 

• RTT stands for the Round Trip Time;
• init_cwnd is the local variable that stores the initial congestion window size, which is set by default in every OS.
• N is the desired congestion window size, say 64 KB.

Example:

RTT = 56 ms (London to New York)
Initial congestion window (initcwnd) = 10 segments
1 segment size = 1460 bytes
For the TCP Sender to transmit 64KB simultaneously, it must have a 
congestion window value of approximately 45 segments.
N = (64KB ÷ segment size = 65536 bytes ÷ 1460 bytes = 44.88 segments)

Time = RTT x ceil(log2(1 + 45/10))
= RTT x ceil(log2(5.5))
= 56 ms x ceil(2.459)
= 56 ms x 3
= 168 ms
Thus, the sender would be able to transmit 64 KB simultaneously after 168 ms.

Three-Way Handshake:

The three-way handshake is the initial connection establishment process. The client first sends the connection request to the server (SYN packet). If memory space and other resources are available at the server-side, then the server accepts the incoming connection request and ACKs this to the client by sending the SYN+ACK packet. When the client receives this packet, it starts the actual communication to the server and sends the GET request from the next packet onwards. In the reply, the server sends the actual data asked by the client.

Impact of Three-way handshake:

If the RTT measurement is 56 ms. This much time just goes waste into connection establishment. The client sends the SYN packet to the receiver for requesting the connection. The server responds to the client by sending an SYN+ACK packet. This two-way round consumes the whole RTT’s worth of time. From the next packet onwards, real communication happens, in which the client first asks for some data from the server, by sending the GET request in a new packet. Therefore, one RTT is the cost that the client pays for 3 way handshake. If somehow this handshake can be avoided, then 56 ms, in this case, can be saved every time the client connects to the server.

Impact of TCP Handshake and Slow Start algorithm

Assume the variables:

Round Trip Time = 56 ms, standard RTT time between London and New York
Available Bandwidth  to both server and client is= 5 MBPS
Receiver window size (rwnd) of both client and server= 
                    65,535 bytes = 64KB = 45 segments
Initial congestion window (init_cwnd)= 10 segments

Server processing time to process the given GET query and 
generate the corresponding response is = 40 ms

Assume the network is clean, with no packet loss and 
1 ACK per packet, only GET requests are sent.

Impact of TCP Handshake and Slow Start algorithm

Step 1: Sender sends the SYN packet at time=0.

Step 2: Receiver gets the SYN packet at time=28 ms, which is one-way time. The receiver accepts the connection request and sends back the SYN+ACK packet at time=28 ms, just after it receives the SYN packet from the sender. 

Step 3: The ACK arrives at sender at time=56 ms, another 28 ms was taken by a packet to reach from receiver to sender side, this makes a total of one RTT time, the two-way journey of the packet. Now the connection is established between sender and receiver using 3-way handshakes.

Step 4: Now sender sends the GET request to the receiver at time=56 ms. It takes 28 ms to reach and the receiver gets the GET request.

Step 5: At time=84 ms server receives the GET request. 

Step 6: The server takes 40 ms to process the request and generate the data to send in reply packets. After 40 ms elapsed, the server sends the 10 segments of data simultaneously at time=124 ms without waiting for a single ACK to come.

Step 7: The sender or client will start receiving the reply packets one after the other, and it will send the ACK for each packet to the server. The client will get all 10 segments by time=152 ms. On receiving the ACK packets, the server will increase its congestion window size by 1 per ACK packet. Initially, cwnd was 10, therefore it send 10 segments simultaneously. When the server increases its cwnd by 1, it sends 2 new packets into the link. 

Step 8: In one RTT time, the server will get the ACK of all 10 packets and thus its cwnd would become 10*2 = 20 at time=180 ms. Also, by this time server has sent 20 new segments into the link, other than the initial 10 segments whose delivery has already been ACK.

Step 9: Now, 20 segments are in the pipe between sender and receiver at time=180 ms.  

Step 10: By time=208 ms, the client will receive all these packets.

Step 11: By time=236 server sends 15 new segments. At this time server will get ACK of all these 20 segments. In the intrim, the server will increase its cwnd by 1 per ACK but can’t send 2 new packets for each ACK cause only 15 segments are left to send (total 45 segments). cwnd=40 now. 

Step 12: Thus at time=264 ms, 15 segments are reached to the client. Thus 264 ms are required to send 64 KB of data to the client.

Step 13: At time=292 ms, 15 ACK will come to the server, and cwnd will become 40+15 = 55, but the server has no data to send.

So, it takes 264 ms to send 45 packets to the client.

The bandwidth available between server and client is 5 MBPS, but still, the file of 64 KB is taking 264 ms. This time will not decrease even if we increase the bandwidth to 50 MBPS or 5 GBPS. If the client is visiting Gmail or google servers then the page load time will be 264 ms, and this time can’t be decreased by increasing the bandwidth.

Requesting the Same File Again in the Same Connection

Assume that the connection is idle for a few seconds less than RTO, the slow start is not restarted and the client sends another GET request to the server. 

Step 1: Sender sends GET request at time=0 ms. 

Step 2: GET request reaches the server at time=28 ms.

Step 3: The server takes 40 ms time for request processing. Generates the reply at time=68 ms and sends it to the client.

Step 4: Note that the cwnd of the server is already 55 in the previous transfer. So, the server will send 45 segments simultaneously at time=68 ms.

Step 5: At time=96 ms, the client receives all 45 segments.

Thus, slow start has wasted 264 – 96 = 168 ms. 

Conclusion:

264 ms taken by the server to successfully(with ACK) send 45 segments to the client.
By formula time taken by Slow Start to grow the cwnd to 64 KB= 168 ms.
Server processing time = 40 ms
Time elapsed in 3-way Handshakes = 56 ms
 
Total time = 3-way-handshake + server_processing + Slow_start
264 = 56(3-way-handshake) + 40(server response time) + 168(Slow_start) ms

Thus, slow start and 3-way Handshakes have wasted = 168 ms + 56 ms = 224 ms.

If there was no slow start and 3-way handshake, then 96 ms would be required.