Hi,

please what is the reason that there is absolutely no information about how to adjust the TCP send and receive window size?

Is this 'parameter' really not usefull for tweaking on RouterOS?

Thanks for getting some info here.

Achim

Are you sure??
Check the manual on MTU and MSS option

Maximiliano

MTU and MSS are not the same as TCP window size. TCP window size gets set at the application layer, not at the routing layer. If you want to change window size then you should change it on the machine sending the data. (correct me if I'm wrong, I'm just going off what I googled)

It would be nice to be able to mangle / firewall based on window size (< > =) however. Botnets seem to use a window size of 0 when they are doing specific smtp badness, and filtering them by looking for tcp/25 with a window size of 0 is an excellent method to kill zombie spam.

Sam

The RFC indicates that TCP Window Scaling occurs at the transport layer. Makes sense to me since it's a transport layer protcol...

The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header

Cisco also has useful informationregarding the option.

Window Scaling is in addition to the existing MSS method.

If you want to change window size then you should change it on the machine sending the data

Okay, this means if I use a http or web proxy on the RouterOS, I need to change the window size on the RouterOS system, right?.

This is in contrast to the usual firewall filtering which only 'forwards' packtes.

So, the question remains valid for me: If I use a TCP service on the RouterOS (e.g. Bandwidth test or web/http proxy), how do I change the tcp window size?

Thanks for more insights here.

Achim

You cannot change the TCP window size on RouterOS.

/Henrik

This can be done with IPTables in Linux. It should be rather easy to incorporate it into the mangle rules in Mikrotik. This would be extremely handy for a simple mechanism for optimizing traffic over WAN links.

https://serverfault.com/questions/52806 ... m-iptables

This can be done with IPTables in Linux. It should be rather easy to incorporate it into the mangle rules in Mikrotik. This would be extremely handy for a simple mechanism for optimizing traffic over WAN links.

https://serverfault.com/questions/52806 ... m-iptables

Why?

You are not downloading/uploading to the router, you are downloading/uploading through the router, i.e. any adjustments to TCP Window Size should be made at the endpoints, i.e. Windows PC, etc

@CZFan
I agree this would be great for helping with long fat links, It was mentioned that the feature would be great to have in the magle table which would be used to modify traffic transiting the router.
This can be a really great tweak for traffic over links where the bandwidth delay product becomes the limiting factor.
Anyway +1 from me for this feature.
Far more valuable than the SMB feature which was added.

I don't think it's safe for a device somewhere in the middle to mangle TCP window size. Most of the time it would probably work all right, but there's a chance to break connection badly. TCP window size has something to do with receiver's buffer size as receiver must potentially buffer whole TCP window size of data in case of retransmissions or out-of-order delivery. I guess that if receiver received more data than expected, then anything could happen.

TCP window size is dynamic thing and ideally it should grow as needed (it just takes some time). If it doesn't, then client's and/or server's TCP stack needs to be fixed.

Of course a mangle rule in the forward chain should only LOWER the window size in TCP packets being forwarded,
never increase it. It is like the adjust-mss action, which should also only LOWER the mss.
I don't think any bad effects could result from lowering the window size in a forwarded packet.
But it could be beneficial, e.g. when trying to give many TCP connections a fair share of the bandwidth on a slow connection.

Of course a mangle rule in the forward chain should only LOWER the window size in TCP packets being forwarded,
never increase it. It is like the adjust-mss action, which should also only LOWER the mss.
I don't think any bad effects could result from lowering the window size in a forwarded packet.
But it could be beneficial, e.g. when trying to give many TCP connections a fair share of the bandwidth on a slow connection.

Agree. But that's not what I think OP and @jerico99 wanted to achieve. I guess they wanted to boost speed of single TCP connections which suffer from long delays and for that window size would need to be increased. Which is a bad thing.

@mkx & pe1chl
Changing the TCP window size up/ increasing isn't always a bad thing,
My first point is to agree that the end point hosts should be setting the window to help fill the pipe regardless of latency however I've recently been working on resolving an issue where bandwidth delay product was causing a limiting factor and windows was not scaling the tcp window properly. As a result a transatlantic connection on an MPLS cloud as topping out at @~13Mbps when the smallest link in path being 100Mbps. Along with things like de duplication and scaling the TCP window larger a wan optimizer was a huge help. I don't like these devices as they can complicate troubleshooting no end. However if I was able to create a rule that says to this destination if the advertised window is less then x add a fixed amount rather or set it to a fixed value. YES this would still have potential to over run the host when receiving data however at that point you would start to see dropped frames and the receiver could always advertise a Zero window to indicate the buffer is full.
I don't think MT should look at deduplication but the ability to manipulate TCP windows would be a great help. However it's a fine tuning tool with great power and thus really does mean the engineer needs to understand what it is going to do and to use it for very selective cases. One point to note is that it would really need the ability to associate a buffer with the Window adjust rule to help prevent over run.
I end this by agreeing YES the end hosts should be doing this, TCP is designed to be end to end but when the hosts don't scale the tcp window correctly we have to step in somewhere.

In most production situations (i.e. the normal mix of several sessions through the same links and routers), throughput
is helped more by decreasing TCP window size than by increasing it! This is because you avoid hitting the point
where packets are dropped due to overload and everything just keeps flowing. Most systems rather have too large
pipelines than too small ("buffer bloat").

Ridiculously large windows are mainly useful for benchmark tests where someone thinks he can measure the speed
of the link by pushing a single TCP session through it. That is not a realistic situation, but when they want to do that
they should use a modern TCP stack which can use those ridiculous windows using windows scaling option.

The reason people want changes like this is that they are looking too much at benchmarks and they are following
website authors that do the same. The original designers of TCP and those that have long experience in it know
that it is not a good idea.

Hi pe1chl,
All valid points, I was just saying there are cases where actually increasing the window size is helpful, Yes you put other connections on the link at risk, As I pointed out such a feature would have to be used on very carefully assessed basis. Unfortunately the case I was stuck with was CIFS /SMB performance for a small office where the same person was the main user of the link. I wasn't suggesting that ridiculously large windows should be used. TCP flow control works damn well. I'm just saying when the Operating systems weren't doing TCP scaling correctly it would be help to have this as a work around, The Ideal solution is to have the hosts do window sizing correctly.
I'm not out to troll or argue here I'm just saying this would be a handy feature if used with care.
Let me ask you pe1chl how would you solve a problem with CIFS/SMB being complained about as unusablely slow where it's maxing out at BDP?
I realise there are options like windows DFS to have local copies and that was explored but didn't fit the work flow, A change of work flow was examined and there is discussion going on around that now to make the end product a nicer fix for all, But since you as saying that messing with TCP windows is a bad thing and should only be decreased I'd like your input / Idea. Maybe I'm missing a trick or something so I would like to open the floor to suggestions around such a use case. as it is a real life case.
Cheers
Mark

CIFS is normally used on Windows and sometimes on Linux (SAMBA) and in both cases the parameters like window size
are perfectly configurable on the end systems, where it is the best place to do it.
However, as far as I am aware (I did not study the latest CIFS as e.g. used on Windows 10) the main problem with CIFS
(and other network filesystems) is not the TCP window size, but the request size over the network. When reading an entire
file over the network, it is normally read in comparatively small chunks that have to be entirely received before a next read
command is sent. So you typically observe sequences like:
->> OPEN file aaaaa
<<- OK
->> READ x bytes
<<- x bytes of DATA
->> READ x bytes
<<- x bytes of DATA
etc.
Of course the roundtrip time of the connection makes this slow when x is relatively small compared to the connection rate.
And the TCP window size is probably already larger than x.

Protocols like FTP, RSYNC, SCP etc are much more efficient because they use a sequence like:
->> READ file aaaaa
<<- entire file aaaaa as DATA
So then the TCP window becomes the determining factor. And still, when there are many users doing the same kind of
operation in parallel it may still be better to limit each connection window so others get a chance as well. Especially when
"fair queueing" is not configured on the interfaces so a burst of data from a single TCP session passes in its entirety
before any other user on the link gets a chance.

A you note, making local cached or synchronized copies of the file can be more efficient, but is not always practical.
Some protocols (like RSYNC) are more efficient at keeping the copies, but when the file changes too frequently it becomes
impractical. In that case it is sometimes a possibility to run the application remotely (where the data resides) and send
the output over the connection (RDP, Citrix, web application).

He Pe1chl
I'm aware of CIFS chattyness being a pain over high latency/long links, And O if I could have just told them to use something like ftp or SFTP I really would have.
As for RDP/Citrix well that's part of the problem, The person was generating huge data set's on a remote machine but needed to finish processing locally.
Ultimately this is a work flow problem and such things can only be worked around by technology / engineers tweaking things. In this case the bandwidth was
being limited to BDP as calculated. The latest version of CIFS 3.x from our friends in microsoft have introduced CIFS multichannel which seems to be another way of working
around the issue it looks like it's opening multiple parallel connections(Note I haven't read all all the doc's just glanced at it, there is probably some requirements to this that I'm not accounting for I have just misread things). Windows setting TCP window sizes seems to be hit or miss really I'm very open to the possibility I was doing it wrong.
Anyway this has been an interesting conversation, I still think it would be a helpful feature but one that must be used with great care. Yea sure you'll have people who don't understand how sliding windows work messing up their connection big woop. Like all advanced features if used correctly It could be one of those features to get you out of a tight spot.
This has been an interesting chat on the feature suggestion / idea thank you for that Let me put it this way I still believe this would be more helpful than the time MT have spent adding a CIFS server to router os, What next rather than fixing BGP being a single core process are they going to add a torrent client in ROS 7. :O shuddering at the thought of this.
Before any such things I really wish MT would actually focus on stuff that matters like the cpu limitation of BGP process.