I've learned that the congestion window is the maximum amount of packets that can be sent in one transmission round. Now TCP seems to acknowledge the packets in bytes, so wouldn't it make more sense to define the congestion window in bytes. So how can the acknowledgments and the congestion window work together?

I hoped to find more information in the according RFC 5681 but after reading I still don't have an answer.

The RFC seems to measure the congestion window based on the SMSS (Senders Maximum Segment Size) which would be bytes and not a package amount.

Besides that the RFC mentions that the congestion windows increases by max SMSS which wouldn't really allow a exponential growth.

So how does congestion control really work in slow start?


  1. Following part of the RFC confuses me:

During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data. Slow start ends when cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted above) or when congestion is observed. While traditionally TCP implementations have increased cwnd by precisely SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND that TCP implementations increase cwnd, per:

  cwnd += min (N, SMSS)                      

It says that the congestion window increases by N which has been referred to as the number of previously unacknowledged bytes acknowledged in the incoming ACK. or SMSS depending on which one is smaller. This would imply the congestion window is in bytes? And how can it be exponential then?

1 Answer 1


The receive window is shared with the sender, and it is how much data can be sent before the sender must pause to wait for an acknowledgement.

The congestion window has nothing to do with acknowledgments (other than those informing it of a lost segment). The congestion window is only known by the sender, and it is how much a sender can send in a burst of sending (as long as the receive window is still open). The sender uses the congestion window to learn how much it can burst before there is a problem.

The sender slowly grows the congestion window until there is a problem, then it will drastically shrink the congestion window when it learns of a problem. It will then slowly grow the congestion window until there is again a problem, at which point it again drastically shrinks the congestion window.

The receiver has no knowledge of this, and it simply acknowledges segments it has received, and that can inform the sender of lost segments, causing the sender to realize there is a problem, at which point the sender will adjust the send window.

The congestion window and the receive window are separate. The receive window is maintained by the receiver and shared with the sender, but the congestion window is maintained by the sender, but it is not shared with the receiver.

  • Thank you for the answer. Can you check out the Edit I made? Because the RFC relates the congestion window to the bytes/acknowledgments.
    – Felix
    Commented Jan 17, 2023 at 16:23
  • If a sender sends a full congestion window with no problems and without exhausting the receive window, it pauses its sending burst. The no problems implies that all the data in the burst was received, and it must get ACKs to prove that. Then it doubles the congestion window, repeating that until there is a problem, at which point it cuts the congestion window in half. The only dependence on ACKs is to prove that there is no problem in the burst (there can be multiple ACKs in the window).. The amount sent can be limited by the receive window, even if the congestion window is not exhausted.
    – Ron Maupin
    Commented Jan 17, 2023 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.