1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

HELP! QoS for VPN client connections problem...

Discussion in 'Tomato Firmware' started by volenin, Aug 29, 2009.

  1. volenin

    volenin Addicted to LI Member


    I'm running Tomato 1.25 on Linksys WRT54G router. I'm running into the following problem: when a server on my internal network ('EAGLE') is running a bit torrent client (TransmissionBT under Ubuntu 8.04.2), the VPN connection initiated from my notebook ('KOSHKA') is grinding to a complete halt (to be exact, the Windows Remote Desktop session that runs over a VPN connection). Again, the termination point of the VPN is NOT on the Router (I'm running unmodded Tomato, so no VPN client option there), but on my notebook which is on my internal network.

    The BitTorrent connections (from 'EAGLE' server) are assigned to the Lowest class (in fact, to simplify the setup and minimize CPU utilization on the router, ALL connections from the server running BT client are being casted into the Lowest class). ALL connections from my Notebook ('KOSHKA' server) are in the 'High' class. On top of it, I put, just in case, the rules for the 'VPN' connections themselves based on the 'virtual' MAC addressed acquired by the VPN client, again, into the 'High' class.

    Alas, none of the above helps. I do see that all connections from the 'server' are moved properly to the 'lowest' category, all connections from the 'notebook' - to the high. Nevertheless, all VPN connections initiated from the notebook are very slow (the Remote Desktop session actually times out).

    If I stop the bittorrent client, VPN connection works fast... I'm limiting number of maximum number of 'peers' on the BT client to 300, so I don't think the router is really being overwhelmed with connections...

    Any ideas how this problem can be rectified? Pls see the excerpts from router setup in the attachments.

    Attached Files:

  2. Rafatk

    Rafatk Network Guru Member

    Try putting GRE protocol on HIGH in QoS rule, and check if that works.
  3. Toastman

    Toastman Super Moderator Staff Member Member

    Volenin, look for other recent posts where people have exactly the same problem, for example
    and then read the QOS thread below for more information.

    The basic problem is you are allowing P2P class to use 75% of your upload bandwidth, which will swamp your router with returning P2P traffic. Try setting to 1% rate and no more than 10% limit ands see if that helps. In addition, the method you are using to identify and clasify P2P traffic (by the default tomato QOS rules) has long been proved not to be effective, use of a default class to trap anything not *specifically* covered by another rule works better.

    Also, what is your ISP speed? Your outgoing max limit seems rather high, I am guessing you have a nominal 512/10,000 line? If that is so, QOS will not be working properly. You need to set your max limit to no more than 85% of the MAXIMUM speed you ever measure on your uplink. Normally I would expect that to be around 350k. You will usually find VOIP to be much improved by setting maximum INCOMING bandwidth limit to around 60% of maximum.
  4. volenin

    volenin Addicted to LI Member

    Thanks for a quick reply... I did try to search the forum for 'VPN' specific issues, but it didn't return any results. I'll check the thread that you mentioned - thanks for the link.

    The claimed download/upload bandwith with my provider is 10M / 512K. The 'real' one as measured by speedtest is around 9.8M / 495K and is quite consistent between measurements.

    I do not experience any problem whatsoever with VOIP - the VOIP test shows quality of connection to be consistent and around 4.0 - 4.1, 9 out of 10 times, with BitTorrent client running heavily at the same time. I wonder though why limiting the incoming bandwidth would improve the quality of VoIP traffic... What you are saying, is to put for the 'Voip' class (eg, Class A) the limit on the 'download' bandwidth (which in my case will be 6M)...?

    I'll try your suggestion of limiting the upload bandwidth further though for the P2P connection. I was thinking though that given my QoS settings, the 'High' class should get AT LEAST 75% of all available upload bandwidth, thus bringing any other traffic (including the one in the 'Lowest' class, ie P2P) to the minimum numbers.... Doesn't it work like that?

    As for using the 'default TOMATO rules' to identify the P2P traffic, I'm actually setting the explicit rule for that - the 'EAGLE' server runs the BT client and all traffic from and to that MAC should be casted to the LOWEST class (and the Tomato 'Graph' and 'Details' connection graphs show that that really seems to be true...)

    As for the 'GRE' protocol, again, I was assuming that doing the QoS based on the MAC or IP address, all protocols included, should handle that... Or this is some known thing with Tomato that filtering by protocol works better?

    Thanks for all suggestions!
  5. Toastman

    Toastman Super Moderator Staff Member Member

    Hi Volenin

    OK, so your max outgoing speed is 495 by measurement. If that is consistent all day every day, then we'll work on that. Now you need to change the QOS MAX BANDWIDTH setting to 85% of 495 = 420. I'd set it to 400 personally. If you don't, then QOS will not work properly under all conditions. QOS works better as the setting reduces, but at the same time that reduction also takes away from your upload capability. You have to compromise. I find 85% is OK, 70% is even better, etc. - but 90% does not work so well for me. Our actual speeds here vary considerably at different times of the day and week, and the lowest figure *must* be used or during the bad periods or the QOS simply doesn't have any free uplink bandwidth to work with.

    re. the P2P classification:

    I always assume rules should apply to all clients, any of which could run P2P, since in my buildings I never have any control over what applications run on a particular computer. But in general, the point is that the different method actually helps you in many more ways. Setting a default class (lets say D) and then allowing anything not covered by a specific rule to BYPASS those rules and end up in D means that things you never even knew existed will end up in D class - you don't have to make complex rules for them or use the largely ineffective and slow L7/IPP2P filters.

    So, I didn't notice the explicit use of MAc for the "eagle" server for the P2P. Sorry. I was just looking at the 1024-65535 being assigned to the P2P class. So that line wouldn't be necessary at all, because all of it would have ended up in the default class anyway - you see?

    Don't forget that rules apply from top to bottom. As that "eagle" server is almost at the bottom of your list, ports like 80, 443 etc will use the rules above. Similarly, the other laptops will have much of their services trapped by the rules above - WWW etc,. If you really want everything on those machines to be prioritized completely, then they should be at the top of the list.

    The limit on incoming bandwidth (for use with VOIP, (VPN?) etc) is to ensure that there is sufficient bandwidth available for incoming VOIP (VPN?) etc packets. It is the overall max bandwidth, or Inbound limit, not that just for VOIP or a class. It is a conclusion of several studies that have been done by research organizations and router manufacturers, and several tables exist to show the result. The one I show in the QOS thread is the easiest to understand. But that figure as a percentage is best used for cable systems, but in ADSL the situation does become less critical as your incoming bandwidth is higher, but the outgoing is usually limited to something quite small. Most of the original tests were done with 2Mbps downlinks. But it's a figure to start from and work upwards until things begin to hiccup. 80% seems to work OK here with 6 and 8Mbps downlinks.

    QOS works better with Ports, MAC or IP addresses, the protocol filters in general don't always work. What you're doing is fine.

    Well, it does and it doesn't :biggrin:

    Imagine this scenario - I have a P2P session going, let's assume a typical Toastman session - 50+ movies and stuff running at 4Mbps+ incoming data. The outgoing transmit buffers will be full of P2P and probably incoming data is also hovering at or around the limit, often P2P comes in huge bursts when several servers just happen to send all at the same time. Therefore, some traffic will quite likely be queued at the ISP waiting to be sent to the router. NOW - Imagine that I start up a http session. It may have a priority, but before it can even get out to the web it has to wait for a space in the transmit buffer. Tomato will dynamically adjust the rate and limit to ensure that it will get the priority and bandwidth allocated to WWW - BUT it will take some time to do so. Now think about the reply from the remote HTTP server. It receives the request I sent it to view a web page - it's already been delayed, but now the reply is also stuck behind all of the P2P in the queue at the ISP. Initially it will time out, the server will back off and resend, the HTTP session will be very slow to respond. It may take several seconds to sort itself out as there follows a period of "bouncing around" until things stabilize. However, just as they do so, a load of P2P sessions will have closed and others will open and these also have to stabilize. More bouncing around. You see the problem? The goalposts are continually moving, and the worst offender is P2P of course. While all this is happening, those classes HIGH etc. are not truly getting the allocation you thought. Everything is in a state of flux. To prevent most of this, we can place a limit on "incoming max bandwidth" which uses TCP/IP protocol backoff stategies to ensure that the incoming bandwidth does not get saturated. This is one of the reasons for the "60%" figure referred to above. The other thing that is absolutely necessary is to limit the amount of outgoing traffic that P2P can send. Hence the 1% rate and 10% limit for the P2P class.

    Also, a tip. When you change something, don't think in terms of a 1% or 2% change. You won't notice anything changing. Think in terms of 5% - 10% jumps and then watch the result over a reasonable time period.

    My explanation is a bit wanting - but I hope it gets across what I wanted to say (??). This "QOS" system isn't something that can be precisely defined, everything affects everything else, it takes time to happen, and it's not perfect. And it does need a lot of thought.

    Whether this stuff applies to your VPN depends on what level of traffic is inside it, I guess. I don't use VPN at all. But I'm trying to think of anything that might be responsible and hope that you can pick up on anything that seems relevant.

Share This Page