Supporting Real-Time Applications in an Integrated Services Packet Network

This paper provides a pretty detailed design for a network supporting Integrated Services QOS, including what types of services to provide and how to schedule packets at the routers. There are several interesting and nonobvious ideas. First, the paper categorizes applications into rigid or adaptive and tolerant or intolerant, a useful taxonomy for examining how applications' needs differ. Second, the paper presents "predicted" services as an important service class. Predicted services differ from guaranteed capacity and delay bounds by saying only that an application will get similar performance to what it had in the past if network conditions continue to be similar. Even though this means there are no hard guarantees, it can lead to much better utilization of the network due to statistical multiplexing, and it is actually a useful service model for playback applications because they can adjust buffering intervals and rates to compensate. Third, in the packet scheduling part of the paper, we see that while Fair Queueing is a good way to isolate flows and provide performance guarantees, FIFO scheduling leads to much better potential throughput and performance for predicted services as long as flows are well-behaved. Again, we ultimately want to take advantage of statistical multiplexing to make the network efficient. Finally, the paper combines weighted fair queueing and priority scheduling to support guarnateed, predicted and best-effort traffic in the same scheduling algorithm. There is a well thought-out explanation of how priority shifts jitter between classes, FIFO minimizes average delay, and WFQ provides isolation.

One weakness of the paper is the service model chosen - describing flows' needs explicitly based on token buckets, delay bounds, etc. It seems difficult to calculate the requirements for an application, and even more difficult to get people to provide reasonable requirements rather than asking for more than they really need. Any design based on reservations will also have pricing complexity and scalability challenges (how to perform allocation). Admission control will also be a challenge (and the paper only briefly mentions how it might be performed). In the end, perhaps predicted service is the only class of "better-than-best-effort" service we can provide in the Internet in a usable, scalable fashion, by giving it a simple pricing model (say 2x more expensive per byte). This is more or less what work on Differentiated Services tried to achieve.

The paper also focuses mostly on a complete system design, rather than on what's needed for incremental deployment. While this is necessary to present an idea in its complete form to the research community and to focus light on the core issues, it may reduce interest in the work because there isn't any clear path to evaluation and deployment. Often researchers provided at least a network simulator implementation for proposed router mechanisms or transport protocols, but I think this paper had neither of those.