FlexQoS QoS does not handle youtube upload

[vrapp]

Family member is uploading a video from his phone to YouTube. The setting in QOS is Adaptive/Gaming, FlexQoS is installed, but the game (WorldOfTanks) on a Windows desktop gets ping 1+s. I'd say, QoS is not doing its job.

Perhaps even more important, router's webui became practically non-responsive either, so it's not even possible to check what is going on.

Router: AC68P, 386.1 beta 1.

 

[dave14305]

What is your ISP Download/Upload speed, and what have you configured as Down and Up Mbps in the QoS page?

 

[vrapp]

Configured as up/down-= 0.87/28; the real top achieved speed is 1/30.

 

[dave14305]

I recently came across this blog post while reading on forum.openwrt.org. It argues that gaming is doomed with less than 3Mbit upload. This guy does some creative QoS stuff for OpenWRT users dedicated to gaming using hfsc instead of the more traditional htb/fq_codel or CAKE.

Why gaming on a DSL line is terrible and the math says there’s nothing you can do about it | Models Of Reality

models.street-artists.org

 

[vrapp]

Thanks, I will check it out. The thread there is so long, it's not even clear what is the final recipe.
As for the insufficient upload speed - I would totally understand if the ping went up from the "unobstructed" 10ms to 40-50ms. But to 1,000? And "adaptive" probably means that it should be able to tell bulk upload from the game - but if it apparently does not , then perhaps it's better to abandon "adaptive" and switch to "traditional"?

 

[dave14305]

How have you configured FlexQoS? Can you post a flexqos debug output (run from ssh)?

 

[vrapp]

I did not make any changes in FlexQoS configuration, left it as it was installed.

Here's debug output:

FlexQoS v1.1.0 released 2020-12-13

Debug date : 2020-12-18 22:28:26-0600
Router Model : RT-AC68P
Firmware Ver : 386.1_beta1
DPI/Sig Ver : 2.0.1 / 2.208
WAN iface : eth0
tc WAN iface : eth0
IPv6 : dhcp6
Undf Prio : 2
Down Band : 28672
Up Band : 891
***********
Net Control : 1:11
Work-From-Home: 1:13
Gaming : 1:10
Others : 1:17
Web Surfing : 1:15
Streaming : 1:12
File Downloads: 1:16
Game Downloads: 1:14
***********
Downrates : 4300, 1433, 8601, 5734, 1433, 2867, 1433, 2867
Downceils : 28672, 28672, 28672, 28672, 28672, 28672, 28672, 28672
Downbursts : 4800, 3200, 9600, 6400, 3200, 3200, 3200, 3200
DownCbursts : 35200, 35200, 35200, 35200, 35200, 35200, 35200, 35200
DownQuantums : 53750, 17912, 107512, 71675, 17912, 35837, 17912, 35837
***********
Uprates : 133, 44, 89, 178, 44, 89, 44, 267
Upceils : 891, 891, 891, 891, 891, 891, 891, 891
Upbursts : 3200, 3200, 3200, 3200, 3200, 3200, 3200, 3200
UpCbursts : 3200, 3200, 3200, 3200, 3200, 3200, 3200, 3200
UpQuantums : 1662, 1514, 1514, 2225, 1514, 1514, 1514, 3337
***********
iptables settings: <>>udp>>500,4500>>3<>>udp>16384:16415>>>3<>>tcp>>119,563>>5<>>tcp>>80,443>08****>7
-o br0 -p udp -m multiport --sports 500,4500 -j MARK --set-mark 0x8006ffff/0x3fffff
-o eth0 -p udp -m multiport --dports 500,4500 -j MARK --set-mark 0x4006ffff/0x3fffff
-o br0 -p udp -m multiport --sports 500,4500 -j MARK --set-mark 0x8006ffff/0x3fffff
-o eth0 -p udp -m multiport --dports 500,4500 -j MARK --set-mark 0x4006ffff/0x3fffff
-o br0 -p udp -m multiport --dports 16384:16415 -j MARK --set-mark 0x8006ffff/0x3fffff
-o eth0 -p udp -m multiport --sports 16384:16415 -j MARK --set-mark 0x4006ffff/0x3fffff
-o br0 -p udp -m multiport --dports 16384:16415 -j MARK --set-mark 0x8006ffff/0x3fffff
-o eth0 -p udp -m multiport --sports 16384:16415 -j MARK --set-mark 0x4006ffff/0x3fffff
-o br0 -p tcp -m multiport --sports 119,563 -j MARK --set-mark 0x8003ffff/0x3fffff
-o eth0 -p tcp -m multiport --dports 119,563 -j MARK --set-mark 0x4003ffff/0x3fffff
-o br0 -p tcp -m multiport --sports 119,563 -j MARK --set-mark 0x8003ffff/0x3fffff
-o eth0 -p tcp -m multiport --dports 119,563 -j MARK --set-mark 0x4003ffff/0x3fffff
-o br0 -p tcp -m multiport --sports 80,443 -m mark --mark 0x80080000/0xc03f0000 -j MARK --set-mark 0x803fffff/0x3fffff
-o eth0 -p tcp -m multiport --dports 80,443 -m mark --mark 0x40080000/0xc03f0000 -j MARK --set-mark 0x403fffff/0x3fffff
-o br0 -p tcp -m multiport --sports 80,443 -m mark --mark 0x80080000/0xc03f0000 -j MARK --set-mark 0x803fffff/0x3fffff
-o eth0 -p tcp -m multiport --dports 80,443 -m mark --mark 0x40080000/0xc03f0000 -j MARK --set-mark 0x403fffff/0x3fffff
***********
appdb rules: <000000>6<00006B>6<0D0007>5<0D0086>5<0D00A0>5<12003F>4<13****>4<14****>4<1A****>5
filter change dev br0 prio 2 protocol all handle 828::800 u32 flowid 1:17
filter change dev eth0 prio 2 protocol all handle 828::800 u32 flowid 1:17
filter add dev br0 protocol all prio 2 u32 match mark 0x8000006B 0xc03fffff flowid 1:17
filter add dev eth0 protocol all prio 2 u32 match mark 0x4000006B 0xc03fffff flowid 1:17
filter add dev br0 protocol all prio 15 u32 match mark 0x800D0007 0xc03fffff flowid 1:16
filter add dev eth0 protocol all prio 15 u32 match mark 0x400D0007 0xc03fffff flowid 1:16
filter add dev br0 protocol all prio 15 u32 match mark 0x800D0086 0xc03fffff flowid 1:16
filter add dev eth0 protocol all prio 15 u32 match mark 0x400D0086 0xc03fffff flowid 1:16
filter add dev br0 protocol all prio 15 u32 match mark 0x800D00A0 0xc03fffff flowid 1:16
filter add dev eth0 protocol all prio 15 u32 match mark 0x400D00A0 0xc03fffff flowid 1:16
filter add dev br0 protocol all prio 20 u32 match mark 0x8012003F 0xc03fffff flowid 1:15
filter add dev eth0 protocol all prio 20 u32 match mark 0x4012003F 0xc03fffff flowid 1:15
filter change dev br0 prio 22 protocol all handle 802::800 u32 flowid 1:15
filter change dev eth0 prio 22 protocol all handle 802::800 u32 flowid 1:15
filter change dev br0 prio 23 protocol all handle 805::800 u32 flowid 1:15
filter change dev eth0 prio 23 protocol all handle 805::800 u32 flowid 1:15
filter change dev br0 prio 2 protocol all handle 828::802 u32 flowid 1:16
filter change dev eth0 prio 2 protocol all handle 828::802 u32 flowid 1:16



And here's the change of ping at another computer once the phone has started the upload. Increase ~100 times over.

Reply from 8.8.8.8: bytes=32 time=11ms TTL=116
Reply from 8.8.8.8: bytes=32 time=12ms TTL=116
Reply from 8.8.8.8: bytes=32 time=11ms TTL=116
Reply from 8.8.8.8: bytes=32 time=12ms TTL=116
Reply from 8.8.8.8: bytes=32 time=14ms TTL=116
Reply from 8.8.8.8: bytes=32 time=13ms TTL=116
Reply from 8.8.8.8: bytes=32 time=14ms TTL=116
Reply from 8.8.8.8: bytes=32 time=651ms TTL=116
Reply from 8.8.8.8: bytes=32 time=1164ms TTL=116
Reply from 8.8.8.8: bytes=32 time=1437ms TTL=116
Request timed out.
Reply from 8.8.8.8: bytes=32 time=2720ms TTL=116
Reply from 8.8.8.8: bytes=32 time=1617ms TTL=116
Reply from 8.8.8.8: bytes=32 time=758ms TTL=116
Reply from 8.8.8.8: bytes=32 time=837ms TTL=116

 

[dave14305]

The last time I tested Adaptive QoS with IPv6, the upload of IPv6 traffic was not being limited. I don’t know if this changed with 386 or not, but is it possible to test again after disabling IPv6?

 

[CaptnDanLKW]

TBH, you are also running the first beta of a new, major version change. The addons are specifically the items which need testing & debugging and the ones likely to be broken.

You should first verify the problem also exists with 384_19.

 

[vrapp]

I will try 384.19. For now, an interesting observation: this happens only with this specific Android phone. Right now I'm uploading large file from another Windows computer, the speed is at the limit, but the ping on other computers is 12-17, i.e. it does not change at all. I also tried youtube upload from an iPhone (the first one was Android), and it also had practically no effect on anyone else. So the question is, what can be special about Android phone? I tried it again, and it again stopped everyone else like before.

 

[Odkrys]

android youtube app use udp 443 port. quic protocol. check it.

 

[dave14305]

Your upload bandwidth is so small that you really need to tweak the per-class bandwidth settings in the FlexQoS page. By default, it gives Others category 30% of your bandwidth, which you have as your lowest priority via the Gaming prioritization scheme. Same for the remaining classes to ensure enough guaranteed (minimum) bandwidth for your highest priorities.

 

[vrapp]

You should first verify the problem also exists with 384_19.

I tried it in the released 384.19, and it was all the same - once the upload started, the ping on other computers went from 10-15ms to 1,000-1,200 ms. It was absolutely the same with and without FlexQoS, and even with QoS turned off completely.
I also tried it again with iPhone, and it looks like I was wrong when I said that it did not experience anything - it did. I probably disconnected it from wi-fi when I measured it last time.
On Iphone, I now tried uploading from Youtube app, and from the browser. From the app, the effect was the same, i.e. ping on another computer went up to ~1,000ms. But when I uploaded the same video from Safari, the ping went to 500-600, and I noticed that Bandwidth Monitor was showing not increased upload traffic on iPhone, but the download one, although the phone was definitely uploading.

Your upload bandwidth is so small that you really need to tweak the per-class bandwidth settings in the FlexQoS page. By default, it gives Others category 30% of your bandwidth, which you have as your lowest priority via the Gaming prioritization scheme. Same for the remaining classes to ensure enough guaranteed (minimum) bandwidth for your highest priorities.

So, what values do you suggest to specify?

 

[vrapp]

I switched QoS to from Flexible Adaptive to Traditional, and the problem was gone - with upload in progress, the ping on another computer increased from 10-12ms to only 50-60ms, rather than to 1,000+ . However, it apparently created new problem of slow download from the attached USB . Is it possible to avoid both problems somehow, with either QoS?

 

[L&LD]

What is Flexible QoS? Are you referring to FlexQoS instead?

 

[vrapp]

Sorry - I mean "adaptive". Tried with and without FlexQos.

 

[vrapp]

The last time I tested Adaptive QoS with IPv6, the upload of IPv6 traffic was not being limited. I don’t know if this changed with 386 or not, but is it possible to test again after disabling IPv6?

Tried without IPv6, no change.

 

[vrapp]

Today I compared this behavior to the Asus firmware on my AC-68P. Both problems disappeared. I switched two times back and forth between Asus RT-AC68P_9.0.0.4_386_41994-g769f84f and Merlin's 386.1.2, and the difference was stable: with the QoS set to Adaptive, youtube upload by one LAN workstation caused the ping to 8.8.8.8 on other workstations going from the usual 10-12ms to 1,000ms and more under Merlin; under Asus, it practically did not change at all. With QoS set to Traditional, downloading a file from USB3-attached storage was going with the speed 300-400KB instead of the usual 12-15 MB/sec under Merlin's; with Asus there was no slowdown, same 12-15MB/sec.
If I understand correctly, QoS is a closed code, and Merlin's modifications don't touch it; but it's probably possible that something in that closed code analyzes the presence of firmware components "outside" of it, and when it does not see the version numbers it expects, it changes the way it works.

 

[L&LD]

Was that with a full reset to factory defaults after flashing the firmware you were testing? If not, the results are less meaningful.

 

[vrapp]

I did not do factory reset after flushing Asus firmware that resolved both problems, but in the previous experiments with Merlin's, yes, I did.