Windows 10 - Auto Tuning and Bufferbloat?

zerowalker · Post by **zerowalker** » Fri Jul 06, 2018 10:42 am

Hi,

So i recently learned about Bufferbloat.
I kinda knew the problem with latency going haywire when you are downloading or uploadoing (usually uploading), and thought that was simply cause you used up your line or something.
But apparently it seems that's not always the case.

So i played around on tests with my router to no avail, then i connected to my NIC directly to no avail, settings didn't do anything noteworthy.
What did changes was the Auto Tuning, disabling that fixed it (or at least improved it a lot).

But then you lose larger window sized than 64kb for the TCP which i guess sucks.
But to me it seems weirth that this is the issue, i think rather than it's the algorithm, which i don't really understand?
I thought the Window Size was decided by both parts agreeing on it with som ACK thing, not via some guessing work done by the OS?

Windows 10 1803 x64

Post by **Philip** » Fri Jul 06, 2018 10:13 pm

You are correct that the TCP Window size is negotiated by the two ends of the connection. You are also correct in that limiting the TCP Window to 64KB (by turning off Auto-tuning / TCP1323 Options) also limits the bandwidth a lot, so it is counter-productive for fast internet connections. The issue is that hops on the way between the two end points (routers/nodes) may get congested, and if they can't store everyone's buffer (TCP Window) they may start dropping packets/introduce bigger delays. If you decide to play nice and reduce your TCP Window, it does not eliminate bufferbloat on shared pipes, where all the nodes in between are bombarded with packets from other connections, and have some type of management for large buffers. I wouldn't worry too much about bufferbloat, it is more important to optimize your end of the connection first. The only possible reason you'd limit your TCP Window size to 64KB is if you are actually having problems with packet loss, and you also don't care about bandwidth/speed, but only latency.

zerowalker · Post by **zerowalker** » Sat Jul 07, 2018 5:11 pm

Can't i limit the TCP Window to something higher?
Like forcing the Scale and prevent Windows from messing with it?

Post by **Philip** » Sun Jul 08, 2018 1:21 am

This used to be possible... Since Windows 8 we can only control how aggressively the auto-tuning algorithm allocates the TCP Window. The options are listed in the TCP Optimizer, you can use either "highlyrestricted" or "normal" for the auto-tuning algorithm I suppose.

zerowalker · Post by **zerowalker** » Sun Jul 08, 2018 1:29 am

Well you still can do that.
But i isn't the algorithm the CTCP thingy for example?
Or is that some other fancy thing it does along with the Auto Tuning;S?

Cause that one can't be disabled anymore, you can barely change any setting now

Are all options available on the Server 2016?

Post by **Philip** » Sun Jul 08, 2018 10:50 pm

CTCP, New Reno, etc. are "Congestion avoidance algorithms", they kick in once there is congestion/packet loss on the line to mitigate the effects and get the line back up to speed. They are better than the traditional TCP "slow start" algorithm, which took a long time to ramp up the speed of the connection after packet loss occurs.

With Server Windows variants you have a few more things unlocked, but I don't think you can control the TCP Window directly either.