MEASUREMENT-BASED MULTICAST
ADMISSION CONTROL IN DIFFSERV
NETWORKS
Olli Alanen, Mikko P¨a¨akk¨onen, Timo H¨am¨al¨ainen, Mikko Ketola and Jyrki Joutsensalo
Department of Mathematical Information Technology University of Jyv¨askyl¨a
40014 Jyv¨askyl¨a, FINLAND
opalanen,mikpaak,timoh,mikket,jyrkij @cc.jyu.fi
Abstract— Multicast admission control in Differentiated Ser-vices 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. Edge 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 nowa-days 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 NRS-problem. 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. THEADC METHODS
We propose methods to be used in multicast admission control decisions in DiffServ networks. They solve the NRS problem described earlier. Each 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. Edge 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 (Equation 1).
! "
(1) If the measured values are below the acceptable maximum ones, the measurement test is accepted. The test measures
Multicast servers E E E E E C C C Measured video-customer Measured conferens customer FTP-server FTP customers 5Mb/s 1-3Mb/s Bottle-neck Multicast customers Multicast customers Multicast customers
Fig. 1. Simulation’s network topology
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 meth-ods 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. SIMULATIONSTUDIES
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 customers 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 customers who are being measured.
The traffic characteristics used in the simulations is pre-sented in Table I. IPTV and video conference traffic were
263000 264000 265000 266000 267000 268000 269000 270000 271000 272000 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Bandwidth [Bits/s] Time [s]
Video traffic profile
Fig. 2. Video traffic profile
64000 64500 65000 65500 66000 66500 67000 67500 68000 68500 69000 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Bandwidth [Bits/s] Time [s]
Conference traffic profile
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 customers 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
TABLE I SIMULATIONS TRAFFIC.
Traffic Bandwidth Packet-size DSCP Delay Max. Jitter Max Loss Max
Control messages - - 5 - -
-Video conference # 68kbit/s # 800Bytes 6 250ms 0.001 0.05s
IPTV # 270kbit/s # 950Bytes 10 400ms 0.00001 0.017s
FTP - 900Bytes 99 - - -1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06 0 500 1000 1500 2000
Bottleneck link throughput [Mbit/s]
Time [s]
Measurement 1 adc Measurement 2 adc No adc
Fig. 4. Bottleneck link’s throughput in the low utilization simulation
0.035 0.04 0.045 0.05 0.055 0.06 0.065 0 500 1000 1500 2000
Flow Delay [s] (Video customer)
Time [s]
Measurement 1 adc Measurement 2 adc No adc
Fig. 5. Video delay in low utilization scenario
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 customers remain at lower level than in cases of method 1 or no method at all. This is because there are less multicast customers 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 utiliz-ing the remainutiliz-ing bandwidth, it can be said that method 2, in lightly loaded situations waste bandwidth: there may not be
3.2e+06 3.4e+06 3.6e+06 3.8e+06 4e+06 4.2e+06 4.4e+06 4.6e+06 4.8e+06 5e+06 5.2e+06 0 500 1000 1500 2000
Bottleneck link throughput [Mbit/s]
Time [s]
Measurement 1 adc Measurement 2 adc No adc
Fig. 6. Bottleneck link’s throughput in the high utilization simulation
0 10 20 30 40 50 60 70 80 0 500 1000 1500 2000
Number of multicast customers
Time [s]
Measurement 1 Measurement 2 adc NO Adc
Fig. 7. The number of multicast customers in high utilization simulation
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 customers 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.
0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0 500 1000 1500 2000
Flow Delay [s] (Video customer)
Time [s]
Measurement 1 adc Measurement 2 adc No adc
Fig. 8. Video customer delay in the high utilization simulation
0 0.01 0.02 0.03 0.04 0.05 0.06 0 500 1000 1500 2000 Loss [%] Time [s] Measurement 1 adc Measurement 2 adc No adc
Fig. 9. Bottleneck link’s loss in the high utilization simulation
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 customers 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.30 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
3.8e+06 4e+06 4.2e+06 4.4e+06 4.6e+06 4.8e+06 5e+06 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3
Bottleneck Link Throughput [Mbit/s]
FTP’s Throughput [Mbit/s]
Measurement 1 Measurement 2 No adc
Fig. 10. Bottleneck links’ utilization as a function of background traffic
0.05 0.06 0.07 0.08 0.09 0.1 0.11 0.12 0.13 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3
Flow Delay (Video)
FTP’s Throughput [Mbit/s]
Measurement 1 Measurement 2 No adc
Fig. 11. Video delay as a function of background traffic
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 customers are a bit stricter than the ones of conference customers, it can be noted from figures 12 and 13 that video customers are being rejected more in relation to conference customers 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 customers 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
14 16 18 20 22 24 26 28 30 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 Nbr of Video members FTP’s Throughput [Mbit/s] Measurement 1 Measurement 2 No adc
Fig. 12. The number of video members as a function of background traffic
14 16 18 20 22 24 26 28 30 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 Nbr of Conference members FTP’s Throughput [Mbit/s] Measurement 1 Measurement 2 No adc
Fig. 13. The number of conference members as a function of background traffic
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 customers 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 customers 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 customers, 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 utiliza-tion and lower delays for the multicast customers. 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
4.55e+06 4.6e+06 4.65e+06 4.7e+06 4.75e+06 4.8e+06 4.85e+06 90 91 92 93 94 95 96
Achieved Throughput [Bit/s]
Threshold
Changing ADC Measurement 1 Measurement 2 No Adc
Fig. 14. Bottleneck links’ throughput as a function of utilization
4e+06 4.1e+06 4.2e+06 4.3e+06 4.4e+06 4.5e+06 4.6e+06 4.7e+06 4.8e+06 4.9e+06 5e+06 1.6 1.8 2 2.2 2.4 2.6 2.8 3
Throughput (bottleneck link 0-1) [bit/s]
Threshold [utilization %]
Changing ADC Measurement 1 Measurement 2 No ADC
Fig. 15. Average bottleneck links’ throughput as a function of background traffic with threshold 94%
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 90-100. 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
0.05 0.06 0.07 0.08 0.09 0.1 0.11 0.12 0.13 1.6 1.8 2 2.2 2.4 2.6 2.8 3
Delay ADC1 (Video) [s]
Threshold [utilization %]
Changing ADC Measurement 1 Measurement 2 No ADC
Fig. 16. Delay experienced by the video customer as a function of background traffic with threshold 94%
30 35 40 45 50 55 60 1.6 1.8 2 2.2 2.4 2.6 2.8 3 Members total Threshold [utilization %] Changing ADC Measurement 1 Measurement 2 No ADC
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.
REFERENCES
[1] O. Alanen, M. P¨a¨akk¨onen, T. H¨am¨al¨ainen, M. Ketola, J. Joutsensalo “Multicast Admission Control in DiffServ Networks”, published in ICON 2004, 16.-19.11.2004.
[2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Services” IETF RFC 2475, 1998. [3] A. Striegel, G. Manimaran, “Dynamic DSCPs for Heterogeneous QoS
in DiffServ Multicasting”, Proc. of IEEE GLOBECOM, 2002. [4] G. Bianchi, N. Blefari-Melazzi, G. Bonafede and E. Tintinelli,
“QUASI-MODO: QUAlity of ServIce-aware Multicasting Over DiffServ and Overlay networks,” IEEE Network, 2003.
[5] B. Yang, P. Mohapatra, “Multicasting in Differentiated Service do-mains”, Proc. of IEEE GLOBECOM, 2002.
[6] R. Bless, K. Wehrle, “IP Multicast in Differentiated Services Networks”, IETF (In Progress) Draft, 2003.
[7] A.Striegel, A. Bouabdallah, H. Bettahar, G. Manimaran, “EBM: A New Approach for Scalable DiffServ Multicasting”, Proc. of Fifth International Workshop on Network Group Communications (NGC), 2003.
[8] Z. Li and P. Mohapatra, “QoS-Aware Multicasting in DiffServ Do-mains”, Proc. of Global Internet Symposium, 2002.
[9] Network Simulator, Available at:$ URL:http://www.isi.edu/nsnam/ns% , 8.4.2004.
[10] A. Striegel, “GenMCast Software Extension for ns-2, ND CSE Technical Report”, Available at: $ URL:http://www.cse.nd.edu/ striegel/GenMCast/% , 8.4.2004. [11] F. Fitzek and M. Reisslein, “MPEG-4 and H.263 Video Traces for
Network Performance Evaluation”, IEEE Network, vol 15, no 6, pages 40-54, November/December 2001.
[12] S. Lima, P. Carvalho, A. Santos, V. Freitas, “A Distributed Admission Control Model for Class-based Networks Using Edge-to-Edge QoS and SLS Monitoring”, Proc of IEEE ICCS, 2002.
[13] G. Bianchi, N. Blefari-Melazzi, “Admission Control over Assured For-warding PHBs: A Way to Provide Service Accuracy in a DiffServ Framework,” IEEE GLOBECOM, 2001.
