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?

The Internet is Free as in Lunch

You find them in the IETF, you will find them at universities and you will find them elsewhere, people who hold that the Internet is/should be free. Now the word free has many connotations. So you will hear that the Internet should be Free as in Beer (so gratis), and or Free as in Speech (so you can say what you like). Just look around you and these statements seem quaint at best. I hold that by aspiring these unrealistic ideals over the Internet makes it Free as in Lunch.

'There is no such thing as a free lunch.' There are always strings attached. By saying that the Internet should be Free one denies the basic economic and political landscape that permeates everything we do. Thinking that these do not apply to the Internet is naive, forcing these ideas on others is dangerous.

Freedom as in beer when applied to a service only happens when someone else pays the bill, i.e. when you are a student at a university or an employee at same. The costs of the Internet are real, someone will have to pay them. Some of these costs could be glossed over when the only way to access the Internet was a 56k modem. With broadband access the costs explode as more and more people actually use the bandwidth more intensively. Any party offering broadband Internet access today will have to face this problem. Naturally the current actions of the telcos to get the money for this from the Google's of the world through extortion is misguided but some way has to be found to cover these costs.

The costs of the bandwidth will end up at the end-user in some shape or form. Thinking that Google is free, of MSN is naive in the extreme. Any website that is offering a complex service apparently for free will have some way to recoup its costs. Such a service will have much equipment to run, software to write and maintain, marketing to do etc. all of this costs money. Google is supported by ads and Google's stock price while MSN is sponsored by ads and Microsoft's war-chest (sales of Windows and Office at monopoly-inflated prices).

As for other apparently free sites, ask yourself the question if you can see a feasible way for them to recoup their costs from you visiting their site. If there isn't there must be hidden strings attached. I agree looking at the world this way makes you really paranoid doing this but it actually is insightful. In the last .com boom and bust we learned that in some cases the hidden strings lead straight to people's pension funds and jobs. There is not much left where that came from, so today the money must come from somewhere else. McAfee is offering the tool siteadvisor that will warn you for sites where the hidden strings are Spyware etc. In some cases the hidden strings are in the form of the personal information you give to the site in order to use it. This information can be used for targeted ads to lure you into impulse purchases. This information can also be used for illegal practices such as identity theft or burglary when you are not at home.

Maintaining that the Internet is free as in beer is dangerous as there are hidden strings attached.

Freedom as in speech depends on being protected from the backlash of your statements. The ability to speak anonymously is a great way to achieve that protection, anything else will depend on the restraint of others not to use the knowledge that they know who you are. A cartoon from 1993 claims that on 'On the Internet, Nobody Knows You're a Dog'. That might have been true in the days when the way to get onto the net you were sharing a single UNIX machine with many others that your internet access could not be tracked back to you. Today with personal computers (so IP addresses can be linked to persons) and web-cookies (so different browsing sessions can be linked) people do know you are a dog, and what kind of dog you are, in which area you live and when you will be in need of a new flea collar.

As long as people think they can use the Internet anonymously it is a great way to snoop on its users. Arrests of people based on the websites they visit is no longer something they do in China only. It happens in the 'free' west too. The Internet is a string that people use to hang themselves. Claiming that the Internet is Free as in speech is a dangerous as there are hidden strings attached.

With all these strings attached to its freedom, the Internet is Free as in Lunch. We would do better when we acknowledged the reality and find a way to deal with the fact that the Internet costs money to run and that Internet use is not inherently anonymous.

On the worrying state of networking standards

This entry was triggered by a column by David Cartwright regarding the Acid2 test for web browsers. The test shows how well a browser implements CSS by feeding it a complex bit of invalid CSS. Only a few browsers actually pass the test, Internet Explorer fails horribly and Mozilla/Firefox fares slightly better but also does not render this image correctly.

David Cartwright goes on to say that if so many browsers, both commercial and open source do not render this test correctly

“there can only be three reasons:

1. The browsers are full of bugs
2. The authors have chosen to implement only a subset of the specification
3. The specification is ambiguous or incomplete

All of these are worrying.”

David is right, from experience I can tell that the problem actually starts at reason 3 and then goes via the 2^nd reason to the 1^st. When the networking standard is not a rendeing system like CSS but a complete protocol the problems multiply. Networking standards (both protocols and datastrcutures) are in a sorry state. I spot a number of worrying trends (1) Inexpert protocol creation, (2) incomplete specification and (3) overly complex designs

Inexpert protocol creation

Those who make the protocol often are not the experts who have an actual experience in building this kind of thing, getting it to interwork with many other independent implementations and scale to millions of global users. Unfortunately ever more often our next generation of networking standards is created by quite the opposite. Students (both undergraduate and PhD) and employees of various companies alike claiming that they know nothing about the subject makes them far better qualified to create a standard for it than experts who have “preconceptions”.

Take for instance the Session Initiation Protocol (SIP). SIP was created by Henning Schulzerinne and his then PhD student Jonathan Rosenberg. Henning has gone on the record he created SIP to allow his students to “play” (his words) with telephony. Jonathan writes in his PhD thesis:

… drawbacks are its substantial (and continually growing) complexity, and the wealth of different ways to accomplish the same function, both of which have led to interoperability problems. …Primitives are provided for admission and bandwidth control. These are not useful outside of LAN-based IP telephony, since …. cannot determine capacity for media calls in a general purpose IP network. … extensibility relies on protocol versioning and vendor specific attributes scattered throughout the protocol, which is very limited.

Most importantly,… has difficulty delivering new services. …. A specification is required for every feature. This limits the speed at which features can be added, and limits vendor creativity….

He wrote this about H.323 the then dominant VoIP protocol which he uses as the reason for creation for SIP. Unfortunately today this can be said doubly for SIP. The SIP specification is no longer 23 pages but 269, and that is only the base spec. Any implementation needs to implement a set of standards and internet drafts to get to a working product.

Incomplete specification

This leads to the second category of problems, incomplete specification. When Jonathan Rosenberg attacked H.323 stating that it was too complex. Actually when compared to today’s Internet standards H.323 was an example of tight specification. True it was complex but how these elements locked together was clear for implementers. (BTW: what got university types and people from small companies worked up was that H.323 made the decision to have its protocol, which was defined in ASN.1, encoded with the method that required an expensive toolset rather than the kind for which many toolsets were freely available a small error of judgment that led to huge effects.)

SIP on the other hand is defined as a text protocol in a very freeform way. This is also very common in networking specifications today, and some go as far as using XML. While a text-based protocol is very convenient to debate about either in a meeting room or on a mailing list, and hence read by humans, the freeform way in which humans may read a message is not very useful for computer programs.

Why is freeform text so bad? An example; if you can use the name of the person you want to send a message to several times in a message to whom should you send it, the last one, all of them? If it is the last one, you will need to check the entire message to see if there is the final recipient lurking there. Today this unfortunately happens in a lot of cases for all kinds of essential information, it is specified that it needs to be there just not how many times, where in the information sent or how to handle error cases.

A complete specification defines for every error case how to handle it. This is what makes specifications so large and so complex to write. So often the specifiers get stuck at the sunny day scenario where everything goes as planned and trust to the common sense of the implementer to handle the error case in the way that is obviously correct. This is where things go wrong, what is obvious to one person is unclear to another. And of course a short spec is a good one, what kind of document would you like to get past management, a 25 page one or a 300 page one?

There is an alternative. I was once involved in a project where we were on our way to create standards that allowed automatic testing of the implementation. Something that would help a great deal in getting a technology deployed quickly and correctly. However this was killed because it was not seen as progressing fast enough. To my satisfaction has the project that came after it sill not delivered anything usable and has bogged down in the quagmire that we managed to avoid by going the long way.

Overly complex designs

On top of all of this standards suffer from feature creep. Partly this is because of enthusiasm of the creators. Partly this is because the creators usually can not agree on everything, person/company/country A wants one thing B wants another, they can not agree and hence both get in. In some standards they do a better job at separating all of these options than in others. So we get overly complex standards with too many features for any implementer to build, one has a usable product when only a part of the features. This of course culminates in the number of bugs, the more complex anything is the more changes one has to make a mistake implementing.

Coming back to the original column, David Cartwright ends by posing the question “how many packages we rely on day to day are hideously broken but we simply don’t know it”. Well David, I can tell you judging from the base material of the networking standards, a whole lot. I singled out SIP because I find it annoying that a technology that was so hyped is so broken (one wishes that as much attention went into its technology as in its marketing) but SIP is just a tip of the iceberg, an example of the state of networking standards. We have a long way to go before Internet standards are as good as we’d wish which may lead to products we can rely on.