> The congestion window size is calculated with the formula cwnd * 2^wscale . In the output above, notice that wscale equals 7 , and cwnd equals 10. This comes out to 10 x 2^7 according to the formula, equal to 1280 bytes.
That's just not true.
If the author is reading this - cwnd unit (in linux) is in packets not bytes. I'm not sure where they got the formula from (that's the receive window scaling formula, and has nothing to do with cwnd), but iirc slow start defaults to 10 packets. With their mss being 32K (a loopback connection) the actual cwnd size in bytes is at least 10 * 32K.
Thanks for taking the trouble to comment on my blog post.
You are correct that cwnd unit is indeed in packets.
And the mss of a loopback connection is, as you say, 32K. But here we are concerned not with connecting to other processes on the same server, but routing across the WAN to the other side of the globe. And unfortunately, unless we are
able to enable jumbo frames, we are stuck with the historical relic of 1500
packet sizes. This means that the initial congestion window size of only 15K.
Thanks for correcting my error about cwnd units. I'll fix the post later today.
No problem! Agreed that restart from idle is a little dumb especially with connections that go idle all the time. IMO whatever timer it uses should be in minutes not round trips.
Thankfully newer congestion control algorithms like BBR (which you can enable, though linux currently ships an older version) do not suffer from this and do not go to slowstart.
That's just not true.
If the author is reading this - cwnd unit (in linux) is in packets not bytes. I'm not sure where they got the formula from (that's the receive window scaling formula, and has nothing to do with cwnd), but iirc slow start defaults to 10 packets. With their mss being 32K (a loopback connection) the actual cwnd size in bytes is at least 10 * 32K.