4

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?

3
  • 3
    In slow start congestion control, TCP increases the window size till the maximum transfer rate "m" is achieved. However, m will always be less than R where R is the maximum receive window size. In a way, receive window has "something" to do with congestion control.
    – surya
    Apr 25, 2018 at 16:46
  • Ok. So they are not directly related, but sender will always check the send window(advertised by the receiver as receive window) and congestion window and then pics the lowest value of two?
    – Martin
    Apr 26, 2018 at 9:21
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Dec 25, 2018 at 8:20

1 Answer 1

4

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.

1
  • 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 reduces congestion window, which also affects how much traffic sender puts onto wire?
    – Martin
    Apr 26, 2018 at 9:25

Your Answer

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

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