ok, I am having a hard time here configuring queues.
The desired result is acceptable call quality on IP phones using the SIP protocol. Without some sort of QOS, a large upload/download will make the calls unbearably choppy and ususable. Specifically, the example below is for a setup with an IP phone behind ROS on a cable modem with 6Mb/600k. All that needs done is a single large upload and the other end of the voice call can hardly make out anything that is said.
Our implementation allows us to identify the voice traffic by (public) IP and by port number. Our SIP uses UDP 5060 for session control and UDP 10000-20000 for the media stream. We have the ability to mark the voice traffic with DSCP, but we’d rather not.
I have tried simple queues, and various queue tree scenarios (using others’ posts as examples). Setting the max-limit to less than the available bandwidth helps, but does not resolve the issue under heavy traffic load. Using the SIP Helper to mark the traffic works (counters increment), but doesn’t resolve the issue.
Here’s what I have at the moment, and any assistance would be greatly appreciated.
/ip firewall mangle
add action=mark-packet chain=prerouting comment=Asterisk disabled=no \
in-interface=ether2 new-packet-mark=voice-in passthrough=no protocol=udp \
src-address=64.129.185.106
add action=mark-packet chain=postrouting comment="" disabled=no dst-address=\
64.129.185.106 new-packet-mark=voice-out out-interface=ether2 \
passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment=Non-Asterisk disabled=no \
in-interface=ether2 new-packet-mark=other-in passthrough=no
add action=mark-packet chain=postrouting comment="" disabled=no \
new-packet-mark=other-out out-interface=ether2 passthrough=no
add action=mark-packet chain=prerouting comment="Should be None!" disabled=no \
in-interface=ether2 new-packet-mark=NOMARK passthrough=no
add action=mark-packet chain=postrouting comment="" disabled=no \
new-packet-mark=NOMARK out-interface=ether2 passthrough=no
/queue type
set default kind=pfifo name=default pfifo-limit=50
set ethernet-default kind=pfifo name=ethernet-default pfifo-limit=50
set wireless-default kind=sfq name=wireless-default sfq-allot=1514 \
sfq-perturb=5
set synchronous-default kind=red name=synchronous-default red-avg-packet=1000 \
red-burst=20 red-limit=60 red-max-threshold=50 red-min-threshold=10
set hotspot-default kind=sfq name=hotspot-default sfq-allot=1514 sfq-perturb=\
5
add kind=pfifo name=voip pfifo-limit=1
set default-small kind=pfifo name=default-small pfifo-limit=10
/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=download packet-mark="" parent=global-in priority=8 \
queue=default-small
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=voice-in packet-mark=voice-in parent=download priority=1 \
queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=other-in packet-mark=other-in parent=download priority=8 \
queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=350000 name=upload packet-mark="" parent=global-out priority=8 \
queue=default-small
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=400000 \
max-limit=400000 name=voice-out packet-mark=voice-out parent=upload \
priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=other-out packet-mark=other-out parent=upload priority=8 \
queue=default
You need to assign limit-at and max-limit to all the child queues. And only max-limit to parent queues.
For example:
upload max-limit=600k
–voice limit-at=300k max-limit=550k
–other limit-at=300k max-limit=550k
download max-limit=6000k
–voice limit-at=3000k max-limit=5500k
–other limit-at=3000k max-limit=5500k
everything else is fine
(but I by my self would use mangle chain forward and interface HTB for this setup)
This exact setup was already tested with all limit-ats and max-limits set. A problem here is the internet service used - probably similar to ADSL where bandwidth is not guaranteed, IP packets get ontop of ATM cells, cells etc. are dropped when the line gets noisy etc. etc. problems. MikroTik have declined to make RouterOS compensate for this stating “it would help only home users”. And they apparantly ignore the fact that Wi-Fi is not noise-protected and all their customers would benefit.
So Yes, it turns out that QoS is just false marketing and “works only whit optic fiber and/or Ethernet with dedicated speed” should be applied to it.
This is why there are 2 limits -
“limit-at” and “max-limit”
Divide with "limit-at"s only bandwidth that you have for sure.
Let’s say we have the typical ADSL line or the coaxial cable modem that has 10Mbps down 1Mbps up. VoIP_up limit-at=555000 max-limit 666000 queue-type=pcq_up; other_up limit-at=10000 max-limit=666000 queue-type=pcq_up; their parent UploadTree limit-at=[not used?] max-liimit=677000 queue-type=default. Do you mean this by Divide with "limit-at"s only bandwidth that you have for sure. ?
Suggest the limit-ats and max-limits and queue types for download, please.
Hmm, guys, this seems like easy at first look, but in practice…
Sorry my first post had a screwed up config after screwing with the MT all night…
Here’s how it looks now:
/ip firewall mangle
add action=mark-packet chain=prerouting comment=Asterisk disabled=no \
in-interface=ether2 new-packet-mark=voice-in passthrough=no protocol=udp \
src-address=64.129.185.106
add action=mark-packet chain=postrouting comment="" disabled=no dst-address=\
64.129.185.106 new-packet-mark=voice-out out-interface=ether2 \
passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment=Non-Asterisk disabled=no \
in-interface=ether2 new-packet-mark=other-in passthrough=no
add action=mark-packet chain=postrouting comment="" disabled=no \
new-packet-mark=other-out out-interface=ether2 passthrough=no
add action=mark-packet chain=prerouting comment="Should be None!" disabled=no \
in-interface=ether2 new-packet-mark=NOMARK passthrough=no
add action=mark-packet chain=postrouting comment="" disabled=no \
new-packet-mark=NOMARK out-interface=ether2 passthrough=no
/queue type
set default kind=pfifo name=default pfifo-limit=50
set ethernet-default kind=pfifo name=ethernet-default pfifo-limit=50
set wireless-default kind=sfq name=wireless-default sfq-allot=1514 \
sfq-perturb=5
set synchronous-default kind=red name=synchronous-default red-avg-packet=1000 \
red-burst=20 red-limit=60 red-max-threshold=50 red-min-threshold=10
set hotspot-default kind=sfq name=hotspot-default sfq-allot=1514 sfq-perturb=\
5
add kind=pfifo name=smallq pfifo-limit=1
set default-small kind=pfifo name=default-small pfifo-limit=10
/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=\
99000000 max-limit=100000000 name=download packet-mark="" parent=\
global-in priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=\
99000000 max-limit=100000000 name=upload packet-mark="" parent=global-out \
priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=\
99000000 max-limit=100000000 name=voice-in packet-mark=voice-in parent=\
download priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=56000 \
max-limit=5800000 name=other-in packet-mark=other-in parent=download \
priority=8 queue=smallq
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=\
99000000 max-limit=100000000 name=voice-out packet-mark=voice-out parent=\
upload priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=56000 \
max-limit=350000 name=other-out packet-mark=other-out parent=upload \
priority=8 queue=smallq
This config does indeed work as far as policing the traffic and ensuring I have all the bandwidth reserved for voice traffic. With no voice traffic, my upload maxes out at 379k. With voice traffic, the upload goes higher and higher and even borrows bandwidth from the non-voice traffic. Very nice.
But I still have a problem with call choppiness as new (non-voice) connections are established and so I would like some feedback and/or ideas about how to troubleshoot the issue further. As an example, I establish a voice call, all is well, then I start a huge upload. The voice will “stutter” for 2-3 seconds and then is fine again even though I never hit my maximum upload speed from the ISP. If I remove the queue trees, I can sustain a steady 509k all afternoon (with absolutely unbearable voice quality).
Are you sure the Asterisk traffic is only UDP? No TCP or ICMP that could affect the call? Try removing protocol=udp from the Asterisk mangle rule.
By the way, great working with you, always supplying good information on the setup and the problem.
OK, to eliminate choppiness of the new connections we must change queue type for your voice queue.
Possibilities are:
1)SFQ - will consider all connections in this queue as equals
2)PCQ with specific classifier (src-address for upload, dst-address for download) - this will equalize clients no connections.
That’s probably not the solution. He is testing with one client (I think).
Absolutely certain we are using only UDP – SIP on 5060, RTP on 10000-20000. I did remove the UDP from the mangle rules and using only the IP address, we get the same result.
I have had some better results, but not an issue resolution, by putting the “other” traffic in a pfifo/1packet queue. The thought being that if just just drop the TCP during congestion, the TCP window will slide faster.
I have also had some positive results in mangling the outbound voice traffic with DSCP 46.
As for clients, in the test scenario posted here, I have 1 client, but I also have a customer for which I am trying to resolve this issue. The customer has a T1 connection and 6 IP phones he would like to use simultaneously while also hammering his connection. The posted configuration, adjusted for T1 bandwidth, gives similar results.
Using either PCQ or SFQ for the non-voice traffic seems to worsen the issue.
I was thinking about voice traffic