Performance of Multicast Traffic Coordinator Framework for Bandwidth Management of Real-Time Multimedia over Intranets

Transcription

1 Performance of Coordinator Framework for Bandwidth Management of Real-Time Multimedia over Intranets Chin Hooi Tang, and Tat Chee Wan, Member, IEEE ComSoc. Abstract Quality of Service (QoS) schemes such as Reservation Setup Protocol (RSVP) and Differentiated Services (DiffServ) have been proposed to address the needs of real-time multicast applications such as Voice over IP and video conferencing. However, both RSVP and DiffServ have limitations in shared broadcast media Intranets such as Ethernet Local Area Networks, as unicast (non-real time) applications typically do not require nor support QoS, while real-time multicast applications can potentially overwhelm the available bandwidths of such Intranets. This paper examines the performance of a proposed bandwidth management based solution, the Coordinator Framework (MTCF), to address the problem. Index terms Bandwidth Management, Quality of Service (QoS), real time multimedia, multicasting, traffic shaping. I. INTRODUCTION Different Quality of Service (QoS) approaches have been developed to improve network performance by controlling data transmission for various types of services. This is necessary to fulfill the high network performance requirement of real-time multimedia or mission critical applications. IETF has proposed Resource Reservation Protocol (RSVP) [] to provide end-to-end resource reservation for applications. RSVP works with the Integrated Services architecture. Nonetheless, there are numerous problems like scaling, security and policy control that makes it not widely deployed within the network []. Consequently, Differentiated Service (DiffServ), which utilizes the TOS octet of IPv or Class Service octet of IPv [], became another means to implement end-to-end QoS on a network []. Nonetheless, DiffServ has limitations when applied to common non-deterministic shared Intranet technologies having multiple multicast sources and sinks. Notably, DiffServ only regulates traffic flow through a given link (termed Per Hop Behavior); it does not address the generation of traffic into a shared Intranet from multiple multicast sources within that network. This paper examines the performance of our proposed approach, the Coordinator Framework (MTCF) [], to enable real-time multicast transmission via Ethernet-type Intranets. II. MULTICAST TRAFFIC COORDINATOR FRAMEWORK MTCF [] comprises two major components a Traffic Manager (TM) and a Multicast Multimedia Firewall (). The TM conditions host-generated multicast traffic to optimize throughput and performance within the MTCF network, whereas the enforces preset bandwidth management policies, where a percentage of the network bandwidth is allocated for unicast traffic and the loading of multicast traffic can be adjusted dynamically to not exceed the Upper Subnet Bandwidth Threshold (USBT). Multicast traffic is forwarded without restriction if loading is below the Lower Subnet Bandwidth Threshold (LSBT). The operates in parallel with unicast routing to interconnect two or more subnets within an Intranet []. Both functions of the and unicast routing can be incorporated into a router equipped with MTCF capability (MTCF Router), as implemented for the experiments outlined in this paper. In an MTCF-compliant network (Figure ), a TM is installed in each host node. The Shaper within TM shapes the multicast data source to a consistent traffic profile. The shaped bandwidth is calculated based on the traffic condition of source and destination subnets. Transmitted multicast packets are forwarded to receiving hosts by the within the MTCF Router, whereas unicast packets would be processed by unicast routing module before arriving at the various destination subnets. The performs bandwidth sampling on all connected subnets and transmits that information to the TMs as multicast Feedback messages. If the bandwidth utilization exceeds the preset thresholds, prioritized multicast packet dropping is performed by the to enforce bandwidth management requirements []. MDT NET TM Subnet MDT NET TM Subnet Router MDT:Multicast Data Traffic NET: Network Stack TM: Traffic Manager : Multicast Multimedia Firewall Feedback Multicast Data Unicast Data Subnet Chin Hooi Tang (hooiye@nrg.cs.usm.my) and Tat Chee Wan (tcwan@cs.usm.my) are both with the Network Research Group, School of Computer Sciences, University of Science Malaysia, Minden, Penang, Malaysia. Figure : Interaction of TM, and router

2 III. OPERATION OF TRAFFIC MANAGER (TM) IV. EXPERIMENTAL RESULTS ) TM Feedback Feedback data consist of Available Source Bandwidth (ASBW) and Available Destination Bandwidth (ADBW) for each destination subnet (including available bandwidth of the source subnet) as measured by the []. ) TM Shaping Policy and Profile Three classes of service are specified with different bandwidth allocation. They are Service, Service and Equal Quality Service []. The service class and Feedback data are used to adjust the Target Transmission Rate (TTR), also known as the Shaping Threshold, for the given multicast stream. Service is intended to give each destination receiver the best possible service within the constraints of its available subnet bandwidth; whereas Service seeks to specify an average bandwidth requirement that can be carried on most destination subnets, so that a majority of receivers can receive reasonable quality multicast transmission from the source. In contrast, Equal Quality Service uses the minimum available subnet bandwidth to specify a traffic profile that could be carried on all destination subnets. This is a minimal performance profile intended to provide all users with some common level of service. ) TM Shaper and Bandwidth Management The Shaper ensures multicast packet transmission rate into the current subnet does not exceed the capability of destination subnet to receive those packets. By reducing the offered multicast transmission rate introduced into the network, bandwidth hogs are prevented from overwhelming other traffic. In addition, the reduction of generate multicast traffic would reduce the number of packets dropped by the while enforcing required bandwidth management policies. Consequently overall system utilization and throughput increases. When Feedback messages are received by the Traffic Manager, the Target Transmission Rate (TTR) acquired from the given service profile is compared with the Current Transmission Rate (CTR) of the source to determine the actual transmission rate to destination nodes. Adjustment to the CTR uses a parameter m as a rateincreasing/decreasing factor (Convergence Factor). From [], it is shown that the given rate increase and decrease mechanisms are effective in controlling the source traffic to the desired rate. denotes convergence of CTR to TTR. If ( CTR TTR < CTR i = CTR i - Else if (CTR < TTR): CTR i = CTR i - m Else if (CTR > TTR): CTR i = CTR i - m A Convergence Factor m =. was chosen experimentally [] to achieve quick convergence. As we are interested primarily in the impact of multicast bandwidth management on Intranet traffic throughput, unicast data streams are set to be unmanaged and will utilize as much of the available network bandwidth as possible (up to the offered throughput of the respective unicast streams). Prioritization of unicast streams using DiffServ or other techniques can be performed if needed. A. TM Shaper Convergence The performance of Traffic Manager (TM) is stable. Whenever multicast traffic is injected into the subnet through TM, traffic will be shaped based on the shaping threshold. The shaping threshold (TTR) increases rapidly and then stabilizes at the specified bandwidth threshold. For example, given TTR = Mbps, = bps and m =., the shaping threshold stabilizes at. Mbps within ms (Figure ). The convergence rate can be accelerated if CTR were initialized to a higher value. Shaping Trend of Traffic Manager Time (ms) Figure : Shaping Threshold Convergence of Traffic Manager (TM) MTCF was developed for the Linux Operating System. The built-in traffic shaping mechanism in the Linux kernel was used to implement TM functionality. This Linux traffic shaper provides bandwidth-throttling for individual IP addresses. The TM modifies the Linux traffic shaper parameters on the fly to achieve the desired shaping thresholds. Several unicast and multicast experiments were conducted to evaluate the MTCF performance. IPERF ( was used as a traffic measurement tool and multicast/unicast traffic generator/receiver for all experiments. Multicast Throughput (Mbps) Shaped Multicast UDP Throughput..... TM Figure : Shaped Multicast UDP Throughput Shaped Ideal

3 Figure shows the shaped multicast UDP throughput for a given TTR on a Mbps Ethernet network. The throughput is accurate for TTR <. Mbps. However, as TTR increases, the Linux traffic-shaper deviates from the ideal target bandwidth, resulting in higher actual throughput for a given TTR. Consequently, for lightly loaded networks, where TTR is expected to be high, the actual multicast throughput may be higher than the desired throughput. However, as network load increases, TTR will be decreased based to compensate for the reduced available bandwidth. The better accuracy of the Linux traffic shaper at lower TTRs will help ensure that the TM is able to limit the amount of multicast traffic transmitted into the network. B. TM Shaping Thresholds T M Unicast Subnet Subnet Routing MTCF Router Figure : TM Shaping Thresholds Test Setup The shaping performance of TM given different UDP traffic loads on source and destination subnets was investigated. The experimental setup is given in Figure. ) TM Shaping Behavior due to Destination Subnet UDP Unicast Maximized, Optimal, Equal Quality Convergence of CTR to TTR ( bps Convergence Factor (m). Lower Threshold (LSBT) % of Network B/W ( Mbps) Upper Threshold (USBT) % of Network B/W ( Mbps) Subnet UDP Unicast Load Mbps Subnet UDP Unicast Load,,,,, Mbps ) TM Shaping Behavior due to Source and Destination Subnets UDP Unicast Maximized, Optimal, Equal Quality Convergence of CTR to TTR ( bps Convergence Factor (m). Lower Threshold (LSBT) % of Network B/W ( Mbps) Upper Threshold (USBT) % of Network B/W ( Mbps) Subnet UDP Unicast Load,,,,, Mbps Subnet UDP Unicast Load,,,,, Mbps Performance for Source and Destination UDP Unicast UDP Unicast (Mbps) Figure : Performance for source and Destination UDP Unicast Performance for Source and Destination UDP Unicast UDP Unicast (Mbps) Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Figure : Performance for Source and Destination UDP Unicast Multicast Shaping Threshold Performance due to Destination UDP Unicast Equal Quality Performance for Source and Destination UDP Unicast UDP Unicast (Mbps) Equal Quality UDP Unicast (Mbps) Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Mbps Source Figure : Multicast Shaping Threshold (TTR) Performance due to Destination UDP Unicast Figure shows the typical shaping behavior of the TM based on different service classes. It can be seen that the shaping threshold is significantly reduced under high loads for Equal Quality service, whereas service experiences a more moderate decrease. Figure : Equal Quality Performance for Source and Destination UDP Unicast Figure -Figure show the interaction between TTR and source & destination loading. TTR is adjusted dynamically given increasing load on the source subnet, thus ensuring that the source subnet does not suffer from traffic overload.

4 Once the destination subnet loading exceeds source subnet loading, TTR is further reduced for Equal Quality service. However, destination UDP load has limited impact for the Maximized and service classes. C. TCP and UDP Unicast Throughput Performance IPERF TCP/UDP T M Unicast Routing Subnet Subnet MTCF Router IPERF TCP/UDP Figure 9: TCP and UDP Unicast Throughput Test Setup The system setup for the TCP and UDP unicast experiments is given in Figure 9. IPERF Multicast traffic generator generates multicast traffic, whereas IPERF Unicast traffic generator generates TCP/UDP unicast traffic from Subnet. The IPERF unicast traffic receiver is used to collect experimental data, while the IPERF multicast traffic receiver is used for multicast monitoring. The effect of TM on the unicast traffic was investigated. ) TCP Tests ) UDP Tests Target Transmission Rate (TTR). Mbps Convergence of CTR to TTR ( bps Convergence Factor (m). Subnet Multicast Load,,,,, Mbps Lower Threshold (LSBT) % of Network B/W. ( Mbps) Upper Threshold (USBT) % of Network B/W. ( Mbps) Subnet TCP Unicast Load Mbps Subnet UDP Unicast Load Mbps The UDP throughput performance is shown in Figure. Throughput (Mbps) 9 UDP Unicast Throughput UDP Multicast (Mbps) Figure : UDP Unicast Throughput The result shows that enabling TM gives significantly better UDP throughput at each level of multicast traffic load. Target Transmission Rate (TTR). Mbps Convergence of CTR to TTR ( bps Convergence Factor (m). Subnet Multicast Load,,,,, Mbps Lower Threshold (LSBT) % of Network B/W. ( Mbps) Upper Threshold (USBT) % of Network B/W. ( Mbps) Subnet TCP Unicast Load Mbps Subnet UDP Unicast Load Mbps The TCP throughput performance is in Figure. Jitter (ms) UDP Unicast Jitter (Averaged) UDP Multicast (Mbps) Throughput (Mbps) 9 TCP Unicast Throughput UDP Multicast (Mbps) Figure : TCP Unicast Throughput The result shows that enabling TM provides better TCP throughput at each level of multicast traffic load. Increasing multicast traffic load affects TCP throughput significantly if TM was disabled. Figure : UDP Unicast Jitter (Averaged) From Figure, we observe that UDP Unicast Averaged Jitter is unbounded if TM were disabled, whereas averaged jitter did not exceed 9 ms when TM was enabled. UDP Unicast Jitter (Instantaneous) Time (s) Figure : UDP Unicast Jitter (Instantaneous) pure udp

5 From Figure, a second instantaneous jitter plot given Multicast traffic loading of Mbps, we observe that TM introduces a jitter of between ms and ms into the UDP stream, whereas, the jitter increases to between ms and ms. Without multicast loading, the UDP stream experiences a relatively stable jitter of ms. The UDP unicast packet loss performance exhibits similar behavior to the throughput performance (Figure ). Percentage (%) UDP Unicast Packet Loss UDP Multicast (Mbps) Figure : UDP Unicast Packet Loss D. UDP Multicast Throughput Performance Throughput (Mbps) 9 UDP Multicast Throughput Dest. Subnet UDP Unicast (Mbps) Normal Multicast () Equal Quality (with TM) Figure : UDP Multicast Throughput given Destination Subnet UDP Unicast The results in Figure indicate that UDP multicast throughput performance is stable in the presence of destination subnet UDP unicast traffic. UDP multicast throughput drops gradually as the destination UDP loading increases, according to the respective service class. As expected, the Equal Quality is more aggressive in throttling offered multicast traffic in order to protect the UDP unicast throughput. In contrast, the throughput is close to the Normal Multicast () throughput since it is influenced primarily by source subnet traffic. T M UDP Multicast Jitter (Averaged) Unicast Subnet Subnet Routing MTCF Router Figure : UDP Multicast Throughput Test Setup Jitter (ms) Dest. Subnet UDP (Mbps) Normal Multicast () Equal Quality Figure shows the system setup for the UDP multicast throughput experiments. IPERF unicast traffic generator generates UDP loading traffic on the destination subnet (Subnet ). IPERF Multicast traffic generator generates multicast traffic, while the IPERF multicast traffic receiver is used to collect experimental data. In order to facilitate a stable TM configuration for measurement, the TTR is set statically based on the collected data in Figure. Maximized, Optimal, Equal Quality Target Transmission Rate (TTR) Based on collected data in Figure Subnet Multicast Load Mbps Lower Threshold (LSBT) % of Network B/W. ( Mbps) Upper Threshold (USBT) % of Network B/W. ( Mbps) Subnet UDP Unicast Load Mbps Subnet UDP Unicast Load,,,,, Mbps UDP Unicast loading is performed only in the destination subnet to provide controlled measurements on the impact of network loading on multicast throughput and jitter. The impact of traffic loading on both subnets is expected to have similar behavior as it mainly affects the selected TTR. Figure : UDP Multicast Jitter (Averaged) given Destination Subnet UDP Unicast Figure shows that the UDP multicast jitter is bounded to less than ms and increases gradually for destination subnet UDP loading up to Mbps. The jitter increases dramatically for the Equality Quality service class when the shaped drops to. Mbps. Therefore, UDP multicast jitter is reasonable for most cases of network loading except when the network becomes very congested ( Mbps). For most multimedia applications, the jitter experienced at moderate network loads can be accommodated using data buffering of about - ms. If Equal Quality service class were to be used, the multimedia codec must implement adaptive data buffering as traffic load increases, to adjust to the much higher jitter encountered (about ms) as the network becomes very congested.

6 Percentage (%) 9 UDP Multicast Packet Loss Dest. Subnet UDP (Mbps) Normal Multicast () Equal Quality (with TM) Figure : UDP Multicast Packet Loss given Destination Subnet UDP Unicast Figure shows that packet loss increases gradually with increasing destination subnet traffic for the Maximized and Optimal service classes. However, the Equal Quality service class experiences significant packet loss of greater than % when destination subnet loading exceeds Mbps. This means that the codecs used for multimedia streaming must be highly loss tolerant if it were to perform well using the Equal Quality service class. V. CONCLUSION The proposed MTCF architecture, comprising Traffic Managers acting in concert with the Multicast Multimedia Firewall, offers an effective way to implement bandwidth management of multicast traffic for shared media Intranets. It could be seen that unicast traffic throughput was protected from potentially bandwidth intensive multimedia multicast applications. In addition, the decrease in available bandwidth for multicast traffic would not result in the total loss of such multimedia services, since the traffic manager ensures that remaining bandwidth is utilized efficiently via traffic shaping to reduce the loading on an already congested network. Consequently, graceful degradation of quality for multimedia applications is made possible. VI. ACKNOWLEDGEMENTS This work is supported in part by funds from the Malaysian government IRPA program. VII. REFERENCES [] R. Braden. Ed, et. al., Resource ReSerVation Protocol (RSVP) Version Functional Specification, RFC, IETF, September 99, [] A Mankin, Ed., et. al., Resource ReSerVation Protocol (RSVP) Version Applicability Statement: Some Guidelines on Deployment RFC, IETF, September 99, [] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv and IPv Headers, RFC, IETF, December 99, [] S. Blake, D. Black, et. al., An Architecture for Differentiated Services, RFC, IETF, December 99, [] C. H. Tang, T. C. Wan, Coordinator Framework for Real-Time Multimedia over Residential Networks, Proc. ISCE, City Univ. of Hong Kong, Hong Kong, Dec. -,, [] T. C. Wan, C. H. Leong, R. C. W. Thum, Multicast Firewall for Intranet Multimedia Applications, Proceedings WEC '99, Subang, Kuala Lumpur, Malaysia, Jul. 9-, 999. [] M. Yamamoto, Y. Sawa, S. Fukatsu, H. Ikeda, NAKbased Flow Control Scheme for Reliable Multicast Communications, Proc. TENCON, Kuala Lumpur, Malaysia, Sep. -,. The choice of codecs should also be done in consideration of the type of service class used. While Maximized and Optimal service classes can utilize codecs which have less jitter and loss tolerance, Equal Quality service requires codecs that are highly adaptive and responsive to packet loss and jitter as traffic loads increase. This suggests that adaptive codecs should be network-traffic aware in order to perform the necessary adaptation. The MTCF can be further extended for use in conjunction with DiffServ mechanisms to provide such QoS support for multimedia multicast services through the Internet. This future work will make the provisioning of QoS for real-time multicast multimedia through the Internet a reality.