Yes, that's absolutely correct on a per-peer basis. The trouble is that for a large torrent, there could be hundreds of peers each attempting to negotiate on the link, and that can cause problems. My experience is with experimenting with just about every QoS setting possible on a Cisco ASA hooked up to the cheapest Verizon DSL several years back- I haven't bothered lately but that's because my home pipe these days is thick enough to make it not matter.
BT would be a lot friendlier for traffic shaping if the tracker played a more active role in flow control, or if otherwise some distributed consensus was negotiated regarding wanting more unsolicited connections.
I'd rather like better data on the problem you describe, as it does not seem to line up with the experimental data I have so far on the interaction of AQM and packet scheduling techniques with bittorrent.
Which predated the development of fq_codel, which is the fair queue (flow queue) + aqm hybrid now deployed in cerowrt, openwrt, and countless other QoS systems. That paper only explored RED or SFQ, not a hybrid.
What I think the positive effects we are seeing now are several factors. 1) a "torrent" is usually on 6 flows at a time, rotating to a new flow every 15 seconds or so. 2) The additional peers trying to negotiate IS a problem at very low rates (say below 4mbit) but invisible at higher rates. 3) reducing latencies under load to under 5ms has enormous gains in bidirectional throughput, which more than compensate for losing torrent's delay based backoff mechanism, which only backs off at 100ms. Which would you rather have, 100ms latency or 5ms?
See, for example, what the fq_codel system does for verizon and comcast here:
We got back 5x free bandwidth on the verizon test. And if you are experiencing 5ms worth of latency does it really matter if you have 6 torrents in the background?
(80, yes! but it's a function of your bandwidth also and... and... more testing is indicated.)
... so I haven't got around to redoing the research and writing a successor paper on it, and probably won't anytime soon. The original authors of that paper have gone off to do several papers of extensive analyses of RED vs ledbat, and I think they've largely gone off into the weeds, not that I mind having that analysis as a basis if ever we (or someone) gets around to analyzing fq_codel with some of those techniques.
Please feel free to test re torrent with a system that uses something like openwrt's qos-scripts or cerowrt's SQM system.
The conclusion of the original paper was that only classification seemed to be an answer to even further deprioritize torrent in an AQM'd and FQ'd world. (which the above systems can do also)
BT would be a lot friendlier for traffic shaping if the tracker played a more active role in flow control, or if otherwise some distributed consensus was negotiated regarding wanting more unsolicited connections.