Network congestion technical implications

During the transfer of information in the Internet, there are various situations related to certain host or network inaccessibility, or channels of communication overload. In these cases a packet loss occurs, which leads to retransmission of already sent data frame or acknowledgement (TCP ACK).

These both cases lead to packet loss and further retransmission of data frame or acknowledgement packets (in case of TCP ACK for last data window).

Let’s see when packet loss occurs during TCP session initiation:

14:53:15.994623 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301221205 ecr 0,nop,wscale 4], length 0

14:53:18.997924 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301221956 ecr 0,nop,wscale 4], length 0

14:53:25.013946 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301223460 ecr 0,nop,wscale 4], length 0

14:53:37.029939 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301226464 ecr 0,nop,wscale 4], length 0

Теxt 1: Listing of SYN blackout

In this listing can be seen that the lack of response from the remote side (originating from the non-receiving of the initial SYN, or because of non-response to confirm the opening of the connection SYN + ACK), the party carrying out the connection, repeats sending SYN packets in the hope to establish a connection.

Also, consider the situation where packet loss occurred at a time when connection is established. Here it should be noted separately that in a normal operation – when this option is disabled and TCP Keepalive the absence of mechanisms to complete the TCP connection inactivity is established, the TCP connection may exist indefinitely in case of the absence of communication between remote parties.

For this reason, evidence of packet loss can be detected only when it is necessary to pass to the next data frame, or after receiving the acknowledgment for the data frame:

14:48:41.417886 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301152560 ecr 1835816346], length 48

14:48:49.925934 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301154688 ecr 1835816346], length 48

14:49:06.949935 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301158944 ecr 1835816346], length 48

14:49:40.997947 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301167456 ecr 1835816346], length 48

Теxt 2: Blackout during TCP session

This listing shows that sending the data frame (with the option PSH) is not enough, because the peer did not confirm the reception of the frame, so that the originating host keeps resending lost packets.

Retransmission mechanism in the absence of the expected response is regulated by the relevant RFC793.

(It is worth mentioning that the standard mechanisms of self-speed transmission are a natural reaction to the TCP packet loss).

Due to the fact that re-sending packets is performed at regular intervals – there is no clear boundary between the temporary loss of packets in the event of overloaded communication channels and complete lack of communication with a single host or in a certain direction.

Accordingly, the differentiation between Blackout and Congestion can be expressed by considering the statistical information of packet loss during a period of time.

As an example, we can consider an HTTP protocol – 1-2% packet loss, in case of small network congestion, has almost no effect on the performance of work. However, it should be noted here that by definition, the server for HTTP requests much greater connection to the network than to the Web browser – thus packet loss always occurs – but we do not notice it, do we?

This is caused by the fact that TCP is designed to solve packet loss situation – which is also one of the principles of self-limitations for speed of data transfer using the TCP protocol. Also, the limited time to re-send the package allows the user to not notice the packet loss.

Significantly higher percentage of packet loss will lead to a significant lock-up transmission and as a consequence – a greatly impact on BGP network performance.

On the other hand – if you are using the TCP protocol for online games, the short-time delay information transfer greatly affects the quality of service, since this type of information imposes higher demands of quality, speed, and most importantly – timeliness of the information transfer.

Packet loss (blackout or congestion) has a significant impact on quality of service on the Internet. For this reason – early diagnosis and routing optimization solutions for network congestion detection has a high impact over network stability. Using traffic engineering solutions such as Intelligent Routing Platform can lead to network optimization and congestion avoidance. The IRP solution is using active network probing for congestion detection and uses innovations in intelligent routing contributing to BGP network optimization. The Intelligent Routing Appliance can be used as an intelligent bgp routing platform in order to increase the network performance. Also, the platform uses leading solutions in traffic cost and commit control to reduce expenses.

Footnote
Request For Comments – collection of standards governing the technical functioning of the various aspects of the Internet.