It might be a stupid question, but as far as I understood the CNWD dictates the rate of a TCP flow.

I created a "load-balancer" that split single packets on two paths of 10Mb/s. This introduces some reordering which prevents the growth of the congestion window. When I measure the CWND for a single path (through captcp) it is around 600KB and the final goodput (with iperf3) is ~9Mb/s, if I do it with the combined paths the CNWD is around 200KB, but the final goodput is ~17Mb/s!

So how comes that the goodput is higher even if the cwnd is limiting only 200kb outstanding in the network?

  • 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 could post and accept your own answer. – Ron Maupin Dec 19 '20 at 22:10

With TCP throughput, there are a lot of factors which come into play. For instance, when the window is larger on a single link, congestion along the link could be a bigger factor. Because of congestion on the single link, IP packets could be dropped, causing TCP to resend segments, thus slowing down the transfer. There is also, a QoS function called RED (Random Early Detection) which randomly drops IP packets in order to prevent queues from becoming full. This forces TCP to slow down and resend segments.

A window is just the amount of traffic which can be sent before needing to wait for an ACK. If it doesn't take long for the ACK to be sent back (how fast the receiver takes to send the ACK, and how long the latency is between the two hosts), your transfer may not be slowed much.

The real way to dictate the speed of traffic flows is to use QoS to establish queues and bandwidths for traffic based on criteria you determine (e.g. DSCP markings).

  • "A window is just the amount of traffic which can be sent before needing to wait for an ACK" - This is incorrect. In TCP, the retransmission timer is initiated as soon as a segment is transmitted and not after the window is transmitted. – Argon Jun 17 '20 at 9:19
  • @Argon, you are referring to something else. My point is that a full window of data can be sent before the sender has to stop and wait for an ACK if it has not received one. An ACK can come at any point within the window, which will change the window, but sending must stop if the window is exhausted with no ACK received. – Ron Maupin Jun 17 '20 at 13:19

CNWD not dictate speed directly, it affects the speed along with other factors (at least RTT).

  • But the RTT is the same in this case – Ambi Jan 7 '16 at 22:01
  • At least in second test multipath is used and throughput must be higher, but higher throughput not necessary require larger CNWD, it what I try to point. For Example, second path can have little more loss (under high load)... For example because of smaller queue size. – mmv-ru Jan 7 '16 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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