Introduction

Unlike traditional QoS models, such as Integrated Services (Intserv for short), which provides end-to-end guarantees on a per flow basis, Differential Services or Diffserv models are intended to provide service differentiation among traffic aggregates over large spatial granularity. As a result, in Diffserv it is possible to specify QoS requirements over the aggregate web traffic of a user, or over the entire traffic received or sent by all users of an organization, such as at Carnegie Mellon University. In addition, in Diffserv the service is defined over long time scales, rather than the duration of a flow, as in Intserv.

Usually, Diffserv models employ a service profile between each customer (user) and the Internet Service Provide (ISP), which defines the commitment of the ISP to the user. Many of the existing proposals, such as the Assured Service model proposed by Clark and Wroclawski, use service profiles that are defined in terms of absolute amount of bandwidth.

Unfortunately, since the set of active sources/destinations from/to which the user sends/receives data cannot be predicted accurately at the time the service profile is associated to the user, it is very hard, if not impossible to

1. provide fixed bandwidth profile, and simultaneously achieve
2. high service assurance, and
3. high resource utilization

We propose an Assured Service model, called LIRA, in which service profiles are defined in units of resource tokens, rather than absolute bandwidth. The number of resource tokens charged to each in-profile packet is a dynamic function of the path it traverses and the congestion level along the path. Defining service profile in terms of resource tokens, instead of fixed bandwidth, allows us to simultaneously achieve (2) high service assurance and (3) high resource utilization.

We believe that this is the right tradeoff for both the ISP and the customer. On one hand, the ISP can achieve high resource utilization, without sophisticated provisioning algorithms. On the other hand, the user has better control on how to manage its in-profile traffic. With fixed bandwidth profile, eventual congestion will cause the service assurance to decrease uniformly. In this situation, there is little the user can do if it wants to improve the service assurance for its most important applications. Reducing the in-profile traffic from other (less important) applications will not help, as most probably the congestion is not caused by the user's traffic only. In contrast, in LIRA, while congestion will cause a decrease of the user's profile, it will not affect the service assurance. This gives the user possibility to chose which of its applications will benefit from using in-profile traffic. Finally, as noted in Section 4 [1], it is also possible to use LIRA to implement the fixed bandwidth semantic, if needed.

To find more about LIRA click here.