Peer2peer makes me want to be near2beer

YappaDappa · Thu Dec 15, 2005 11:21 am

quite frustrated....

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

cheers!

Ron

Syonyk · Fri Dec 16, 2005 10:46 pm

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.

-=Russ=-

cibernet · Tue Dec 20, 2005 2:25 am

You can try to add a simple queue to limit all-p2p to a maximun amount off bandwidth

HarvSki · Tue Dec 20, 2005 11:49 am

Which version of MT ROS are you using? 2.9 is better at p2p, well easier anyway.

andrewluck · Thu Dec 22, 2005 7:32 pm

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.

Anyone have any ideas on how to solve this?

Regards

Andrew

yancho · Thu Dec 22, 2005 9:51 pm

Limit upload... http://www.faqs.org/docs/Linux-HOWTO/AD ... HOWTO.html

Diganet · Fri Dec 23, 2005 12:07 am

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.

Anyone have any ideas on how to solve this?

Regards

Andrew

TCP adjusts automatically...

/HP

andrewluck · Fri Dec 23, 2005 10:49 pm

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. :)

Regards

Andrew

Eugene · Tue Dec 27, 2005 4:16 pm

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.

andrewluck · Mon Jan 02, 2006 9:58 pm

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.

Regards

Andrew

YappaDappa · Sun Jul 20, 2014 10:20 pm

and now, 8 years later, there is almost NO defense it seems

Peer2peer makes me want to be near2beer

Peer2peer makes me want to be near2beer

Re: Peer2peer makes me want to be near2beer

Who is online