Community discussions

 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

QoS Tree VoIP problem

Mon Jan 21, 2019 10:02 am

I have a problem with voip in QoS.
When i download a heavy traffic like a pig file(s) or torrent(s) my voip have problem.
While listening to others normally, others listen to me with a break.
The upload bandwidth isnt full at that time.
I have a pppoe connection (vdsl 50/5).
I have a pbx and i use the Mikrotik sip helper for my VoIP.

My settings are:
/ip firewall mangle
add action=change-mss chain=forward in-interface=all-ppp new-mss=1452 \
    passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535
add action=change-mss chain=forward new-mss=1452 out-interface=all-ppp \
    passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535
add action=mark-packet chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-packet-mark=QoS_1-UP out-interface=all-ppp packet-mark=\
    no-mark passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment="SYN Light" \
    connection-bytes=0-10000000 new-packet-mark=QoS_2-UP out-interface=\
    all-ppp packet-mark=no-mark packet-size=0-666 passthrough=no protocol=tcp \
    tcp-flags=syn
add action=mark-packet chain=postrouting comment="ACK Light" \
    connection-bytes=0-10000000 new-packet-mark=QoS_2-UP out-interface=\
    all-ppp packet-mark=no-mark packet-size=0-123 passthrough=no protocol=tcp \
    tcp-flags=ack
add action=mark-packet chain=postrouting comment=DNS dst-port=53 \
    new-packet-mark=QoS_3-UP out-interface=all-ppp packet-mark=no-mark \
    passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment=ICMP-Echo new-packet-mark=\
    QoS_3-UP out-interface=all-ppp packet-mark=no-mark passthrough=no \
    protocol=icmp
add action=mark-packet chain=postrouting comment=NTP dst-port=123 \
    new-packet-mark=QoS_3-UP out-interface=all-ppp packet-mark=no-mark \
    passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment=Light connection-bytes=\
    0-10000000 new-packet-mark=QoS_4-UP out-interface=all-ppp packet-mark=\
    no-mark passthrough=no protocol=tcp
add action=mark-packet chain=postrouting comment=Heavy connection-bytes=\
    10000000-0 new-packet-mark=QoS_5-UP out-interface=all-ppp packet-mark=\
    no-mark passthrough=no protocol=tcp
add action=mark-packet chain=postrouting comment=Torrents new-packet-mark=\
    QoS_8-UP out-interface=all-ppp packet-mark=no-mark passthrough=no \
    protocol=udp src-port=55555
add action=mark-packet chain=postrouting comment="All others" \
    new-packet-mark=QoS_7-UP out-interface=all-ppp packet-mark=no-mark \
    passthrough=no

/queue tree
add bucket-size=0 limit-at=200k max-limit=4M name=QoS_1-UP packet-mark=\
    QoS_1-UP parent=pppoe-out1-UP priority=1 queue=fifo-UP
add bucket-size=0 limit-at=2M max-limit=4M name=QoS_2-UP packet-mark=QoS_2-UP \
    parent=pppoe-out1-UP priority=2 queue=sfq_UP
add bucket-size=0 limit-at=1M max-limit=4M name=QoS_3-UP packet-mark=QoS_3-UP \
    parent=pppoe-out1-UP priority=3 queue=sfq_UP
add bucket-size=0 limit-at=1M max-limit=4M name=QoS_4-UP packet-mark=QoS_4-UP \
    parent=pppoe-out1-UP priority=4 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_5-UP packet-mark=QoS_5-UP \
    parent=pppoe-out1-UP priority=5 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_7-UP packet-mark=QoS_7-UP \
    parent=pppoe-out1-UP priority=7 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_8-UP packet-mark=QoS_8-UP \
    parent=pppoe-out1-UP queue=sfq_UP
add bucket-size=0 limit-at=60M max-limit=60M name=pppoe-out1-DW packet-mark=\
    no-mark parent=bridge1 queue=pcq_DW
  
Where is the problem?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1783
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 11:44 am

Hey

* your tree should be a tree, not a list!

<some main queue linked to interface max=4M>
<q1 priority=1>
<q2 priority=2>
....

Currently each queue can transmit at 4M...-> no QoS

* you should also prioritise download, at least giving prio to VOIP
* don't use "bucket-size=0"
* "out-interface=all-ppp" (mangle) != "parent=pppoe-out1-UP" (queue)
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 1:56 pm

Hey

* your tree should be a tree, not a list!

<some main queue linked to interface max=4M>
<q1 priority=1>
<q2 priority=2>
....

Currently each queue can transmit at 4M...-> no QoS

* you should also prioritise download, at least giving prio to VOIP
* don't use "bucket-size=0"
* "out-interface=all-ppp" (mangle) != "parent=pppoe-out1-UP" (queue)
Hey @sebastia.
Thank you for your answer.
Could you give me an example please?
I dont understand your notes about "tree/list", "no QoS" and "out-interface/parent"

In addition...
1) Why must i have priority in download?
I dont have bottleneck in download (i have 50M from vdsl and the 1G from my network card).
And i listen very good the other side.
2) If i have default value in bucket-size each queue could demand additional traffic from the parent.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1783
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 2:12 pm

* "tree"
You need one parent queue linked to an interface, with a number of child queues connected to that parent queue, ex:
# e1_int is my interface to lan
add max-limit=180M name=int parent=e1_int
add name=int20 packet-mark=20 parent=int priority=2
add name=int30 packet-mark=30 parent=int priority=3
add name=intFT packet-mark=no-mark parent=int priority=6 queue=hotspot-default

* "no qos"
Since all queues are linked to interface with limit of 4M, they are all allowed to consume the total upload bandwidth, independent of usage of other queues.

* mangle
The mangle is applied to packets leaving on interface "all-ppp", but the queue is attached to interface "pppoe-out1-UP".

* priority in download
If you don't, the quality of download is not maintained, and you're listening experience will very depending on the load.

* "no bottleneck"
If there is a heavy downloader, the 50M pipe will be filled, easily.

* "bucket"
bucket means "how much can I use BEFORE asking parent for more. But in your case there is no parent: parent is interface for all separate queues.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 8:04 pm

* "tree"
You need one parent queue linked to an interface, with a number of child queues connected to that parent queue, ex:
# e1_int is my interface to lan
add max-limit=180M name=int parent=e1_int
add name=int20 packet-mark=20 parent=int priority=2
add name=int30 packet-mark=30 parent=int priority=3
add name=intFT packet-mark=no-mark parent=int priority=6 queue=hotspot-default

* "no qos"
Since all queues are linked to interface with limit of 4M, they are all allowed to consume the total upload bandwidth, independent of usage of other queues.

* mangle
The mangle is applied to packets leaving on interface "all-ppp", but the queue is attached to interface "pppoe-out1-UP".

* priority in download
If you don't, the quality of download is not maintained, and you're listening experience will very depending on the load.

* "no bottleneck"
If there is a heavy downloader, the 50M pipe will be filled, easily.

* "bucket"
bucket means "how much can I use BEFORE asking parent for more. But in your case there is no parent: parent is interface for all separate queues.
Hey again.

1. I forgot post the above code.
add bucket-size=0 limit-at=4500k max-limit=4500k name=pppoe-out1-UP parent=\
pppoe-out1

The code is:
add bucket-size=0 limit-at=4500k max-limit=4500k name=pppoe-out1-UP parent=\
    pppoe-out1
add bucket-size=0 limit-at=200k max-limit=4M name=QoS_1-UP packet-mark=\
    QoS_1-UP parent=pppoe-out1-UP priority=1 queue=fifo-UP
add bucket-size=0 limit-at=2M max-limit=4M name=QoS_2-UP packet-mark=QoS_2-UP \
    parent=pppoe-out1-UP priority=2 queue=sfq_UP
add bucket-size=0 limit-at=1M max-limit=4M name=QoS_3-UP packet-mark=QoS_3-UP \
    parent=pppoe-out1-UP priority=3 queue=sfq_UP
add bucket-size=0 limit-at=1M max-limit=4M name=QoS_4-UP packet-mark=QoS_4-UP \
    parent=pppoe-out1-UP priority=4 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_5-UP packet-mark=QoS_5-UP \
    parent=pppoe-out1-UP priority=5 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_7-UP packet-mark=QoS_7-UP \
    parent=pppoe-out1-UP priority=7 queue=sfq_UP
add bucket-size=0 limit-at=1k max-limit=4M name=QoS_8-UP packet-mark=QoS_8-UP \
    parent=pppoe-out1-UP queue=sfq_UP
add bucket-size=0 limit-at=60M max-limit=60M name=pppoe-out1-DW packet-mark=\
    no-mark parent=bridge1 queue=pcq_DW
All QoS_X-UP (1-8) queues have parent the pppoe-out1 queue.
pppoe-out1 queue is link to pppoe-out1 which is me pppoe client.
Now it's ok or should i change pppoe-out1 with physical ether interface (ether1)?

2. I will change bucket size with default value.

3. Should i change mangle interface from all-ppp to pppoe-out1 (or ether1)?
I believe all-ppp include pppoe-out1.
Is this correct?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1783
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 9:39 pm

1. that is better, it should point to pppoe

3. didn't encounter a "ppp-all" interface before, and it's not treated as a list "out-interface=all-ppp". Just to make sure I would use pppoe-out1 for now.
Once confirmed working, you can try with ppp-all, and verify.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Jan 21, 2019 10:44 pm

1. that is better, it should point to pppoe

3. didn't encounter a "ppp-all" interface before, and it's not treated as a list "out-interface=all-ppp". Just to make sure I would use pppoe-out1 for now.
Once confirmed working, you can try with ppp-all, and verify.
I change all-ppp with pppoe-out1 in mangle and QoS.
I change bucket size to default value (0.100).
Now i have:
/ip firewall mangle
add action=change-mss chain=forward in-interface=pppoe-out1 new-mss=1452 \
    passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535
add action=change-mss chain=forward new-mss=1452 out-interface=pppoe-out1 \
    passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535
add action=mark-packet chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-packet-mark=QoS_1-UP out-interface=pppoe-out1 packet-mark=\
    no-mark passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment="SYN Light" \
    connection-bytes=0-10000000 new-packet-mark=QoS_2-UP out-interface=\
    pppoe-out1 packet-mark=no-mark packet-size=0-666 passthrough=no protocol=tcp \
    tcp-flags=syn
add action=mark-packet chain=postrouting comment="ACK Light" \
    connection-bytes=0-10000000 new-packet-mark=QoS_2-UP out-interface=\
    pppoe-out1 packet-mark=no-mark packet-size=0-123 passthrough=no protocol=tcp \
    tcp-flags=ack
add action=mark-packet chain=postrouting comment=DNS dst-port=53 \
    new-packet-mark=QoS_3-UP out-interface=pppoe-out1 packet-mark=no-mark \
    passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment=ICMP-Echo new-packet-mark=\
    QoS_3-UP out-interface=pppoe-out1 packet-mark=no-mark passthrough=no \
    protocol=icmp
add action=mark-packet chain=postrouting comment=NTP dst-port=123 \
    new-packet-mark=QoS_3-UP out-interface=pppoe-out1 packet-mark=no-mark \
    passthrough=no protocol=udp
add action=mark-packet chain=postrouting comment=Light connection-bytes=\
    0-10000000 new-packet-mark=QoS_4-UP out-interface=pppoe-out1 packet-mark=\
    no-mark passthrough=no protocol=tcp
add action=mark-packet chain=postrouting comment=Heavy connection-bytes=\
    10000000-0 new-packet-mark=QoS_5-UP out-interface=pppoe-out1 packet-mark=\
    no-mark passthrough=no protocol=tcp
add action=mark-packet chain=postrouting comment=Torrents new-packet-mark=\
    QoS_8-UP out-interface=pppoe-out1 packet-mark=no-mark passthrough=no \
    protocol=udp src-port=55555
add action=mark-packet chain=postrouting comment="All others" \
    new-packet-mark=QoS_7-UP out-interface=pppoe-out1 packet-mark=no-mark \
    passthrough=no

/queue tree
add limit-at=4500k max-limit=4500k name=pppoe-out1-UP parent=\
pppoe-out1
add limit-at=200k max-limit=4M name=QoS_1-UP packet-mark=\
    QoS_1-UP parent=pppoe-out1-UP priority=1 queue=fifo-UP
add limit-at=2M max-limit=4M name=QoS_2-UP packet-mark=QoS_2-UP \
    parent=pppoe-out1-UP priority=2 queue=sfq_UP
add limit-at=1M max-limit=4M name=QoS_3-UP packet-mark=QoS_3-UP \
    parent=pppoe-out1-UP priority=3 queue=sfq_UP
add limit-at=1M max-limit=4M name=QoS_4-UP packet-mark=QoS_4-UP \
    parent=pppoe-out1-UP priority=4 queue=sfq_UP
add limit-at=1k max-limit=4M name=QoS_5-UP packet-mark=QoS_5-UP \
    parent=pppoe-out1-UP priority=5 queue=sfq_UP
add limit-at=1k max-limit=4M name=QoS_7-UP packet-mark=QoS_7-UP \
    parent=pppoe-out1-UP priority=7 queue=sfq_UP
add limit-at=1k max-limit=4M name=QoS_8-UP packet-mark=QoS_8-UP \
    parent=pppoe-out1-UP queue=sfq_UP
add limit-at=60M max-limit=60M name=pppoe-out1-DW packet-mark=\
    no-mark parent=bridge1 queue=pcq_DW
Any comment for this?
Will work correct the VoIP????
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1783
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: QoS Tree VoIP problem

Tue Jan 22, 2019 10:18 am

Didn't verify it all, but for VOIP it should be fine. packets are marked on output and matching packet-mark is defined on queue for that output interface.

As mentioned before, on the inbound (download) side, I would recommend to also do mangling & class-based queueing, but if you're happy for the moment...Leave as is.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Tue Jan 22, 2019 1:40 pm

Didn't verify it all, but for VOIP it should be fine. packets are marked on output and matching packet-mark is defined on queue for that output interface.

As mentioned before, on the inbound (download) side, I would recommend to also do mangling & class-based queueing, but if you're happy for the moment...Leave as is.
I haven't problem with download.
My problem is about VoIP.
As i say... when i download torrent, my upload is only 1-2M of 5M and the other side of phone line, listen me with brakes.
Anyway...
I tested the new settings with torrent and i'll post again.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Thu Feb 07, 2019 9:20 pm

I still have a problem when the dw speed increase >30M (of total 50M).
The up speed is very low ~1M (of total 5M).
But the outgoing voice quality have a problem (sound with gap).
I don't know if the problem is in the priority or the number of connections.
I use qbittorent with total connections 150, per torrent connections 75 and active downloads/uploads 2.
Are this connections a heavy load for MT
or the priorities does not work correctly?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 10:53 am

So what you say is that heavy download at your side doesn't affect how you hear the remote party (which would sound more logical) but how the remote party hears you, i.e. the suffering VoIP packets go in the opposite direction than the heavy load, correct?

If so, I'm not familiar with the ISP habits in Greece, but could it be that there is a Wi-Fi link between your place and the rest of the internet? The point is that Wi-Fi links are half-duplex (Rx and Tx cannot run simutaneously) so on low speed links this can generate jitter (small uplink VoIP packets have to wait until a large download TCP packet finishes transport). And some phones tolerate less jitter than others.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 11:21 am

So what you say is that heavy download at your side doesn't affect how you hear the remote party (which would sound more logical) but how the remote party hears you, i.e. the suffering VoIP packets go in the opposite direction than the heavy load, correct?

If so, I'm not familiar with the ISP habits in Greece, but could it be that there is a Wi-Fi link between your place and the rest of the internet? The point is that Wi-Fi links are half-duplex (Rx and Tx cannot run simutaneously) so on low speed links this can generate jitter (small uplink VoIP packets have to wait until a large download TCP packet finishes transport). And some phones tolerate less jitter than others.
My connection with internet is a vdsl 50/5.
When make a call (or call me others) then the other side hear me with gaps when i have traffic >30M of total 50M download (~20M bw free).
The same time the upload traffic are very low ~1-2M of 5M total (~3-4M bw free).
In addition i hear the side perfect without any quality problem even if i have full load of download 40-50M.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 12:03 pm

the other side hear me with gaps
Now the other side is always the same single VoIP phone or the situation is always the same when you call any remote number via some VoIP provider?

Can you sniff the traffic on the outgoing interface during such situation into a file or stream it to a machine running tcpdump or dumpcap (from the Wireshark suite) via an interface of your Mikrotik dedicated to the streaming, to see what you really send out?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 1:30 pm

Now the other side is always the same single VoIP phone or the situation is always the same when you call any remote number via some VoIP provider?
The other side has the VoIP equipment of ISP or simple classic analog phones (the transformation of VoIP made in ISPs).
The result is the same in all cases.
Can you sniff the traffic on the outgoing interface during such situation into a file or stream it to a machine running tcpdump or dumpcap (from the Wireshark suite) via an interface of your Mikrotik dedicated to the streaming, to see what you really send out?
Which interface?
VoIP or pppoe?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 1:45 pm

Sniff at pppoe.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 3:35 pm

ok i have it.
Parallel i have a torrent with full load 40-45M dw and i make i call outside.
I capture in MT the traffic of VoIP (Interface: pppoe AND IP address: the subnet of my VoIP provider).
I copy the pcap files to my PC and open it with wireshark.

Here it is my result for my VoIP with and without full load of torrent:
Image
Image
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 10:25 pm

Assuming you've identified the RTP stream by direction properly, it means that your Mikrotik is not just delaying the VoIP packets but dropping them, and even does that in chunks of up to three packets. So the first thing to do is to run /tool profile in that situation, to see whether the CPU load doesn't stay above 25 % (as there are spikes sometimes so 1/4 of the total CPU throughput is the maximum base load you can deem safe, maybe even less).

If the CPU load is higher, a complete export of your firewall (not just the mangle table) may or may not reveal some space for optimisation. If there is none, the hardware is insufficient for the purpose.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 11:00 pm

Assuming you've identified the RTP stream by direction properly, it means that your Mikrotik is not just delaying the VoIP packets but dropping them, and even does that in chunks of up to three packets. So the first thing to do is to run /tool profile in that situation, to see whether the CPU load doesn't stay above 25 % (as there are spikes sometimes so 1/4 of the total CPU throughput is the maximum base load you can deem safe, maybe even less).

If the CPU load is higher, a complete export of your firewall (not just the mangle table) may or may not reveal some space for optimisation. If there is none, the hardware is insufficient for the purpose.
ok i do it.
My cpu, in normal mode, have 10-15 usage.
When i dw a file i have 50-70 usage.
But if i disable all mangles, filters and queues... the usage is the same.
What kind of hw must i buy to prioritize a traffic.
My ISP equipment cost ~20-50e and work with load and voip correctly.
It's very disappointment for me to buy a model ~150e and do not have a acceptable QoS.
I bought a MT only for QoS.
Ι am very dissatisfied...
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Fri Feb 08, 2019 11:21 pm

if i disable all mangles, filters and queues... the usage is the same.
PPPoE processing also takes some CPU. For QoS, you have to look at CPU parameters, so unless you really needed the switchey functions of the CRS109 (8 GE ports, a standard-compliant PoE input, SFP cage) and the display, a hAP ac² with a quad core 716 MHz 32-bit ARM would have been better suited for the purpose for about half the price. I don't understand what the purpose of CRS109 is, for me a single core MIPSBE on 600 MHz and even a single gigabit port don't fit together if any L3 functionality is required.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: QoS Tree VoIP problem

Sat Feb 09, 2019 2:27 am

My cpu in normal usage shows 10-15%. When downloading a file, 50-70% usage. What kind of hardware must I buy to prioritize traffic? I bought a CRS109 only for QoS. Ι am very dissatisfied.

I do understand your frustration. New comers to the MikroTik brand do not realize product differences, understandably so. QoS is a CPU feature. Despite what the CRS109 appears to be (an all-in-one), it is really a switch with bolted on routing. The product is not a lie, rather its just not something that can meet the demands of today's internet speeds. The RB4011 is the appropriate hardware ( you need 8 ports?) for what you're trying to do.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Sat Feb 09, 2019 8:08 pm

@sindy and @pcunite thank you very much for your help.
In conclusion... the problem is the hw.
Wrong buy from me.
I saw the RB4011iGS+5HacQ2HnD-IN and i like very much.
Yes i need at least 8 ether ports.
sfp port only for upgrade.
Wireless of course.
I use and apc ups with usb connection but... never mind...
Is it sure that with this hw I will be ok with QoS?
My connection is 50/5 but maybe be upgrade to 200/20 or higher.
Are this requirements adequate?

thank everyone again...
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1398
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: QoS Tree VoIP problem

Sat Feb 09, 2019 11:17 pm

You dont have to spend all that money for a 4011, just keep the CRS109 as a "switch only" and add a Mikrotik hEX for the "Routing".
MTCNA, MTCTCE, MTCRE & MTCINE
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 8:48 am

You dont have to spend all that money for a 4011, just keep the CRS109 as a "switch only" and add a Mikrotik hEX for the "Routing".
I believe it's a good time for upgrade...
I want to try RB4011iGS+5HacQ2HnD-IN.
I suppose is more powerfully from hEX (in cpu).
Isn't it?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 11:06 am

I haven't got the 4011 so I can only extrapolate.

A few months ago I did a throughput measurement of hAP ac² with PPPoE on WAN; as QoS is essentially incompatible with fasttracking (you could fasttrack only the VoIP packets but there are so few of them that doing so wouldn't save you much CPU power), the throughput measurement with bi-directional traffic and no fasttracking on client side is most relevant for your case (without fasttracking, every single packet has to pass through all stages of the firewall). The summary value of 1180 Mbit/s in both directions in total is the maximum you would achieve with a hAP ac² as I had no packet marking rules in place during the test. 4011 uses the same CPU architecture and number of cores like the hAP ac² but almost double the clock rate, so you should get around 2300 Mbit/s total throughput on full-MTU-sized packets. Further throughput decrease in Mbits/s comes from handling of short packets, as smaller packets mean less payload bytes transported while spending the same CPU effort for routing, firewalling etc.

In real life, there is very roughly one small packet per two large ones for one-way file transfers (a small TCP ACK is usually sent for every second data packet received and the data packets are as large as the path permits). VoIP calls use only small to mid-size packets, except the call control (signalling) which is a few packets' exchange in the beginning of a call, but the share of the VoIP on the total traffic will likely be negligible unless you provide the VoIP service for the whole neighbourhood.

So all in all, 200/20 Mbit/s will surely be fine with 4011 even with QoS and PPPoE handling, 1000/1000 may or may not be depending on the traffic pattern. Another performance drop would happen if you'd deploy bridging to provide advanced L2 functionalities on the LAN ports (VLAN filtering, MSTP, ...)

The official test results are much more optimistic on large packets but they don't take into account the PPPoE processing.

The 4011 is also more powerful than hEX, although here the comparison would be more complex as the CPU architecture is different.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 2:18 pm

I haven't got the 4011 so I can only extrapolate.

A few months ago I did a throughput measurement of hAP ac² with PPPoE on WAN; as QoS is essentially incompatible with fasttracking (you could fasttrack only the VoIP packets but there are so few of them that doing so wouldn't save you much CPU power), the throughput measurement with bi-directional traffic and no fasttracking on client side is most relevant for your case (without fasttracking, every single packet has to pass through all stages of the firewall). The summary value of 1180 Mbit/s in both directions in total is the maximum you would achieve with a hAP ac² as I had no packet marking rules in place during the test. 4011 uses the same CPU architecture and number of cores like the hAP ac² but almost double the clock rate, so you should get around 2300 Mbit/s total throughput on full-MTU-sized packets. Further throughput decrease in Mbits/s comes from handling of short packets, as smaller packets mean less payload bytes transported while spending the same CPU effort for routing, firewalling etc.

In real life, there is very roughly one small packet per two large ones for one-way file transfers (a small TCP ACK is usually sent for every second data packet received and the data packets are as large as the path permits). VoIP calls use only small to mid-size packets, except the call control (signalling) which is a few packets' exchange in the beginning of a call, but the share of the VoIP on the total traffic will likely be negligible unless you provide the VoIP service for the whole neighbourhood.

So all in all, 200/20 Mbit/s will surely be fine with 4011 even with QoS and PPPoE handling, 1000/1000 may or may not be depending on the traffic pattern. Another performance drop would happen if you'd deploy bridging to provide advanced L2 functionalities on the LAN ports (VLAN filtering, MSTP, ...)

The official test results are much more optimistic on large packets but they don't take into account the PPPoE processing.

The 4011 is also more powerful than hEX, although here the comparison would be more complex as the CPU architecture is different.
Thank you very much for your advice.
Something else...
It's a good idea to pass the voip, ack and syn traffic from fast track?
In this way... have better priority from other traffic of QoS?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 2:51 pm

It's a good idea to pass the voip, ack and syn traffic from fast track?
In this way... have better priority from other traffic of QoS?
Fasttracking means that most packets of a fasttracked connection are only processed by the connection tracking stage of the firewall and are not processed by the various rule chains and queues. ACK-only packets belong to a connection, and fasttracking by its very principle handles either all packets of a connection or none, so within the same connection, you cannot selectively fasttrack only ACK-only packets and process the large packets the regular way even if it would make any sense (and it actually doesn't, see below).

Also, as even fasttracked packets still need the CPU to get moving, fasttracking a few packets out of the total (the VoIP flow volume is negligible as compared to your torrent traffic) will not significantly lower the CPU load, so even if you fasttrack VoIP packets and keep queueing the rest, there will be losses in your scenario.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 6:45 pm

It's a good idea to pass the voip, ack and syn traffic from fast track?
In this way... have better priority from other traffic of QoS?
Fasttracking means that most packets of a fasttracked connection are only processed by the connection tracking stage of the firewall and are not processed by the various rule chains and queues. ACK-only packets belong to a connection, and fasttracking by its very principle handles either all packets of a connection or none, so within the same connection, you cannot selectively fasttrack only ACK-only packets and process the large packets the regular way even if it would make any sense (and it actually doesn't, see below).

Also, as even fasttracked packets still need the CPU to get moving, fasttracking a few packets out of the total (the VoIP flow volume is negligible as compared to your torrent traffic) will not significantly lower the CPU load, so even if you fasttrack VoIP packets and keep queueing the rest, there will be losses in your scenario.
I will have the RB4011iGS, maybe, Wednesday.
I did some tests with full dw and voip call.
And i have a spreadsheet with result from wireshark.
When i have the RB i'll post the sum of all results for compare.

Anyway...
I change the rules:
now i mark connections first and then packets.
I haven't seen any difference in cpu util with only packets marks.
I have seen difference with simple queue vs tree.
With simple queue the cpu have max peek ~70-80% until 90-100% with trees.
I continue mark only upload traffic in postrouting.
Some suggestion for the mangles?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Sun Feb 10, 2019 9:27 pm

The goal is to make every packet pass through as little firewall rules as necessary, and let these few rules' match conditions be as simple as possible. To fulfil this goal, it is best to translate complex match conditions into connection-marks when handling the first packet of each connection, so that you don't need to re-evaluate all those conditions for every single packet, and to translate the connection-mark into the packet-mark as the first thing to be done for packets which already have got a connection-mark because the connection tracker has found them to match a marked connection. So what you get is something like:
/ip firewall mangle
#first of all, send the packets belonging to already marked connections to the chain translating connection marks into packet marks
add action=jump chain=postrouting connection-mark=!no-mark jump-target=connmark2pktmark

#now stop handling these packets in the postrouting chain as we've already done everything we wanted about them
add action=accept chain=postrouting connection-mark=!no-mark

#only initial packets of not-yet-marked connections can get to this point; let's set the connection marks representing priorities according to various match conditions
add action=mark-connection chain=postrouting new-connection-mark=P1 [condition1.1 [condition1.2 [condition1.3 [...]]]] passthrough=yes
add action=mark-connection chain=postrouting new-connection-mark=P2 [condition2.1 [condition2.2 [condition2.3 [...]]]] passthrough=yes
...
add action=mark-connection chain=postrouting new-connection-mark=P8 [condition8.1 [condition8.2 [condition8.3 [...]]]] passthrough=yes
#it is important to assign some connection-mark to ALL connections - if you don't, subsequent packets of non-marked connections
# would come here again thanks to the first two rules

#and now, let these initial packets which have just got their connection mark assigned also get their appropriate packet mark, otherwise
# they'd get away with none and would not be put to the proper queue
add action=jump chain=postrouting jump-target=connmark2pktmark

#this is THE END of the postrouting chain in mangle

#this is the chain translating connection-marks into packet-marks; all rules have passthrough=no because there is no point
#in checking the other ones once we've done the translation

#first, accept the download packets as you say we aren't queueing them at all
add action=accept chain=connmark2pktmark out-interface-list=LAN passthrough=no

#next, do the translations, starting NOT from the highest priority ones but from those responsible for most trafic - because to reduce the CPU load, 
# the more packets in a class the less rules you need to check them against
add action=mark-packet chain=connmark2pktmark connection-mark=P8 new-packet-mark=P8 passthrough=no
...
add action=mark-packet chain=connmark2pktmark connection-mark=P1 new-packet-mark=P1 passthrough=no
This is the rough skeleton. Real life may be more complex, and I don't say this will surely save your CRS109 from trash because the optimisation won't do a dramatic change , but you may give it a try. I'd recommend to start from just two priorities - VoIP and the rest. If doing so saves the VoIP calls, it makes sense to spend effort on fine-graining the other priorities.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 9:07 am

The goal is to make every packet pass through as little firewall rules as necessary, and let these few rules' match conditions be as simple as possible. To fulfil this goal, it is best to translate complex match conditions into connection-marks when handling the first packet of each connection, so that you don't need to re-evaluate all those conditions for every single packet, and to translate the connection-mark into the packet-mark as the first thing to be done for packets which already have got a connection-mark because the connection tracker has found them to match a marked connection. So what you get is something like:
/ip firewall mangle
#first of all, send the packets belonging to already marked connections to the chain translating connection marks into packet marks
add action=jump chain=postrouting connection-mark=!no-mark jump-target=connmark2pktmark

#now stop handling these packets in the postrouting chain as we've already done everything we wanted about them
add action=accept chain=postrouting connection-mark=!no-mark

#only initial packets of not-yet-marked connections can get to this point; let's set the connection marks representing priorities according to various match conditions
add action=mark-connection chain=postrouting new-connection-mark=P1 [condition1.1 [condition1.2 [condition1.3 [...]]]] passthrough=yes
add action=mark-connection chain=postrouting new-connection-mark=P2 [condition2.1 [condition2.2 [condition2.3 [...]]]] passthrough=yes
...
add action=mark-connection chain=postrouting new-connection-mark=P8 [condition8.1 [condition8.2 [condition8.3 [...]]]] passthrough=yes
#it is important to assign some connection-mark to ALL connections - if you don't, subsequent packets of non-marked connections
# would come here again thanks to the first two rules

#and now, let these initial packets which have just got their connection mark assigned also get their appropriate packet mark, otherwise
# they'd get away with none and would not be put to the proper queue
add action=jump chain=postrouting jump-target=connmark2pktmark

#this is THE END of the postrouting chain in mangle

#this is the chain translating connection-marks into packet-marks; all rules have passthrough=no because there is no point
#in checking the other ones once we've done the translation

#first, accept the download packets as you say we aren't queueing them at all
add action=accept chain=connmark2pktmark out-interface-list=LAN passthrough=no

#next, do the translations, starting NOT from the highest priority ones but from those responsible for most trafic - because to reduce the CPU load, 
# the more packets in a class the less rules you need to check them against
add action=mark-packet chain=connmark2pktmark connection-mark=P8 new-packet-mark=P8 passthrough=no
...
add action=mark-packet chain=connmark2pktmark connection-mark=P1 new-packet-mark=P1 passthrough=no
This is the rough skeleton. Real life may be more complex, and I don't say this will surely save your CRS109 from trash because the optimisation won't do a dramatic change , but you may give it a try. I'd recommend to start from just two priorities - VoIP and the rest. If doing so saves the VoIP calls, it makes sense to spend effort on fine-graining the other priorities.
@sindy
Thank you for your advice.
I have some questions:
1. In connections mark, why i need to have passthrough=yes?
In this way when some connection mark as C1 and next check all the others rules.
2. Why I need to have jmp for mark connections at the end of connections mark.
When finish with connections mark, do not continue to packet mark?
3. In packet mark you say to accept the download packets.
Why?

I had this mangles:
# maybe not need the next
add action=jump chain=postrouting comment=Connections connection-mark=no-mark \
    jump-target=conmark out-interface=pppoe-out1
# maybe not need the above
add action=jump chain=postrouting comment=Packets connection-mark=!no-mark \
    jump-target=pktmark out-interface=pppoe-out1
# connection mark
add action=mark-connection chain=conmark comment=VoIP dst-address-list=\
    VoIP new-connection-mark=QoS_1-UP passthrough=no protocol=udp
...
add action=mark-connection chain=conmark comment="All others" \
    new-connection-mark=QoS_7-UP passthrough=no
# packet mark
add action=mark-packet chain=pktmark comment=VoIP connection-mark=QoS_1-UP \
    new-packet-mark=QoS_1-UP passthrough=no
...
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 9:38 am

1. In connections mark, why i need to have passthrough=yes?
In this way when some connection mark as C1 and next check all the others rules.
because after assigning a connection-mark, you need to continue handling the packet in order to translate the connection-mark into a packet-mark also for this packet, otherwise it would not get the packet-mark at all, only the subsequent packets of the connection would get it.

2. Why I need to have jmp for mark connections at the end of connections mark.
When finish with connections mark, do not continue to packet mark?
No, as you cannot jump to another rule in the same chain or call a portion of the same chain, so the chain "connmark2pktmark" must be called from chain "postrouting" in order that it could be called from both places where I do that. Of course you might put the same rules one more time to the end of chain "postrouting" instead of calling that other one, but that single jump is not too costly in CPU and is only done for initial packets of connections, so it is better to have each translation rule only once.

3. In packet mark you say to accept the download packets.
Why?
Because you've written somewhere that you don't prioritize them. If you do, modify that accordingly - at best create another rule translation chain for the other direction to minimize the number of rules traversed by each packet.

Other than this, prioritization of download traffic has to be different from prioritization of upload traffic - there is no point in slowing down UDP or TCP ACK packets in download (WAN->LAN) direction because they've already used the uplink bandwidth and by slowing these down you do not affect further packets in the same direction. By slowing down the download direction TCP packets with a payload (no matter whether they contain the ACK or not, only their size matters here), you slow down the recipient's ACK on them, and thus indirectly slow down the sending speed at sender's end.

In upload direction, you can slow down anything; of course, if you slow down some UDP streams so much that you fill up their respective queue and it starts dropping them, it will affect the service. Just think about not slowing down ACK twice - once indirectly by slowing down TCP with payload in download direction, and the second time directly in upload direction. It would be another waste of resources to discriminate between TCP packets with and without payload in download direction and then again in upload direction, so better to slow down just the upload and save the size comparison in both directions.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 6:54 pm

@sindy

Now my configuration is:
/ip firewall mangle
add action=jump chain=postrouting comment=Packets connection-mark=!no-mark \
    jump-target=pktmark out-interface=pppoe-out1

add action=accept chain=postrouting comment=Connections connection-mark=\
    !no-mark out-interface=pppoe-out1

add action=mark-connection chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-connection-mark=QoS_1-UP out-interface=pppoe-out1 \
    passthrough=yes protocol=udp
...
add action=mark-connection chain=postrouting comment="All others" \
    connection-mark=no-mark new-connection-mark=QoS_7-UP out-interface=\
    pppoe-out1 passthrough=yes

add action=jump chain=postrouting jump-target=pktmark out-interface=\
    pppoe-out1

add action=mark-packet chain=pktmark comment=Torrents connection-mark=\
    QoS_8-UP new-packet-mark=QoS_8-UP passthrough=no
...
add action=mark-packet chain=pktmark comment=VoIP connection-mark=QoS_1-UP \
    new-packet-mark=QoS_1-UP passthrough=no
But i can't see any traffic in accept rule for connection-mark=!no-mark.
Why?
Any comments for the new configuration?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 7:30 pm

But i can't see any traffic in accept rule for connection-mark=!no-mark.
Why?
Because your chain=pktmark works well and does not leave any packets unhandled :-) That action=accept rule was there just to catch packets for which the translation of connection-mark to packet-mark did not happen for any reason in the chain=pktmark and not let them get further. However,
Any comments for the new configuration?
yes, there is an important one related to the above - as you have added out-interface=pppoe to the first two rules as compared to my suggestion, all packets in the download direction do pass through all the connection-marking rules followed by passing through all the chain=pktmark rules, because neither of the first two rules matches on them (as they have a connection-mark assigned but don't have out-interface=pppoe). So if you don't want to enqueue download packets, remove the out-interface=pppoe from the accept rule with connection-mark=!no-mark, so it will accept all download packets belonging to already marked connections and thus will not let them pass all the connection-marking rules (as doing so generates an unnecessary CPU load). So all download packets (except the initial ones of connections initiated from WAN side which probably don't exist) will be handled by just two rules - the first one which won't match on them, and the second one which will accept them. In my initial suggestion, the first rule in the chain=connmark2pktmark was responsible for the same, but it caused the upload packets to pass through that one extra rule, so the way described just above is more efficient.

Other than that, it seems fine to me. So if after implementing the change above you still experience RTP packet loss, there is no more optimisation I could suggest.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 9:49 pm

But i can't see any traffic in accept rule for connection-mark=!no-mark.
Why?
Because your chain=pktmark works well and does not leave any packets unhandled :-) That action=accept rule was there just to catch packets for which the translation of connection-mark to packet-mark did not happen for any reason in the chain=pktmark and not let them get further. However,
Any comments for the new configuration?
yes, there is an important one related to the above - as you have added out-interface=pppoe to the first two rules as compared to my suggestion, all packets in the download direction do pass through all the connection-marking rules followed by passing through all the chain=pktmark rules, because neither of the first two rules matches on them (as they have a connection-mark assigned but don't have out-interface=pppoe). So if you don't want to enqueue download packets, remove the out-interface=pppoe from the accept rule with connection-mark=!no-mark, so it will accept all download packets belonging to already marked connections and thus will not let them pass all the connection-marking rules (as doing so generates an unnecessary CPU load). So all download packets (except the initial ones of connections initiated from WAN side which probably don't exist) will be handled by just two rules - the first one which won't match on them, and the second one which will accept them. In my initial suggestion, the first rule in the chain=connmark2pktmark was responsible for the same, but it caused the upload packets to pass through that one extra rule, so the way described just above is more efficient.

Other than that, it seems fine to me. So if after implementing the change above you still experience RTP packet loss, there is no more optimisation I could suggest.
But if i remove from first and second rule the out interface, packet mark count additional the dw traffic.
Before... i catch only upload in connections and packet mark.
Even if all dw traffic pass from all connections mark, i have last rule to jump to packet mark with out-interface.
So the dw traffic don't pass to packet mark.
Is a good idea to make one more jump for connections mark?
Like this:
add action=jump chain=postrouting comment=Packets connection-mark=!no-mark \
    jump-target=pktmark out-interface=pppoe-out1
add action=accept chain=postrouting comment=Connections connection-mark=\
    !no-mark out-interface=pppoe-out1
add action=jump chain=postrouting comment=Packets connection-mark=no-mark \
    jump-target=conmark out-interface=pppoe-out1
And change all chains in connections mark from postrouting to conmark.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 10:34 pm

But if i remove from first and second rule the out interface, packet mark count additional the dw traffic.
Don't remove out-interface=pppoe from the first rule, remove it only from the second one.
First rule will send only connection-marked UL packets to the mark translating chain (and they will never return from there as they get packet-marked with passthrough=no there), and it will ignore all DL packets so they won't be sent to the mark translating chain.
Only all the DL packets and the UL packets with no connection-mark will reach the second rule, and that rule will match on all of the DL packets belonging to already connection-marked connections and will thus accept them, so only packets in either direction which have no connection-mark will get past this second rule (and eventually get a connection-mark assigned followed by getting assigned a packet-mark, but there are so few of them that it doesn't matter).

Before... i catch only upload in connections and packet mark.
Even if all dw traffic pass from all connections mark, i have last rule to jump to packet mark with out-interface.
So the dw traffic don't pass to packet mark.
Sorry, can you re-word this? I'm lost a bit in what is "before" and which "last rule" you have in mind. But as it is the last one, it means to me that there are some rules before it, through which the DL packets had to pass. And even though none of those rules before matched those packets, the evaluation may take the same amount of CPU time when it doesn't match as when it matches - although I suppose that the mismatch of the whole rule is declared as soon as the first mismatch of one of the conditions is encountered, the first condition failing to match may be the last one evaluated.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Mon Feb 11, 2019 11:37 pm

But if i remove from first and second rule the out interface, packet mark count additional the dw traffic.
Don't remove out-interface=pppoe from the first rule, remove it only from the second one.
First rule will send only connection-marked UL packets to the mark translating chain (and they will never return from there as they get packet-marked with passthrough=no there), and it will ignore all DL packets so they won't be sent to the mark translating chain.
Only all the DL packets and the UL packets with no connection-mark will reach the second rule, and that rule will match on all of the DL packets belonging to already connection-marked connections and will thus accept them, so only packets in either direction which have no connection-mark will get past this second rule (and eventually get a connection-mark assigned followed by getting assigned a packet-mark, but there are so few of them that it doesn't matter).

Before... i catch only upload in connections and packet mark.
Even if all dw traffic pass from all connections mark, i have last rule to jump to packet mark with out-interface.
So the dw traffic don't pass to packet mark.
Sorry, can you re-word this? I'm lost a bit in what is "before" and which "last rule" you have in mind. But as it is the last one, it means to me that there are some rules before it, through which the DL packets had to pass. And even though none of those rules before matched those packets, the evaluation may take the same amount of CPU time when it doesn't match as when it matches - although I suppose that the mismatch of the whole rule is declared as soon as the first mismatch of one of the conditions is encountered, the first condition failing to match may be the last one evaluated.
ok...
I fixed it.
Now i have:
/ip firewall mangle
add action=jump chain=postrouting comment=Packets connection-mark=!no-mark \
    jump-target=pktmark out-interface=pppoe-out1

add action=accept chain=postrouting comment=Connections connection-mark=\
    !no-mark

add action=mark-connection chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-connection-mark=QoS_1-UP out-interface=pppoe-out1 \
    passthrough=yes protocol=udp
...
add action=mark-connection chain=postrouting comment="All others" \
    connection-mark=no-mark new-connection-mark=QoS_7-UP out-interface=\
    pppoe-out1 passthrough=yes

add action=jump chain=postrouting jump-target=pktmark out-interface=\
    pppoe-out1

add action=mark-packet chain=pktmark comment=Torrents connection-mark=\
    QoS_8-UP new-packet-mark=QoS_8-UP passthrough=no
...
add action=mark-packet chain=pktmark comment=VoIP connection-mark=QoS_1-UP \
    new-packet-mark=QoS_1-UP passthrough=no
And now all counts are correct.

If i change the accept rule with:
add action=jump chain=postrouting comment=Packets connection-mark=no-mark \
    jump-target=conmark out-interface=pppoe-out1
Is this ok?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 12:43 am

If i change the accept rule with:
add action=jump chain=postrouting comment=Packets connection-mark=no-mark \
    jump-target=conmark out-interface=pppoe-out1
Is this ok?
Well, there is little difference whether you use a separate chain=conmark and jump to it from chain=postrouting for packets which need connection-marking, or whether you do the connection-marking within chain=postrouting itself and bypass that part of it for packets which do not require connection-marking. So sorry if I mislead you, I didn't go deep into your configuration in post #29 because I've understood from what you wrote there that it was an excerpt from the one you've published earlier and in those ones there were no dedicated chains for connection marking and packet marking.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 8:55 am

If i change the accept rule with:
add action=jump chain=postrouting comment=Packets connection-mark=no-mark \
    jump-target=conmark out-interface=pppoe-out1
Is this ok?
Well, there is little difference whether you use a separate chain=conmark and jump to it from chain=postrouting for packets which need connection-marking, or whether you do the connection-marking within chain=postrouting itself and bypass that part of it for packets which do not require connection-marking. So sorry if I mislead you, I didn't go deep into your configuration in post #29 because I've understood from what you wrote there that it was an excerpt from the one you've published earlier and in those ones there were no dedicated chains for connection marking and packet marking.
Now i have this configuration (according to your suggestions):
/ip firewall mangle
add action=jump chain=postrouting comment=MrkConJmp2PckMark connection-mark=\
    !no-mark jump-target=pktmark out-interface=pppoe-out1
add action=accept chain=postrouting comment=AccMarkCon connection-mark=\
    !no-mark

add action=mark-connection chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-connection-mark=QoS_1-UP out-interface=pppoe-out1 \
    passthrough=yes protocol=udp
...
add action=mark-connection chain=postrouting comment="All others" \
    connection-mark=no-mark new-connection-mark=QoS_7-UP out-interface=\
    pppoe-out1 passthrough=yes

add action=jump chain=postrouting comment=MrkConJmp2PckMark jump-target=\
    pktmark out-interface=pppoe-out1

add action=mark-packet chain=pktmark comment=Torrents connection-mark=\
    QoS_8-UP new-packet-mark=QoS_8-UP passthrough=no
...
add action=mark-packet chain=pktmark comment=VoIP connection-mark=QoS_1-UP \
    new-packet-mark=QoS_1-UP passthrough=no
I believe it's ok now.

if there is no error lets see the queue.
I have this rules (my vdsl is 50/5):
/queue simple
add dst=pppoe-out1 limit-at=4500k/0 max-limit=4500k/60M name=pppoe-out1-UP \
    target=bridge1
add comment=VoIP dst=pppoe-out1 limit-at=200k/0 max-limit=4M/60M name=\
    QoS_1-UP packet-marks=QoS_1-UP parent=pppoe-out1-UP priority=1/1 target=\
    bridge1
add comment="SYN-ACK Light" dst=pppoe-out1 limit-at=2M/0 max-limit=4M/60M \
    name=QoS_2-UP packet-marks=QoS_2-UP parent=pppoe-out1-UP priority=2/2 \
    target=bridge1
add comment="DNS, NTP, ICMP" dst=pppoe-out1 limit-at=1M/0 max-limit=4M/60M \
    name=QoS_3-UP packet-marks=QoS_3-UP parent=pppoe-out1-UP priority=3/3 \
    target=bridge1
add comment="TCP Light" dst=pppoe-out1 limit-at=1M/0 max-limit=4M/60M name=\
    QoS_4-UP packet-marks=QoS_4-UP parent=pppoe-out1-UP priority=4/4 target=\
    bridge1
add comment="TCP Heavy" dst=pppoe-out1 limit-at=1k/0 max-limit=4M/60M name=\
    QoS_5-UP packet-marks=QoS_5-UP parent=pppoe-out1-UP priority=5/5 target=\
    bridge1
add comment=Torrents dst=pppoe-out1 limit-at=1k/0 max-limit=4M/60M name=\
    QoS_7-UP packet-marks=QoS_7-UP parent=pppoe-out1-UP priority=7/7 target=\
    bridge1
add comment="All others" dst=pppoe-out1 limit-at=1k/0 max-limit=4M/60M name=\
    QoS_8-UP packet-marks=QoS_8-UP parent=pppoe-out1-UP target=bridge1
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 10:23 am

To me it seems fine, just double-check whether you have the connection-mark=no-mark condition in all action=mark-connection rules except the first one, to avoid accidentally rewriting an already assigned connection-mark. You obviously realized such need on oyur own, but as you haven't shown all these rules for easier readability (good!), you have to double-check yourself.

What are the practical results?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 11:33 am

To me it seems fine, just double-check whether you have the connection-mark=no-mark condition in all action=mark-connection rules except the first one, to avoid accidentally rewriting an already assigned connection-mark. You obviously realized such need on oyur own, but as you haven't shown all these rules for easier readability (good!), you have to double-check yourself.

What are the practical results?
In connection mark i haven't checked for nomark except last rule for all packets.
In this way some connections may be change park.
I believe all connections would be have connection-mark=no-mark as the last rule.
I leave it without because you hadn't anything mark in your suggestion.
I add them:
add action=jump chain=postrouting comment=MrkConJmp2PckMark connection-mark=\
    !no-mark jump-target=pktmark out-interface=pppoe-out1
add action=accept chain=postrouting comment=AccMarkCon connection-mark=\
    !no-mark

add action=mark-connection chain=postrouting comment=VoIP dst-address-list=\
    VoIP new-connection-mark=QoS_1-UP out-interface=pppoe-out1 \
    passthrough=yes protocol=udp connection-mark=no-mark
...
add action=mark-connection chain=postrouting comment="All others" \
    connection-mark=no-mark new-connection-mark=QoS_7-UP out-interface=\
    pppoe-out1 passthrough=yes
I hadn't any problem without connection-mark=no-mark (with double/replace mark) because the rules is very tight.
But with add state nomark it's like most correct.
I add nomark and the first rule.
It's unnecessary but i don't believe to have additional cpu load.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 10:09 pm

It's amazing!!!
With new QoS configuration and RB4011 i have <5% cpu load on full dw.
In the same time i have voip mean jitter 0.21ms (in CRS with none dw i had 0.22ms), max 0.35ms (in CRS with none dw i had 0.54ms) and 0 packet loss.

Many many thanks to all!!!
Especially @sindy for QoS and @pcunite for the suggestion of RB4011.

@sindy
Dο you know some book for MT QoS analysis?
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 11:09 pm

Dο you know some book for MT QoS analysis?
Haven't needed one yet so no. What do you mean by QoS analysis?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
denisun
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 11:17 pm

Dο you know some book for MT QoS analysis?
Haven't needed one yet so no. What do you mean by QoS analysis?
Some book to explain how work QoS (packet flow etc).
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: QoS Tree VoIP problem

Tue Feb 12, 2019 11:58 pm

Some book to explain how work QoS (packet flow etc).
Well, that wouldn't be a book on analysis but a book on how it works, that's different things (for me, an analysis is a process of finding out how something works or why something happens, not just a description how it works by someone who knows it). So if this and this (including the link to HTB) page do not say enough, what answers do you miss there?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 35 guests