Multicast Network Administration Control in Diff Services

Transcription

1 MASURMNT-BASD MULTICAST ADMISSION CONTROL IN DIFFSRV NTWORKS Olli Alanen, Mikko Pääkkönen, Timo Hämäläinen, Mikko Ketola and Jyrki Joutsensalo Department of Mathematical Information Technology University of Jyväskylä Jyväskylä, FINLAND Abstract Multicast admission control in Differentiated Services network is an important but lightly researched subject. We propose two distinct admission control methods. The methods reject new multicast join requests that would otherwise decrease the quality experienced by the existing receivers. dge nodes filter join requests and generate new requests. The proposed methods are developed as an extension to the DSMCast protocol but could also be adapted to other protocols. In this paper the methods are compared against each other and to the situation without any admission control. I. INTRODUCTION Different Quality of Service (QoS) architectures are nowadays widely used and researched. They provide better quality in terms of guaranteed bandwidth, delay, jitter and packet loss. Differentiated Services (DiffServ) [2] has been the main interest of QoS researchers because it is currently the best solution for unicast QoS. For some new applications like IPTV and video conferencing, multicasting is another way of providing better QoS by saving network bandwidth. However, there are three major problems of transporting multicast traffic in DiffServ networks. The problems are heterogeneous trees [3] [7], scalability [3], [7], [8] and neglected reserved sub-tree (NRS) [3] [7] and they should be solved to attain guaranteed quality level for multicast traffic. DSMCast [3] is an exceptional solution for these problems. It solves the problems of heterogeneous trees and scalability and gives a competent framework for solving the NRSproblem. This paper proposes admission control extensions to the DSMCast protocol. The methods are distributed solutions to the NRS-problem and they reject the joining attempts that would degrade the QoS of the existing receivers more than is allowed. The methods could be changed to inter-operate with any other protocol with only small modifications. The methods were simulated with a network simulator [9] and the results show the strengths of these methods. II. TH ADC MTHODS We propose methods to be used in multicast admission control decisions in DiffServ networks. They solve the NRS problem described earlier. ach of the methods are distributed to the egress nodes of the network, which makes the core nodes and the whole network scalable. The basic idea is to filter the join requests arrived to the edge nodes and send some extra leave messages when necessary. A measurement based method is presented in [1] and in this paper improvements are added to it. The methods are referred as Measure 1 and 2, respectively. Also, to go a bit further, a combination of these two methods is presented to conquer the weaknessess of each one described later in the paper. The methods purpose is to check if a specified flow can reach the requirements demanded. This means that client must define the traffic profile of the flow and the QoS parameters that it should fulfill. The parameters are defined in the extended join-message Join(S,G,QoS) where the QoS parameter includes the average bandwidth usage of the flow, DSCP and the maximum acceptable value for delay. The first and second parameters indicate the source of the data and the group address. The admission control methods can be divided in three phases and next subsections describe each one of these phases. A. dge Test In the first test, the egress edge checks from its group states if it is already forwarding the group. If it is, the join request is accepted because adding new receiver to that multicast group does not increase the utilization of the DiffServ domain at all as the data is already being received at that edge. On the other hand, if the edge is not yet forwarding the group, it moves to the next test before making any decisions. B. Measurement Test The measurement test functions in the same manner no matter using method 1 or 2, and it goes as follows. The egress edge first joins the group, receives the first m of the group s packets for calculating the current value for the end-to-end delay, packet loss and jitter with the equation of exponential average (quation 1).! " If the measured values are below the acceptable maximum ones, the measurement test is accepted. The test measures (1)

2 Multicast Multicast 5Mb/s 1-3Mb/s Video traffic profile Measured videocustomer FTPserver Bottleneck C C C Measured conferens customer Bandwidth [Bits/s] Multicast servers Multicast FTP Fig. 2. Video traffic profile Fig. 1. Simulation s network topology Conference traffic profile the actual multicast traffic therefore giving the most realistic results of the current network conditions. Of course, network conditions can change rapidly therefore leading to degracion of the QoS experienced by the users. C. Bandwidth Test The bandwidth test has a slight differencies between methods 1 and 2. However, the common part for both of the tests is described next. The available bandwidth is measured simultaneously with the measurement test. When the first packet of the group arrives to the egress edge, it checks the DSMCast header to find the branching node. Then the egress edge sends to the branching node a packet indicating how much bandwidth the requested flow will utilize. When the packet is returning, it is examined at each node if there is enough bandwidth available for the flow. The bandwidth test is passed if every node on the route had enough resources available. The bandwidth test is based on so called GRIP-test, which is described more in detail in [4]. The difference between the two tests is that in method 1 the overall available bandwidth of each link on the path is monitored. On the other hand, in method 2, the available bandwidth for a particular class at each link on the path is monitored. If the bandwidth test was also accepted, the requesting receiver is joined to the multicast group. III. SIMULATION STUDIS Simulations were done with the Network Simulator 2 [9] and a GenMCast extension [10]. The topology used is presented in Fig. 1. All the measured traffic flows through all the core routers in the simulation s topology. Only two and their QoS is measured in the simulations and other multicast and FTP clients just make background traffic and join requests. In this case we do not have to care about multicast tree or routing and it is enough to examine only the path from source to destination. Figures 2 and 3 show the example traffic profiles of video -and conference who are being measured. The traffic characteristics used in the simulations is presented in Table I. IPTV and video conference traffic were Bandwidth [Bits/s] Fig. 3. Conference traffic profile used as traffic sources and there were 10 groups for both of them. The video traffic was captured from real video streams compressed to H.263 format [11]. Ten FTP clients were used and their total load was limited by defining the link between FTP servers and the core router to small enough. The upper bounds for QoS metrics are also presented in Table I. These upper bounds were used in the delay test of the admission control method. Weighted Round Robin (WRR) scheduler was used in the output queues of each node. The weight of each queue was defined a bit smaller than the amount of expected traffic in the class. The purpose of the admission control is to handle these kinds of cases. The queue lengths were defined to 25, 50 and 200 packets for conference, IPTV and bacground FTP traffic, respectively. Joins and leaves to/from the groups were randomized by certain random distributions. The duration of the membership was simulated with exponential distribution because it seems to describe the duration of the connection in a most realistic way. After leaving the group, the waited another Pareto-distributed time-interval. 80 simulations with different FTP throughput were run and the results of the simulations with explanations are shown in the next subsections. A. Low Utilization The first results are from a simulation where links were lightly loaded and the queues were not full at any time. The bandwidth of the FTP s link in this simulation was 1.3 Mb/s. It can be seen from figure 4 that the method 1 does not have a lot of effect in this kind of lightly loaded situation - the situation is almost the same with or without it. Because none

3 TABL I SIMULATIONS TRAFFIC. # # # # Traffic Bandwidth Packet-size DSCP Delay Max. Jitter Max Loss Max Control messages Video conference 68kbit/s 800Bytes 6 250ms s IPTV 270kbit/s 950Bytes ms s FTP - 900Bytes Bottleneck link throughput [Mbit/s] e e+06 adc adc Bottleneck link throughput [Mbit/s] 5.2e e e e adc adc e+06 Fig. 4. Bottleneck link s throughput in the low utilization simulation Fig. 6. Bottleneck link s throughput in the high utilization simulation Flow Delay [s] (Video customer) adc adc Number of multicast adc NO Adc Fig. 5. Video delay in low utilization scenario Fig. 7. The number of multicast in high utilization simulation of the links is heavily utilized, the admission control procedure does not reject many requests and therefore the bandwidth of the bottleneck link is utilized almost as well as in the case of no admission control. This is depicted in figure 4. However, with method 2, it can be seen clearly that the bottleneck link is not that well utilized although the amount of background traffic is the same than in case of method 1. This is due the rejections of the joining attempts. As it is depicted in figure 5, the delays of video remain at lower level than in cases of method 1 or no method at all. This is because there are less multicast within the class, hence leading to smaller delays. As the available bandwidth in method 2 is tested within each class, the background traffic is not able to cause blocking to the multicast clients based on this test. However, when the number of clients within certain class is large enough, there will be no more space in that class for new connections and therefore it leads to rejections. Now when there is not that much background traffic utilizing the remaining bandwidth, it can be said that method 2, in lightly loaded situations waste bandwidth: there may not be available bandwidth within that certain class, hence causing rejections although on the link scale there still exists available bandwidth. Method 1 on the other hand works better in lightly loaded situations by utilizing the available bandwidth better. B. High Utilization The second results are from a simulation where utilization of the network was much higher. The bandwidth of the FTP s link in this simulation was 3.0 Mb/s. The throughput of the bottleneck link is presented in the figure 6. Throughput with the method 1 is a bit lower than without it or with method 2. The increased amount of background traffic causes the delay- and bandwidth tests to fail therefore decreasing the number of accepted multicast connections with method 1. With method 2 the number of accepted multicast is bigger, hence increasing the utilization of the bottleneck link to its maximum. The number of multicast members as a funcntion of time is depicted in figure 7. As it can be seen from the throughput figure, when not using admission control at all, the situation seems to be quite the same. However, this is not the truth.

4 Flow Delay [s] (Video customer) adc adc Bottleneck Link Throughput [Mbit/s] e e+06 Fig. 8. Video customer delay in the high utilization simulation Fig. 10. Bottleneck links utilization as a function of background traffic Loss [%] adc adc Flow Delay (Video) Fig. 9. Bottleneck link s loss in the high utilization simulation Fig. 11. Video delay as a function of background traffic Figure 8 shows the corresponding delays, clearly depicting method 1 to give the smallest delays. Unlike in lightly loaded network, the delays with method 2 are now greater than with method 1. Although the delays are longer with the method 2, they are still below the acceptable limits. Anyway, in case of no admission control is used, the delays have already increased significantly due the packets being queued. In fact, in figure 9 it can be seen that some packet loss is occurring. This all is related to the large amount of background traffic. Method 1 is to reject more requests than method 2 therefore decreasing the delays while with no admission control the suffer from excessive delays and some packet loss. As the figure 6 indicates, the best throughput is achieved by not using any admission control method at all. Anyway, this is done by the cost of excessive delay and packet loss, so it is not the best solution. However, method 1 keeps the delays low and prevents packet loss from occurring while the network is never well utilized. Method 2, on the other hand, can be seen as a compromise between these two: delays are pretty low and utilization is kept very high. From an operators point of view, maintaining the network well utilized would be the ideal case. C. Utilization effect For this subsection, a total of 21 simulations were run, every round increasing the amount of the background traffic. In the figure 10 it can be seen how the bottleneck links utilization increases as a function of the FTP-traffic, from 1. Mb/s all the way up to 3.00 Mb/s. For the method 1 the critical point seems to be at 1.6 Mbit/s. At this point the increased background traffic causes that the measured QoS values do not stay within the required limits therefore causing connection requests being rejected, based on both bandwidth - and delay test. However, because the admission control 1 maintains the number of multicast receivers low enough all the time, the delay remains low throughout the simulation. This can be seen in figure 11, which depicts the delay experienced by the measured video customer. As the Qos requirements (jitter and packet loss) of video are a bit stricter than the ones of conference, it can be noted from figures 12 and 13 that video are being rejected more in relation to conference when background load increases. When not using admission control at all, the network is well utilized all the time. Also the maximum delay experienced by the multicast receivers is reached at about 2.0 Mbit/s. This is the point where the background traffic has used all the bandwidth dedicated to it on the bottleneck link. Nevertheless, because no admission control is used, the number of video and conference remain the same throughout the whole simulation. On the other hand, when using method 2, the utilization level reaches the maximum possible at about 2.5 Mbit/s - from this point onward the available bandwidth is used as well with the case of no admission control. This can be explained as follows. At 2.5 Mbit/s the background traffic has used all the bandwidth of its own plus the bandwidth which was left over from the multicast receivers. Like mentioned earlier, method 2 tends to leave some amount of bandwidth decicated to that class unused. It can be noted from the figure 11 that at 2.2 Mbit/s the delays increase the most due the packets being queued until about 2.5 Mbit/s. After this point the

5 Nbr of Video members Achieved Throughput [Bit/s] e No Adc Threshold Fig. 12. The number of video members as a function of background traffic Fig. 14. Bottleneck links throughput as a function of utilization Nbr of Conference members Fig. 13. traffic The number of conference members as a function of background Throughput (bottleneck link 0-1) [bit/s] 4.9e e e e e+06 No ADC Threshold [utilization %] Fig. 15. Average bottleneck links throughput as a function of background traffic with threshold 94% delays settle down to a certain value. This refers that multicast receivers have reached their maximum queuing delay because the amount of background traffic is at its maximum. Ss the background load increases, the amount of video -and conference decreases, but not that steeply than in case of method 1. This means that when the background load is big enough, there will be more multicast accepted with method 2 than with method 1. Again, from the operators point of view, this favors the usage of method 2 as it utilizes the network better while keeping the delays at pretty good level. In addition, in this high loaded situation it also possibilitates more accepted multicast, which normally are the more valuable ones. This leads us to a situation, where both of the methods, one and two, are good at some point. The method 1 was better in lightly loaded situations where it offered better network utilization and lower delays for the multicast. However, as the background load increased, method 2 became better at some point by offering service for more multicast clients within pretty good delay bounds and first of all, better network utilization. That s why in the following subsection we define a certain utilization threshold level which is used as a trigger to change between these two methods on the fly. D. Utilization level triggered ADC In this subsection we examine the effect of changing the admission control method on the fly. It means that when the bottleneck links utilization level reaches a certain predefined value, we change the admission control method. As it came up in the low utilization scenario, method 1 uses the network resources more efficiently. On the contrary, method 2 becomes better when the utilization is high. That s why here we use method 1 when working below the defined threshold value, and method 2 when utilization is above it. First we drove a simulation as a function of threshold level to find where the throughput reaches the best value. Figure 14 shows the result of this simulation. From the figure it can be noted that throughput reaches bigger values with changing ADC in comparison when only using either one of the methods. This bigger throughput is achieved when the threshold level is between The figure shows clearly that the best throughput values occur more or less when threshold level is set to 94. Now we can examine more in detail the effect of changing the admission control at this very threshold level. Following figures 15, 16 and 17 show us the results. Figure 15 captures the benefits of changing the method. The bandwidth of the bottleneck link is utilized well with all kinds of background traffic volume. Figure 16 also shows that the delays can be controlled with this kind of admission control. Figure 17 illustrates the effectiveness of the method by average member counts. It can be seen that the combination of the methods gives good results by accepting almost as much members as with the measurement 2 method. IV. CONCLUSIONS The benefits of an admission control are clearly shown in this paper. The results also depict the fact, that some admission control is necessary. Our two distinct measurement-based methods provide better and guaranteed quality of service in

6 Delay ADC1 (Video) [s] No ADC Threshold [utilization %] Fig. 16. Delay experienced by the video customer as a function of background traffic with threshold 94% Members total No ADC Threshold [utilization %] Fig. 17. Number of members as a function of background traffic with threshold 94% different kind of scenarios. By combining these two methods, even better utilization of the bottleneck link was achieved and the QoS-guarantees were still fulfilled. The further studies on the admission control of the multicast receivers will be continued on the area of parameter-based methods. Revenue of the network operator will also be considered as one parameter for making the admission control decisions. RFRNCS [1] O. Alanen, M. Pääkkönen, T. Hämäläinen, M. Ketola, J. Joutsensalo Multicast Admission Control in DiffServ Networks, published in ICON 2004, [2] S. Blake, D. Black, M. Carlson,. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services ITF RFC 2475, [3] A. Striegel, G. Manimaran, Dynamic DSCPs for Heterogeneous QoS in DiffServ Multicasting, Proc. of I GLOBCOM, [4] G. Bianchi, N. Blefari-Melazzi, G. Bonafede and. Tintinelli, QUASI- MODO: QUAlity of ServIce-aware Multicasting Over DiffServ and Overlay networks, I Network, [5] B. Yang, P. Mohapatra, Multicasting in Differentiated Service domains, Proc. of I GLOBCOM, [6] R. Bless, K. Wehrle, IP Multicast in Differentiated Services Networks, ITF (In Progress) Draft, [7] A.Striegel, A. Bouabdallah, H. Bettahar, G. Manimaran, BM: A New Approach for Scalable DiffServ Multicasting, Proc. of Fifth International Workshop on Network Group Communications (NGC), [8] Z. Li and P. Mohapatra, QoS-Aware Multicasting in DiffServ Domains, Proc. of Global Internet Symposium, [9] Network Simulator, Available at: $ URL: [10] A. Striegel, GenMCast Software xtension for ns-2, ND CS Technical Report, Available at: $ URL: striegel/genmcast/%, [11] F. Fitzek and M. Reisslein, MPG-4 and H.263 Video Traces for Network Performance valuation, I Network, vol 15, no 6, pages 40-54, November/December [12] S. Lima, P. Carvalho, A. Santos, V. Freitas, A Distributed Admission Control Model for Class-based Networks Using dge-to-dge QoS and SLS Monitoring, Proc of I ICCS, [13] G. Bianchi, N. Blefari-Melazzi, Admission Control over Assured Forwarding PHBs: A Way to Provide Service Accuracy in a DiffServ Framework, I GLOBCOM, 2001.