Congestion Control is the Friction of the Internet

I recently took a Network Engineering class, and as a refinery process engineer, I could not help but see the flow of data packets through the paradigm of fluid flow through piping systems. For example, the ‘bandwidth’ of a line seemed to be equivalent to the diameter of a pipe. However, there was one principle in network engineering that initially did not appear to have a direct companion in fluid dynamics – congestion control.

To understand congestion control, it is necessary for some additional internet context. The original purpose of the internet was to connect disparate existing physical networks. Several universities already had their own computer networks. The internet founders established protocols that allowed for shared use of internet resources. The process of sharing network resources is called ‘multiplexing’.

To help in your understanding of the complexity of the internet, I encourage you, dear reader, to open up your command line (on windows computers) and type the command ‘tracert -4 www.dhirubhai.net’. The result of the command on my computer is shown below:

My trace of the route that my computer takes to connect to linkedin revealed six intermediate hops to different routers. There are thousands upon thousands of internet connections that are using the exact same resources. If the resources are shared, the question becomes how to avoid overwhelming the network, such as routers and links? More specifically, how do the millions of simultaneous internet users control the rate at which data packets are sent and received to avoid exceeding data transfer limits, but also use maximum network capacity? The solution (at least for TCP traffic) is congestion control. There are many flavors of congestion control, but for the purposes of this brief article, I will focus on TCP-Reno.

The Transmission Control Protocol (TCP) 3-way handshake requires an initial synchronize request (SYN) that waits for an acknowledgement (ACK, SYN) from the sender. The fact that an acknowledgement message must be received is the foundation of congestion control. If the rate at which packets arrive at a router exceed the rate at which they can be processed, the queue size will eventually exceed the allotted queue memory and packets will start to be ‘dropped’. Dropping packets means that they are not delivered to their destination, and therefore acknowledgement messages are never received by the sender. The sender can use dropped packets to determine the appropriate rate at which to send data. It may be surprising to some, but the rate at which your devices send and receive data is often not constant. The plot below shows a typical ‘sawtooth’ pattern of network traffic:

TCP-Reno follows a pattern of Additive Increase Multiplicative Decrease (AIMD). As data is transferred, the rate of data increases until a packet drop is detected, at which point the data transfer rate is decreased multiplicatively (hence the gradual increase and sharp decreases in the sawtooth pattern). As explained in the previous paragraph, dropped packets can be detected by the lack of an acknowledgement message.

Networks of pipes flowing fluid did not need an invention called ‘congestion control’ because the natural world has friction. A simplified explanation is that as fluid flows through pipes, a portion of the kinetic energy is transformed into heat due to friction at the pipe wall. As the velocity of the fluid increases, friction also increases. It can be useful to consider the maximum flowrate through a pipe network to be determined by friction. Therefore, friction provides a limit for the maximum amount of fluid that can flow through a pipe given specified pressures, fluid properties, and other parameters such as roughness of the pipe wall. Finding friction factors is relatively easy for laminar flow (Re < 2000) and can get complicated for turbulent flow (Re > 4000). My oversimplified understanding is that congestion control needed to be implemented because friction does not exist in computer networks.

I am not entirely sure there is a definite conclusion to these meanderings that I have passed off as an article. What I can say is that I felt my appreciation of both friction and congestion control increase as I reviewed the concepts and completed a mental comparison. Attempting to organize my thoughts in the form of a hopefully education article has allowed me to explore the initial ideas that I had about the similarities of congestion control and friction. If you were interested in any of the topics that I mentioned, but you found yourself asking, ‘That was sort of interesting, but I feel like the author doesn’t know how to explain it well’, then please follow up with one of the references below. Thanks for reading!

Never Stop Learning!

How does the Internet Work? – Standford (From 2002 but still useful)

What is the TCP 3-Way Handshake? – CISCO Youtube Video

What is TCP-Reno Congestion Control? – Intro to Computer Networks

How does friction affect fluid flow? - Youtube - Moody Diagram

Sawtooth Pattern Photo: elastic.co/blog/found-understanding-memory-pressure-indicator