locked
TCP Window size problems RRS feed

  • Question

  • We have rented a high bandwidth low latency line between Zürich (Switzerland) and Hongkong. Through this line we have two firewalls connected via an ipsec vpn tunel. The tunel is stable and the latency is about 180 ms. The bandwidth is somehow not working properly. We have been analysing this problem for quiet some time and come to the conclusion that there is an issue with "tcp window scaling" of our window r2 2008 server, our windows 7 clients and windows 2012r2 (latter is a test system in Hongkong). Somehow it is not scaling it correctly. When testing with iperf and setting the tcp window size to about 425 we are recieving the rented bandwidth.

    We have found a hotfix which sounded like a solution but is not applicable http://support.microsoft.com/kb/983528 but somehow it is not applicable to our systems.

    Here test results from iperf no adjustment to TCP Window size

    bin/iperf.exe -c 10.150.250.157 -P 1 -i 1 -p 5001 -f m -t 10
    ------------------------------------------------------------
    Client connecting to 10.150.250.157, TCP port 5001
    TCP window size: 0.06 MByte (default)
    ------------------------------------------------------------
    [196] local 10.120.220.1 port 57117 connected with 10.150.250.157 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [196]  0.0- 1.0 sec  0.22 MBytes  1.84 Mbits/sec
    [196]  1.0- 2.0 sec  0.75 MBytes  6.29 Mbits/sec
    [196]  2.0- 3.0 sec  0.17 MBytes  1.44 Mbits/sec
    [196]  3.0- 4.0 sec  0.06 MBytes  0.52 Mbits/sec
    [196]  4.0- 5.0 sec  0.09 MBytes  0.79 Mbits/sec
    [196]  5.0- 6.0 sec  0.09 MBytes  0.72 Mbits/sec
    [196]  6.0- 7.0 sec  0.07 MBytes  0.59 Mbits/sec
    [196]  7.0- 8.0 sec  0.09 MBytes  0.79 Mbits/sec
    [196]  8.0- 9.0 sec  0.13 MBytes  1.05 Mbits/sec
    [196]  9.0-10.0 sec  0.09 MBytes  0.79 Mbits/sec
    [196]  0.0-13.6 sec  1.77 MBytes  1.09 Mbits/sec
    Done.

    I have seen this quiet often with iperf the there is rise with the second packet and it is falling down to about 1 Mbit/s.

    Friday, June 1, 2018 12:36 PM

All replies

  • Hi ,

    Thanks for your question.

    Please try the following suggestions to see if it could be of help.

    1. Check firewall settings and ensure traffic restrictions are turned off
    2. The maximum throughput of a single connection depends on:

    Bandwidth

    Send window (buffer size)

    Receive window (buffer size)

    Latency

    Network congestion

    In all recent Microsoft Windows implementations, windows scaling is enabled by default.

    You ‘ll find places on the Internet telling you to change registry values to increase your window size

    You can do that by editing the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DefaultSendWindow

    Refer to the following link:

    How to Adjust TCP Window Size to Improve Network Performance

    https://www.auvik.com/media/blog/tcp-window-size/

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Hope you have a nice day!

    Best regards!

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, June 4, 2018 9:57 AM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, June 7, 2018 10:10 AM
  • Dear Travis

    Thank you very much for your fast and detailed answer.

    As written in my question: "...When testing with iperf and setting the tcp window size to about 425 we are recieving the rented bandwidth..." So we do not think it can be an issue with the firewall. Actually we had very intense contact with the vendor of the firewall for a few weeks looking in details if our configurations are correct.

    Thank you for the link but as you have written yourself the windows scalling is enabled in all recent Microsoft versions so it makes no sense to change the TCP-Window-Size.

    As we have rented a line from Zürich to HK there should be not much "congestion" possible.

    Please note that we have been testing/analysing the problem for quiet some time and have seen that the bandwidth is possible when using a TCP windows size of 425 when using Iperf. The provider of the line has also done some tests with his linux system and had no problem on the line.

    What is also interesting is that when testing the line with UDP we have no problems to achieve the bandwidth.

    Do you have any suggestions what we could do to solve this problem?

    Best Reagards



    Friday, June 15, 2018 11:52 AM
  • Hi,

    Thanks for your reply.

    TCP is a data transport protocol designed for reliable delivery of data end-to-end. The cost for the reliable delivery of data is loss in goodput in contrast to UDP which does not guarantee delivery as the expense of throughput.So usually UDP transmission rate is faster than TCP .

    • TCP is directly impacted by latency

           TCP is a more complex protocol as it integrates a mechanism which checks that all packets are correctly delivered. This mechanism is called acknowledgment: it consists of having the receiver transmit a specific packet or flag to the sender to confirm the proper reception of a packet.

    When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.

    • TCP is impacted by retransmission and packet loss

           Packets will need to be retransmitted (even if only the acknowledgment packet got lost and the packets got delivered).

           The TCP congestion window size will not permit an optimal throughput.

    So we can modify the following parameters to improve performance(The TCP features can be changed by changing the entries in the registry):TCP window size, Windows scaling, Timestamps, Protection against Wrapped Sequence Numbers (PAWS), Selective Acknowledgements (SACKs), TCP retransmission behavior and fast retransmit.

    Specific operation please refer to the following link:

    https://support.microsoft.com/en-us/help/224829/description-of-windows-2000-and-windows-server-2003-tcp-features

    Hope you have a nice day!

    Best regards,

    Travis 




    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, June 19, 2018 6:34 AM
  • I just wanted to add a note here that I have just discovered that currently, iPerf3 v3.1.3 for Windows comes bundled with a version of Cygwin1.dll (2.5.1) which has a hard-coded TCP window size setting of 278,775.

    This causes results to be limited to 12.6Mb/s per thread.

    This is why iPerf speeds in Linux are much better that in Windows.

    Updating the Cygwin dll to the latest version resolves this issue.

    I have informed the iPerf devs of this issue.

    Thanks to the Argon Systems article which directed me to this line of inquiry!
    https://argonsys.com/microsoft-cloud/library/windows-network-performance-suffering-from-bad-buffering

    • Proposed as answer by akshaymus Thursday, February 13, 2020 4:36 AM
    Sunday, June 9, 2019 8:42 AM
  • This is such a helpful observation, this issue led me astray in diagnosing some issues for such a long time, thank you for posting this. 
    Thursday, February 13, 2020 4:37 AM
  • No problem!  I'm glad that it helped someone else!
    Thursday, February 13, 2020 4:48 AM