Am I correct that TCP receive window
(which is a send window
for the sender) has nothing to do with TCP CUBIC congestion control? TCP receive window
is solely a property of TCP flow control?
1 Answer
The first thing to realize is that the TCP window size and the round-trip time (RTT) limit the throughput: no more than one window size per RTT can be transported.
Essentially, with a large RTT (latency) you need a larger window for the same throughput than with a smaller RTT. If you can't increase the window you can't utilize the full bandwidth. This is why the bandwidth-delay product is important to model throughput scenarios in network planning.
Accordingly, congestion control works the other way: with slow start, the windows start at medium size and - assuming ample bandwidth - is ramped up.
At some time, somewhere on the way, a port's capacity is reached and packets can't be forwarded right away. They need to get queued. They spend more time on the way, so ACKs begin to arrive late. The RTT measured by the sender goes up.
In response to filling buffers -> growing RTT the window is reduced again. Sending slows, queues empty, RTT goes down again. In response, the window is allow to grow, starting the cycle over.
In theory, this sounds (fairly) simple. In practice, you have to fine tune the exact response mechanism. Keep in mind that TCP used to work over slow serial modems with just a few 1000 bit/s and today runs over multi-gigabit/s lines (nearly) just as well - that's easily seven or even eight orders of magnitude!
This is where BIC and CUBIC come into play: the traditional congestion control, even with window scaling, has got its limits. Basically, it oscillates between congestion on the one side and throughput is below potential bandwidth on the other.
Instead of ramp up until congestion, then cut back, BIC and CUBIC try to model the channel's exact congestion behavior with a quadratic or cubic function, so that you can run a channel in the "sweet spot" with maximum throughput, just before congestion starts. The model parameters are continuously adjusted to the feedback parameters, so that the model changes when the channel changes.
-
Thanks! Still, if for example, TCP congestion control detects a congestion on the connection, then it does not reduce the size of the
Window Size
field in TCP header? Instead, it reducescongestion window
, which also affects how much traffic sender puts onto wire?– MartinApr 26, 2018 at 9:25
send window
(advertised by the receiver asreceive window
) andcongestion window
and then pics the lowest value of two?