Congestion Control's content lacks context and clarity.

### MDN URL

https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

### What specific section or headline is this issue about?

Response Section, `Congestion Control/ TCP slow start` sub heading.

### What information was incorrect, unhelpful, or incomplete?

The content about [Congestion Control](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work#congestion_control_tcp_slow_start) seems to lack context and clarity of how `ACKs` are sent and received in a congested network.

The below statement could be re-written better.

> On the other hand, sending too many segments at once can lead to the problem that in a busy network the client will not be able to receive the segments and will just keep responding with `ACKs` for a long time, and the server will have to keep re-sending the segments.

In a congested network, the sender/server will send segments that exceed the window size of the client (i.e, how much data the client can receive). As a result, the client wouldn't be able to handle that many segments, resulting in no `ACKs` being sent to the server for **those segments**. Now, the server hasn't received an `ACK` for **those segments** within a given time frame and proceeds to re-transmit the packet.

Content on **Buffers** should be added. Its a fundamental concept in Congestion Control.

I expected the content to include more context on when the `ACKs` will be sent to the server in a congested network and when does the sender re-transmit those same segments. I also expected to see a short/basic content on Buffers since its a fundamental concept in Congestion Control.

### Do you have any supporting links, references, or citations?

Here are some links/references related to the above issue:

[About DUP ACKs](https://stackoverflow.com/questions/48148820/what-is-duplicate-ack-when-does-it-occur)
[About Buffers](https://stackoverflow.com/questions/42857662/understanding-buffering-in-tcp)

### Do you have anything more you want to share?

This is my version of the improving the above content's clarity:
---
If the server waits for an ACK after each segment, it will result in frequent ACKs from the client for those segments. This may increase transmission time, even in the case of a low-load network.

On the other hand, sending too many segments at once can lead to the problem of the client not being able to receive the segments in a busy network. As a result, no ACK will be sent to the server. The server will expect to receive an ACK from the client within a given time frame. If the ACK is not sent, the server re-transmits the segments to the client. This process occurs repeatedly until the server receives an ACK for the segments.

One important thing to note is that every client has a *Buffer*. A *Buffer* temporarily holds incoming data. When the server sends too many segments to the client, the *Buffer* gets full. This may result in the client sending an ACK for the last successfully transmitted packet (DUP ACKs).

`Any changes can be made in the future. I'll be happy to work on this issue.`