I love the MT platform. Literally saved my WISP operation with it’s highly affordable and practicle features. However, I can’t seem to get P2P filter working correctly. Specifically Bit Torrent. I don’t want to kill it. I feel my customers can use these programs, but as long as the this type of traffic is low priority, and severely rate-limited (but not blocked). Can anyone share their experiences here with 2.9.x and P2P filtering? If you got it working with these conditions, do you mind explaining? I tried the mangler several version ago, and it just sent my CPU usage to 100 on one single connection
BitTorrent is rough to filter, because it’s so many connections at once.
You should just be able to use the P2P mangle rule to mark packets, and set up a queue tree entry to set them to priority 8 (low priority), and restrict them to a given bandwidth. That’s what we do on our network.
One thing’s puzzling me about bandwidth limiting. You can only throttle and prioritise traffic leaving the router. So, how do I limit an individual user or application with the traffic that’s inbound to my network from my ISP when I have no control over what is happening at the remote end of the dsl link?
My understanding is that I can rate limit the traffic as it comes into my network from the MT. But, at this point, the traffic has already crossed the bandwidth constrained dsl link. If I start dropping packets in an attempt to control the sending rate then those dropped packets will need to cross the dsl link again and available bandwidth will be reduced.
Thanks for the link to the Linux-howto page. I’d already given that some detailed study. It’s main aim is reducing latency of interactive sessions and not bandwidth control as such. I guess my question was rather loaded as I’m seeing a lot of posts here with people trying to limit P2P downloading and wondering why it doesn’t work as they expect. Just trying to provoke some discussion here and assure myself that I haven’t missed something obvious.
This explains how the TCP congestion control mechanism works:
What is this TCP Window Thing?
A TCP window the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it gets an acknowledgment back from the receiver that it has gotten some of it.
For example if a pair of hosts are talking over a TCP connection that has a TCP window size of 64 KB (kilobytes), the sender can only send 64 KB of data and then it must stop and wait for an acknowledgment from the receiver that some or all of the data has been received. If the receiver acknowledges that all the data has been received then the sender is free to send another 64 KB. If the sender gets back an acknowledgment from the receiver that it received the first 32 KB (which could happen if the second 32 KB was still in transit or it could happen if the second 32 KB got lost), then the sender could only send another 32 KB since it can’t have more than 64 KB of unacknowledged data outstanding (the second 32 KB of data plus the third).
Why have a TCP window?
The primary reason for the window is congestion control. The whole network connection, which consists of the hosts at both ends, the routers in between and the actual connections themselves (be they fiber, copper, satellite or whatever) will have a bottleneck somewhere that can only handle data so fast. Unless the bottleneck is the sending speed of the transmitting host, then if the transmitting occurs too fast the bottleneck will be surpassed resulting in lost data. The TCP window throttles the transmission speed down to a level where congestion and data loss do not occur.
OK. But there are two problems with doing bandwidth control this way.
1: UDP
2: You’re dropping packets to control the incoming flow rate. This inevitably means that you’re sacrificing some bandwidth for every incoming stream that you’re limiting.
I admit though, if you’ve no control over the upstream router then this is the only way of doing it.
