-
Notifications
You must be signed in to change notification settings - Fork 53
Description
After three years of adoption of the book, based on students questions and checking the RFC, I think the congestion control part is pretty confused and in some sentences not accurate.
First it introduces a generic "window" as "window is the maximum between the host's sending window and the window advertised by the receiver". There is no definition of "sending window", but one can imagine that an abstract definition is " the maximum amount of data that the sender can send, as that amount can be stored in the out buffer".
Then cwnd is introduced saying: "window that can be used by the sender is constrained by \min(cwnd,rwin,swin) where swin is the current sending window and rwin the last received receive window"
Now, the problem is that in my understanding, in the RFC of TCP, there is not a "sending window" in strict terms. What the RFC calls snd.wnd is referred to as send window. But it is not conceptually the same as the abstract definition from before. That is the value of the last "window" field received from the other endpoint:
https://datatracker.ietf.org/doc/html/rfc9293#section-3.10.7.4
In the ESTABLISHED state:
If SND.UNA =< SEG.ACK =< SND.NXT, the send window should be updated. [...] SND.WND <- SEG.WND
So snd.wnd is not the sending window, it's the local variable where one endpoint stores the last known value of the receiver window of the other endpoint (that should correspond to "rwin"). There is not a sending window as in the abstract definition, because the sender simply does not accept data if data can't be stored in the sending buffer:
https://www.rfc-editor.org/rfc/rfc9293.html#name-send-call
Under "ESTABLISHED STATE CLOSE-WAIT STATE" it says:
Segmentize the buffer and send it with a piggybacked acknowledgment (acknowledgment value = RCV.NXT). If there is insufficient space to remember this buffer, simply return "error: insufficient resources"
So the "sender" does not have a real sender window, as a consequence \min(cwnd,rwin,swin) does not make much sense. It does, of course, conceptually, but not after having introduced TCP and the TCB.
Confusion is also made worse by the description of the TCB, that is not entirely correct:
I refer to:
snd.wnd : the current size of the sending window (in bytes)
rcv.wnd : the current size of the receive window advertised by the remote host
The first thing does not exist, and the second is actually not correct, because that should be the size of the receiving buffer of the "sender" itself, not the size of the other endpoint. This led me to a wrong suggestion in a another issue that I raised one year ago, and should also be corrected (about Nagle's algorithm).
So students arrive to Slow Start with confused ideas on windows.
Finally about slow start.
The same line i linked before introduces AIMD, "The Additive Increase part of the TCP congestion control increments the congestion window by [MSS] bytes every round-trip-time. [...] The Multiplicative Decrease..." . There is no mention of the exponential growth. Only later on, it says "During slow-start, the congestion window is doubled every round-trip-time."
These two sentences are both correct, but make it hard to understand Slow Start.
Furthermore, the pseudocode seems also correct but the comment does not help:
if tcp.ack > snd.una: # new ack, no congestion
if dupacks == 0: # not currently recovering from loss
if cwnd < ssthresh:
# slow-start : quickly increase cwnd
# double cwnd every rtt
cwnd = cwnd + MSS
The comment says that cwnd is doubled, but the code linearly adds MSS. Actually, since this happens at every ACK, and eventually we have one ACK per sent segment, so at most cwnd/MSS per RTT, then over a RTT we double the cwnd. But the comment should be more clear on how, otherwise it recalls the linear increment mentioned before.
When everything is put together (the windows, the description of AIMD, the doubling every RTT and the pseudocode), students have hard times to get the congestion control algorithm.
If you agree on these issues, I can ask some student to rephrase this section (also the part on Nagle's algorithm as a consequence, as it now wrongly mentions rcv.wnd ) and after supervision, provide a patch.