Add post about reasons for congestion control

[mengelbart]

No description provided.

[Sean-Der]

I think this is better for a second post in a series.
We should merge it now though, but I think we should suggest
users read another introductory post first.

I think users will first ask 'Why do I even care about Congestion Control'.
People don't want to consume a highly technical topic without knowing what is
in it for them. Worth asking others, but this is how I got interested/see the topic.

* Ever wonder why your conference call starts low quality and gets better gradually?
* Ever wonder why people can't hear you in the conference call randomly?
* Ever wonder why green artifacts appear in the call?
* Ever wonder why sometimes your conference call seems to become more delayed, and then catch up?

Before we can even begin to understand why these problems happen you have to understand how information
flows over the internet. The internet is made up of many different hops. Imagine you are sending a packet
from one internet user to another. It will flow through the different hops. Some of those hops maintained
by the users ISP. Maybe some of those hops are maintained by the business they work at.  You can visualize it
like so.

[Sender] ---> [Node 1] ---> [Node 2] ---> [Node 3] --> [Node 4] --> [Receiver]

All of these hops are just computers with all the usual constraints. They have a CPU, memory and network cards.
They are all running network stacks and Operating Systems that have different behaviors and bugs. These
hops are also being utilized by millions of other users using the same networks.

---

The video conferencing behaviors mentioned before are because of these hops. The internet is made up of pieces that
are constantly changing. Hops also don't have a way to communicate their status to senders. If a hop loses a packet
because it is under heavy CPU load it has no way to tell the sender. If a hop is slow to forward a packet because RAM
is exhausted it has no way to tell the sender.  It is up to the receiver to communicate that information.

This means that senders and receivers have to figure out this information on their own. We If we want to have a good 
experience we need to figure out how much we can send, without overloading these hops. Overloading these hops is
 commonly referred to as network congestion. So what we need is a 'Congestion Controller'.

---

Since these hops have no way of communicating with Senders it is a game of heuristics. Senders and receivers need 
to look at attributes of the packets they sent and made decisions. How long did it take to send the packets? Did any 
packets get lost? Did large packets get lost or take longer? Any information we can get is fair game.

---

Testing how software responds to congestion adds to this complexity. When developers right conferencing software
they are usually doing it under favorable terms. As a developer how do I test and anticipate all the behaviors that will exist
when I send a packet? You can't expect every person building network software to test the millions of different configurations. So good testing software needs to exist and it needs to easy to use.

[Sean-Der]

Instead of drawio I would use mermaidjs. It renders in github and hugo, don't have to commit binary files and can be modified without editing software!

[mengelbart]

Oh that's cool, I didn't know mermaidjs. Will change it!

[mengelbart]

Makes sense. I can put your suggestion in another, first post tomorrow. But then I would also suggest waiting with merging until the first post is done, too. In case we want to adjust this one to build upon the first.