Adaptive QOS and voip not working so well together (and high ping)

[defcon]

More on Adaptive QoS

BWDPI as a DPI (deep packet inspection) engine is fairly capable, especially for a consumer router. More than 700 types of common applications are identified based on counting the number app icons TrendMicro/Asus have prepared for their routers.

It includes both WhatsApp and Skype. So kinda surprise if BWDPI can't properly prioritise voice calls from such apps. Sometimes I wonder if turning on "App Analysis" is required for Adaptive QoS to work better. People would normally assume DPI is performed always regardless of this knob...

Also worth checking during a VoIP call to see what type of app is the traffic identified. I've been using "WiFi Call" on iPhone at home where cellular signal is usually one bar or two. BWDPI identifies WiFi Call as "General" which I take it as unable to identify...as WiFI Calls are all encrypted through a dedicated IPsec tunnel.

• If people could figure out the rule number corresponding to "General". Then simply put that number in highest priority category through bwdpi_app_rulelist. That could be one preferred workaround.
• Assigning the iPhone/Android device doing VoIP the highest priority (the red color button on Bandwidth Monitor page) may also improve the latency situation..
• I would bet "General" is part of "Others" on Adaptive QoS customisation page. Giving "Others" a higher priority maybe below VoIP will help too...but risk propping up other unrelated "Others" traffic..

Quite a few workarounds are there worth trying before getting hands wet into nitty gritty of traditional QoS IMO. But really DPI based QoS shall be made more configurable (for people who prefer to)...

I've never noticed a dropped WiFi call as-is. Thus I never experimented with the above suggestions. Would like to hear feedback from people who tried and see improvements.

@RMerlin maybe if we can get a compiled strace/lsof thrown on the router we can do some debugging to see if we can further customize/reverse engineer ASUS's implementation

 

[RMerlin]

@RMerlin maybe if we can get a compiled strace/lsof thrown on the router we can do some debugging to see if we can further customize/reverse engineer ASUS's implementation

You can add these tools through Entware.

What you are looking for resides in good part in the qosd binary. A strings dump of that exe will give you a list of the tc commands it uses.

 

[sfx2000]

One limitation of Traditional QoS is that it only lets you configure rules based on tcp/ip parameters (port, protocol and IP). BWDPI's big advantage is its engine can classify traffic at an L7 level.

QoS is very mis-understood - it's probably better to refer this as traffic shaping, and even then, it's about conditional fairness across the different interfaces/clients/applications...

 

[Nullity]

QoS is very mis-understood - it's probably better to refer this as traffic shaping, and even then, it's about conditional fairness across the different interfaces/clients/applications...

Using the most common, mostly accurate term is my preference, which is "(Traditional/Adaptive) QoS". Standard AsusWRT users just want gaming & VOIP to perform optimally.

 

[lilstone87]

Using the most common, mostly accurate term is my preference, which is "(Traditional/Adaptive) QoS". Standard AsusWRT users just want gaming & VOIP to perform optimally.

Yes I would agree with the last part you said here. I will say however I haven't found Adaptive QoS performing optimally for me when using a decent amount of upload bandwidth recently. I currently use a AC3100, and it was probably two weeks ago. I had adaptive QoS enabled, and even had gaming system prioritized. Well I was doing some online gaming, and noticed things were feeling, and even appearing to lag. So I looked over things while still gaming, and my network was using 8mbps(1MB's) of upload bandwidth. Which is about 25% of my total upload bandwidth, so no reason I should be feeling things getting so laggy. I even checked ping times, which normally may raise 5ms, if that on average when using that amount of active upload bandwidth.

So with all that said.. I'm sure I don't fully understand the way Adaptive QoS should work. But I think it should be working better then this, and not allowing gaming to suffer in this manner, when prioritized, and only 25% of my total upstream was being used at the time. Btw this wasn't a single one time deal, I was able to get it to happen a couple times, that day. But also noticed it happen a time, or two before. I just didn't take the time to look into it actively before.

 

[Nullity]

...
So with all that said.. I'm sure I don't fully understand the way Adaptive QoS should work. But I think it should be working better then this, and not allowing gaming to suffer in this manner, when prioritized, and only 25% of my total upstream was being used at the time. Btw this wasn't a single one time deal, I was able to get it to happen a couple times, that day. But also noticed it happen a time, or two before. I just didn't take the time to look into it actively before.

That was my biggest obstacle when learning about generic QoS and related technologies... I never got the results I (ignorantly) expected.

I remember disregarding an SNB forum post said you must verify that your QoS configuration performs as expected. Months later I realized he was absolutely correct.

 

[kvic]

To me: Adaptive QoS = Traditional QoS plus using deep packet inspection to classify network traffic for packet prioritisation.

People could complain about lack of exposed end-user configurability in the current offering in ASUSWRT. Or lack of flexibility using port/ip/etc in addition to deep packet inspection ATM. The fundamentals are with Adaptive QoS having an edge here.

As an analogy, when Great Firewall in China used "traditional ways" (port/ip/etc) to block access, people could cross the wall with ease. After GFW deploys deep packet inspect (and an additional temporal dimension..) to identify the "right" traffic to block, its effectiveness improves by many orders of magnitude.

 

[kvic]

Yet more on Adaptive QoS...

DSLreport buffer bloat test of my line 100/100:

It doesn't get me A+ but I'm happy with A..

Settings

Bandwidth Setting = Manual
Upload Bandwidth = 95 Mb/s
Download Bandwidth = 0 Mb/s

Manual is a must IMO.

Download bandwidth shall simply set to 0 for home internet by all intent and purpose..

With a fat upstream pipe or symmetric up/down , upload bandwidth can be set 90% to 95%.

With a thin upstream pipe (e.g. < 20Mbit/s) or asymmetric up/down (especially those extraordinarily asymmetric like 150/10 down/up), I think people worth experimenting with upload bandwidth set to between 50% and 70%.

Let us know if people tried and see improvements...

 

[charlie2alpha]

My opinions are a bit different. DPI is effective, yes, but only as good as the equipment doing it. Our routers have limited processing power ( if they didn't, hardware acceleration wouldn't be a necessity) and therefore the DPI engine is also limited in what it can do.

Also, taking into account that the majority of connections these days are already using TLS/other encryption that makes it harder for that DPI engine to figure out what the traffic really is.

Speaking with practical terms from own tests, it cannot detect encrypted torrent traffic, neither popular VoIP-enabled messaging applications like Skype, Viber, WhatApp messenger, Google Hangouts etc. So what happens is that all of these end up in the "Generic" category which is plain wrong since there will be no prioritization at all for the time sensitive VoIP packets.

So, by doing just the DSL Reports test, yes, you'll get an A+ if you limit your upstream enough, but the real challenge for any Traffic Shaping system is when there're multiple streams of a different nature, requiring different priorities. And in that, Trendmicro's supplied engine in the ASUS routers just isn't good enough. Not for the applications I use anyway, it just fails miserably. And to be honest, I wouldn't except much from consumer level equipment after all.

Also my last objection, why would anyone with an upstream no more than 10Mbps would limit it as far as 50%? We're paying for our connections and expect to be able to use the full bandwidth of it. If we're required to limit our bandwidth so much just to have a decent bufferbloat result, then the QoS system used in this case is a complete failure. I have a 5Mbit upload and set the upload at 4.75Mbps and get A+ in bufferbload, A+ in quality. Because I don't use the adaptive system, neither ASUS' normal QoS but my own script.

No, I do not expect anyone to do this, but for sure the DPI engines have their own issues and limitations, their biggest enemy being encryption which is being enabled for more and more things these days.

 

[sfx2000]

No, I do not expect anyone to do this, but for sure the DPI engines have their own issues and limitations, their biggest enemy being encryption which is being enabled for more and more things these days

http://www.ntop.org/products/deep-packet-inspection/ndpi/

 

[RMerlin]

I suspect that the Trend Micro DPI engine goes beyond inspecting the packet payload, as it can specifically classify "Google SSL traffic". It probably also check at the TCP header, looking up source and destination IP and ports.

 

[charlie2alpha]

I suspect that the Trend Micro DPI engine goes beyond inspecting the packet payload, as it can specifically classify "Google SSL traffic". It probably also check at the TCP header, looking up source and destination IP and ports.

That is probably the case, checking for port 443 is easy after all.

 

[charlie2alpha]

http://www.ntop.org/products/deep-packet-inspection/ndpi/

Quite interesting, I don't know how effective it is. In our ASUS routers though we are limited to the Trendmicro engine.

 

[RMerlin]

ndpi is a modern replacement for the old L7Filter netfilter module that was previously used by Tomato. I know it was added to DD-WRT, I don't know if they actively use it on the webui tho.

 

[RMerlin]

That bit is quite interesting:

The trend of Internet traffic is going towards encrypted content often using SSL. In order to let nDPI support encrypted connections, we have added a decoder for SSL (both client and server) certificates, thus we can figure out the protocol using the encryption certificate. This allows us to identify protocols such as Citrix Online and Apple iCloud that otherwise would be undetected.

Could be also another method Trend Micro uses to separate Google SSL traffic from the rest (and would be far more accurate than having to constantly update the list of known subnets belonging to Google).

 

[charlie2alpha]

That bit is quite interesting:



Could be also another method Trend Micro uses to separate Google SSL traffic from the rest (and would be far more accurate than having to constantly update the list of known subnets belonging to Google).

That helps but I don't know if it can detect the type of traffic effectively. As I pointed out, their engine fails to detect VoIP that doesn't use standard SIP.

 

[RMerlin]

That helps but I don't know if it can detect the type of traffic effectively. As I pointed out, their engine fails to detect VoIP that doesn't use standard SIP.

I would expect the VoIP traffic to use a certificate with a different CN than their public website, so that could already help in identifying it. So technically, it would be possible at least.

 

[bluepoint]

Yet more on Adaptive QoS...

DSLreport buffer bloat test of my line 100/100:

It doesn't get me A+ but I'm happy with A..

Settings

Bandwidth Setting = Manual
Upload Bandwidth = 95 Mb/s
Download Bandwidth = 0 Mb/s

Manual is a must IMO.

Download bandwidth shall simply set to 0 for home internet by all intent and purpose..

With a fat upstream pipe or symmetric up/down , upload bandwidth can be set 90% to 95%.

With a thin upstream pipe (e.g. < 20Mbit/s) or asymmetric up/down (especially those extraordinarily asymmetric like 150/10 down/up), I think people worth experimenting with upload bandwidth set to between 50% and 70%.

Let us know if people tried and see improvements...

100/100 Mbps Service actual @102/125 Mbps when speedtested without QOS.

Settings

Bandwidth Setting = Manual
Upload Bandwidth = 120 Mbps
Download Bandwidth = 100 Mbps

 

[Chris Wolf]

Hi guys - great thread here. I own a VoIP company, we use a non-standard port for SIP messaging . . (7770) . . the standard port is 5060. That being said, Adaptive QoS is picking up SIP messaging and properly categorizing it as "VoIP" ..

The bad news is that the actually digitized human conversation known as the "RTP stream" is categorized as 'General' and therefore falling under "Default".

At the moment I have to set "Others" as the highest priority in "customize" in order to get the RTP stream to takes its place at the top.

If anyone is interested in geeking out on this and figuring out how to get *any* RTP stream categorized as VoIP, let me know . . I have great technical resources yet I just began to use merlin for smaller customer prems, I'm not really a Linux guy but I have people who are.

thx

 

[FreshJR]

Hi guys - great thread here. I own a VoIP company, we use a non-standard port for SIP messaging . . (7770) . . the standard port is 5060. That being said, Adaptive QoS is picking up SIP messaging and properly categorizing it as "VoIP" ..

The bad news is that the actually digitized human conversation known as the "RTP stream" is categorized as 'General' and therefore falling under "Default".

At the moment I have to set "Others" as the highest priority in "customize" in order to get the RTP stream to takes its place at the top.

If anyone is interested in geeking out on this and figuring out how to get *any* RTP stream categorized as VoIP, let me know . . I have great technical resources yet I just began to use merlin for smaller customer prems, I'm not really a Linux guy but I have people who are.

thx

You resurrected this dinosaur and missed my thread on front page?

https://www.snbforums.com/threads/s...category-unidentified-traffic-priority.36836/

We figured out how to redirect default traffic into the others catagory which can then be moved up and down in the UI, since out of the box the default catagory is always LAST and cannot be adjusted.

Default is different from others. Default is always last. That threw me for a loop aswell.


A better approch probably would be if you are able to identify the RTP stream using by destination IP or some easy identifier, then you can use traffic control (tc) to supplement ASUS's rules with your own rule, making sure your rule would sort the packet into VOIP, before Asus's rule sorts it into default.