ARC dscp and WMM(TOS) dscp Inconsistency.

[jungyu_park]

Hi.

I am using R610 & Unleashed 200.10.10.5.246 firmware.
I discovered the ARC function, and it seems to be a technology that utilizes the dpi of QOSMOS.

It worked pretty well in my tests (google drive, youtube and etc) so I moved the dscp marking rules I was using on my windows 10 laptop to ARC.
ARC is a pretty attractive feature to me because it can be easily used with mobile smartphones and tablets.

In Android, it is difficult to set dscp or tos marking unless the app has a function.

ARC uses the following dscp values ​

voice : cs6 / video : af41 / best effort : cs0 / background : af11

and this works fine but strangely, when I set the same dscp marking on the router in front of the AP, it is applied differently to the wmm queue.

The problem is:

ARC vocie: cs6 > voice queue

router cs6 > voice queue (OK)

ARC video: af41 > video queue
router af41 > best effort (Wrong)

ARC best effort: cs0 > best effort
router cs0 > best effort (OK)

ARC background: af11 > background
router af11 > best effort (wrong)

I checked whether the packets in the queue are properly classified using the command below.

remote_ap_cli -A "get mqstats wlan32 all"

The question is, does ARC behave differently than TOS?

It uses different values set in the TOS, but they are categorized properly.

The TOS values of Ruckus AP are

ToS Classification-Voice = 0xE0 0xC0 0xB8
ToS Classification-Video = 0xA0 0x80
ToS Classification-Data = 0x0
ToS Classification-Background = 0x0

Voice is cs7 cs6 ef / video is cs5 cs4 / data and background are set to default values ​​(none, cs0).

Shouldn't the firmware match the values ​​of ARC and TOS?
I'm using them by manually typing.

tos classification video 0xA0,0x80,0x88
tos classification background 0x28

[eizens_putnins]

Interesting question, and I hope you'll get answer. 

But it probably is mainly theoretical question -- as it doesn't make much sense to do QOS on router connected to Internet -- as Internet doesn't support QOS and all you get is the best effort in any case...

QoS makes sense in Corporate network (which is fully controlled and can be set with QOS end to end), or even inside home network, if you have not enough bandwidth for applications you try to use  in the same time, so WiFi needs to prioritize which traffic to transfer to Internet the first.

     Normally nowadays WiFi is faster than Internet connection, so there is no much need to do so. Even if QOS is applied, it will be ignored outside of your LAN anyway, so what you can do is in the best case try to get traffic properly out to ISP, farther it will be Internet best effort... 

In most cases even corporate networks don't rely on QoS, as it is just so much improvement it can provide, but instead upgrade networks to be wire-speed - 1G switches with 10G uplinks and 10G or faster core are for all practical reasons wire-speed for any office use. When network is wire-speed, QOS is not relevant, as there are no overran buffers, no traffic needs to be dropped, and latency is very low.

In fact, for most office needs it would be absolutely enough to have 100Mb/s connections on PCs, so 1G network in reality doesn't need any specific QoS to be set, outside of default VoIP and video marking, as it has more bandwidth, than users can consume.

For some years most enterprise vendors don't manufacture any 100Mb/s switches (ok, actually some still do, but they are not typically used in enterprise environment), so with new equipment you usually get 1/10/40/100 Gb/s infrastructure which will be much faster than any realistic user needs.

If QOS becomes necessary,  it means there are some much more serious issues with network design (or just too slow Internet connection).

[jungyu_park]

@eizens_putnins 

Hello.

I am using 500Mbps symmetric internet.

I'm having a problem in practice, which is that when I use IDM (internet download manager) to open multiple TCP connections on Google Drive to download files, there is no margin on my bandwidth.

The actual IDM download speed exceeds 50MB/s, and in this state, other tasks (web browsing, video stream, etc.) cannot obtain the required bandwidth quickly.

I sometimes do more than 10 simultaneous downloads, which seems to exceed the AP's packet-per-second capability.

I am using openwrt on my intel celeron J4105 mini pc and I solved this bufferbloat issue of wired connection by setting sqm(cake).

However, sqm only works up to about 300Mbps for Wi-Fi connections, and beyond that (my speed) is ineffective.

This is probably because there is a separate buffer in the wireless mac-layer.

So I surfed the web for a while to solve this problem and found out that I can use WMM QoS through DSCP marking.

WMM QoS completely solved my problem and google drive downloads went to the background queue and became the last priority.

You can see the BK queue and this is the value created by google drive download.

As more and more applications use simultaneous connections such as torrent clients and steam and battle.net, setting these programs in the background using ARC will give users a better experience.

[syamantakomer]

Well done!

[jungyu_park]

@syamantak_omer​

Hello.

Does Ruckus have any plans to update the qosmos dpi engine?

It's been over a year since it was updated.

### QM_DPI VERSION INFO ###
DPI Signature Version:
DPI Engine Version : 5.6.0-39 (build date Oct 21 2020)
DPI Bundle Version : 1.510.1-22 (build date Oct 30 2020)

And one more thing, can't you change the dscp marking of background packets to cs1 in the qosmos dpi engine?
That engine uses af11.

But it conflicts with linux's cake scheduling.

https://github.com/torvalds/linux/blob/26291c54e111ff6ba87a164d85d4a4e134b7315c/net/sched/sch_cake.c...

Cake classifies af11 as background only in diffserv8 and besteffort in diffserv4 and diffserv3.

I am currently using a kernel module that changes af11 to background by changing the sch_cake code.
In diffserv8 it costs a bit more mbps than the other rules.

It's not difficult, but please consider changing the background marking to cs1 for better packet classification.

https://datatracker.ietf.org/doc/html/rfc8325#section-4.2.8

Unfortunately, there really is no corresponding fit for the High-
   Throughput Data service class within the constrained 4 Access
   Category [IEEE.802.11-2016] model.  If the High-Throughput Data
   service class is assigned to the Best Effort Access Category (AC_BE),
   then it would contend with Low-Latency Data (while [RFC4594]
   recommends a distinction in servicing between these service classes)
   as well as with the default service class; alternatively, if it is
   assigned to the Background Access Category (AC_BK), then it would
   receive a less-then-best-effort service and contend with Low-Priority
   Data (as discussed in Section 4.2.10).

   As such, since there is no directly corresponding fit for the High-
   Throughout Data service class within the [IEEE.802.11-2016] model, it
   is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby
   admitting it to the Best Effort Access Category (AC_BE).