Fundamental Design Issues for the Future Internet

This paper takes a step back from QOS work and explains economically why QOS might be a good idea, and what issues need to be resolved in implementing it. The author uses a utility model to quantitatively explain some of the motivation for QOS and help understand the design choices. For example, he shows that priority scheduling provides better aggregate utility than FIFO when some flows care more about delay. Utility functions are also used to explain convincingly why best-effort works for bulk transfer applications but not for realtime applications where utility drops sharply below a certain level. This is an argument for admission control. Some back-of-the-envelope calculations also show that overprivisioning may not be sufficient if even a small number of users have extremely large flows. Finally, the author explains the tradeoff between different ways of identifying service classes for flows: while identifying them automatically in the network based on port number, protocol type, etc helps reuse applications, a pricing model approach where applications choose their service class can lead to more flexibility.

Obviously QOS did not take off in the wide-area Internet, and the reasons this happened provide valid criticisms of the paper. The main reasons why QOS didn't take off were probably improvements in bandwidth (and its price) and the difficulty in charing for services that use QOS. Despite the fact that a QOS system could increase utility for everybody, that kind of market won't be set up if it's complicated to determine pricing, account for usage, explain charges to users, get users to accept variable per-month pricing, etc. These "mundane" details were probably as important as technical challenges and architectural rigidity in hindering adoption of QOS, because it would be easy (if hacky) to wrap around existing protocols and clients and just put applications in the best-effort class if they are not specifically marked for QOS. The improvements in bandwidth also helped. Finally, there was perhaps less demand for online video than expected because of the distribution costs (multicast could have helped here, but it also didn't really take off). Many computer networking researchers express some surprise that in the end YouTube, with its non-live, low-quality content, has become the main form of online video.

Nonetheless, the fact that QOS didn't take off and the Internet is doing okay doesn't mean that we shouldn't consider how much better the Internet could be with a different service model. Certainly online video and audio services are still challenging to implement, low in quality, and not used extremely widely. Other interactive applications, such as games, also suffer from the unnecessarily large latencies imposed by the Internet - ask anyone who plays them. Even "bulk transfer" web-based applications use dedicated links or CDNs such as Akamai to reduce latencies, which has a significant effect on user engagement. So in the end, if we see *any* major qualitative change in the Internet in future years, it could well be due to lower latency enabling new applications.