Comment 8 for bug 63757

Well, this bug following the exact description is actually fixed: with pfifo_fast (the default currently); you *do* have QoS. When you switch it out to sfq is the point where you no longer have QoS... but that's all just semantics.

What this gets to then is that applications need to be thought to be wise about the choices they make w/r/t how they classify the traffic they send out:

(From the socket(7) manpage)
SO_PRIORITY
    Set the protocol-defined priority for all packets to be sent on this socket. Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline. For ip(7), this also sets the IP type-of-service (TOS) field for outgoing packets. Setting a priority outside the range 0 to 6 requires the CAP_NET_ADMIN capability.

That setting can be set with setsockopt().

NetworkManager itself doesn't watch traffic so couldn't be applying special rules to it on a per-application basis.

Perhaps we could provide with a way to switch the scheduler on an interface from NM; but that seems like an advanced enough setting that I'd be a little weary of exposing it in UI, so the end benefit of doing such a change is low. We could still use this bug for that "request" though.

As for transmission, which seems to be the simplest way to reproduce such QoS issues; maybe it's not using the best defaults to be cautious enough with bandwidth. That's hard to choose, but I'm opening a bug task for it anyway.

Please, if you're running into such issues; file bugs with the application(s) that exhibit the issue.