Quality of Service

RouterOS General
1

I have setup some mangle rules to mark packets, specifically P2P packets.

We plan to implement some more packet marking to mark VoIP packets to give them higher priority. Not sure yet how to do this. Any input on this greatly appreciated.

I am attaching a picture of my mangle rules with good descriptions. Assuming everything that you cant see is right, are these in the right order to get the desired reaction?
mangle.JPG

2

Hi. About P2P, you need to look into this topic http://forum.mikrotik.com/t/how-block-connection-of-p2p/18495/1 About VoIP (SIP), I guess you need to catch RTP packets. So L7 filter is better to mark SIP RTP packets http://l7-filter.sourceforge.net/protocols

3

Only problem is, we are an ISP. Comcast has been sued for blocking things like p2p.

We are not wanting to block it, just to traffic shape it and give it lower priority than “normal” traffic.

4

I understand. If you can mark P2P traffics successful, you can do any action block or set priority. I believe you can find solution from the topic, which I posted.

5

With the current state of encrypted bittorrent, there is no tracking it specifically. The traffic is explicitly designed to avoid being filtered and throttled.

Here are some hard facts on shaping p2p traffic:

  • Older p2p like kazaa and eDonkey respond well to the p2p l7 filter
  • The L7 bittorrent filter in the wiki and forums only flags Tracker activity
  • Even if the tracker is blocked, DHT/UTP allows bittorrent peers to exchange host info
  • The L7 filter does not flag DHT/UTP, use DNS to block if needed.
  • The L7 filter does not flag bittorrent peer transfers (the actual bulk data)
  • Bittorrent peer transfers are usually encrypted and designed to not be tracked
  • Even when encrypted well, bittorrent still “leaks” detectable packets periodically
  • Peer transfers are primarily UDP connections, but will fail over to TCP
  • UDP transfers do not respond to standard QoS (UDP lacks flow-control, it is left up to the application)

From this, the best non-blocking approach I have come up with for handling p2p traffic is as follows:
Whitelist - Detect what you can (http/https, DNS, SSH, skype, games, whatever seems important) and increase its priority.

Flag p2p users - Look for the presence of p2p/bittorrent traffic from a user and add them to a dynamic address list for a preset amount of time (5-20 minutes). You will not be able to catch all the traffic, but by identifying the “leaks”, you know the traffic is coming from the user somewhere. Every time a packet flags, it should renew the address list timer.

Take secondary measures - As long as a user stays flagged, impose additional limits on them. Some examples:

  • Add a heavy non-DNS UDP connection limit - This forces udp bittorrent traffic over to TCP, where traditional QoS and packet shaping can regulate it properly (since TCP flow-control is handled by the TCP/IP stack, not the application). This may have adverse effects on video games and skype quality, but after the user closes down the p2p applications, their address list entry will time out and they will go back to normal. UDP conn limit was added in 5.7 for console, and 5.8 for WinBox.

Limit non-whitelist traffic - Add a reduced bandwidth cap for non-whitelisted traffic. Not always the best plan for ISP’s, but useful for hotspots.

Reduce non-whitelist priorty - Reduce the priority of all non-whitelisted traffic while the user is flagged.

Flag the user’s traffic - If these rules are implemented on CPE / tower equipment, add DSCP marks to non-whitelisted traffic to let your core know it has a high potential of being p2p traffic (and to reduce it’s priority if needed)

There is no real “magic bullet” for p2p (specifically because of bittorrent). They are built to bypass the exact type of throttling and limiting you are trying to impose. Also remember, you are shooting at a moving target. uTorrent 3.0 added new features that make blocking even more difficult, and the protocols keep rapidly advancing, so keep an eye on it. If you have any questions, let me know.