Providing Fairness in DiffServ Architecture

Transcription

1 Providing Fairness in DiffServ Architecture Department of Computer Science & Engineering The Pennsylvania State University University Park, PA 162 Abstract abstrct I INTRODUCTION The Differentiated Services (DiffServ) [1] proposed by the Internet Engineering Task Force (IETF), has become the most viable solution in providing the Quality of Service (QoS) over IP network ( due to scalability ) In the Diffserv architecture, IP flows are classified into different forwarding schemes, and aggragated according to them The one of the forwarding mechanisms has been standardized by the DiffServ working group is Assured Forwarding Per-Hop Behaviors (AF PHBs) [2] In the AF PHBs, Packets are monitored and marked according to the service profile called service level agreement at the edge of the network If the measured flow conforms to the service profile, the packets that belong to this flow are marked as an in-profile, otherwise the packets are marked as an out-profile At the time of congestion, the core router deploys RIO-like [3] queue management mechanism to give a better chance to survive for the in-profile packets by preferably dropping the out-profile packets Although the AF PHBs did not recommended a specific mechanism to share excess resources, the fair sharing of excess resources is strongly required to deploy AF class over currently existing class ie, class (BE class) The excess resource problem can be addressed in two different aspect: inter class and intra class fairness Most of the recent researches tackled the intra class fairness problems such as the impact of responsive and non-responsive flow interaction within a single class However, the inter class fairness problems has not been properly addressed yet In this paper, we propose the followings to provide the inter and intra class fairness in the DiffServ architecture Fair WRR: Since edge router do not have flow aggragate information about core of the network, inter class fairness should be addressed in the core of the network In this paper, the fair WRR is proposed to protect the best-effort traffic from out-profile packets of AF class The fair WRR dynamically adjusts the service weights and buffer spaces according to the traffic changes to avoid unfair bandwidth share while maintaining low packet loss rate Fair Dropper: In DiffServ architecture, all the sophisticated traffic conditioning functions are pushed to the edge router so that the core router do not aware of the flow level bandwidth share Therefore, the intra class fairness should be addressed at the edge router In this paper, the fair dropper is proposed to detect and penalize two greedy flows: One is the non-responsive flows which does not respond to the congestion notification and the other is the responsive flows that recover from the congestion too early than the others The simulation results The rest of this paper is organized as follow: Section II briefly summarize the background and motivation of this work The proposed scheduling and dropping algorithm is detailed in Section III In Section IV, the results of the simulation are demonstrated and discussed Finally, the concluding remarks are followed at Section V II BACKGROUND AND MOTIVATION This section summarizes motivation for this work and previous works: Differentiated Service is defined by PHBs, and the PHB can be specified by in terms of the resources required to meet the service goals such as end-to-end delay and loss rate The bandwidth and buffer are the most common resources in network so that adopting or developing the most appropriate resource management mechanisms (scheduling and active queue management mechanism respectively) is the critical factor not only in implementing the PHBs but also in assuring the fairness in the Diff- Serv The required functionality of these two mechanisms in the router varies as the location of the router does ie, the edge or core of the network We will briefly explain the required functionality of the router at edge and core of the network in term of the scheduling and active queue management schemes A Core router The amount of traffic in network core is enormously large compare to edge of the network so that the core router should be as simple and fast as possible Therefore, maintaining flow level information is obviously unaffordable burden for the core router However, the network core is the only place that the aggregated traffic can be measured if the overhead can be ignored Therefore, the core router should be able to provide a mechanism that controls the fairness such as fair share of excess bandwidth between different classes of service Active Queue Management Scheme: The main role of active queue management mechanism is to avoid the congestion and global synchronization to achieve better link utilization In diffserv architecture, differentiated packet dropping mechanism is another important functionality that should be implemented in the active queue management scheme Many variations of multi-level RED such as RIO-C, RIO-DC, WRED can be deployed in the core router to implement different levels of drop precedences In multi-level RED, a set of RED [4] parameters for out-profile packets is more aggressive than that of in-profile packets so that out-profile packets experience relatively earlier and severe loss than in-profile packets A study [5]have shown that RIO-C generally outperforms the RIO-DC and WRED in terms of the protection on in-profile packets, and recommended the staggered RED parameter set to provide the better protection

2 n1 n5 1Mbs 1Mbs d1 dynamically changing workload to give a fair treat on BE packets over AF out-profile packets n6 1Mbs Edge Router n1 1-1ms 1Mbs d5 b1 b5 1Mbs 3ms Core Router 1Mbs 1ms Core Router d6 (a) Bandwidth of 1 AF flows (b) Bandwidth of AF flows b6 Edge Router 1Mbs 1-1ms b1 1-1ms d1 End Host End Host Drop Rate Drop Rate Fig 1 The network topology used for simulation on the in-profile packets Scheduling Scheme: Generally, Priority Queuing [6], WRR [7], and Class-Based Queuing (CBQ) [8]are considered as a core router scheduling algorithm, especially, Priority Queuing and WRR are preferred for its simplicity However, the impact of the number of aggregation on inter class fairness over statically configured scheduler has not been reported yet To demonstrate the limitation of statically configured scheduler, we performed the simple simulations using the topoligy shown in Fig 1 via ns2 simulator [9] Traffics were injected to one direction over common 5Mbs link using FTP over TCP/Reno agent, and only ACKs were coming back from the other direction The half of upper senders (n1 to n5) and the half of lower senders (b6 to b1) generated AF traffics and the rest of the senders generated BE traffics, and we set the committed bandwidth for each sender as 64kbps At the edge router, the token bucket traffic meter was used with simple FIFO scheduler, and RED was used as an active queue management scheme with RED parameters of //2 over maximum buffer size The core router operated with WRR and RIO-C with separate buffers for each class (one for AF and the other for BE, and both had maximum buffers ) //1 and //2 were used for AF out-profile and AF in-profile packets respectively, and //1 is used for BE traffic Fig 2 shows the impact of statically configured WRR scheduler on the inter class fairness as the number of established connections varies In Fig 2 (a), 1 AF flows and BE flows were started every 2 sec and we measured the percent bandwidth of the each class of traffics for secs at secs In Fig 2 (b), the number of connection for AF class were increased to If the allocated bandwidth for AF class is between 1 to 7%, the AF traffic suffered from high loss rate so that protection on AF in-profile packets could not be assured To protect AF in-profile packets, the service weight of WRR for AF class should be at least % of link bandwidth However, In figure 2 (a), this value resulted in unnecessary over-protection on AF out-profile packets when the number of AF connection reduced to 1 so that more than 7link bandwidth were consumed for AF out-profile packets whereas the BE flows were suffering from unaffordably high loss-rate Therefore, scheduling mechanism should be able to adopt to (c) Loss Rate of 1 AF flows (d) Loss Rate of AF flows Fig 2 1 and AF flows are competing for the bandwidth over statically configured WRR B Edge router The role of the edge router in DiffServ architecture, is more complicated than that of the core router The edge router should be able to provide metering policing, and shaping for the incoming flows by the requirement of the class to which the flows belong Since, the edge router meters and maintains the information on each individual flow, the edge router is the most appropriate place that can tackle the fairness among the competing flows in a class ie, intra class fairness Not like in the core router, The fairness among the competing flows in a class can be addressed in both active queue management scheme and scheduling scheme Active Queue Management Scheme: It is well known fact that the packet loss rates of RED are proportional to the bandwidth share this leads to the skewed bandwidth share toward non-responsive against responsive flows FRED [1], SFB [11], RED-PD [12], CHOKe [13] are versions of active queue management schemes that were proposed to protect responsive flows from greedy non-responsive flows All these schemes tried to minimize the number of per-flow information that should be maintained, on the other hand, identify and penalize the nonresponsive flows effectively with limited amount of information Applying these schemes on out-profile packets may provide the fairness with minor modification However, as it was discussed in [12], the performance of SFB and CHOKe may not be guaranteed with large number of flows or non-responsive flows and FRED and RED-PD still maintain per-flow information using different sampling schemes although the number of monitored flows are small Moreover, the performance of these scheme on the responsive flows which have different round-trip time has not been extensively studied yet Scheduling Scheme: If the overhead of maintaining the priority, time order can be ignored, there are many different scheduling algorithms can be used to support required property of the service with fairness However, the major concern in here is the overhead caused by sophisticated scheduling schemes

3 III THE PROPOSED SCHEME In this section we describe the proposed scheme to provide the fairness in DiffServ the proposed scheme includes two mechanism; The one, called Fair WRR, is for the core router scheduling scheme to provide inter class fairness and the other is the fair dropper for intra class fairness at edge router The functionality of the fair dropper can be absorbed into the sophisticated scheduling algorithm However, the fair dropper takes advantage of simplicity when used with simple WRR or FCFS A Fair WRR In The Core Router A1 Dynamic Service Weight (DSW) As we described in the previous section, the AF out-profile packets may consume significant amount of bandwidth with statically configured WRR so that the BE traffic suffer from unfairly large loss rate To prevent this, the service weight of any rate based scheduler should be able to dynamically adapt to given workload Generally, AF class is differentiated from BE class in that mainly AF traffic should experience low loss rate than BE traffic so that the protection on in-profile can be an important performance metric in providing AF class over BE class Therefore, the in-profile packet loss can be used as a signal to increase the allocated bandwidth (ie, service weight) for AF traffic class, vice versa The amount of increment is taken from the previously allocated bandwidth for BE class On the other hand, sustained overflow at BE class and no loss at AF class can be used to decrease the allocated bandwidth for AF traffic class to protect the BE traffic packets from monopolizing out-profile packets This is the key idea of the fair WRR Figure 3 shows the fair WRR algorithm However, the care should be taken when the BE class service weight increase because the increment comes from the AF class service weight the over-sensitive reduction in AF bandwidth can cause oscillation in bandwidth allocation between two classes so that this can lead unnecessary AF inprofile packet loss Therefore, we used overflow in BE buffer, BE average queue size, which is calculated in RIO, and longer periods in decreasing AF service weight if ( (now ; last time) > monitor period) if ( AF in drop count > ) decrease service weight BE by one unit increase service weight AF by one unit else if((overflow count BE > ) and ( Avg queue BE > congestion thresh ) and ( decrease count == decrease thresh )) decrease service weight AF by one unit increase service weight BE by one unit last time = now Fig 3 Fair WRR algorithm A2 Dynamic Buffer Allocation (DBA) If the number of AF connections are increased, AF in-profile packet are dropped due to low service weight This activates the fair WRR to adjust the AF service weight to accommodate the amount of in-profile traffic injected Therefore, small number of the AF in-profile packet losses are unavoidable when the service weight is dynamically adjusted One way to prevent further inprofile packet loss when the traffic is in increasing phase is to give more buffer space The fair WRR with dynamic buffer allocation (DBA) works as following: When the service weights of AF class and BE class are balanced, the default amount buffer size is allocated As the service weight of one class grows, the buffer size for the class also grows linearly The amount of increased buffer space comes from the other class which is relatively less congested When the buffer size should be decreased in AF class and there is insufficient amount of free buffer space, The buffered packets are dropped at the end of the buffer as long as it is not in-profile packet The fair WRR with dynamic buffer size works in two folds First, the in-profile packets loss is lessened When the AF traffic is in increasing phase, the fair WRR finds the proper service weight at the cost of small in-profile packets loss This unnecessary packet loss can be lessened by allocating more buffer spaces for possible successive in-profile packets Moreover, since the minimum and maximum thresholds of RIO are pushed up as the buffer space increase, the increased buffer space gives more chance for the in-profile packet to survive at the congestion Second, the end-to-end delay is stabilized If the buffer size is fixed with dynamically adjusted service weight, the variations of the end to end delays fluctuate as the number of connection varies Moreover, If the service rate is decreased with the same buffer size, the buffer will grow as the number of AF connection decrease Here, the unnecessarily large buffer will give a more chance for AF out-profile packets to survive so that the large buffer will only contribute to longer end-to-end delay without decreasing loss rate In dynamic buffer allocation scheme, the allocated buffer space is proportional to the service weight Therefore, the end to end delay fluctuations are lessened with more protection on in-profile packets at the congested node However, The special care should be taken with DBA because RED (or RIO) requires at least some amount of buffer space to work properly For example, if the allocated buffer space for BE class is too small, then the buffer will suffer frequent overflows and this will leads the most of TCP flows remain in the time-out periods Then, the minimum bandwidth for the BE class may not be guaranteed B Fair Dropper In The Edge Router The Load Adaptive Fair Dropping (LAFD) was proposed in [14] to address the difficulties of RED in dealing with the congestion such as static parameter setting, inaccurate congestion estimation The main idea of LAFD is to calculate optimal drop rate for given link capacity and current packet drop rate from following TCP throughput estimation formula [15] X r 1 3 x = RT T where p is loss probability, and RTT is round-trip time for the flow Upon every packet arrival, LAFD randomly drop the 2p

4 Non-Response Flow Detection Avg_rate > Target_Max Drop Pbt is Zero Drop Mode == Non-responsive Avg_rate < Target_Min Avg_rate == Previous Avg_rate && Number of drop > Calculate Calculate Calculate Calculate Calculate Responsive DR Non-Response Non-Response Responsive DR Responsive DR DR DR Fig 4 Non-responsive flow detection algorithm packet with probability of p, and count the number of transfered packets for an interval of time At the end of each interval of time, LAFD adjust the packet drop rate from CIR = Committed Information Rate avg rate = average arrival rate for a flow avg in = average in-profile bandwidth for a flow all avg out = average out-profile bandwidth of all flow For Each Packet Arrival: drop the packet with probability of p count the number of the drop for the flow At The End Of Time Interval T: calculate average rate avg in avg out if (avg min >avg out) or(avg max <avg out) call Non-Responsive Flow Detection Calculate Responsive: if (drop pbt == ) if((all avg out > ) and ( CIR <avg in + avg out )) set minimum drop probability for the flow else avg p =(( in +avg out avg in +all avg ) 2-1)p out if (p >p) p =p p =(( x C )2 ; 1)p where p is the amount of drop probability that should be adjusted, x is arrival rate of total traffic, and C is the link capacity One of the assumption made in this scheme is that all flows are TCP friendly (responsive to packet drop)so that the fairness between responsive flows and non-responsive flows can not be guaranteed We extended this scheme so that the proposed scheme provide the flow level fairness regardless of traffic characteristics The fair dropper keep track of the number of out-profile packets transfered during an interval of the time At the end of the interval, if the number of out-profile packets transfered for a flow is out of minimum and maximum range, then, the flow is re-classified into either responsive or non-responsive flow, and the drop rate that enforces the fair share of the bandwidth is recalculated by the type of the traffic Here, we used two constant values The one is monitor interval and the other is minimum and maximum range The monitor interval was quite robust when 5 to 2 sec was used However, if the large interval is used, the response time of the fair dropper can be deteriorated so that the bandwidth of a flow can be unnecessarily dropped to the committed information rate For minimum and maximum range, 7 to 13% of target bandwidth can be used with time sliding window meter [3], but the fair dropper worked well with to 1% and 9 to 11% when the token bucket used In the simulation, to 1% was used In figure 4 shown non-responsive flow detection algorithm, a flow is classified as a non-responsive flow if the flow maintain the same incoming rate while it lost the packets during last interval If a flow is misclassified as non-responsive, the flow will suffer unfairly large packets loss for the next interval To correct misbehavior of the detector, the non-responsive flow detector reclassify a flow as responsive if a flow share less than minimum target bandwidth Since the non-responsive flow never reduce the sending rate on packet loss, the drop probability of the non-responsive flow should be calculated in different ways from responsive flow mod f actor =(avg in + avg out)=avgout if ( mod f actor > 2)mod f actor =2 p=p+(p mod f actor) Calculate Non rresponsive: current diff = avg rate ; avg in target diff = CIR + all avg out ; avgin if ( avg in > CIR + all avg out ) p=1 else if ( avg rate > CIR + all avg out ) p=(current diff ; target diff)=current diff Fig 5 Fair Dropper algorithm Here, the calculation of drop probability for responsive flow followed that of LAFD, and the drop probability of non-responsive flow is proportional to the amount of excessive bandwidth shared during last interval The details of the drop probability calculation are included in Figure 5 However, not like LAFD which targeted congestion control, the drop probability of the fair dropper is applied to only outprofile packets so that we weighted the p with the ratio of all packet of th flow to the out-profile packets To prevent oversensitiveness, we limited the modification factor not to exceed the % of original value IV SIMULATION RESULTS We discuss the performance results and show how the Fair WRR and the Fair Dropper work to provide the inter and intra class fairness A Fair WRR Figure 6 shows how fair WRR protects BE traffic from AF out-profile packets In the simulation, the same topology and environment were used as in Section II except for dynamically changing workload 1 AF and BE flows started initially, and 5 AF flows were added after sec and last for sec All the AF flows have the same committed information rate of

5 (a) WRR of 9:1 (b) PQ of 9:1 TABLE II IMPACT OF DYNAMIC BUFFER ALLOCATION ON PACKET LOSS RATE WHEN CIR = 256K Sim 15 AF flows AF flows time WRR DSW DSW + WRR DSW DSW + only DBA only DBA (c) (DSW) (d) (DSW and DBA) Fig 6 Impact of scheduler in inter class fairness 64kbps We simulated with different values of the AF packet drop monitoring period for the fair WRR, and ms worked reasonably The AF out-profile traffic shared about 7% of the link bandwidth whereas the BE traffic suffered from high loss rate with the statically configured scheduler in Figure 6 (a) and (b) In contrast, the fair WRR efficiently protected the BE traffic against the AF out-profile traffic by adapting the service weight to the changing workload in Figure 6 (c) and (d) To see the effect of the DBA on the loss rate of AF traffic, the combinations of the following two case were simulated under-provisioned network vs over-provisioned network the two different committed information rate: 64kbps vs 256kbps and AF flows were used to simulate the slightly under and over provisioned networks with 64kbps of committed information rate for each flow, and 15 and flows were used with 256kbps case Table?? and?? shows that the dynamic buffer allocation provided the more protection on the AF inprofile traffic when the network is over-provisioned, and large committed information rate is used When the network is overprovisioned or large committed information rate is used, the inprofile ratio of entire the packets is higher than other cases so that by providing more buffer space at the congested node, the chance for arriving in-profile packet to be dropped is reduced TABLE I IMPACT OF DYNAMIC BUFFER ALLOCATION ON PACKET LOSS RATE WHEN CIR = 64K Sim AF flows AF flows time WRR DSW DSW + WRR DSW DSW + only DBA only DBA While the fair WRR improve the protection on the BE traffic, the end-to-end delay variation with the fair WRR is amplified because the fair WRR utilizes the maximum delay as long as the minimum loss rate can be maintained In the following simulation, 1 AF flows were started at the beginning and 5 more AF flows were added after sec Figure 7 showed that the average end-to-end delay during the first secs is greater than that of next secs without dynamic buffer allocation scheme The result showed that this variation of the delay is reduced with the dynamic buffer allocation Average Delay Averate Delay of AF 1/ Flows Without dynamic buffer size With dynamic buffer size Time Fig 7 Impact of dynamic buffer allocation on the end-to-end delay B Fair Dropper The simulation in this section shows the impact of the fair dropper on the intra class fairness To quantify the level of the fairness, we used the fairness index [16] and the standard deviation First, We used 1 TCP flows with different round trip times to show the effect of the fair dropper on the responsive flows, and all the flows have the same committed information rate of 64kbps In Table IV-B, when the fair dropper was not used, the actual bandwidth of each flows showed strong dependency on the round trip time By lessening the dependency, overall fairness improved in both fairness index and standard deviation with the fair dropper Next, We changed the traffics into 8 TCP and 2 CBR The bandwidth of a flow was depend not only on the round trip time but also the type of traffic so that CBR traffic took 2 times as much bandwidth as TCP flows took in Table IV-B Through out simulation, the fair dropper showed successful detection on non-responsive flows, and there were no mis-classification Now, we used two different committed information rate for AF traffic and with the large number of flows When the number of flows are increased, the responsive flows only can share the small fraction of out-profile so that fairness among the responsive flows is no longer problematic However, the non-responsive flows are still achieve the much higher bandwidth than the responsive flows In figure 8, the fair dropper

6 TABLE III IMPACT OF FAIR DROPPER ON 1 TCP FLOWS WITH CIR = 64KBPS 1 1 Flow RTT BW without BW with # (ms) FD (Kbps) FD (Kbps) Avg SD FI TABLE IV IMPACT OF FAIR DROPPER ON 1 FLOWS (8 TCP AND 2 CBR) WITH CIR = 64KBPS Flow Source RTT BW without BW with # Type (ms) FD (Kbps) FD (Kbps) 1 TCP TCP TCP TCP TCP TCP TCP TCP CBR CBR Avg SD FI achieved slightly higher average bandwidth by reducing the nonresponsive flows Bandwidth x TCP 64K CBR 64K TCP 256K CBR 256K CIR = 64K CIR = 256K Flow number (a) Without fair dropper Bandwidth x TCP 64K CBR 64K TCP 256K CBR 256K CIR = 64K CIR = 256K Flow number (b) With fair dropper Fig 8 Bandwidth share of 45 AF flows 3 5 (a) Fair WRR 3 5 (b) Fair WRR With Fair Dropper Fig 9 Bandwidth share of 45 AF flows REFERENCES [1] S Blake, D Black, M Carlson, E Davies, ZWang, and WWeiss, An Architecture for Differentiated Services, RFC2475, December 1998 [2] J Heinanen, F Baker, W Weiss, and J Wroclawski, Assured Forwarding PHB Group, RFC2597, June 1999 [3] David D Clark and Wenjia Fang, Explicit Allocation of Best-Effort Packet Delivery Service, IEEE/ACM Transactions on Networking, vol 6, no 4, pp , August 1998 [4] S Floyd and V Jacobson, Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, vol 1, no 4, pp , August 1993 [5] R Makkar, I Lambadaris, J H Salim, N Seddigh, B Nandy, and J Babiarz, Empirical study of buffer management schemes for DiffServ assured forwarding PHB, in Proceedings of ICCN, October, pp [6] N K Jaiswal, Priority Queues, Academic Press, 1968 [7] Manolis Katevenis, Stefanos Sidiropoulos, and Costas Courcoubetis, Weighted Round-Robin Cell Multiplexing in a General-Purpose ATM Switch Chip, IEEE Journal on Selected Areas in Communications, vol 9, no 8, pp , October 1991 [8] S Floyd and V Jacobson, Linksharing Resource Management Models for Packet Networks, IEEE/ACM Transactions on Networking, vol 3, no 4, pp , August 1995 [9], On-line document Network simulator (Ns), Available from [1] D Lin and R Morris, Dynamics of Random Early Detection, in Proceedings of the ACM SIGCOMM, September 1997, pp [11] W Feng, D D Kandlur, S Debanjan, and Kang Shin, Stochastic fair blue - a queue management algorithm for enforcing fairness, in Proceedings of IEEE INFOCOM, April 1, pp [12] R Mahajan and S Floyd, RED-PD: Controlling High Bandwidth Flows at the Congested Router, ICSI Technical Report TR-1-1, April 1 [13] R Pan, B Prabhakar, and K Psounis, CHOKe - A stateless active queue management scheme for approximating fair bandwidth allocation, in Proceedings of IEEE INFOCOM, March, pp [14] S Ha, S Han, and V Bharghavan, A Scalable Router Mechanism for Load Adaptive Fair Packet Dropping, in Proceedings of IEEE Global Telecommunications Conference, November, pp [15] J Padhye, V Firoiu, D Towsley, and J Kurose, Modeling TCP Throughput: A Simple Model and its Empirical Validation, in Proceedings of the ACM SIGCOMM, August 1998, pp [16] R Jain, The Art of Computer Systems Performance Analysis, John Wiley and Sons Inc Finally, We investigated the effect of the fair dropper on the inter class fairness The simulation result showed that the fair dropper did not improved the inter class fairness much However, The in-profile drop rates are reduced slightly by limiting the non-responsive flows V CONCLUDING REMARKS In the paper, We proposed two mechainsim to provide the fairness in DiffServ, One for the core router scheduling and the other for edge router dropper The simulation results showed that to achieve the inter and intra class fairness, the mechanism that enforce the fairness should be deployed at both core and edge of the network