I just stumbled on a good article on Internet QoS written by David Weinberger in 2002, which reminded me of an observation I've made that I haven't seen discussed elsewhere. (Perhaps a lack of reading on my part...).
There is a simple form of differential QoS that's already ubiquitous in the Internet today and it's being leveraged, wittingly or unwittingly, by VoIP service providers right now.
I'm referring to flow control -- specifically the fact the TCP/IP includes flow control and UDP/IP does not. Most of the traffic on the Internet is TCP traffic. When a link in the network becomes congested, the router driving that link starts dropping packets intermittently and randomly across all flows. The TCP source reacts to lost packets by requesting retransmission, but it also engages in flow control by backing off the rate at which it sends packets. UDP, on the other hand, does no retransmission and no flow control.
The effect of congestion is that UDP traffic suffers some packet loss, but the UDP source continues to send packets at whatever rate it desires. Meanwhile, TCP flows cooperatively reduce their packet transmission rates to share the remaining bandwidth. If the congested link has enough capacity to carry all of the offered UDP traffic and some of the TCP traffic, then the UDP traffic gets what it needs and the TCP traffic shares the remaining capacity. That sounds like differential quality of service to me.
Indeed, some limited experiments with Skype on a congested access link suggest this differential QoS is being used to advantage today. One of the neat things about Skype is that it will work in most circumstances, including behind firewalls and NATs that block all UDP traffic. In that case, Skype apparently sends voice traffic over TCP. But running voice over TCP on a congested link results in occasional dropouts and other anomalies in the voice conversation. Opening up outbound UDP ports allows the Skype traffic to leverage the UDP-TCP QoS difference and voice quality improves. I caution that I'm basing this on a single experiment. But the results seem consistent with what I would expect from TCP vs. UDP.
Investing in QoS is a poor idea as Dan Bricklin explains here. But with access networks tied up by monopolies or duopolies, most consumers have a limited opportunity to acquire additional access bandwidth and the UDP-TCP QoS difference I've discussed hits a sweet spot for a lot of today's DSL and cable access services.
Skype requires 46 kbps or so bi-directionally. While many DSL and cable modem services offer 1-3 Mbps downstream, their upstream capacity is limited, frequently to just 100-200 kbps. Having 46 kbps of UDP traffic share a 200 kbps link with multiple other TCP flows appears to work, i.e. it's OK if another family member sends a large email while I'm on Skype given Skype is using UDP.
I won't invest in QoS but I seem to be benefiting from the differential QoS that's inherent in the flow control difference between TCP and UDP.
Caution: This is only partly true. In some private correspondence, David Reed pointed out that, yes, on a congested link UDP traffic will take precedence over TCP traffic for the available bandwidth but this doesn't help VoIP traffic. When congestion occurs, the router queue in front of the congested link fills up and introduces significant delays.
See my revised comments here:
http://blogs.nmss.com/communications/2005/05/defacto_qos_rev.html
Posted by: Brough | June 16, 2005 at 03:37 PM