A hierarchy of dumb FIFO queues does not make a real QoS system. It can produce reasonable-looking benchmark numbers when the prioritization rules and benchmark are contrived to match, but in the face of real-world traffic that uses HTTP to carry vastly different kinds of traffic over links that don't have constant bandwidth and latency, OpenBSD is hopeless. Even the rate-limiting capability that OpenBSD has is rudimentary and lacks the ability to account for per-packet overhead and framing overhead, which is necessary for accurate traffic shaping on common service types like ADSL.
If you say you don't see any disadvantages for OpenBSD on QoS, then your idea of QoS is twenty years out of date.
You're right, OpenBSD no longer has ECN, and my comments regarding OpenBSD were out of date.
And yes, ECN is far more effective because it provides feedback to the sender.
All of the BSDs are still way behind; the best by only a few years, while others are stuck in the 1990s.
I just wish tc had an interface understandable by your average sysadmin. I have to dig into the source to figure out what anything does, but not many users will have the ability/desire to do that.
I believe the syntax for writing QoS on FreeBSD and OpenBSD provides very good expressive capability [1]. By using tagging [2], one can assign QoS priority to anything that a firewall rule can define.
Having used FreeBSD QoS on dial-up, ISDN, DSL and cable over the years, it is this expressiveness that is one of the reasons I prefer the pf packet filter and thus BSD.
Here's an example for bandwidth limited wan. Interactive ssh sessions get a queue with a minimum bandwidth; scp and sftp bulk transfers go to a separate queue.
[1] PF - Packet Queueing and Prioritization http://www.openbsd.org/faq/pf/queueing.html[2] PF - Packet Tagging (Policy Filtering) http://www.openbsd.org/faq/pf/tagging.html