qBitorrent - using ToS and DSCP to put bittorrent into low effort "Bulk" QoS catagory.

[BrianG61UK]

I saw in advanced settings of qBittorrent on my Windows 11 PC that, by default, the ToS of connections to peers is set to 4 implying that the DSCP will be 1 for these connections to peers. And after checking I see DSCP=1 means low effort QoS so that makes all makes good sense.

Then I set my router to put connections with DSCP=1 into a low effort "Bulk" category. But I get no effect and nothing goes into the "Bulk" category.

Has this part of qBitorrent on Windows been checked and/or tested?

I could have got something wrong, but I had no problem getting my router to put my VoIP phone in a high effort "Voice" category when DSCP=46 or DSCP=26 so I think I am probably doing it correctly.

My attempts to see any incoming packets from my PC with DSCP=1, or indeed any non zero value, while doing a torrent download (by using tcpdump on my router) failed too.

Anyone got any ideas why I can't make this work?
Is this perhaps just broken and can't be done on Windows, or perhaps just not on Windows 11?
Or just broken and never tested in qBitorrent perhaps?
Or is it just me?

[BrianG61UK]

I'm leaning towards something being really broken in the implementation of CAKE QoS that I was using on my router. So it's likely there is nothing wrong in qBittorrent.

[LilTroy]

It's possible that this is a bug but Windows is also known to clear DSCP marks set by user apps. The TOS advanced setting in qBittorrent is part of LibTorrent which is obviously a core dependency. Yes, a TOS value of 4 maps to the DSCP value of 1. Technically the background bulk data traffic class is referred to in the literature as ‘Lower Than Best Effort’ (LBE/LE) or alternatively as ‘Less Than Best Effort’ in the RFC 8622 standard spec. All other classes have precedence over it. However, it's not strictly necessary to achieve the desired lower priority effect. That's what the custom designed Micro Transport Protocol (μTP) and magical congestion control algorithm LEDBAT is for. The latter stands for ‘Low Extra Delay Background Transport’ which was designed specifically for torrenting. It works so well that Microsoft & Apple modified it and incorporated it into their own OSes. MS made the necessary modifications so that it'd work with TCP, rather than UDP, and added it natively to the OS in order to deliver Windows Updates. BITS clients make use of it on user uploads. MS named theirs LEDBAT++ because they fixed a few known issues with the original LEDBAT algorithm (note: their version doesn't play well when BBR congestion control is also present on the same link).

Getting back to the aforementioned RFC, here are a couple relevant snippets of interest. Pay attention to the bolded parts in particular.

In the case of a lack of a transport protocol and congestion control that are adapted to LE, applications can also use existing common transport protocols and implement session resumption by trying to reestablish failed connections. Congestion control is not only useful for letting the flows within the LE Behavior Aggregate (BA) adapt to the available bandwidth, which may be highly fluctuating; it is also essential if LE traffic is mapped to the default PHB in DS domains that do not support LE. In this case, the use of background transport protocols, e.g., similar to Low Extra Delay Background Transport (LEDBAT) [RFC6817], is expedient.

In the case that LE traffic is mapped to the default PHB, LE traffic may compete with BE traffic for the same resources and thus adversely affect the original BE aggregate. Applications that want to ensure the lower precedence compared to BE traffic even in such cases SHOULD additionally use a corresponding lower-than-BE transport protocol [RFC6297], e.g., LEDBAT [RFC6817].

Ideally, μTP with its built-in LEDBAT congestion control should be used with L3 DSCP QoS packet markings, and optionally L2 CoS frame tagging, but it isn't going to make or break its operation. Especially given how poorly QoS works when traffic is routed over the public internet. It's highly unreliable there since routers/switches in the path often ignore the markings, reclassify the flows, and tag the packets according to their own QoS policies. ISPs will then shape (throttle) & police it as they see fit. Where QoS works beautifully is inside enterprise & corporate environments on private networks that are tightly controlled and managed.

On a final note you can override apps that set their own DSCP markings, and prevent Windows from clearing them, through policy-based QoS in the Group Policy editor. If this actually is a bug in the qBittorrent client then this will resolve it by letting you force DSCP 1 → Enable DSCP QoS Tagging on Windows Machines. You can also set DSCP values on each individual network adapter inside the registry, through PowerShell cmdlets, or programmatically with Windows' respective QoS API. As an experiment I just captured hundreds of thousands of packets while downloading a torrent. I configured the display filter in Wireshark to only show DSCP tagged packets (ip.dsfield.dscp != 0). The result was as expected, only a fraction of the total traffic, both inbound & outbound, contained markings. I observed over a half-dozen DSCP markings from different peers in the swarm with 0 (unmarked) being by far the most prevalent. No surprise there since it's the default ‘Best Effort’ (BE) classification after all.

Local Group Policy

GPol.png (34.51 KiB) Viewed 271 times

Packet Capture

PCap.png (50.45 KiB) Viewed 271 times