I live 'til now without QOS. As more and more customers use Voip I’ve to change
this. As I see it’s neccessary to take some time learning and planning QOS. May
be someone is willing to accelerate my learning curve ). So please quote my
posting.
First of all I’ve to identify and classify traffic. As I’ve read here it’s the easiest/best
to use IP-Adresses of sipservers to identify sip-traffic.
I want to introduce 3 traffic classes.
High priority low latency (sip,icmp,ospf,winbox,…)
Normal traffic (web,smtp,…)
No use traffic (p2p,…)
My Idea is to make the classification once for every packet. So I want to use
TOS to mark it once when entering my network. All routers in my network along
the path can use the TOS-mark for queuing. So routers in the middle of my
network do not need to classify/mangle packets.
TOS as received with customer’s packets is not reliable. So it has to be cleared
when entering my network. (I’v done some sniffing on sip-rtp-traffic. Even there
are different TOS settings if at all).
Then I have to identify links which build bottlenecks and make a queuetree
for this interface (one on each side of the link). The queuetree has one Father
and 3 children (one for each traffic class). Each children has a different priority.
DSCP (ToS is replaced with DSCP).
DSCP should be correct way to identify different type of traffic across the network. Traffic that is going over the router and action set on out chains ‘action=change DSCP (ToS)’, the DSCP value will be changed.
So you can identify specific traffic on other router by DSCP value.
Off course mangle to mark the packets.
Queue to set the priorities (as without priorities configured by the means of router, DSCP is just value that does improve anything).
So what you are saying is that you just mark the packets using Mangle rules, then queue them using queues(tree or simple) with different priorities, correct?
Yes,
the purpose of DSCP is just another option to determine the packet.
You may call it something like ‘packet-marks’, but ‘packet-marks’ works within the same router only.
However, it is possible to identify DSCP over the network, where packets are transported.
Ok cool, I’ll roll it over at the next meeting and see what they say. Hopefully we can implement it quickly there-after and then I can give you guys feedback.
We are working on the same topic and we have pretty good resources on the backhaul side, but we not found any QoS implementation that did the job inside the backhaul side. So far, we found two principal bottlenecks: the main dedicated link and the APs.
Recent implementations on both bottlenecks we found are showing nice results. The main link QoS is very simple cuz have a fixed bandwidth and only two interfaces (pub and local) using queue tree. The endpoint QoS (Wireless AP) is more complicated and need advanced QoS implementation.
The thing that really helped us a lot was limiting tcp connections to 30 at the AP side.
). So please quote my
Hope it helps.