Reader Dave Johnson argues that QoS isn’t necessary on big packet networks because the carrier can simply provision the network adequately to carry all possible traffic at once:
If an ISP has ample internal and outgoing bandwidth, as in more than enough to provide for the sum total of their customers allocations, then where does that leave the latency issue? The only way packets are delayed or refused is because there is not enough capacity on the destination wire. If there is enough capacity then *where* is the problem? Customers are by definition limited in the amount of data (under any protocol) that they can send, so all quantities are known.
As idiotic as this sounds, it’s a common Urban Myth, originally expressed in the works of David Isenberg, if not elsewhere. Bandwidth is free, you see, so just hook me up and don’t worry about it.
OK, let’s play along. How much bandwidth does an ISP have to have on its internal network to allow all of its customers to use all the bandwidth in their hookups all the time? Verizon’s FIOS customers have 100 megabit/sec connections, and there are 375,000 of them. So all Verizon needs for “ample” bandwidth inside its own network is a 37.5 terabit/sec (terabit being a million million) switch, and a similar sized connection to the public Internet.
Of course, that kind of bandwidth doesn’t exist.
Will it in the future? Maybe, but by then instead of worrying about 375,000 customers on the Verizon network, we’ll be worrying about 200 million Americans with 100 megabit/sec each. That adds up to 20,000 terabits/sec. I don’t see any switches capable of handing that load on the horizon, of course. This is a ridiculous exercise, and I only do it because the argument from hyper-regulation side is so lame.
Now lets assume that ISPs can cap bandwidth for each user to some level of transport per day, week, or month. Does that alter the arithmetic above? Actually, no, because you still have to design for peak load. If everybody wants to download American Idol at the same time, you need to accommodate that, so that’s where we are.
The fastest datalinks we have today are 40 gigabits/sec. So let’s take a bunch of them and bond them together to get a 20,000 terabit/sec pipe. We only need 500,000 of them. Supposing we can build a switch that handles 20 such pipes (not really practical today, because of limitations on bus speeds, but let’s be generous) you need 25,000 of them. But now how do we interconnect these switches to each other? Well, we just need to interconnect them to each other in a big mesh, but we’re playing with probabilities again, betting that no combination of users will over-use the path between one switch and anohter. So we’ll have to add another level of switches to enable each end-user to reach each end-user through any intermediate switch, and there will be a lot of these. Somebody has to pay for all these switches, because even if they were cheap (and they aren’t), they’re not free.
This is why QoS is needed: “more bandwidth” only works up to the economic and physical constraints on bandwidth, both of which are real.
So here’s the lab problem in summary: the fastest pipes we have are 40 gigabits/second. How many of them, and in what topology, do you need in order for 100 million users to transmit 100 megabits/second of traffic with no delay?