Quality of Service is a contentious subject. Every now and again, I look at Wikipedia's QoS page. (Here are my comments 18 months ago). While the Wikipedia content continues to evolve, it always downplays anything that questions the value of sophisticated QoS. As of today, the section titled "QoS Problems" has been cut back to a single sentence (which does reference a classic anti-QoS paper): "Internet2's QoS Working Group concluded that increasing bandwidth is probably more practical than implementing QoS."
Rather than directly debunk QoS yet again, let me investigate where QoS is actually useful by looking real life situations and the deployed solutions that allow for robust services despite congestion. Identifying common elements in successful deployed solutions is much more realistic than theorizing about NGNs that still await deployment.
The first thing to notice: the only problem is on access links. As I've written before:
Once you get beyond the access network, every link in the Internet —
local, regional, national or international — is carrying multiplexed
traffic from many users. Multiplexing many, many, bursty flows results
in relatively predictable volume. Traffic volumes vary by time of day,
but these links don’t saturate, except as a result of poor engineering
or forecasting on the part of an ISP, or failures in other parts of the
network causing rerouted traffic. Either case generates a rapid
response from any ISP that expects to remain in business. So “best
efforts” in the Internet core means sub-millisecond delay variations
and near zero lost packets.
Net, net: you never need QoS priority schemes in the core, all traffic gets excellent service.
Access links are another story for two reasons. First it can be very expensive to add more bandwidth. This may be a byproduct of political/ regulatory issues, but we won't go there, at least in this post. :-) Second, an access link may saturate due to an outgoing email with large Powerpoint attachment (the home case) or an equivalent event in the corporate environment, for example, transfer of a large CAD file.
But these are solved problems with multiple commercial products on the market for residential and corporate use. It's worth looking at what these products do in order to understand exactly what kind of QoS is really required, when you can't just provision more bandwidth.
In the corporate market, there are two approaches. The brute force approach splits voice and video telephony traffic from data traffic using two separate Internet connections with the VoIP connection sized to preclude any potential congestions. When a single access link is shared, the typical solution employs a QoS router
at the customer’s end. The QoS router gives absolute priority to outbound VoIP
packets and protects inbound VoIP packets by active traffic shaping;
i.e., by signaling remote TCP hosts to throttle inbound TCP data flows
so there’s enough capacity for inbound VoIP packets.
Elsewhere within corporate LANs, there is either no QoS or simple priorities. Since VoIP traffic is a tiny percentage of all traffic, it can be given
absolute priority without noticeably impacting other applications.
Thus some enterprise VoIP installations use QoS based on DiffServ or
Ethernet 802.11p/q. Typically there are just two classes assigned, with
absolute priority for VoIP and video telephony.
I've written about equivalent solutions for residential situations that support VoIP and interactive gaming. The solution? Consumer VoIP phone adapters incorporate simple
priority and have the ability to fragment large packets (so as to
reduce serialization delays). Because it's so useful for VoIP and also for
interactive gaming, this functionality is showing up in popular residential routers
from Linksys, Netgear, etc.
Two classes and simple priority is what it takes ― Gold bits for voice (and video and interactive gaming); Brown bits for everything else.
And that's only when you can't get more bandwidth. On your own premises, it's likely cheaper and easier to upgrade to Fast Ethernet or Gigabit Ethernet.