# Moderate incoming bandwidth for torrents.



## SchwarzerVossatka (Dec 25, 2016)

Hello. I am running torrents on a separate machine in my home network running FreeBSD 11.0-RELEASE-p5. When torrents are being downloaded with a high speed, other connections, like ordinary HTTP connections are slightly starved. For example, when I normally download a file from web site at 2 Mbyte/s, with torrents working I download the same file at 50Kbyte/s.

The only working solution is to reduce the maximum speed threshold for torrents (using dummynet, for an example). So if my port range for torrents is 44000-44015, I use the following (re1 is my network interface):

`ipfw pipe 1 config bw 1Mbyte/s
ipfw add pipe 1 tcp from any to me dst-port 44000-44015 in via re1`

This works just fine, torrents download speed reduces and HTTP download speed increases. But I am not satisfied with this solution. For example, if I have no HTTP activity, my torrent download speed is still low. I would like a solution, where HTTP has a bigger priority than torrents, so torrent speed is only decreased when I download something via HTTP.

So I've looked at weighted queues in dummynet and wrote something like this:

`ipfw pipe 1 config bw 0
ipfw sched 1 config type qfq pipe 1
ipfw queue 1 config sched 1 weight 90 mask src-ip 0xffffffff
ipfw queue 2 config sched 1 weight 10
......
ipfw add queue 2 tcp from any to me dst-port 44000-44015 in via re1
......
ipfw add queue 1 tcp from any 80 to me in via re1`

So, I as thought this creates a queue with weight 90 for every HTTP connection with every host and a queue with weight 10 for summary torrent traffic. So overall torrent traffic is no more than 10% if at least 1 HTTP connection is present. I was wrong. It passes all traffic when pipe's bw is 0 (unlimited) and acts just like the first case when it's limited to something like 1Mbyte/s.

So my question is this: Can we moderate torrent traffic without setting any restrictions to summary bandwidth for both HTTP and torrent? The idea is that torrent is getting as much bandwidth as possible, but HTTP connections must not be starved. The idea is simple but hard to formulate precisely.


----------



## gofer_touch (Dec 25, 2016)

Most torrent clients have some kind of bandwidth shaping settings within them. You can for instance cap the torrent speed to a reasonable level.


----------



## SchwarzerVossatka (Dec 25, 2016)

gofer_touch said:


> Most torrent clients have some kind of bandwidth shaping settings within them. You can for instance cap the torrent speed to a reasonable level.



Yep, they do. But they are not aware of any HTTP traffic. I want something like "dynamic" threshold, which is high when I do not downloading anything via HTTP and reasonably low when I do. Is there something as sophisticated as that?


----------



## PacketMan (Jan 2, 2017)

I don't know if FreeBSD or one of its ports can do this, but you can buy a commercial grade router like Juniper or Cisco and build a Quality of Service (QoS) policy that will give HTTP preferential treatment over bittorrent. But for home use I wouldn't waste my money. If you can get yourself the right class of router loaded with the right licensed feature set, then now you got something else fun to learn. And of course you will need to learn which QoS design and which router feature set will work for you.


----------



## chrcol (Jan 14, 2017)

FreeBSD can do it as I have traffic shaping on my pfSense unit which of course is based on FreeBSD.  I dont want to write a full guide here so to summarise.

You need to make the FreeBSD device the bottleneck so it can manipulate the traffic flows.  So e.g. setting the queue size to a lower rate than your maximum throughput.

Make multiple queues in ALTQ, at least 2 one as default and another with a higher priority level.
Route the http(s) traffic to the higher priority ALTQ queue with a firewall rule.

I should have given you enough information in this reply that can allow you to search for the specifics, if you install pfSense, this is made easier by having a GUI to configure the shaper.

Likewise you also want a ACK queue on the upstream for ACK packets to keep http snappy.


----------

