Community discussions

MikroTik App
 
KimC
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 94
Joined: Sun Jun 06, 2004 3:16 pm
Location: Denmark

A better QOS approach - or how to control Bittorrent

Sun Mar 07, 2010 11:35 am

Hello friends

For every larger scale WISP, one of the biggest problems is the allways improving Bittorrent with encrypted protocols etc. The Mikrotik "all-p2p" is not powerfull enough to do the job. And if you don't handle this problem, you often see entire cells totally dominated by one or two users communicating with "the entire internet", effectively leaving all the reamining users on the cell off-line.

We have been figthing this problem for a long time, and I believe that we have found a better way, which I would like to share with you. Here are some tips, that should get you started:

Generally:
- Use central traffic identification on your powerfull main router (or on a bridged shaper on your uplink).
- On the shaper you need to mark all known p2p-connections. Then add all external adresses to a dynamic address-list (experiment with time-out for memory/performance reasons).
- Use the address-list to mark your local p2p-traffic, as it represents all known p2p-destinations (if you analyze BT-traffic, you always detect some un-encrypted packets in the beginning of a session).
- Use four priority levels (voip, surf with limited conn-bytes, best effort and p2p)
- Use DSCP-tagging on all traffic, and make sure that TOS=0 goes into "best effort". You allways tend to forget some traffic ;-)
- On all local equipment, you must use the DSCP-tags to mark the four traffic categories in order to queue them correctly

On the local routers with AP, you
- Create dynamic address lists for voip-destinations and p2p-users.
- Create your normal queues, but make the p2p-type more restrictive (very limited upload and a reasonable download)
- If a local user receives p2p-traffic, add him to the p2p address-list.
- All traffic to/from p2p-users is going through the restricted p2p-queue, except their voip-traffic
- Upload traffic is tagged and queued as follows:
- Voip as voip (use the DSCP info you already have through your address-list and the download traffic)
- P2P as P2P (all traffic except voip from your p2p-users)
- Surf upload from known surf-connections (via DSCP)
- The rest as best-effort

As a result, you are in control again. If a user starts using p2p, it is most likely identified quickly, as all the other known p2p-users are "telling" about the new p2p-user via the central address-list. The local p2p-user is effectively controlled the way you like. When the user quits his p2p-program, he will be "released" according to the time-out on the local p2p-users address-list.

And most important - if a p2p-user is calling support about his lower quality connection, you just give him the truth: He can use p2p as much as he wants, but when he does, the upload will be very restricted. As soon as he quits, his internet will be as good as his neighbors... and they need to be able to watch tv, speak on their phones etc...

And finally: The above is the key to have a well functioning QOS on the low-power Mikrotik gear we all loves. Let the hard work be done on an appropriate sized main router, and let the easy tasks be done locally.

I hope, that the above will help you to implement a better QOS ! Please don't beg for configurations - you will not get them from me, as I believe in "understanding before implementing".

Best regards
Kim
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: A better QOS approach - or how to control Bittorrent

Thu Mar 11, 2010 5:11 pm

Thanks, nice article. maybe you should add it to Wiki? forum posts are disappearing in time...
 
Muqatil
Trainer
Trainer
Posts: 573
Joined: Mon Mar 03, 2008 1:03 pm
Location: London - UK
Contact:

Re: A better QOS approach - or how to control Bittorrent

Thu Mar 11, 2010 7:26 pm

I am already using this type of QoS and i can confirm it works fine.
Good Article!
 
GREG3f
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Wed Dec 03, 2008 9:52 pm

Re: A better QOS approach - or how to control Bittorrent

Tue May 04, 2010 5:47 pm

I have found the following firewall rules to help enormously with P2P users on our wireless network...
chain=forward action=add-src-to-address-list protocol=tcp src-address=216.58.0.0/16 src-address-list=!bypass address-list=too-many-connections address-list-timeout=5m dst-port=1025-65535 connection-limit=20,32 time=7h-22h,sun,mon,tue,wed,thu,fri,sat 

chain=forward action=drop protocol=tcp src-address-list=too-many-connections dst-port=1025-65535 connection-limit=15,32 

chain=forward action=drop protocol=udp src-address-list=too-many-connections dst-port=1025-65535 limit=10/1m,3 

chain=forward action=drop protocol=tcp dst-port=1025-65535 connection-limit=50,32 

chain=forward action=drop protocol=udp dst-port=1025-65535 limit=30/1m,10 
Simply create an address list called bypass and enter any IPs you trust that may need more connections.

Of course this does not help with the lower ports, but it will significantly help with most P2P users. We have found that the main is not the bandwidth, but the number of connections created at a single tower.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3119
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: A better QOS approach - or how to control Bittorrent

Fri May 07, 2010 2:49 am

I have found the following firewall rules to help enormously with P2P users on our wireless network...
chain=forward action=add-src-to-address-list protocol=tcp src-address=216.58.0.0/16 src-address-list=!bypass address-list=too-many-connections address-list-timeout=5m dst-port=1025-65535 connection-limit=20,32 time=7h-22h,sun,mon,tue,wed,thu,fri,sat 

chain=forward action=drop protocol=tcp src-address-list=too-many-connections dst-port=1025-65535 connection-limit=15,32 

chain=forward action=drop protocol=udp src-address-list=too-many-connections dst-port=1025-65535 limit=10/1m,3 

chain=forward action=drop protocol=tcp dst-port=1025-65535 connection-limit=50,32 

chain=forward action=drop protocol=udp dst-port=1025-65535 limit=30/1m,10 
Tried this on a real user that has many, many connections running. But mostly udp. Max I counted in torch at one moment was 35
But never more then 10 tcp connections.

I enabled these rules for user's network and looked what happened. Well, nothing....
Ok, only little amount of tcp connections, so I triggered the "too-many-connections" address list listing by setting tcp temporarily for 1 connection.
Ok, now users address became listed. I set the previous rule back to example and watched what happens. Nothing again.
Although I see an occasional udp package drop because the limit makes it drop, the the amount of short lived udp connection stays there.
I peeked in the main gateway conn tracker and saw more then 170 udp connections listed for this specific user!
All these connections were time updated all the time meaning they were maintained!

In the AP this client runs over I deleted all conn. tracker connections for this client and immediately after this client build some 100 new connections, most of them udp, again! With these rules applied.
So for me it sounds it is not really working...
Only the tcp connections will be limited, udp not because it is actually impossible for router to do so.
 
GREG3f
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Wed Dec 03, 2008 9:52 pm

Re: A better QOS approach - or how to control Bittorrent

Fri May 07, 2010 3:37 am

Correct, it is almost impossible to limit UDP because it is a connectionless protocol.

However I have found most issues with tower stability to be caused by TCP connections. As an example try pinging a client on your ap while running a bandwidth test with only one connection... ping times will slowdown while testing... now try the same test with 20 connections... ping times get very long and even start to timeout. Now when P2P runs with 100's of connections, no one can get any decent connections. The above script seems to keep the tcp connections in check and the tower running smoothly. If you want to slow down a client who has to many UDP connections, try placing them in a queue and slow em down. I always found that even slowing down someone to 500k with 50 plus TCP connections, the still influenced the tower.

Who is online

Users browsing this forum: A9691, AshuGite, AtisE, Bing [Bot], sebus46, VinceKalloe and 81 guests