Supporting Real-Time Applications in ISPN

Written around the same time as the previous paper, this one attempts to design a network infrastructure for three different classes of service: guaranteed (delivery within a certain advertised latency limit), predicted (give some guarantee based on the level of traffic), and usual datagram traffic. Based on the desire to route these classes, the network is built to work with two kinds of real-time applications: ones that adapt and can tolerate some increased latency, as well as applications that do not adapt and are intolerant to increased latency.

WFQ is used for the guaranteed class, but the paper points out that FIFO is actually better than an FQ-type algorithm when it comes to predicted service because FIFO, in some sense, "distributes" the bursty penalty over all the flows in the router, while WFQ penalizes the bursting one only; predicted service prefers a small penalty to all over a large penalty to a single flow.

One major result here is a new kind of FIFO (called FIFO+) queuing that attempts to make packets operate in a FIFO manner over all links in the path. This allows the network to route

the predicted class well. However, such an algorithm requires distributed control data; for each flow one has to have enough control to know which packets deserve to be routed first. In addition, any advertised delay must be an aggregate of delays on the path; this also involves communication and control record-keeping across any flow before it is actually allocated. These seem like large inefficiencies.

Overall, the algorithms in the paper do meet their goals in some sense. Given, however, the large increases in bandwidth as well as the major changes required in this proposal, it is no wonder it has not been implemented. Along with the large changes required in routing etc., there is also the need for additional record keeping for billing as well as other non-technical aspects that just seem impossible to overcome.