We often hear of network congestion, perhaps a little less often than what are the mechanisms that try to manage it.
The primary mechanism for managing the congestion is the drop packet. When the apparatus is in trouble it throws packets in a pseudo-random order to save time (and bandwidth), by trusting that the application protocols are able to manage their packet loss.
There are two side effects that affect the performance of the transmission:
The Real User Experience is able to identify the packets which contain the ECN flag. To do so it is sufficient that the network apparatuses have ECN activated. This can be done by configuring the queuing mechanisms such as RED, WRED, GRED, HIGH depending on the vendor.
The information about the status of congestion of a network device helps us to quickly localize the cause of the performance reduction.
As it can be seen in the example above, we have requests between two IPs in the local network, which “suffer” packet drops (see field “Retransmission”). This drops are likely to be caused from a network device which has send its state of congestion (see field “Congestion”). We don’t know the identity of the device in question, but have the possibility to simply follow the route of the packets and to verify the statistics of the devices which meet each other to identify them.
Using Nedi integration we can discover which are the switch/router bound to the client or server for go further in analysis of the network device:
Hint: Eventually, you are asking yourself, which is the number of congestions starting from which you should pay particular attention to them. A congestion does not necessarily require excitement. I personally suggest you to observe the development of the congestions. If they become more frequent, you should further investigate on the cause of them and therefore follow the packet-route. In this way, you will be able to identify emerging bottlenecks before they have a negative impact on the application performance experienced by the users.
In order that the recovery mechanism of the state of congestion (reduction of the transmission rate) works, it is necessary that also the clients and servers have ECN activated. Generally, all recent operating systems support the ECN, even if in some case the mechanism is disabled by default:
From Windows Server 2012 is enabled by default. In the previous versions and in the client versions is disabled by default.
The mechanism can be enabled with: netsh interface tcp set global ecncapability = enabled
From kernel 2.4.20 it supports the ECN in these ways, configuring it through the sysctl interface by setting parameter /proc/sys/net/ipv4/tcp_ecn :
0 – disable ECN and neither initiate nor accept it
1 – enable ECN When requested by incoming connections, and anche request ECN on outgoing connection attempts
2 – (default) enable ECN When requested by incoming connections, but do not request ECN on outgoing connections
In the version 10.5 it supports ECN but it is disabled by default. It can be enabled by setting sysctl variables net.inet.tcp.ecn_negotiate_in
In the version 11.10 it is enabled by default
In the version 9 ECN is enabled by default