Overload Based Explicit Rate Switch Schemes with MCR Guarantees

2 downloads 0 Views 391KB Size Report
proposed algorithms are studied and compared using several con gurations. The con gura ... The ABR users specify minimum rate using MCR (minimum cell rate) parameter during connection ..... 4.3 Generic Fairness Con guration - 2 (GFC-2).
Overload Based Explicit Rate Switch Schemes with MCR Guarantees 1 2 Bobby Vandalore, Sonia Fahmy, Raj Jain, Rohit Goyal, Mukul Goyal The Ohio State University Department of Computer and Information Science Columbus, OH 43210-1277 Phone: 614-688-4482, Fax: 614-292-2911 E-mail: fvandalor, fahmy, jain, goyal, [email protected]

Abstract: An explicit rate switch scheme monitors the load at each link and gives feedback to the sources. We de ne the overload factor as the ratio of the input rate to the available capacity. In this paper, we present four overload based ABR switch schemes which provide MCR guarantees. The switch schemes proposed use the overload factor and other quantities to calculate feedback rates. A dynamic queue control mechanism is used to achieve ecient usage of the link, control queues and, achieve constant queuing delay at steady state. The proposed algorithms are studied and compared using several con gurations. The con gurations were chosen to test the performance of the algorithms in presence of link bottlenecks, source bottlenecks and transient sources. A comparison of the proposed algorithms based on the simulation results is presented.

Keywords: ATM switch algorithms, ABR service, trac management

1 Introduction The ATM (asynchronous transfer mode) is the chosen technology for implementing B-ISDN (broad-band integrated services digital network). ATM is connection-oriented cell switching standard. It uses xed size cells which are 53 bytes long. ATM o ers di erent service categories for transporting di erent types of trac. The ABR (available bit rate) service category in ATM is used to transport data trac with minimum rate guarantee. The ABR users specify minimum rate using MCR (minimum cell rate) parameter during connection 1 2

Submitted to the INFOCOM '99. Available through http://www.cis.ohio-state.edu/~ jain/papers.html This research was sponsored in part by Rome Laboratory/C3BC Contract #F30602-96-C-0156.

1

setup. The ABR service gives guarantee that the ACR (allowed cell rate) is never less than MCR. ABR uses closed loop feedback to control the source rates (see Figure 1). The source sends periodically (after every Nrm ? 1 data cells) an RM (resource management) cell to gather information from the network [1]. The RM cells are turned around at the destination. The switches along the path indicate the current rate which they can support in the explicit rate (ER) eld of the RM cell. When the source receives the backward RM cells, it adjusts its allowed rate accordingly.

Figure 1: RM cell path The speci cation of the ABR feedback control algorithm (switch scheme) is not yet standardized. [2] used binary feedback to advise source about congestion information. Distributed algorithms which emulated the centralized algorithm were given in [3, 4]. Improved, simpler distributed algorithms were proposed in [5, 6, 7, 8, 9, 10]. Recently, [11, 12] discuss a generalized de nition of max-min fairness and its distributed implementation. [13] discusses a weight-based max-min fairness policy and its implementation in ABR service. [14, 15] discuss the fairness in the presence of MCR guarantees. In [16], we had proposed a general de nition of fairness, and gave an overload based ABR switch scheme which provides MCR guarantees. In this paper, we propose three additional algorithms which use the overload factor to calculate the explicit rate feedback. All the proposed algorithms provide MCR guarantee and achieve generalized fairness. The load factor (also referred to as \overload factor" or \overload") is the ratio of the measured input rate to the available ABR (available bit rate) capacity. ERICA+ switch scheme monitors the load on the link and calculates feedback based on the load. It tries to 2

achieve unit load on links to eciently use the link and also converge to max-min fairness [1]. Max-min fairness assumes zero MCR values. In this paper, we have used the generalized fairness with MCR as de ned in [16]. Section 2 discusses the de nition of generalized fairness used in algorithms. Section 3 gives a brief overview of ERICA+ and then discusses proposed algorithms. In section 4, various simulation con gurations used in the simulations are discussed. Section 5 gives the results of the simulations. The simulations test whether the schemes provide MCR guarantees and converge to generalized fairness. A comparison of the algorithms based on the simulations results is given in section 6. Finally, section 7 gives the conclusions of the paper.

2 General Weighted Fairness: De nition ATM Forum Trac Management Speci cation 4.0 [1] recommends di erent de nitions of fairness to be used when MCRs are non-zero. These fairness de nitions are equal share of excess bandwidth, proportional to MCR of excess bandwidth, proportional to predetermined weights of bandwidth. Here, we give the de nition (as de ned [16]) of generalized weighted fairness which can realize all the above fairness de nitions. De ne the following parameters:

Al = Total available bandwidth for all ABR connections on a given link l. Ab = Sum of bandwidth of under-loaded connections which are bottle-necked elsewhere. A = Al ? Ab , excess bandwidth, to be shared by connections bottle-necked on this link. Na = Number of active connections Nb = Number of active connections bottle-necked elsewhere. n = Na ? Nb , number of active connections bottle-necked on this link. i = MCR of connection i.  = Pni=1 i Sum of MCRs of active connections which are bottle-necked by this link. 3

wi = preassigned weight associated with the connection i. gi = generalized weighted fair Allocation for connection i. The general weighted (GW) fair allocation is de ned as follows:

gi = i + wPi (nA ?w) j =1 j

The excess available bandwidth (A ? ) is divided in proportion to the predetermined weights.

3 The Switch Schemes The general structure of the algorithms proposed are similar to the ERICA+ [5]. First, we brie y discuss the ERICA+ algorithm and then give the general structure of the proposed algorithms. The four switch algorithms proposed have the same structure and only di er in, the way in which end of interval accounting is done, and the manner in which the feedback is calculated.

3.1 Overview of ERICA+ ERICA+ operates at the output port of a switch. It periodically monitors the load, active number of VCs and provides feedback in the BRM (backward RM) cells. The measurement period is called the \averaging interval." The measurements are done in forward direction and feedback is given in the reverse direction.

ERICA+ Algorithm At the end of the Averaging Interval: Total ABR Capacity

Link Capacity ? VBR Capacity

(1)

Target ABR Capacity

Fraction  Total ABR Capacity

(2)

z FairShare

ABR Input Rate Target ABR Capacity Target ABR Capacity Number of Active VCs 4

(3) (4)

MaxAllocPrevious

MaxAllocCurrent

(5)

MaxAllocCurrent

FairShare

(6)

When an FRM is received: CCR[VC]

CCR in RM Cell

(7)

When a BRM is received: CCR[V C ] z

(8)

THEN ER

Max (FairShare, VCShare)

(9)

ELSE ER

Max (MaxAllocPrevious, VCShare)

(10)

Max (MaxAllocCurrent,ER)

(11)

VCShare IF (z > 1 + )

MaxAllocCurrent

IF (ER > FairShare AND CCR[VC] < FairShare) THEN ER ER in RM Cell

FairShare

(12)

Min (ER in RM Cell, ER, Target ABR Capacity) (13)

In overload (z > 1 + ) conditions, the algorithm calculates the maximum of the FairShare and VCShare as the feedback rate. In under-load conditions, the maximum of MaxAllocPrevious (which is the maximum allocation given in the previous averaging interval) and the previous two terms is the feedback rate. Equation 12 avoids sudden increase in the feedback rate. The Fraction term is used to control the queues, by dynamically varying target ABR capacity. 1 ? Fraction amount of the link capacity is used to drain the queues. Fraction can be either a constant less than one (e.g., Fraction = 0:9 implies 90% link utilization), or dynamic function of switch queue length. ERICA+ uses a two hyperbolic curves with which control the queue in under-load and overload regions. To ensure that a minimum amount of link capacity is used for data, the Fraction value is limited to a minimum of QDLF (queue drain limit factor). Typically a value QDLF = 0:5 is used.

5

3.2 Overload Based Algorithm: General Structure The four di erent switch schemes have the following common algorithmic structure. They di er in the manner in which the feedback rate is calculated and in accounting. The algorithms perform the following steps for calculating the feedback rate: 1. The problem of non zero MCRs is reduced to one with zero MCRs. The MCR is subtracted from each connection's current source rate to obtain the excess rate of each source over MCR. If the source is transmitting at a rate less than its MCR, an excess rate of zero is used. 2. The switch algorithm for zero MCRs is applied to these excess rates to obtain the feedback rate. The excess available capacity (A ? ) is divided in proportion to the pre-determined weight. 3. MCR for each source is added to the explicit feedback rate calculated in the previous step. The resulting rate is indicated in the ER eld of BRM cells. The sources transmit data initially at their initial cell rate (ICR) value. After one round trip time, the feedback from the switches arrives at the sources, and sources adjust their allowed rate accordingly. If a constant queue control function is used (say Fraction = 0:9), the GW fairness allocation is achieved in few round trips. If a dynamic queue control function is used, the available capacity varies depending on the queue length. Therefore, the feedback rate also varies till the queues are drained. Once the queues are drained, the feedback rates converge to the GW fair allocation. The simulations use both constant queue length and hyperbolic queue control functions. [17] discusses the design of queue control functions which enable the switch algorithms to reduce rate oscillations, achieve constant delay and high link utilization (100%) .

Overload Based Algorithm Structure: At the End of Each Averaging Interval: Total ABR Capacity

Link Capacity ? VBR Capacity ?

Target ABR Capacity

Fraction  Total ABR Capacity 6

n X i=0

min(SourceRate(i); i )

ABR Input Rate ?

Input Rate

n X i=0

min(SourceRate(i); i )

Input Rate Target ABR Capacity

z

End of Interval Accounting() When an FRM is received: CCR[VC]

CCR in RM Cell

When a BRM is received: Excess ER ER ER in RM Cell

Calculate Excess ER() i + Excess ER Min(ER in RM Cell,ER,Target ABR Capacity)

The key steps that di erentiate the algorithms are the procedures End of Interval Accounting() and Calculate Excess ER().

3.3 Algorithm A: VCShare and ExcessFairShare The ExcessFairShare term is de ned as follows:

ExcessFairShare(i) = wPi(nA ?w) j =1 j

This divides the excess available bandwidth (A ? ) in proportion to the weights w(i). An allocation of i + ExcessFairShare(i) for each source i is the GW fair allocation. A source might be bottlenecked at some other link, hence using less than its fair share of link capacity. By using the notion of activity level, the e ective weight of the bottlenecked source can be calculated. The activity level for a given VC is de ned as follows:  SourceRate(i) ?   i AL(i) = minimum 1; ExcessFairShare (i) The activity level can be used to accurately estimate the e ective number of VCs [18]. We extend this notion to the weighted case by multiplying the weight function with the activity level of the ExcessFairShare term. Therefore the ExcessFairShare is: 7

(i)(A ? ) ExcessFairShare(i) = wPiAL n w AL(j ) j =1 j

In Algorithm A, the Excess ER is calculated based on the V CShare and the ExcessFairShare terms. For each source, the activity level and the ExcessFairShare are updated at the end of each interval. When a BRM arrives at the switch, V CShare is calculated, and the maximum of V CShare and ExcessFairShare is given as the feedback rate. The V CShare term has the overload factor in its denominator. If the link is overloaded, the V CShare decreases, and if the link is underloaded, it increases. As the network reaches steady state, the V CShare term converges to the ExcessFairShare term. The allocation at the steady state for each source i is i + ExcessFairShare(i), which is the GW fair allocation. In [16], a proof for convergence of this algorithm is given assuming certain conditions.

End of Interval Accounting(): foreach VC i do

AL(i) ExcessFairShare(i)

 SourceRate(i) ?   i minimum 1; ExcessFairShare (i) (Target ABR Pn Capacity)wi AL(i) j =1 wj AL(j )

endfor

Calculate Excess ER(): VCShare Excess ER

Max(0; SourceRate(i) ? i ) z

Max (ExcessFairShare(i), VCShare)

3.4 Algorithm B: ExcessFairShare/Overload In this version, the Excess ER is calculated based on ExcessFairShare and the overload factor z . The End of Interval Accounting() is the same as in the previous algorithm (algorithm A). When a BRM cell arrives, the feedback rate is calculated as the ExcessFairShare term, divided by the overload. The source rate is not used in feedback rate calculation. As the network reaches steady state, the overload will become one and the Excess ER will 8

converge to the required Excessfairshare, achieving GW fair allocation. Since the overload factor varies every averaging interval, the rate oscillations increase for this algorithm. If the \averaging interval" is greater than the feedback loop, then the switch adjusts to the feedback rate before the next averaging interval. If the averaging interval is smaller, then before the source can adjust to the feedback rate, multiple feedbacks are given. The ExcessFairShare calculation is not accurate, since the source rate does not re ect the feedback rate. One solution to overcome this problem is to use exponential averaging of the ExcessFairShare term.

Calculate Excess ER(): Excess ER

ExcessFairShare(i)

z

3.5 Algorithm C: MaxAllocation/Overload Let the GW fair allocation be (g1 ; g2 ; : : : ; gn ) for n bottle-necked sources. The excess bandwidth is divided proportional to weights (gi ? i )=w(i) = (gj ? j )=w(j ). Let m be the VC such that term (gm ? m )=w(m) is the maximum of such terms of all VCs. An allocation which assigns rates as i + w(i)(gm ? m )=w(m) will achieve GW fairness. The term (gm ? m )=w(m) is de ned as the weighted maximum allocation. In algorithm C, the feedback is calculated as term proportional to weight of VC and the weighted maximum allocation is divided by overload. The overload in the denominator increases or decreases the allocation depending on the load. The source rate is not used in the feedback calculation. This algorithm can give rise to large queues if the weighted maximum allocation is measured incorrectly. This problem of large queues occurred during the simulation of this algorithm using GFC-2 con guration.

End of Interval Accounting(): WtMaxAllocPrevious

WtMaxAllocCurrent

WtMaxAllocCurrent

0

9

Calculate Excess ER(): Excess ER WtMaxAllocCurrent

w(i)WtMaxAllocPrevious

z

Max (WtMaxAllocCurrent,Excess ER/w(i))

3.6 Algorithm D: VCShare and MaxAllocation In this algorithm, the End of Interval Accounting() is the same as in the previous algorithm (algorithm C). The Excess ER is calculated based on the weighted maximum previous allocation (WtMaxAllocPrevious) and V CShare under underloaded conditions (z < 1+). For overloaded conditions, the V CShare is given as the feedback rate. The problem of large queues explained in the previous algorithm is not expected to occur since the maximum previous allocation is given as feedback only if the link underloaded. As the overload converges to one, the V CShare converges to w(i)(gm ? m )=w(m), achieving the GW fair allocation.

Calculate Excess ER(): VCShare IF (z > 1 + )

Max(0; SourceRate(i) ? i) z

THEN Excess ER

VCShare

ELSE Excess ER

Max (w(i) WtMaxAllocPrevious, VCShare)

WtMaxAllocCurrent

Max (WtMaxAllocCurrent,Excess ER/w(i))

4 Simulation Con gurations We used simple, transient, link bottleneck and source bottleneck con gurations to test the proposed algorithms. In nite sources were used (which have an in nite amount of data to send, and always send data at ACR) in all the simulations. The rates are expected to converge to GW fair allocation values in the presence of in nite sources. The algorithms are expected to give minimum rate guarantees for Poisson or self-similar sources. These types of sources were not used since the GW fair allocation for source with varying rates is also 10

dynamically varying. The data trac is only one way, from source to destination. Using two-way trac would produce similar results, expect that the convergence time would be larger since the RM cells in the backward direction would travel with trac from destination to source. All the link bandwidths are 149.76 (155.52 less the SONET overhead), except in the GFC-2 con guration.

4.1 Three Sources This is a simple con guration in which three sources send data to three destinations over two switches and a bottleneck link. See gure 2. This con guration is used to demonstrate that the switch algorithms can achieve the GW fairness. Source 1 Source 2

Destination 1

Switch 1

Bottleneck Link

Switch 2

Destination 2 Destination 3

Source 3

Figure 2: N Sources - N Destinations Con guration

4.2 Source Bottleneck In this con guration, the source S1, is bottle-necked to rate (10 Mbps), which is below its fairshare (50 Mbps) for rst 400 ms of the simulation. This con guration tests whether the fairness criterion can be achieved in the presence of source bottleneck.

Figure 3: 3 Sources - Bottleneck Con guration

11

4.3 Generic Fairness Con guration - 2 (GFC-2) This con guration is a combination of upstream and parking lot con guration (See Figure 4). In this con guration, all the links are bottle-necked links. This con guration is explained in [19].

Figure 4: Generic Fairness Con guration - 2

4.4 Simulation Parameters The simulations were done using extensively modi ed version of NIST ATM simulator [20]. The parameter values for di erent con gurations are given in Table 1. The algorithms were simulated using both constant queue control function (Fraction = 0:9) and using dynamic queue control function. The dynamic queue control function tries to achieve a constant queue length at steady state. The \Target Delay" parameter speci es the desired queue length at steady state. For dynamic queue control, hyperbolic functions was used, with curve parameters a = 1:15 and b = 1. The QDLF value was set to 0:5. Exponential averaging was used to decrease the variation in measured quantities such as overload and number of VCs. Exponential averaging of overload factor and number of VCs were done with a decay factor of 0.8 for algorithms A and D. The algorithms B and C are more sensitive to overload factor. So, a the decay factor of 0.4 was used to average overload in algorithms C and D. 12

Table 1: Simulation Parameter Values Con guration Name Three Sources Source Bottleneck GFC-2

Link Averaging Target Weight Distance interval Delay Function 1000 Km 5 ms 1.5 ms 1 1000 Km 5 ms 1.5 ms 1 1000 Km 15 ms 1.5 ms 1

The weight function of one was used in all con gurations. This corresponds to MCR plus equal share of excess bandwidth. The value of  = 0:1 was used for algorithm D. In [16] it was shown that algorithm A achieves GW fairness for other various values of weight function.

5 Simulation Results In this section we present the simulation results of algorithms using di erent con gurations. Table 2 gives the expected GW fair allocation with constant queue control function (shown as con guration name and CQF) and with dynamic queue control function (shown as con guration and DQF) for each simulation using three source con guration. The queues when using constant queue control function took longer time to drain. The bottle-neck link utilization was as expected 90% when constant queue control was used. With dynamic queue control the algorithms achieved 100% link utilization for bottle-necked links.

5.1 Three Source: Results The MCR value for the three source con guration is 10,30,50 Mbps for the source 1, source 2 and source 3 respectively. For the simulation with queue control, the excess bandwidth (149.76 - 90 =) 59.76 is divided equally among the three sources. The expected allocation is (10+59.76/3, 30+59.76/3, 50+59.76/3) = (29.92, 39.92, 69.92). Figure 5(a)-(d) shows the ACRs for algorithms A,B,C and D (with dynamic queue control) respectively. Figure 5(e)(h) shows the ACRs for the algorithms using constant queue control function. From the 13

Table 2: GW fair allocation for di erent con gurations Con guration Source 1 Source 2 Source 3 and Queue Control Simple and CQF 14.93 44.93 64.93 Simple and DQF 29.92 49.92 69.92 Transient and CQF (0-0.4s,0.8-1.2s) 67.39 67.39 Transient and DQF (0-0.4s,0.8-1.2s) 74.88 74.88 Transient and CQF (0.4-0.8s) 44.93 44.93 44.93 Transient and DQF (0.4-0.8s) 49.92 49.92 49.92 Source Bottleneck and CQF (0-0.4s) 32.39 52.39 72.39 Source Bottleneck and DQF (0-0.4s) 39.86 59.86 79.86 Source Bottleneck and CQF (0.4-0.8s) 14.93 44.93 64.93 Source Bottleneck and DQF (0.4-0.8s) 29.92 49.92 69.92 graphs, it can be seen that the expected allocation is achieved by all the four algorithms, using constant queue control and dynamic queue control.

5.2 Three Source Transient: Results MCR value of zero was used for all three sources in this con guration. The con guration simulation was simulated for 1.2 seconds. Source 2, is a transient source. It is active between 0.4 to 0.8 seconds of the simulation. For the simulation using dynamic queue control, the expected allocation is (74.88,0,74.88) during (0,0.4s) and (0.8-1.2s) where source 2 is not active. The expected allocation is (49.92,49.92,49.92) during (0.4,0.8s) time interval. Figures 6 (a)-(d) shows the ACRs for the algorithms A, B, C and D with dynamic queue control respectively. Figures 6(e)-(h) shows the ACRs for the algorithms with constant queue control. All the algorithms achieve the expected allocation in both non-transient and transient periods. Algorithm B is sensitive to queue control function, hence there rates oscillate (see Figure 6(b) ) during the non-transient periods. 14

5.3 Source Bottleneck: Results In this con guration the MCR values of (10,30,50) Mbps were used. The total simulation time was 800 ms. The source S1, is bottle-necked at 10 Mbps for rst 400 ms of the simulation. It always sends data up to 10 Mbps even its ACR larger than 10 Mbps. Figures 7 (a)-(d) shows the ACRs for the algorithms A, B, C and D with dynamic queue control respectively. Figures 7(e)-(h) show the ACRs graph for the algorithms using constant queue control function. The expected allocation is (39.86,59.86,79.86) for rst 400 ms and it is (29.92,49.92,69.92) after 400 ms. The algorithms A and B do not converge to the expected allocation. The CCR value in the RM cells of source S1, do not re ect the actual source rate. The algorithms C and D do converge to the expected allocation. Algorithm C performs better than algorithm D, since it has lesser oscillations. Figures 8 (a)-(b) show the ACRs using measured source rate (per VC option) instead of CCR eld for algorithms A and B with dynamic queue control. Figures 8 (c)-(d) show the ACRs for algorithms A and B with constant queue control function. When measured source rate is used the algorithms A and B do converge to expected allocations in the presence of source bottleneck.

5.4 GFC-2: Results MCR value of zero was used for all sources. Figure 9 (a)-(d) show the ACRs of each type of VCs A through H for algorithms A, B, C and D with dynamic queue control respectively. Figure 9(e)-(h) shows corresponding ACRs graph when constant queue control function was used with the algorithms. The expected allocation with constant queue control and dynamic queue control is given in the table 3. Algorithm B and D have rate oscillations due to queue control. Algorithm B with constant queue control, does not converge to expected GW fair allocation as seen in gure 9(f). Due to limitations of precision in calculation, the algorithm converged to a point where (SourceRate(i) ? i )  z = ExcessFairShare(i), with z < 1. In fact the overload factor for link between switches SW1 and SW2 was only 0:85. The maximum queue occurred at switch SW6 around 500 ms for all algorithms. The value of the maximum queue was 39000, 30000, 340000 and 34000 cells for algorithms A, B, C and D respectively. Algorithm C does not have any queue control. Algorithm C had 15

a huge queue because the maximum allocation for A type VC which has large round trip time was assigned for seven VCs of type G which have small round trip time. The input rate at the link between SW6 and SW7 is overloaded by a factor of seven which gives rise to the huge queues. Table 3: GFC-2 con guration: Expected allocations VC A B C D E F G H When using DQF 10 5 35 35 35 10 5 52.5 When using CQF 9 4.5 31.5 31.5 31.5 9 4.5 47.25

6 Comparison of Switch Schemes Table 4 gives a comparison of the algorithms. Scheme End of Interval Feedback Max. Queue Requires Per VC for Sensitivity to Name Complexity Complexity Length Source Bottleneck Queue control Algorithm A O(N) O(1) Medium Yes Yes Algorithm B O(N) O(1) Medium Yes Yes Algorithm C O(1) O(1) Large No No Algorithm D O(1) O(1) Medium No No Table 4: Comparison of the algorithms Algorithm A has O(N) complexity at end of the interval. Algorithm B is not fair in the presence of link bottlenecks. Algorithm D results in large switch queues. The algorithm D is the best of the proposed algorithm since it has O(1) complexity both at the end of interval and when a BRM cell arrives. It also does not require per VC accounting and is not sensitive to the queue control function.

16

7 Conclusion In this paper, we have presented four algorithms which achieve GW fairness and provide MCR guarantee. The algorithms monitor the load on the link and calculate the overload factor. The overload and other quantities (ExcessFairShare or WtMaxAllocPrevious) are used to calculate the feedback rates. The algorithm proposed have similar structure. The algorithms di er in the end of interval accounting and feedback calculation. Simulations show that the algorithms converge to GW fairness in most cases. Queue control can be done using constant function and dynamic (hyperbolic) function. Algorithm B is unfair in the presence of link bottlenecks. Algorithm A and B have O(N) complexity for the end of interval calculations. Algorithm C, can give rise to large queues if the con guration has sources with di erent round trip times sharing the same link. The algorithm D, which uses the V CShare and WtMaxAllocPrevious is the best, since it has O(1) complexity and does not require per VC accounting to handle source bottlenecks.

abr_3.snapfile/case=wAL_ccr_exfs/option=14403/optionb=295/dist=1000/sto

abr_3.snapfile/case=wAL_ovl_exfs/option=14403/optionb=295/dist=1000/stoptime=

ptime=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=2/ / Date:07/08/98

600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=4/swdum11=0.4/ / Date:07/08/98

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

120 ACR (Mb/s)

ACR (Mb/s)

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

120 100 80 60 40

100 80 60 40

20

20

0

0 0

100

200 300 400 Time in milliseconds

500

0

600

(a) Algorithm A and DQF

100

=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=16/swdum11=0.4/ / Date:07/08/98 ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

600

abr_3.snapfile/case=final_ccr_maxfs/option=14403/optionb=295/dist=1000/stoptime

abr_3.snapfile/case=final_ccr_maxfs/option=14403/optionb=295/dist=1000/stoptime =600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=16/swdum11=0.4/ / Date:07/08/98

100 80 60 40

100 80 60 40

20

20

0

0 0

100

200 300 400 Time in milliseconds

500

600

0

(c) Algorithm C and DQF

100

200 300 400 Time in milliseconds

500

600

(d) Algorithm D and DQF abr_3.snapfile/case=info_ovl_exfs/option=14401/optionb=295/dist=1000/stoptime

abr_3.snapfile/case=info_ccr_exfs/option=14401/optionb=295/dist=1000/st

=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=4/swdum11=0.4/ / Date:07/16/98

optime=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=2/ / Date:07/16/98

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

500

(b) Algorithm B and DQF

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

100 80 60 40

100 80 60 40 20

20 0

0 0

100

200 300 400 Time in milliseconds

500

600

0

(e) Algorithm A and CQF

100

200 300 400 Time in milliseconds

500

600

(f) Algorithm B and CQF

abr_3.snapfile/case=info_ovl_maxfs/option=14401/optionb=295/dist=1000/stoptime

abr_3.snapfile/case=info_ccr_maxfs/option=14401/optionb=295/dist=1000/stoptime

=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=8/swdum11=0.4/ / Date:07/16/98

=600000/exp_avg_N=0.9/t0v=5000/f_r=5000/swdum3=16/swdum11=0.4/ / Date:07/16/98

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:90.00 90.00 90.00 90.00 90.00 90.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

200 300 400 Time in milliseconds

100 80 60

100 80 60

40

40

20

20 0

0 0

100

200 300 400 Time in milliseconds

500

(g) Algorithm C and CQF

600

0

100

200 300 400 Time in milliseconds

500

600

(h) Algorithm D and CQF

Figure 5: Three Sources: ACR graphs for algorithms A, B, C and D. 18

abrtrans_3.snapfile/case=wAL_trans_2/option=14403/optionb=295/dist=1000/s

abrtrans_3.snapfile/case=wAL_trans_4/option=14403/optionb=295/dist=1000/stoptim

toptime=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=2/ / Date:07/08/98

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=4/swdum11=0.4/ / Date:07/08/98

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

120 ACR (Mb/s)

ACR (Mb/s)

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

120 100 80 60 40

100 80 60 40

20

20

0

0 0

200

400 600 800 Time in milliseconds

1000

1200

0

(a) Algorithm A and DQF

200

abrtrans_3.snapfile/case=fin_trans_8/option=14403/optionb=295/dist=1000/stoptim

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=16/swdum11=0.4/ / Date:07/08/98 ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

1200

abrtrans_3.snapfile/case=fin_trans_16/option=14403/optionb=295/dist=1000/stoptim

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=8/swdum11=0.4/ / Date:07/08/98

100 80 60 40

100 80 60 40

20

20

0

0 0

200

400 600 800 Time in milliseconds

1000

1200

0

(c) Algorithm C and DQF

200

400 600 800 Time in milliseconds

1000

1200

(d) Algorithm D and DQF

abrtrans_3.snapfile/case=info_trans_2/option=14401/optionb=295/dist=1000/s

abrtrans_3.snapfile/case=info_trans_4/option=14401/optionb=295/dist=1000/stoptim

toptime=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=2/ / Date:07/16/98

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=4/swdum11=0.4/ / Date:07/16/98

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

1000

(b) Algorithm B and DQF

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

100 80 60 40

100 80 60 40

20

20

0

0 0

200

400 600 800 Time in milliseconds

1000

1200

0

(e) Algorithm A and CQF

200

400 600 800 Time in milliseconds

1000

1200

(f) Algorithm B and CQF

abrtrans_3.snapfile/case=info_trans_8/option=14401/optionb=295/dist=1000/stoptim

abrtrans_3.snapfile/case=info_trans_16/option=14401/optionb=295/dist=1000/stoptim

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=8/swdum11=0.4/ / Date:07/16/98

e=1200000/exp_avg_N=0.9/f_r=5000/t0v=1500/swdum3=16/swdum11=0.4/ / Date:07/16/98

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

ICR:50.00 10.00 40.00 10.00 55.00 10.00 / XRM:253.00 253.00 253.00 253.00 253.00 253.00 / Graph: 0

3 Sources: ACR for ABR sources

3 Sources: ACR for ABR sources

160

160 ACR of abr[1] ACR of abr[2] ACR of abr[3]

140

ACR of abr[1] ACR of abr[2] ACR of abr[3]

140 120 ACR (Mb/s)

120 ACR (Mb/s)

400 600 800 Time in milliseconds

100 80 60

100 80 60

40

40

20

20

0

0 0

200

400 600 800 Time in milliseconds

1000

(g) Algorithm C and CQF

1200

0

200

400 600 800 Time in milliseconds

1000

1200

(h) Algorithm D and CQF

Figure 6: Three Sources transient: ACR graphs for algorithms A, B, C and D

btlnk.snapfile/option=14403/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1

btlnk.snapfile/option=14403/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1

500/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=wAL_bot_A/swdum3=2/ / Date:07/08/98

500/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=wAL_bot_B/swdum3=4/ / Date:07/08/98

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160

ACR for S1 ACR for S2 ACR for S3

140

120

120

100

100

ACRs

ACRs

140

160

80

80

60

60

40

40 20

20 0

0 0

100

200

300 400 500 Time in milliseconds

600

700

0

800

(a) Algorithm A and DQF

100

200

800

0/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=bot_D_pervc/swdum3=16/ / Date:07/08/98 ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160 140

ACR for S1 ACR for S2 ACR for S3

160 140

120

120

100

100

ACRs

ACRs

700

btlnk.snapfile/option=14531/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=150

btlnk.snapfile/option=14531/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=15

80

80

60

60

40

40 20

20 0

0 0

100

200

300 400 500 Time in milliseconds

600

700

800

0

(c) Algorithm C and DQF

100

200

300 400 500 Time in milliseconds

600

700

800

(d) Algorithm D and DQF

btlnk.snapfile/option=14401/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1

btlnk.snapfile/option=14401/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1

.0/sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botA/swdum3=2/ / Date:07/16/98

.0/sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botB/swdum3=4/ / Date:07/16/98

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160 140

ACR for S1 ACR for S2 ACR for S3

160 140

120

120

100

100

ACRs

ACRs

600

(b) Algorithm B and DQF

00/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=bot_C_pervc/swdum3=8/ / Date:07/08/98

80

80

60

60

40

40

20

20

0

0 0

100

200

300 400 500 Time in milliseconds

600

700

800

0

(e) Algorithm A and CQF

100

200

300 400 500 Time in milliseconds

600

700

800

(f) Algorithm B and CQF

btlnk.snapfile/option=14529/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1.0/

btlnk.snapfile/option=14529/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1.0/

sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botC_pervc/swdum3=8/ / Date:07/16/98

sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botD_pervc/swdum3=16/ / Date:07/16/98

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160 140

ACR for S1 ACR for S2 ACR for S3

160 140

120

120

100

100

ACRs

ACRs

300 400 500 Time in milliseconds

80

80

60

60

40

40

20

20

0

0 0

100

200

300 400 500 Time in milliseconds

600

700

(g) Algorithm C and CQF

800

0

100

200

300 400 500 Time in milliseconds

600

700

800

(h) Algorithm D and CQF

Figure 7: Source Bottleneck: ACR graphs for Algorithm A, B, C and D. 20

btlnk.snapfile/option=14531/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500

btlnk.snapfile/option=14531/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500

/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=wAL_bot_A_pervc/swdum3=2/ / Date:07/08/98

/air=1.0/sw_int=100/t_threshold=400000/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=wAL_bot_B_pervc/swdum3=4/ / Date:07/08/98

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160

140

120

120

100

100

ACRs

ACRs

140

ACR for S1 ACR for S2 ACR for S3

160

80

80

60

60

40

40

20

20

0

0 0

100

200

300 400 500 Time in milliseconds

600

700

800

0

(a) Algorithm A with Dynamic Queue Control

100

200

600

700

800

(b) Algorithm B with Dynamic Queue Control

btlnk.snapfile/option=14529/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1.0/

btlnk.snapfile/option=14529/optionb=110/stoptime=800000/exp_avg_N=0.9/icr=25.0/icr1=50.0/icr2=30.0/icr3=110.0/xdf=0.0/tdf=0.0/t0v=1500/air=1.0/

sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botA_pervc/swdum3=2/ / Date:07/16/98

sw_int=100/t_threshold=400000/mxlnkrate=149.76/maxsrcrate=10.0/mib=20000/mib=20000/wandist=1000/case=info_botB_pervc/swdum3=4/ / Date:07/16/98

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

ICR:50.00 25.00 30.00 25.00 110.00 25.00 / XRM:256.00 256.00 256.00 256.00 256.00 256.00 / Graph: 0

WAN Bottlenecked: ACRs

WAN Bottlenecked: ACRs

180

180 ACR for S1 ACR for S2 ACR for S3

160 140

ACR for S1 ACR for S2 ACR for S3

160 140

120

120

100

100

ACRs

ACRs

300 400 500 Time in milliseconds

80

80

60

60

40

40

20

20

0

0 0

100

200

300 400 500 Time in milliseconds

600

700

800

(c) Algorithm A with Constant Queue Control

0

100

200

300 400 500 Time in milliseconds

600

(d) Algorithm B with Constant Queue Control

Figure 8: Source Bottleneck: ACR graphs for Algorithm A, B using measured source rate

21

700

800

gfc2.snapfile/case=wAL_ccr_exfs/option=14403/stoptime=2500000/exp_

gfc2.snapfile/case=wAL_ovl_exfs/option=14403/stoptime=2500000/exp_avg_N=

avg_N=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=2/ / Date:07/08/98

0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=4/swdum11=0.8/ / Date:07/08/98

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

GFC-2: ACRs

GFC-2: ACRs

180

180 A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

140

ACRs

120 100

A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

160 140 120 ACRs

160

80

100 80

60

60

40

40

20

20

0

0 0

500

1000 1500 Time in milliseconds

2000

2500

0

(a) Algorithm A and DQF

500

gfc2.snapfile/case=final_ovl_maxfs/option=14403/stoptime=2500000/exp_avg_

gfc2.snapfile/case=final_ccr_maxfs/option=14403/stoptime=2500000/exp_avg_N

N=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=8/swdum11=0.4/ / Date:07/08/98

=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=16/swdum11=0.4/ / Date:07/08/98

GFC-2: ACRs 180 A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

140 120 100

A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

160 140 120 ACRs

160

ACRs

2500

ICR:17.64 43.97 / XRM:253.00 253.00 253.00 / Graph: 0

GFC-2: ACRs 180

80

100 80

60

60

40

40

20

20

0

0 0

500

1000 1500 Time in milliseconds

2000

2500

0

(c) Algorithm C and DQF

500

1000 1500 Time in milliseconds

2000

2500

(d) Algorithm D and DQF

gfc2.snapfile/case=info_ccr_exfs/option=14401/stoptime=2500000/exp

gfc2.snapfile/case=info_ovl_exfs/option=14401/stoptime=2500000/exp_avg_N

_avg_N=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=2/ / Date:07/16/98

=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=4/swdum11=0.8/ / Date:07/16/98

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

GFC-2: ACRs

GFC-2: ACRs

180

180 A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

140 120 100

A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

160 140 120 ACRs

160

ACRs

2000

(b) Algorithm B and DQF

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

80

100 80

60

60

40

40

20

20

0

0 0

500

1000 1500 Time in milliseconds

2000

2500

0

(e) Algorithm A and CQF

500

1000 1500 Time in milliseconds

2000

2500

(f) Algorithm B and CQF

gfc2.snapfile/case=info_ovl_maxfs/option=14401/stoptime=2500000/exp_avg_N

gfc2.snapfile/case=info_ccr_maxfs/option=14401/stoptime=2500000/exp_avg_N

=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=8/swdum11=0.4/ / Date:07/16/98

=0.9/t0v=1500/a=1.15/b=1/f_r=15000/swdum3=16/swdum11=0.4/ / Date:07/16/98

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

ICR:17.64 43.97 / XRM:253.00 253.00 / Graph: 0

GFC-2: ACRs

GFC-2: ACRs

180

180

140 120 100 80

140 120 100 80

60

60

40

40

20

20

0

A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

160

ACRs

A_SW1 B_SW1 C_SW5 D_SW1 E_SW2 F_SW3 G_SW6 H_SW4

160

ACRs

1000 1500 Time in milliseconds

0 0

200

400

600 800 1000 1200 1400 1600 1800 Time in milliseconds

(g) Algorithm C and CQF

0

500

1000 1500 Time in milliseconds

2000

2500

(h) Algorithm D and CQF

Figure 9: GFC-2 con guration: ACR graphs for algorithms A, B, C and D with dynamic queue control.

References [1] Shirish S. Sathaye. \ATM Forum Trac Management Speci cation Version 4.0". April 1996 [2] Nanying Yin and M. G. Hluchyj. \On closed-loop rate control for ATM cell relay networks". In Proc. of IEEE INFOCOM, pp. 99-108, 1994. [3] Anna Charny. \An algorithm for rate allocation in a packet-switching, network with feedback". Master's thesis, MIT, Cambridge, May 1994. [4] Danny H. K. Tsang, Wales K. F. Wong. \A new rate-based switch algorithm for ABR trac to achieve max-min fairness with analytical approximation and delay adjustment". In Proc. IEEE Globecom'96. [5] Shivkumar Kalyanaraman, Raj Jain, Rohit Goyal, Sonia Fahmy, and Bobby Vandalore. \The ERICA Switch Algorithm for ABR Trac Management in ATM Networks," 3 Submitted to IEEE/ACM Transactions on Networking, November 1997, [6] C. Fulton, San-Qi Li and C. S. Lim. \UT: ABR feedback control with tracking". Preprint. [7] L. Kalampoukas, A. Varma, K. K. Ramakrishnan. \An ecient rate allocation algorithm for ATM networks providing max-min fairness". In Proc. of the 6th IFIP International Conference on High Performance Networking, September 1995. [8] K. Siu and T. Tzeng. \Intelligent congestion control for ABR service in ATM networks". Computer Communication Review, vol. 24, no. 5, pp. 81-106, October 1995. [9] Y. Afek, Y. Mansour, and Z. Ostfeld. \Phantom: A simple and e ective ow control scheme". In Proceedings of the ACM SIGCOMM, August 1996. [10] L. Roberts. \Enhanced PCRA (Proportional Rate Control Algorithm)". ATM Forum Contribution/AF-TM 94-0735R1, August 1994. 3

All our papers and ATM Forum contributions are available through http://www.cis.ohio-state.edu/~jain/

23

[11] Yiewei T. Hou, Henry H.-Y. Tzeng, Shivendra S. Panwar. \A generalized max-min rate allocation policy and its distributed implementation using the ABR ow control mechanism". In Proc. of INFOCOM, April 1998. [12] Santosh P. Abraham and Anurag Kumar. \A stochastic approximation approach for a max-min fair adaptive rate control of ABR sessions with MCRs". In Proc. of INFOCOM, April 1998. [13] Y. T. Hou, H. Tzeng, and S. S. Panwar. \A Simple ABR switch algorithm for the weighted max-min fairness policy". In Proc. IEEE ATM'97 Workshop, pp. 329-338, Lisbon, Portugal, May 25-28, 1997. [14] D. Hughes. \Fair share in the context of MCR". ATM Forum contribution/AF-TM 94-0977, October 1994. [15] N. Yin. \Max-min fairness vs. MCR guarantee on bandwidth allocation for ABR". In Proc. of IEEE ATM'96 Workshop, San Franscisco, CA, August 25-27, 1996. [16] Bobby Vandalore, Sonia Fahmy, Raj Jain, Rohit Goyal, Mukul Goyal, \A De nition De nition of General Weighted Fairness and its Support in Explicit Rate Switch Algorithms", To appear in ICNP `98, Austin, Texas, October 1998, [17] Bobby Vandalore, Raj Jain, Rohit Goyal, Sonia Fahmy \Design and Analysis of Queue Control Functions for Explicit Rate Switch Schemes" Submitted to IC3N'98. [18] Sonia Fahmy, Raj Jain, Shivkumar Kalyanaraman, Rohit Goyal and Bobby Vandalore, \On Determining the Fair Bandwidth Share for ABR Connections in ATM Networks," Proc. of the IEEE International Conference on Communications (ICC) 1998, June 1998 [19] Robert J. Simcoe. \Test con gurations for fairness and other tests". ATM Forum/940557, July 1994. [20] Nada Golmie. \Netsim: network simulator". http://www.nist.gov/.

24

Suggest Documents