Investigating the Performance of Audio/Video Service Architecture II: Broker Network Ahmet Uyar & Geoffrey Fox Tuesday, May 17th, 2005 The 2005 International Symposium on Collaborative Technologies and Systems (CTS 2005) Saint Louis, Missouri, USA

Outline Introduction NaradaBrokering Overview Delivery priority for inter-broker traffic Single meeting tests Multiple Meeting Tests Wide area tests Conclusion

Introduction We investigate the performance and the capacity of the broker network in multiple broker settings. We test the scalability of the broker network for both single large size meetings and multiple smaller size meetings. We perform wide area tests to investigate the issues in real life videoconferencing settings over Internet. The test results provide guidelines for the deployment and feasibility of GlobalMMCS videoconferencing system in particular and software based systems in general.

NaradaBrokering broker organization

Performance Tests We used an H.263 video stream with 280kbps bandwidth. We used two 8 node Linux clusters to perform the tests. At cluster1, each node had 2.4GHz Dual Intel Xeon CPUs, 2GB of memory and Linux kernel. At cluster2, each node had 2.8GHz Dual Intel Xeon CPUs, 2GB of memory and Linux kernel.

Delivery Priority for Inter-broker Traffic We have given priority to inter-broker package delivery over local client deliveries. This lets packages to travel many brokers with very little overhead. Therefore, the broker network can grow in size. It eliminates cases where one overloaded broker severely affects the performance of other brokers. It lets the load to be distributed among brokers in large size meetings.

Single Queue First User (ms) Mid User (ms) Last User (ms) Avr. (ms) Broker users Broker 2 (6 users) Double Queue First User (ms) Mid User (ms) Last User (ms) Avr. (ms) Broker users Broker 2 (6 users) Latencies with single and double queuing

Single Video Meeting Tests for Distributed Brokers There are equal number of participants in each broker. We gather results from the last user from each broker.

Latencies from 4 brokers Broker1 and Broker2 have very similar latency values. Broker3 and Broker4 have similar and slightly better latency values. Going through multiple brokers does not introduce considerable overhead. Scalability of the system can be increased almost linearly by adding new brokers.

Multiple Meeting Tests for Distributed Brokers The same setting as the single video meeting tests. However, all brokers were running at cluster 2. The behavior of the broker network is more complex, since there are many stream deliveries among the brokers. Having multiple meetings provide both opportunities and challenges. Conducting multiple concurrent meetings on the broker network can increase both the quality of the service provided and the number of supported users as long as the size of these meetings and the distribution of clients among brokers are managed appropriately. The best broker utilization is achieved when there are multiple streams coming to a broker and each incoming stream is delivered to many receivers. If all brokers are utilized fully in this fashion, multi broker network provides better services to higher number of participants.

Multiple Video Meeting Tests 4 brokers can support 48 meetings with 1920 users in total with excellent quality. This number is higher than the single video meeting tests in which four brokers supported up to 1600 users. When we repeated the same test with meeting size 20, 1400 participants can be supported with 70 meetings. Number of Meetings Total users Broker1 (ms) Broker2 (ms) Broker3 (ms) Broker4 (ms) Number of Meetings Total users Broker1 (%) Broker2 (%) Broker3 (%) Broker3 (%) Latency values and loss rates for meeting size 40

Wide-Area Media Delivery Tests We tested with five distant sites: Syracuse, NY Tallahassee, Florida Cardiff, UK Two sites at Bloomington, IN We tested two cases: single broker at Indiana one broker at each site

Single Video Meeting Tests Users per site Total users Latencies of last participants (ms) BW per site INNYFLUK Mbps Mbps Mbps Mbps There is one broker at Indiana. There is one video meeting. One user is publishing the video stream at IN. There are equal number of participants at every site. Latency values are the combination of transmission latency and routing overhead. First row shows mainly the transmission latency, since the routing overhead is very small. Transmission latency is very small for all sites. It does not increase significantly when more streams are transmitted.

Summary of Wide-Area Tests Running brokers at distributed locations has many benefits: Saves bandwidth, and eliminates bandwidth limitations. Transferring smaller number of streams yields better transmission services with smaller latency, jitter and loss rates. Load is distributed to many brokers, more users can be served with better quality services. End-to-end package latency can be reduced considerably by running brokers at geographically distant locations. The networks that we used provided excellent services with very small loss rates, latency and jitter values. The network connections need to be checked for high quality. Some sites can not use their full capacity.

Conclusion Test results showed that the broker network can scale well for both single large size meetings and multiple smaller size meetings. In large size meetings, the capacity of the broker network is increased with respect to the capacity of the added brokers. In multiple smaller size meetings, the distribution of users among brokers are important. Inter-broker stream exchange can reduce the scalability. Few users should not be scattered around the broker network. In wide area networks, this videoconferencing system provides many benefits with distributed broker architecture: bandwidth savings, latency savings, and better quality services. In summary, thousands of concurrent users can easily be supported in distributed broker settings.

Questions…