Trouble with Traffic Shaping



  • Hi Guys,

    Just installed pfSense a couple days ago and I'm trying to dive into the Traffic Shaping feature.  I'm having trouble getting the rules I apply to actually work.  Right now, when I use the wizard, everything it says it is going to do seems to happen.  My trouble comes from the fact that I can't seem to make the queues work.  This is compounded by the fact that BitTorrent seems to use a lot of different ports even if I tell it to use a specific one.  I was thinking I could use a white-list type of setup and assume all traffic is BitTorrent unless I say it isn't.  I'm okay with this, but I need to get the queues working first. EDIT:  I got all BitTorrent traffic flowing through a single port, but this doesn't really change the problem.  I can't seem to get BT to give up bandwidth once it's taken hold of it.  All the traffic is in the right queue, just not getting shut down like I think it should.

    For testing purposes, I have this setup currently:

    WAN
    …qInternet (HFSC 768kbit)
    ......qAck (Priority 6 20%)
    ......qWeb (Priority 7 50%) - Real time m2: 50% - Port 80 has a rule to come here
    ......qP2P (Priority 1 10%)

    LAN
    ...qInternet (HFSC 9.8mbit)
    ......qAck (Priority 6 20%)
    ......qWeb (Priority 7 50%) - Real time m2: 50% - Port 80 has a rule to come here
    ......qP2P (Priority 1 10% Default)

    Basically what I would expect this to do is give me a guaranteed 4.9mbit on the qWeb queue.  What actually happens is the qP2P sucks up all the bandwidth and no queueing actually takes place.  I can see it getting funneled to the correct queues in pftop, but the qlength never goes above 0.

    If I set the qP2P upperlimit m2 to 10%, everything functions like I would expect (only 10% bandwidth on everything but port 80 which gets the remaining 90%).  What I ultimately want to have happen is for qP2P to have access to 100% of the bandwidth until something else wants it.  When that happens, I want qP2P to give it up and have the other queue get it.  In my head, I see this as 100% bandwidth usage in uTorrent until I download something on port 80.  When I download something on port 80, it gets 100% and uTorrent gets 0%.

    Can this be done?  If so, what am I missing?



  • HFSC doesn't actually have any sense of priority, that is just a GUI mistake.  So one queue doesn't really have any more priority than any other, except if a queue is marked as realtime, but that was designed for low latency stuff like voip, things that are not necessarily high bandwidth, they just need low latency.

    The other problem is that bittorrent traffic is so ill-manered, it is hard to control.  Since bittorrent traffic is usually made up of hundreds/thousands of separate longer lasting and short lasting flows/sessions it doesn't react quickly to packet drops, which is the only way that a pfsense router can try to shape the incoming traffic, by dropping packets that have already made it to you, to try to get the sender to back off.  TCP/IP is supposed to back off it's transmit rate when packet loss is detected, but that doesn't work so well when there are 100 different connections that need to back off, and it doesn't happen instantly.

    Web traffic on the other hand is made up of numerous short lived connections.  So when you view a web page there is a flurry of activity grabbing the different elements, and then it is done (internet video is obviously not like this of course).  So when you try to view a web page PFSense will try to slow down the bittorrent traffic, but it takes longer to slow it down than it takes for the web page to load.

    Add into this the bufferbloat problem with most consumer grade network equipment, which just makes it worse since the tcp/ip backoff takes even longer with there are multiple seconds of packets buffered.

    My suggestion is to just limit your torrent bandwidth to %40-%50 percent of your total bandwidth.  Game of thrones.. I mean your legal linux ISO's will still download in a reasonable amount of time, and other traffic will remain responsive.  Plus your ISP won't hate you as much (you should also consider not torrenting during prime time 6pm-midnight, which your ISP will again appreciate.)

    You could also try the priority queuing shaping method, that actually does use priority, but it still won't be perfect.  Oh and one other person reported that making the p2p queue really huge, like 2000-3000 packets helped control bittorrent better… but I don't remember if that can be done from the GUI.

    There aught to be a FAQ on this.

    Oh and as far as I know, I think I know what I'm talking about, but I'm always happy to be corrected.
    Josh


Log in to reply