search

mdn / content

The content behind MDN Web Docs
https://developer.mozilla.org
Other
9.12k stars 22.45k forks source link

Congestion Control's content lacks context and clarity. #35182

Open mohammednumaan opened 1 month ago

mohammednumaan commented 1 month ago

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 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 About Buffers

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.

mohammednumaan commented 1 month ago

@Josh-Cena Hey there! I was wondering if you could lend a hand by taking a quick look at the issue? Your help would be greatly appreciated!

Josh-Cena commented 1 month ago

Sorry, I'm not very educated in this area, so we should wait for another maintainer to triage and give suggestions.