Open mohammednumaan opened 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!
Sorry, I'm not very educated in this area, so we should wait for another maintainer to triage and give suggestions.
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.
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 anACK
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.