Can Router override TCP Window Size (do it's own auto tuning?)

[zerowalker]

As question says,

I don't really fully understand this, but from reading around it seems it's like this in a nutshell.

TCP allows a maximum of 64kb data to be sent without knowing if it got through.
That's too low nowadays so they added a Shift factor to increase it to 1mb or something i think.

And Window Size (along with the scaling factor?) is determined by the client and host dynamically by the latency or something.


That all make sense, what doesn't make sense to me is why the OS (at least Windows) use some algorithm for this,
or if that algorithm is to prevent something (which i don't get either).
There's CTCP and CUBIC for example.

Now here is the issue with that, i recently learned of Bufferbloat, a thing i knew about but not that it was a "bug" if you will.

Basically if you use your connection heavily (especially upload) your latency goes haywire.
I thought this was just because there's only that much stuff the line and all hardware etc can handle.
Which apparently is not always the case.

So, to go back to the CTCP stuff, i noticed i had a really bad Bufferbloat, even though i got 100/100 fiber.
So i first thought i had to tweak around with the router, it didn't have any real effect.
I then connected directly to my PC, same issue, i then played around with my NIC settings to no avail.

So eventually i went to the advanced TCP Settings in Windows, and the thing that solved it for me was turning of Auto Tuning.
This limits the window size to 64kb, the scale is simple turned off.

Now, i don't know if it's really the Auto Tuning itself, of if it's the algorithm that's used along with it.
Cause in Windows 10 (which i use) you can't disable the algorithm, you have to disable the entire Auto Tuning.
(It sucks, there's a ton of stuff you can't change anymore in there).

"It's called congestionprovider", think congestion is what it tries to prevent, but as said before, didn't get what that was.

So now i was wondering, i am guessing the OS/NIC etc, doesn't really have a clue what's going on and only simply handles the packets and run it's algorithm stuff based on the information.

Can't the Router do the Auto Tuning, or force a size/scale?
Cause as the packets go through, simply writing some bits should be easy enough right?



Well that was a ton of rant about shirt i don't understand haha, enjoy;P!

 

[ColinTaylor]

That's what the router's QoS does.

 

[zerowalker]

it does?
i thought it simply prioritized packets based on rules, not modifying them in anyway?

 

[kfp]

it does?
i thought it simply prioritized packets based on rules, not modifying them in anyway?

He meant that QoS solves bufferbloat.

 

[ColinTaylor]

AFAIK the router's kernel enables ECN when requested by incoming connections and the sfb and fq_codel queueing disciplines use ECN. But I'm not an expert on the intricacies of that. But as kfp implied, using QoS has been shown to improve bufferbloat.

 

[zerowalker]

Okay did some more testing.

Auto Tuning causes it, QoS improves it, but NOT if you have "Automatic" for the Bandwidth.
That was the problem why i didn't really notice anything before.
I had Traditional now and it worked fine, then i tried Adaptive again with Automatic and it was bad, changed to Manual and it worked much better.

Though still, if the issue comes from the Auto Tuning thingy to begin with, isn't it better to solve that rather than solve it after the "damage is done" so to speak?
Feels weird that if you didn't have a router you wouldn't have a choice in the matter.

As for ECN, i thought that was something both client and server had to use in order to come up with the window size without dropping packets or something?
So thought the router didn't really do anything with it?

 

[kfp]

Auto Tuning causes it, QoS improves it, but NOT if you have "Automatic" for the Bandwidth.

<snip>

Feels weird that if you didn't have a router you wouldn't have a choice in the matter.

You have to set the bandwidth so QoS can do its job and prevent bufferbloat.

I’m not sure what you mean by “wouldn’t have a choice in the matter”. Ideally ISPs should prevent bufferbloat on the modem, but they don’t so we have to do it on our routers, and obviously you’ll have to own a router to do it, but ultimately the fault is on the ISPs.

 

[zerowalker]

Well doing some testing with FreshJS QoS, that doesn't seem to work at all no matter the bandwidth i set.

And what i meant is, the router is the middle hand between your PC and your ISP.
So why not fix it on your PC.

I don't even have a Modem as i use fiber so can't say anything there, it make sense that it's messier though.

 

[kfp]

Well doing some testing with FreshJS QoS, that doesn't seem to work at all no matter the bandwidth i set.

And what i meant is, the router is the middle hand between your PC and your ISP.
So why not fix it on your PC.

I don't even have a Modem as i use fiber so can't say anything there, it make sense that it's messier though.

I don’t use QoS on my Asus devices so not going comment more on it. Maybe @FreshJR can provide some insight?

Think about what bufferbloat is solving and why it doesn’t make sense to solve it on just one device (your PC). The problem is happening between your ISP and your home network, so it makes sense to solve it at that bottleneck instead of on your PC. Your mobile phone won’t benefit from QoS on your PC and you’ll still suffer from bufferfloat.

Depends on how your ISP implements it yes you might not get access to one, but on the other end of that ethernet jack on your wall it’s eventually connected to a modem or router (wherever they limit your bandwidth), and that’s really the ideal place to have proper QoS.

 

[zerowalker]

It make sense in a network yeah.

But as the Auto Tuning causes it for me in the first place, which is something i have somewhat control over (just quite limited in Windows 10),
it make sense to tweak that part first, doesn't it;o?

And yeah it does make sense to have it with the ISP, but then again, QoS is weird as it's just "what do you want to get prioritized",
which isn't an universal bufferbloat solution right?
It just happens to solve it as you usually want to prioritize the stuff that causes it to appear?

 

[kfp]

It make sense in a network yeah.

But as the Auto Tuning causes it for me in the first place, which is something i have somewhat control over (just quite limited in Windows 10),
it make sense to tweak that part first, doesn't it;o?

And yeah it does make sense to have it with the ISP, but then again, QoS is weird as it's just "what do you want to get prioritized",
which isn't an universal bufferbloat solution right?
It just happens to solve it as you usually want to prioritize the stuff that causes it to appear?

I just tried turning it off and it makes no difference in my bufferbloat score. Now that you mention you have fibre and don't have access to a modem, do you get a public IP from your ISP? Perhaps it's the ISP's router trying to do some QoS and it works well with a static TCP window size.

How is QoS weird? Yes, one aspect of it is to prioritize different types of traffic, another aspect is to implement a queuing discipline to so all hosts have a fair chance of getting traffic out, another is a bandwidth limiter to prevent bufferfloat. It is not some side-effect, it is part of QoS.

 

[zerowalker]

But that queue only works if Control Packets are the highest priority right?
So if you had a queue that just prioritized that, and didn't care about the rest, it would end up the same way right?
Everything else is personal in what traffic you care about.

And yeah might be that the ISP tries something.
Guess i have to try with some other OS to see if that's the case, or if it's just the handling of it that's bad.

 

[kfp]

But that queue only works if Control Packets are the highest priority right?

My previous comment was not completely accurate so I've edited it.

What solves bufferfloat is the bandwidth limiter, which basically tries not to send+receive more than your ISP allows you. What the queue does is give all your devices a fair shot at making a connection, so that a 4K Netflix stream would not affect a webpage loading response time.

Web-based bufferfloat tests use HTTP(S) which is not under Control Packets so it shouldn't have any impact on the score.

 

[zerowalker]

Ah, reminds me of the ADSL days, if you ever touched anywhere close to your limit, especially on upload, your entire connection would go awry xd.

I thought it used Control Packets to check the latency while doing transfers via TCP or something, if that's not the case, then it makes sense.

What's your score on this?
https://sourceforge.net/speedtest/

 

[kfp]

From the link you provided

This test utilizes WebSockets for latency, jitter, and buffer bloat measurements.

WebSockets is a TCP protocol using HTTP ports, I doubt any QoS classifier would put them in Control Packets category.
I ran Wireshark while the test was going on and they all seems to be TCP/TLS streams.

I don't have QoS set up actually because of laziness, but all this back and forth makes me want to finally set it up properly now.
As for scores, I did two runs, max goes to about 500ms so pretty bad.
I don't know how good SourceForge tests are, but here is a more well-respected test, and I've never gotten better than 'B'.

 

[Grisu]

this is how "A" will look like
only 40MHz bandwith

and 80MHz bandwith 5G maxing my line.

On the other side sourceforge test would give me the result that to weak for VoIP or Skype 3 times tested!
Only 4th test got reliable for VoIP and Skype.
So I dont believe these tests too much ...

 

[Sinner]

this is how "A" will look like
only 40MHz bandwith

View attachment 13630

and 80MHz bandwith 5G maxing my line.
View attachment 13631

On the other side sourceforge test would give me the result that to weak for VoIP or Skype 3 times tested!
Only 4th test got reliable for VoIP and Skype.
So I dont believe these tests too much ...
View attachment 13632

How reliable are those speeds your getting? If you set adaptive qos to like 90% of your lowest stable achieved speeds that bufferbloat rating of C will turn to an A. Problem solved

 

[Grisu]

get it all the time again.

there is no QoS in AP-mode ...

I dont have any problem with these tests, only wanted to show how confusing they may be and wanted to show kfp an overall A-rating.

 

[kfp]

get it all the time again.

there is no QoS in AP-mode ...

I dont have any problem with these tests, only wanted to show how confusing they may be and wanted to show kfp an overall A-rating.

I’m talking about an A for bufferbloat.. which you don’t have. I was just saying that without more advanced configuration on my router, I’ve never gotten a better score than B for bufferbloat.

And of course you can’t do QoS in AP mode, you have to do it on your router.

 

[zerowalker]

Well noticed now that the QoS isn't working that well for Upload overall, it seems to cap to 50mbps for me at times for some reason,
i can't figure out why, it helps to turn it off and on at times it seems, but the settings itself doesn't seem to have any consistency.

With QoS:
http://www.dslreports.com/speedtest/35595003
Without QoS:
http://www.dslreports.com/speedtest/35595224
Without QoS & Auto Tuning disabled in Windows:
http://www.dslreports.com/speedtest/35595288


Tbh i can't really read them, i don't see any graph for the bufferbloat;S

And yeah know the link i gave stated Websockets and that it used TCP, but thought the latency was determined by pinging.
I guess it looks at the differences between the current and last packet or something.
Or maybe the ACK response after the Window Size has been reached.

EDIT:

Hmm, the first one has that Bufferbloat graph though... weird

DslReport CLI (it seems to work with the Bufferbloat graph):

QoS & Auto Tuning disabled:
http://www.dslreports.com/speedtest/35595924
QoS Disabled:
http://www.dslreports.com/speedtest/35596004
QoS Enabled (Adaptive, 92 up, 94 down):
http://www.dslreports.com/speedtest/35596071

EDIT 2:

At least one can clearly see that Auto Tuning messes it up.
Which reminds me to try to do a test from some other OS,
or maybe via the router itself if that works, to confirm if that part can be solved.