Dynamic Resource Management Technique with Advance ... - CiteSeerX

4 downloads 11479 Views 327KB Size Report
request scheduling, advance reservation, and dynamic resource management. 1. ... The resource manager manages a domain's resources using service ...
Dynamic Resource Management Technique with Advance Reservation over QoS-provisioned Networks Dong-Hoon Yi and JongWon Kim Networked Media Lab., Department of Information and Communications, Kwang-Ju Institute of Science and Technology (K-JIST), Gwangju, 500-712, Korea E-mail: {dhyi,jongwon}@kjist.ac.kr ABSTRACT Works on QoS-enabled IP networks have led to two distinct approaches: the integrated service (IntServ) and the differentiated service (DiffServ) architectures. To address the tradeoff between service guarantee and scalability, a resource manager (a.k.a. bandwidth broker: BB) can be employed to complement the IntServ/RSVP with the DiffServ in the pursuit of end-to-end QoS. One major component of the resource manager is a decision mechanism for resource allocation, which enables hosts to request per-flow, quantifiable resources along the end-to-end path and to obtain feedback regarding the acceptance. However, most of existing resource manager implementations are still adopting the decision mechanism that makes a decision on the immediate availability of resources, especially bandwidth. Considering the variations in the demand over the time, we can easily expect some level of inefficiency due to this in terms of resource utilization and management. Thus, we are investigating the methods to support the request scheduling and advance reservation for the dynamic resource management. We use a time slot manager to ensure that the committed resources never exceed a specified limit and to predict the unused (but reserved) bandwidth. Network simulations are conducted to evaluate the enhanced performance of the proposed mechanism (i.e., with respect to the acceptance rate, the resource utilization, and others). Keywords: The differentiated service network, resource manger, bandwidth broker, call admission control, request scheduling, advance reservation, and dynamic resource management.

1. INTRODUCTION Increasing demand for various media contents are accelerating the buildup of improved network infrastructure for massive media delivery. In this process, the QoS (quality of service) provisioning of network resources becomes more important in order to overcome the limitation of current best-effort IP service. The QoS models proposed by IETF (Internet engineering task force) attempt to provide building blocks of QoS-enhanced IP networks. Work on QoS-enabled IP networks has led to two distinct approaches: the integrated service architecture (IntServ) [1] and its accompanying signaling protocol, RSVP [2], and the differentiated service architecture (DiffServ or DS) [3]. While the IntServ architecture can provide more strict end-to-end QoS to applications over heterogeneous networks, it faces the scaling problem. Thus, instead of having a distributed admission control and having all core routers processing RSVP messages as in IntServ, a resource manager (a.k.a. bandwidth broker: BB) can be employed to complement the IntServ/RSVP with the DiffServ in the pursuit of end-to-end QoS [1–3,6]. Together, these can facilitate the deployment of continuous media applications, which can leverage the QoS-provisioned networks to enhance media streaming. One major component of the resource manger is the decision mechanism for resource allocation (usually called as call admission control, CAC, in networking literatures), which enables hosts to request per-flow, quantifiable resources along end-to-end path and to obtain feedback regarding admissibility of the request. A properly managed decision mechanism can control the interaction between the network-aware application and the QoS-enabled networks. Typically the resource manager uses the generalized resource tables containing information about network topology, flows and QoS states in each path and nodes [6, 7, 17]. That is, a client that wishes to communicate with guarantee uses a broker service to secure simultaneous reservations for all the required resources (at ingress/egress points and network interior). The resource manager manages a domain’s resources using service policies defined based on the clients requirements. The resource manager typically

reserves the bandwidth requested by clients, for a price. This reservation, however, is usually made without any understanding of the nature of the contents that will be transmitted [15]. It can lead to a waste of bandwidth. In comparison, dynamic resource management approaches manage the resources in a domain by dynamically reallocating resources based on the current requirement of application and the state of network [8, 15]. This approach is motivated by the observation that the actual usage of reserved channels in total rarely approaches its peak reserved rate. Consequently, when there is no remaining bandwidth in the channel, a portion of the bandwidth either unused or adjusted can be returned to the pool of total available bandwidth. Also, most of existing resource managers support only immediate reservation, which makes decision on the immediate availability of resources [7, 8]. Considering the variations in the demand over the time, we can easily expect some level of inefficiency due to this in terms of resource utilization and management. For example, recent real-time oriented multiparty applications require the advance reservation. The client who wish to set up a multimedia multi-party meeting (i.e., meeting involving multiple human beings) needs to schedule meeting in advance to make sure that all the participants can join at the scheduled time without any network provisioning difficulty. They must arrange the network connections and other resources required for the entire meeting. Also, though they are not real-time, lots of distributed applications have strict QoS requirements (e.g., reasonable bound on delay jitter and broad bandwidth for streaming movies and data-intensive distributed computing jobs). Unless they can be reserved in advance, there is no guarantee that the required resources are available at the right time. Targeting the DiffServ QoS-provisioned networks, this paper proposes a dynamic resource management. The proposed resource management actively manages the resources in a domain by dynamically reallocating resources. To avoid inefficient rejection of requests when the resource manager notices a short-time bottleneck (but becomes idle later), it is possible to put requests first into a scheduling queue before responding to the client. The resource manager attempts to allocate the resource in several sequential scheduling phases. If all trials fail, the request is rejected. The proposed management also provides the advance resource reservation. In fact, the advanced reservation can benefit from its flexibility. The added time-domain flexibility (if allowed by the application) enables multiple scheduling attempts (with different starting time and duration). The proposed resource management scheme is implemented and evaluated using the NS-2 simulator [19]. Experiments demonstrate that, by dynamically scheduling and reallocating available resources, we can effectively increase the overall utilization. It also enables to support increased service numbers of clients while honoring QoS guarantees. The paper is organized as follows. In Section 2 we describe issues about the resource manager deployment over the DiffServ networks to provide the required QoS. Next, in Section 3, we propose the proposed dynamic resource management scheme with the advance reservation feature. The evaluation of the proposed resource management will follow in Section 4. Finally, we conclude the paper in Section 5.

2. RESOURCE MANAGER DEPLOYMENT OVER QOS-PROVISIONED NETWORKS The emerging DiffServ [3] scheme in IP-QoS methods provides a less complex and scalable solution. The DiffServ approach allows different QoS levels to different classes of aggregated traffic flows, as opposed to individual flows. There are a few differentiated service classes documented in RFC, e.g., assured service (AS) [5] and premium service (PS) [4], but new services can be defined by internet service providers who offer them. On-going research efforts in the DiffServ can be divided into two classes: absolute differentiation [17] and relative differentiation [20]. We focus on the absolute service differentiation, e.g., the expedited forwarding (EF) per-hop behavior (PHB) since it provides premium service where a client’s request for service guarantees is satisfied. By carefully managing the resources at the edge of the network, it is possible to provision a QoS network with reasonably strong guarantees, even though traffic is treated as an aggregate in the core of the network. Fig. 1 shows that the typical deployment scenarios for the resource manager in single or multiple DiffServ domains. The resource manager is an agent that provides a centralized mechanism to control the resources within a single DiffServ domain [7, 12]. All agreements between the client and the service provider that pertain to the type of service required are known as service level agreements (SLA). The resource manager manages

Recalculate BW (Each link)

Decision Message

Super Resource Manager

Resource (Each link) Information

Service request

Resource Manager

Check resource in each domain

Decision Message Service request

Check resource in each link

DS Domain 3

Edge Router

DS Domain 4

DS Domain 1

Core Router

Edge Router

DS Domain 2

Edge Router

Core Router

Edge Router

Edge Router

Requester in DS domain 1

Target in DS domain 2

Target in DS domain 4

Requester in DS domain 4

Figure 1. Typical resource manager deployment scenarios over the DiffServ networks.

a domain resources using service policies defined based on the client’s requirements. These SLAs are used to define the relation between policies and PHBs, while a service provisioning policy (SPP) indicates how traffic conditioners are configured at the edge of the domain and how the traffic streams are mapped to the DiffServ behavior aggregates. The resource manager requires both the SLAs and the SPPs to achieve a range of services, which are provided to the user. Based on the SLAs, the manager decides whether it can provide the allocation, and configures the edge router to mark and classify the packets as decided in the SLA [3, 6]. Usually there is a single resource manager per service domain. When the sender and receiver belong to different domains, relevant resource managers from their domains and the intermediate ones must communicate the resource reservation states between each other, as shown in Fig. 1. In this case, the decision on the resource allocation is performed by the resource manager in upper layer enabling the scalable resource management with the hierarchical structure. Recalculate BW (Each link)

2

DB 3

New Flow

Resource Information 4

Update!

'Ok' Acceptable path Find! 1 Resource Manager (bandwidth)

Figure 2. The simplified model for the resource management procedure.

The resource manager [6, 7] removes the need for resource reservation states in the core routers by centrally storing and managing them. A resource manager may be co-located with a router/switch as a plug-in software package. The main modules are regarding the resource allocation and routing ones. The former maintains the resource allocation states and is responsible for the resource reservation. The latter decides the path that the admitted flow will traverse towards the receiver. The resource manager also contains databases with information about network topology, flows and states of allocated resources in each path and node. Fig. 2 describes the general process of the resource allocation module. When a new client wants to receive the guaranteed service, it sends a request message to the resource manager. The resource manager recalculates the available bandwidth, and verifies whether the request can be admitted or not. If the request is admitted, the manager sends a acceptance message, and updates its database [12]. The realization of end-to-end QoS guarantees for the emerging network-based applications requires increased flexibility in the process of resource reservation and allocation. We are going to exploit the recent trends in the resource management: towards advance and dynamic resource reservation and allocation [?, 8, 11].

Without the advance reservation feature [18], the application has no choice other than requesting the resources for the desired QoS∗ (in terms of bandwidth, delay, and loss) at the time it starts the delivery. Also it is usually assumed that the resources are requested for an indefinite duration. Given the requests of unspecified durations, the network does not have enough information to efficiently plan future allocations. This is because it cannot predict the arrivals of new requests and the terminations of existing applications. Thus, without the advance reservation, we encounter either increased costs due to excess over-provisioning or degraded services for critical traffics. To make matters worse, in some systems such as supercomputers, over-provisioning may not be an option [15]. However, there exist lots of applications to benefit from the advance reservation as in case of multiparty interactive applications. The advance reservation provides an increased expectation that the resource can be allocated when demanded, much as the reservation of an airline ticket provides an increased expectation of obtaining a seat. Note that, in order to provide an effective QoS provisioning, it is important to ask the applications to submit the anticipated duration† . To address this, there have been works on the advance reservation of resource for the end-to-end QoS [9, 15, 18]. Several advance reservation techniques have been proposed to balance immediate and advance reservations, to support the advance reservation of predictive flows, and to handle multicast traffic. Conventional approaches to network resource allocation rely on predetermined traffic characteristics [13]. The amount of resource (e.g., bandwidth) required to provide the QoS is estimated using these values. They face the following problems; the source characteristics may not be known ahead of time; parameters may not adequately characterize the source; and the number of parameters required should be kept small, so as to reduce the allocation complexity. A layered n-th order Markov model may adequately characterize a source, nevertheless the computation of allocation amounts becomes intractable for real-time applications. In [13], the allocation amount is statically determined before the start of transmission for the duration of application. This simple approach may suffer from the problems noted above, albeit the low resource utilization if the peak-tomean ratio is high. On the contrary, on-line allocations in [8, 13] periodically re-negotiate allocation amount based on the predicted traffic behavior. To enjoy the advantage, they however require that the applications can adapt to the adjusted allocation. It also may suffer from a large number of re-negotiations, and it rely on an effective performance monitoring.

3. PROPOSED DYNAMIC RESOURCE MANAGEMENT WITH ADVANCE RESERVATION 3.1. Request Scheduling and Advance Reservation First, we propose to adopt the scheduling of request so that we can cope with the busty demands for resources. A queue to patch the incoming requests is deployed and all requests are first queued in this queue before checking the availability of resources. Then, the resource manager decides the admission on the request periodically considering up-to-date resource states. The delayed (and repeated) check on the availability on the resource increases the ratio of successful reservation, which in turn contributes to the improved resource utilization. Here, we assume that the requester can wait for some period until it get the notification. Fig. 3 shows how the request scheduling can prevent inefficient rejection of requests, when there is sudden increase in requests. To prevent excessive waiting, we set a threshold on the waiting time. If a request is timed out, it is dropped from the queue and rejected. Also, when the amount of required resources is too large to be provided, the request is dropped early regardless of the waiting time. Note that, when the resource is available at the time when the request is entered in the resource manager, the response is almost identical (albeit very slight processing overhead). With the request scheduling in place, we can add the advance reservation feature. As discussed above, to reduce the risk of being refused at the time when it is necessary, the advance reservation is necessary. Fig. 4 illustrates the problem of the indefinite service duration case. Consequently we require that all the requests for advance reservation should declare the desired duration. ∗ Note that the application can dynamically modify these reservation requests depending on the change in the traffic characteristics and performance requirements † However, there exist an easy and inexpensive ways to re-negotiates the extension of the duration.

Request scheduling Queue Burst requests

300k,0 1.5M,0 160k,0 600k,0 300k,0

There is no available resource ! Puts off admission

Requested information ( Requested BW, Wait Time ) After 1 time period

New requests

160k,0

300k,1 1.5M,1 160k,1 600k,1 300k,1

There is some available resource (500k) ! Perform admission Accept request Randomly drop or keep Keep

After several time periods

New requests

600k,0

160k,3 300k,4 1.5M,6 600k,6

Over wait drop

Figure 3. Request scheduling by the request queuing. 100 %

Service violation !! Reserved bandwidth in a resource pool

Reserved bandwidth for definite service duration

Reserved bandwidth for indefinite service duration 0%

t1

t0

100 % Available Resource !Accept new request

75 % Available Resource !Accept new request

t2

t3

Service terminate with no violation.

Service terminate !Cannot provide the promised service quality !!

Figure 4. Indefinite service duration and advance reservation.

Resource management based on the time slot table is adopted in this paper to realize the advance reservation feature. The allocation is processed per time slot table. Fig. 5 describes the creation process of the time slot table. The time slot table is originally segmented by the time segment (i.e., slots). When a new advance reservation is made, slots are occupied according to the start time and duration of new reservation. Thus, the size of segment plays important role in the management of time slot table. If set too small, it means fine-grained and efficient use of slots at the cost of increased processing overhead. On the contrary, we can easily expect the reverse effect in case of large slots. Note that, for some application which needs to start immediately, we may not be able to apply the advance reservation (since the duration is usually not known in this case). Thus, we propose that the requests for the advance and immediate reservations are separately managed.

3.2. Dynamic Resource Managements As we mentioned above, reservation requests for immediate and advance reservation have to be separately managed. Thus, in this work, a predefined pool of resource (e.g,, bandwidth) is assigned. The allocation rate

100 % New Request

100 % New Request

Reserved bandwidth

Reserved Bandwidth

0% 0%

t1

t0 t0

t1

t2

t3

t2

t3

t4

t0`

t4

(a)

t5 t4`

(b)

Figure 5. Effect on the intervals for the advance reservation: (a) Large intervals and (b) small intervals.

of the resource pool is sometimes burst, but rarely goes to the maximum (i.e., full allocation) and a portion of the resource pool remains unused. If the resource is provisioned only to a particular pool, no other in different pool can use it. However, it the resource sharing across the resource pool is allowed, we can expect the sharing gain as long as we can control (i.e., minimize) the service infringement due to this kinds of sharing. Take the unused minimum BW for test interval Test time interval (changed by requested BW)

Change boundary value! Small BW case Large BW case

Reserved BW pool for immediate reservation Reserved BW pool for advance reservation

Figure 6. Processes of dynamic resource management (when the resource pool for the immediate reservation becomes full).

For this purpose, we can utilize the time slot table since it can provide credible information about the anticipated usage of the resource. By examining the time slot table, we can perform the decision on the dynamic resource allocation as shown in Fig. 6. The test interval for the allocation is changed based on the amount of requested bandwidth. Generally, as requests need more bandwidth, they tends to last longer. So, we need to set longer test interval in this case. Note that, the minimum bandwidth is set to avoid service violations.

4. SIMULATION RESULTS The evaluation on the proposed resource manager is performed by network simulator NS-2. We choose the resource management with advance reservation over the DiffServ QoS-provisioned network. The simulation topology is presented in Fig. 7, where 22 hosts are interconnected via a 10Mb/sec to each of edge routers, respectively. Each host generates a traffic distributed exponentially with burst (500ms) and idle (500ms) time. The arrival and maintenance time of request traffic is also exponentially distributed whose mean time is uniformly distributed between predetermined intervals. Other simulation parameters are shown in Table 4. We assume that, when the request is rejected, the reservation is retried and thus we apply different mean call arrival as depicted in Table 4. The resource manager keeps track of traffic rates from all clients using a meter (such as the TSW tagger), which is a part of the edge router. When the measured traffic violates the committed

Recalculate BW (Each link)

Advance Reservation Resource Information Acceptance Message

•EF traffic

-Advance

10M

DiffServ 7M 10M

: :

E1 Edge1

Service Requests

Request scheduler

•Web traffic •FTP application

Acceptance Message

Resource Manager

Service Requests

-Immediate

Time-slot Table

5ms

C Core

10M 7M 5ms

Edge2 E2

8M 6M 5ms

Edge3 E3

10M

10M

: :

: :

Figure 7. Simulation topology.

rate, the resource manager treats the traffic with higher drop precedence. We also assume that all reservations for resource requests are asking for peak rate service and they use their peak rate during their duration. This is why we choose the premium service (i.e., EF PHB) of DiffServ only, since it provides the required peak rate guarantee. To simulate background traffics, other traffic sources from FTP and WWW applications are added. Table 1. Simulation parameters. Rate

EF traffic Immediate & advance reservation

Web traffic

Holding time Exponential distribution with uniform random mean In Interval [a,b]

160k

[1, 3]

300k

[1, 5], [5, 15], [15, 35]

600k

[5, 15], [8, 22]

900k

[5, 15]

1.5M

[30, 60]

2.0M

[20, 45]

144k

Pareto on-off traffic

Call arrival interval Diffserv policy After reject

After normal end

Uniform random [0.1, 0.5] x Holding time

Uniform random [0.1, 1] x Holding time

FTP application

TSW2CM (initial CP : 5) & TSW3CM (initial CP : 10)

TSW3CM (initial CP : 12)

" TSW2CM : Uses a CIR (Committed Information Rate) and 1 drop precedence. ! Advance reservation channel : 900k, 1.5M, 2M (Mean time 1~40) " TSW3CM : Uses a CIR, PIR (Peak Information Rate) and 3 drop precedence. ! Immediate reservation channel : 160k, 300k, 600k, 900k (Mean time 1~15)

4.1. Request Scheduling First, we evaluate the performance of request scheduling by comparing cases such as without resource scheduling ( denoted as ‘basic admission’) and with scheduling (three early drop cases) as shown in Fig. 8. For each call, 3Mb/sec bandwidth is reserved. For the case of immediate reservation, the decision is made at the moment when the service request arrives. As expected, in comparison to the immediate reservation, we can observe the gain from the time-domain flexibility of request scheduling. Also as shown in Fig. 8, the early drop can prevent the excessive waiting when there is a slim chance to get the desired resource. Without the early drop, all requests have to wait until the preset waiting time is over or the requested service is accepted. We can also observe the tradeoff between allocation delay and the acceptance ratio, which is well utilized with the random early drop case.

2000

1.0

Average accept throughput

Call acceptance ratio

0.9

0.8

0.7

0.6

0.5 Basic admission Early drop (All) Early drop (None) Random early drop

0.4

1500

1000

500

Basic admission Early drop (All) Early drop (None) Random early drop

0

0.3 0

200

400

600

800

1000

0

1200

200

400

600

800

1000

1200

Time

Time

(a)

(b) 25

Average waiting time

20

15

10

5 Early drop (All) Early drop (None) Random early drop

0

0

200

400

600

800

1000

1200

Time

(c) Figure 8. Performance comparison with and without resource scheduling. (a) Average acceptance ratio, (b) Average acceptance throughput, and (c) average waiting time.

4.2. Time Granularity in Advance Reservation Table 2. Comparison of acceptance based on the time granularity. Advance reservation Time granularity

Accept

Reject

1

73

74

5

46

75

10

37

79

30

34

102

The advance reservation is possible with the creation of time slot table. With large interval granularity, the time slot table is easily manageable. However the time table may not able to provide the desired accuracy as shown in Fig. 9. Table 2 shows that the impact of time granularity on the request acceptance ratio. As time interval gets small, the information stored in each slot better represents the state of resource allocation. But we need to manage exponentially increasing number of time slots.

4.3. Dynamic Resource Allocation with Advance Reservation The unused resource can be borrowed, when the immediate request needs more resource than can be provided from its own resource pool. We observe the impact of test interval in Fig. 10. As expected, if test interval becomes

3500

3500 Time granularity = 30

3000

3000

2500

2500

Reserved bandwidth

Reserved bandwidth

Time granularity = 1

2000 1500 1000

2000 1500 1000

500

500

0

0

0

200

400

600

800

1000

1200

0

200

400

Time

600

800

1000

1200

Time

(a)

(b)

6000

7000

5000

6000 5000

4000

Accepted throughput

Accepted throughput

Figure 9. Effect of time granularity in advance reservation: (a) short interval (=1) and (b) large interval (=30).

3000

2000

1000

4000 3000 2000 1000

0

0

Various test_time

0

200

400

600

800

1000

1200

Time

Test_time = 0 (fix)

0

200

400

600

800

1000

1200

Time

(a)

(b)

Figure 10. Dynamic resource management with (a) various test interval cases and (b) no test interval case.

large, the probability of service violation is decreased. To find out more efficient allocation, we compare the various test intervals. As mentioned, we set longer test interval as the requested amount of bandwidth becomes larger. Also, in Fig. 3, we compare the average acceptances based on the test time interval setting under the proposed resource management.

5. CONCLUSION AND FUTURE WORKS The proposed resource management technique operated on the Diffserv network achieves the enhanced acceptance and resource utilization. The proposed request scheduling and advance reservation helps the networks to dynamically provision the differentiation. However, the conducted simulations so far are not complete yet at this stage of work. We are planning several extensions such as and refinement of dynamic resource management and multiple service domains .

REFERENCES 1. R. Braden et al, “Integrated services in the Internet architecture,” IETF RFC 1633, 1994. 2. L. Zhang et al, “RSVP: A new resource reservation protocol,” IEEE Network, vol.7 Sept. 1993.

2500

Average accept throughput (For immediate reservation)

2000

1500

1000

500 Test_time = 50 (fix) Test_time = 0 (fix) Various test_time Static

0

0

200

400

600

800

1000

1200

Time

Table 3. Effect of test interval for the dynamic resource allocation (immediate reservation).

3. S. Blake et al, “An architecture for differentiated services,” IETF RFC 2475, Dec. 1998. 4. V. Jacobson, K. Nichols, and K. Poduri, “An expedited forwarding PHB,” IETF RFC 2598, June 1999. 5. J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, “Assured forwarding PHB,” IETF RFC 2597, June 1999. 6. Z. Zhang et al, “Decoupling QoS control from core routers: A novel bandwidth broker architecture for scalable support of guaranteed services,” in Proc. ACM SIGCOMM ‘2000, Stockholm, Sweden, August 2000. 7. I. Khalil and T. Braun, “Implementation of a bandwidth broker for dynamic end-to-end resource reservation in outsourced virtual private networks,” in Proc. of the IEEE 25th Annual Conference on Local Computer Networks (LCN ‘2000, Nov. 2000. 8. A. Ramanathan and M. Parashar, “Active Resource Management for the Differentiated Services Environment,” in Proc. of the International Conference on Internet Computing (IC ‘2001), June 2001. 9. D. Ferrari, A. Gupta and G. Ventre, “Distributed advance reservation of real-time connection,” ACM/Springer-Verlag Multimedia Systems, 1997. 10. M. Degermark, T. Kohler, S. Pink and O. Schelen, “Advance reservations for predictive service in the Internet,” ACM/Springer Journal of Multimedia Systems, 1997. 11. A. Gupta. “Advance reservation in real-time communication services,” in Proc. of the IEEE 22nd Annual Conference on Local Computer Networks (LCN ’1997), 1997. 12. S. Sargento and R. Valadas, “Call admission control in IP networks with QoS support,” in Proc. IEEE INFOCOM, 2000. 13. E. Fulp and D. Reeves, “On-line dynamic bandwidth allocation,” in Proc. of the IEEE International Conference on Network Protocols, 1997. 14. I. Hsu and J. Walrand, “Dynamic bandwidth allocation for ATM switches,” Journal of Applied Probability, vol. 33, 1996. 15. I. Foster, C. Kesselman, C. Lee, B. Lindell, K. Nahrstedt, and A. Roy, “A distributed resource management architecture that supports advance reservation and co-allocation,” in Proc. International Workshop on Quality of Service (IWQoS ‘1999), 1999. 16. R. Bolla, F. Davoli, M. Perrando and M. Repetto, “Hybrid analytical/simulation mechanism for access control and on-line bandwidth optimization in Diffserv environments,” Courmayeur, 2002. 17. I. Stoica and H. Zhang, “Providing guaranteed services without per flow management,” in Proc. of ACM SIGCOMM ‘1999, Sept. 1999. 18. W. Smith, I. Foster and V. Taylor, “Scheduling with advanced reservation,” in Proc. of the 2000 International Parallel and Distributed Processing Symposium, May, 2000. 19. UCB/LBNL/VINT, Network simulator - ns (version 2). http://www.isi.edu/nsnam/ns, 1998. 20. C. Dovrolis, D. Stiliadis, and P. Ramanathan, “Proportional differentiated services: Delay differentiation and packet scheduling,” in Proc. of ACM SIGCOMM, Sept. 1999.