DiffServ Architecture: Impact of scheduling on QoS

Transcription

1 DiffServ Architecture: Impact of scheduling on QoS Abstract: Scheduling is one of the most important components in providing a differentiated service at the routers. Due to the varying traffic characteristics of different applications such as Voice, Video and Data traffic, it is not possible to mix them in one queue. Voice and Video application have stringent delay and loss requirements and require differential treatment from the data traffic which runs over TCP. In order to provide any differentiation of traffic, we must provide three separate queues for each of these traffic classes. Therefore, the simplest scheduling mechanism, i.e. FCFS, cannot be employed in a DiffServ architecture. Priority Queuing can provide a good QoS to the higher priority classes and thus can be used to service the Expedited Forwarding (EF) class. However, lower priority traffic classes can be starved if the higher priority queues have a steady traffic inflow. Weighted Fair Queuing (WFQ) can avoid the problem of starvation but it is difficult to select appropriate weights for the different traffic classes. Even a very high weight to the EF class fails to provide the QoS support, which can match the support provided by PQ. Therefore, a combination of PQ and WFQ should be used to provide differential treatment to the different traffic classes. Introduction: With the rapid growth of the Internet, customers are demanding multimedia applications such as telephony and video on demand, to be available on the Internet. The greatest challenge facing the providers of these services is the provisioning of Quality of Service (QoS). The best effort service provided by the IP layer does not provide any QoS guarantees. The elaborate reliability features provided by TCP at the expense of a greater end to end delay are inappropriate for multimedia communication. The key requirements of multimedia traffic are low end to end delay and bounded jitter. There have been various architectures, proposed during the 1990 s, which have promised to meet these requirements. Integrated Services(IntServ) architecture proposed during the mid 90 s advocates the reservation of resources in advance [RFC 1633]. Each flow is supposed to reserve the needed resources before the actual transmission of information. All the routers are required to be IntServ compliant by having information about each and every flow and make separate decision for each of them. Differentiating each and every flow according to its needed resources ensures strict QoS guarantees. However, the reason IntServ has not been accepted in the Internet is its scalability problem. Typically more than 250,000 flows pass through Internet core routers and storing information about each of them is simply impractical. It was felt that it would be efficient to transfer the processing requirement from the core of the network to the edges. Differentiated Services (DiffServ) architecture proposes the differentiation of traffic on the basis of its class [RFC 2474]. Each class is composed of an aggregation of similar flows. Therefore, whereas there may be more than 250,000 flows passing through the Internet routers, they would be differentiated into 5-10 classes. This architecture is scalable but has several problems before it can be actually implemented. Service can be easily stolen in this architecture by marking packets to be of

2 a high priority class. It also fails to meet the varying delay constraints imposed by various multimedia applications under heavy network load since there can be jitter within a traffic of certain class. However, this architecture provides a basis which could be used to provide QoS guarantees to specific applications. DiffServ Architecture: In this architecture, traffic is aggregated into classes at the edge routers and each class receives certain per hop behavior (PHB) at the core routers. The three main classes proposed in this architecture are the Expedited Forwarding (EF) class, Assured Forwarding (AF) class and the Best Effort class. The EF class is assured a minimum departure rate which is equal to at least its arrival rate. This class is suitable for applications which require very low jitter and no packet loss, such as voice. On the other hand, AF class is not guaranteed any strict bandwidth allocation but it is assured a priority in packet dropping over the Best Effort class. The Best Effort class is not provided any guarantee. The PHB of the core routers depends on the class to which the traffic belongs. The key to achieving a certain PHB is the use of appropriate scheduling mechanisms combined with buffer management schemes. This ensures that the router is able to give differential treatment to the traffic in terms of bandwidth allocation and packet dropping. Therefore, these PHB at all routers can translate into end to end QoS guarantees. However, the extent of these guarantees is still being actively researched since it is very important for the future growth of Internet. This project is aimed at studying the various scheduling schemes available for DiffServ architecture. The two QoS parameters which are analyzed are jitter and packet loss. With the sophisticated compression schemes employed nowadays, packet loss can have significant impact on the QoS. It is due to the fact that with the help of compression, one packet contains a lot of information, the loss of which results in losing significant amount of information. Moreover, sometimes subsequent packets/frames are encoded with respect to previous packets/frames and therefore one packet drop can have impact on the subsequent packets as well. Jitter, which is the variation in the end to end delay, is another very important QoS parameter. Jitter is mainly produced due to the variable queuing delay encountered at the routers. With a fixed end to end delay, multimedia applications such as video streaming can employ a buffer and with the help of some initial buffering can start non-stop play out. However, if jitter is present and is unbounded we can not design a suitable buffering mechanism which could ensure that we are able to play non-stop videos. Therefore, a bounded jitter is essential in the provisioning of QoS. Simulation: The network simulator, OPNET IT-GURU [3] has been used for simulation purposes. It has a QoS module which allows three different scheduling schemes, 1)First Come First Serve (FCFS), 2)Priority Queuing (PQ) and 3) Weighted Fair Queuing (WFQ).

3 Network Model: The network model consists of two routers having three kinds of traffic sources, FTP traffic, VoIP traffic and Video Conferencing traffic. The link connecting the two routers is the bottleneck in the communication. The capacity of this link is 1.54 Mbps whereas all the other links have a capacity of 10Mbps. The Video Source and VoIP source are acting as background source traffics for VoIP and Video Conferencing. Their respective sinks are present and their statistics are not monitored. They have been included to ensure that in the presence of separate queues for each traffic type, the original traffic gets mixed with the traffic of similar type. This would ensure that the queuing delay for each packet at each hop is variable. The various parameters for each application are as follows: FTP Command Inter Request File Size Type of Service Mix(Get/Total) Time(sec) 50% Exponential(10) Constant(50000) Best Effort(0) Video Conferencing Frame Inter arrival Frame Size Type of Service Time 15 frames/sec 128X120 pixels Streaming Multimedia(4) VoIP Silence Length Talk Spurt Encode Type of Service Length Scheme Exponential (0.85) Exponential(0.325) GSM silence Interactive Voice(6)

4 In this simulation, it is assumed that the routers implement output queues. All the packets destined for the same output are queued at the relevant output ports. In case of FCFS, only one queue is kept for each output port while in PQ and WFQ, three separate queues are kept at each output port for the three traffic classes; Voice, Video and Data. The differentiation is provided on the assumption that each source can appropriately classify its traffic and would not try to mark the lower priority packets as higher priority packets. Scheduling Schemes: There are various scheduling schemes, each having its own advantages and disadvantages. In this report, simulations study of the various scheduling schemes has been conducted. The results are as follows: FCFS: It is the simplest scheduling scheme to implement. All the packets leave in the same order in which they arrive. It is quite obvious that we can not provide any differential treatment to any of the packets. There is no guarantee on the number of packets dropped for each traffic flow and the delay encountered by packets at each hop. It is also unfair in the sense that flows sending the traffic at higher rates get most of the buffer and bandwidth share. On the other hand, flows of lesser bit rates are adversely affected. They get lesser buffer and bandwidth share and a greater packet loss. Therefore, well behaved sources working over TCP would be greatly affected because of congestion control mechanisms employed by TCP. All the above assertions are verified by the simulations. The graphs below show that the loss is the greatest for FTP which is the most conservative flow. Similarly, it is the least for VoIP which has an almost Constant Bit Rate traffic which is higher than the other sources. FTP Video Conferencing VoIP Packet Loss: The difference between the Average Traffic Sent and the Average Traffic Received Another important issue in FCFS is the buffer size. We can reduce packet loss by increasing the buffer size. However, increasing the buffer size would result in a greater variation in the end to end delay since the packets originally being dropped are being stored at the end of the buffer, thus incurring a larger end to end delay.

5 IP traffic dropped as a function of Max Queue Size Voice Traffic Received as a function of Max Queue Size Voice Packet delay variation 1) Voice Traffic Received as a function of Jitter Graph 1 summarizes the above issue by showing the trade off between the traffic received and the jitter. A lower jitter would mean a lower traffic received which is equivalent to a higher packet loss. Number of Queues: Once it is shown that we cannot mix all the three traffic classes in one queue, the next issue is to determine the appropriate number of queues to service these classes. This issue has been addressed in [1], in which the mixing of various traffic classes has been considered. Voice and Data traffic cannot be mixed without incurring a large loss in throughput. The utilization of the link has to less than 20% so as to ensure that the stringent requirements of Voice traffic are met in the presence of the bursty nature of the Data traffic. Similar reasoning has been presented for not mixing Data and Video traffics. Although, Video traffic has less stringent requirements compared to Voice traffic, packet loss after a certain limit can severely degrade the QoS for Video applications. Therefore, these two traffic classes should not be mixed in a single queue. Lastly, the mixing of Voice and Video traffic has been considered. For this analysis, the Video traffic has been differentiated into constant bit rate traffic (CBR) and variable bit rate (VBR) traffic. In CBR video encoding, the encoding parameters are adjusted according to the content of the scene to output a constant bit rate stream. CBR Video traffic is therefore, similar to Voice traffic but has a higher bit rate. Therefore, if the

6 aggregate load of CBR Video and Voice traffic can be handled, they can be mixed together in one queue. However, in case of VBR Video traffic, which is bursty, the two traffic classes cannot be mixed. Practically, it would be unreasonable to assume that all the Video flows would be CBR. Therefore, it is essential to have three separate queues for each of the three traffic classes. In the ensuing simulation analysis, three separate queues have been used for Data, Voice and Video traffic. PQ: The simulation for FCFS shows that it is unfair and can not provide differential treatment to the higher priority traffic. PQ can be implemented by having a separate buffer for each of the traffic. The queue having a higher priority is given preference in the scheduling decision. We only move to the lower priority queues if the higher priority queues are empty. The advantage of PQ is that QoS guarantees can be provided for the higher priority queues. However, the QoS given to the lower priority queues is very much dependent on the traffic characteristics of the higher priority queues. If there is a steady inflow of traffic in the higher priority queues, lower priority queues can be starved. For the simulation purpose, the Type of Service(ToS) field in the IP header is used to assign priority to a traffic source. As mentioned above, the highest priority is given to Voice traffic which requires strict QoS guarantees. The next priority is given to Video Conferencing traffic while the FTP traffic belongs to the Best Effort class. Video Conferencing VoIP FTP The above graphs compare the Traffic Received for the three traffic types in the two scenarios. The blue curves show the traffic received in case of PQ and the red one is for FCFS. The highest priority traffic i.e. VoIP, has an improvement in the received traffic. In fact by assigning it the highest priority we have eliminated its packets losses. The results for the second priority traffic class, Video Conferencing, show that the packet losses for this traffic class, has increased with the use of PQ. This is due to the fact that it only got an opportunity when the queue for VoIP traffic was empty. Since, there are packet losses in the second priority class, it is natural that the best effort class would not have got any service. This is shown by the traffic received for FTP traffic. It has been completely starved and no traffic was received.

7 Implementing PQ greatly reduces jitter for higher priority queues. It is due to the fact that a packet only has to wait behind the packets of the same traffic type. In FCFS, since there is only one queue, a packet has to wait behind a greater number of packets belonging to different traffic types. This greatly increases the variability in the delay incurred at each hop. The graphs below compare the jitter for Voice and Video Conferencing Traffic in the two scenarios. VoIP jitter : FCFS PQ Video Conferencing jitter: FCFS PQ The worst case jitter for VoIP in case of FCFS was approximately 2.0 seconds while in PQ it is almost seconds. Similarly, the worst case jitter for Video Conferencing in case of FCFS is 1 second while in PQ it is seconds (Note:There is a difference in the scale for FCFS and PQ graphs) In the above scenario, the two higher priority queues, Voice and Video had a high traffic inflow and therefore the FTP traffic was completely starved. Giving FTP traffic the highest priority and Voice traffic, the lowest priority, gave interesting results. The FTP traffic received was significantly increased while there was on change in the Video traffic received. The Voice traffic, which was given the lowest priority, was completely starved out. A look at the graph for the total IP traffic dropped reveals that the traffic dropped is greater if the highest priority traffic is FTP rather than Voice. It is due to the fact that

8 Voice traffic, which runs over UDP, is unable to adjust to the packet loss. FTP traffic, which runs over TCP, adjusts to the packet loss by slowing its rate. Therefore, if the objective is to minimize the total traffic dropped, than the lower priority classes should be such that they are able to adjust to the packet loss. PQ: Original Priorities PQ1: New Priorities FTP Traffic Received Video Traffic Received Voice Traffic Received IP traffic dropped Weighted Fair Queuing: The problems of fairness and starvation can be avoided by employing a fair scheduling mechanism, Weighted Fair Queuing (WFQ). Fair Queuing is based on the idea of Generalized Processor Sharing (GPS). The idea is to logically simulate bit by bit round robin scheduling by scheduling packets in a similar manner. In WFQ, weights are associated with each queue such that the number of consecutive time

9 slots given to a queue depends on the weight associated with each queue. This scheme ensures that the lower priority queues are not starved and are given the bandwidth share, which is equal to their relative weight. Two simulations were conducted for WFQ with different weights assigned to each of the three queues. The weights along with the simulation results are as follows: WFQ: Queue FTP Video Voice Weight Comparison of FTP Traffic Received in the three schemes Comparison of Video Traffic Received in the three schemes Comparison of Voice Traffic Received in the three schemes Comparison of IP traffic dropped in the three schemes The above graphs show a significant increase in the traffic received for FTP traffic, since it is not being starved and is given a separate queue. Video traffic received is higher in

10 WFQ compared to PQ because the higher priority queue (Voice), is only given a higher share and is not serviced all the time. However, the Voice traffic received is lower in WFQ compared to PQ in which it had the highest priority. The jitter in WFQ was almost identical to that in PQ and therefore the graphs have not been shown. As discussed earlier, Voice traffic has the most stringent QoS requirements. The above WFQ simulation showed an improvement in the overall fairness and the traffic being received. However, the traffic received for Voice traffic decreased, which can lead to severe degradation in the quality of Voice. Therefore another simulation was conducted with higher weight for the Voice traffic class. WFQ1: Queue FTP Video Voice Weight The above graph show the comparison of Voice traffic received in the two scenarios of WFQ. It shows that a very high weight has resulted in only a slight increase in the received traffic. Moreover, it is still less than the traffic received with PQ. Combination of WFQ and PQ: As shown above it is difficult to select appropriate weights for each traffic class. Moreover, the strict guarantees, which are needed by the EF class and provided by PQ, are not met with WFQ. Therefore, [2] have proposed an adaptive priority mechanism, which results in a scheduling mechanism, which is similar to WFQ with optimum weights. It maintains the priorities within a certain range such that the minimum guarantees are also provided while the lower priority queues are also not starved. However, this scheme requires monitoring of traffic flows and doing computations, which are not easy to implement. In [1] a similar technique has been used which advocates the use of a combination of PQ and WFQ scheduling mechanisms. Their idea is based on the observation that Voice traffic, which usually requires limited

11 bandwidth, would not starve the lower priority traffics. However, since Video traffic requires large bandwidth it would starve the lower priority traffic. Therefore, PQ should be used to schedule Voice traffic while WFQ should be used for Video and Data traffic. It would ensure that appropriate differentiation is being done and starvation is also avoided. The above scheme was simulated in this report. Since, OPNET IT GURU do not provide support for two different scheduling mechanisms to be used in one router, an additional router (Router2) was used. This router received the Video and FTP traffic and employed the WFQ scheduling scheme. It was connected to the original router (Router1), which also received the Voice traffic and employed a PQ scheduling mechanism. In this router, the highest priority was given to the Voice traffic while equal priorities were given to FTP and Video traffics. This ensured that while PQ is applied to the Voice traffic, WFQ is applied to Video and FTP traffic. Therefore, the possibility of Video traffic starving FTP traffic is eliminated. New network model The Video traffic was assigned the weight of 2 while the FTP traffic was assigned a weight of 1. The new scenario was named Combination and a comparison with the original scenarios showed an improvement in the traffic received for Voice which is comparable to that of PQ. At the same time, lower priority queues are not being starved and the overall IP traffic dropped is also reasonable.

12 FTP traffic received in all the schemes Video traffic received in all the schemes Voice traffic received in all the schemes IP traffic dropped in all the schemes Conclusions: The above simulations show the need as well as the ways to provide differentiation of traffic. The use of a combination of WFQ and PQ gives the best results. It not only ensures that we are able to service EF class traffic, which needs absolute priority, but it also avoids the problem of starvation. However, it was assumed that Voice traffic would not starve the lower priority queues. Moreover, despite the importance of the scheduling technique there are other important factors which also contribute in providing a certain PHB at a router. There is a need to combine the scheduling schemes with appropriate buffer management schemes such as RED. Also, there are many

13 obstacles which need to be cleared before the actual deployment of DiffServ architecture. Although, the above simulations provide a fair comparison of the various scheduling algorithms and their impact on the QoS, there are other factors, which would also contribute in providing a framework that could provide QoS support for multimedia traffic over the Internet. References: [1] F. Tobagi, W. Noureddine, B. Chen, A. Markopoulou, C. Fraleigh, M. Karam, JM Pulido, J. Kimura, "Service Differentiation in the Internet to Support Multimedia Traffic", in Springer Verlag LNCS, Vol. 2170, September [2] N.Natchimuthu, J.Khan, Adaptive Traffic Management Algorithm for IP-Based DiffServ WAN, ATNAC [3] OPNET Technologies, Inc.