How misconceptions confuse the QoS issue

Over on Telepocalypse Martin links to a piece by Bob Frankston on QoS and he tries to draw an analogy and make a point from it.

Again I am reminded ludicrous how the QoS and control debates are. Two points spring to mind after reading Bob's piece (1) everyone who maintains that having QoS means that everyone is throttled is ehm, mistaken, to put it mildly. (2) using the analogy, no-one disputes sidewalks versus roads. One lane for the slow traffic and one for the fast. In my country you regularly have a lane between that, for bicycles, coming to three classes of service.

There will ALWAYS be a bottleneck somewhere. The most likely place will be the first place where aggregation is done, as it is economically infeasible to buy as much bandwidth to the rest of the world as you are selling to you customers (say you are selling 1 million broadband accounts for 1Mb/s each, you will not be buying 1*10^6 Mb/s bandwidth. A star network will have the bottleneck where the star is connected to the rest of the world, unless no-one really wants to communicate with the rest of the world, much. (think peer to peer filesharing, assuming p2p software learns about the concept of nearby nodes vs far away nodes.)

The way to address this bottleneck today is by aggregating the bandwidth without regard to what is being carried, so best-effort. There is a whole slew of applications that really can not live with the 20x over provisioned asymmetric broadband we have now in a world where broadband users are using their broadband more and more (so the utilization goes up and everyone suffers). My own DSL line sometimes has 10% loss these days, meaning the net is being used more in my area. This means VoIP is getting iffy and the telcos who are rolling it out need to do some QoS marking on the VoIP in order to get it to work.

Contrary to popular belief QoS for broadband IP networks is a means to have several kinds of bandwidth on the same line (something you cannot do on a road and hence the analogy breaks). If you are a proponent or a an opponent of QoS and think that this means setting bandwidth aside for applications and thus making it unusable for others full-timeyou are, again, ehm, mistaken.

Now the RIGHT way to do QoS is to schedule the several kinds of bandwidth (from best-effort for email, to high-bandwidth and guaranteed for video calls) over the same infrastructure. This bandwidth should be requestable on-demand by service providers who need more than the basic best-effort connectivity for their services. This will require some upgrades to the existing infrastructure but they ought to be recouped easily because of the value created by enabling an open(!) network that can deliver more applications than the broadband internet access sold now.

Now the math of scheduling QoS determines that it is easy to have something like 50%-60% of guaranteed real-time traffic of the network but becomes increasingly expensive when you want to take it to 80%-90%. So the cheapest way is to introduce the tech needed to deliver QoS and double the available bandwidth. This will lead to there being more best-effort bandwidth available if there are no video calls to carry, so QoS gives more rather than less bandwidth to the people who complain today that QoS will take ‘their’ bandwidth away and it give them the same amount of best-effort bandwidth in the presence of video calls.

There are people in this industry who like me have known of the shape of doing QoS right since the turn of the century, and even a few who like me know of the exact tech needed to do it. Why then does no one else seem to come to the same conclusion and rather fight over misconceptions?