IPTComm2007 New York, July 19 th 2007 A. Amirante, T. Castaldi, L. Miniero and S.P. Romano

“Improving the scalability of an IMS-compliant conferencing framework through presence and event notification”

IPTComm2007New York, July 19th 2007

A. Amirante, T. Castaldi, L. Miniero and S.P. Romano

COMICS (COMputers for Interaction and CommunicationS)

research groupUniversity of Napoli Federico II

IPTComm2007 -- New York City, July 19th 2007

2

Agenda

Rationale & Motivation A standard centralized conferencing

architecture Performance assessment and bottlenecks

identification Improving scalability through distribution of

components/responsibilities Conclusions


3

Conference

The term “Conference” can be used to describe any meeting of people that “confer” about a certain topic Web Conferencing is used to indicate live meetings or presentations over the Internet


4

Standardization efforts

No standardization for many years Lack of interoperability Platform dependency Security issues Cost Market segmentation

Standardization Bodies ITU (International Telecommunication Union) IETF (Internet Engineering Task Force) 3GPP (3rd Generation Partnership Project)


5

IETF SIPPING Working Group Session Initiation Proposal Investigation Documents the use of SIP for several applications

related to telephony and multimedia SIP Conferencing

Loosely-Coupled Conference Fully Distributed Multiparty Conference

Tightly-Coupled Conference

Focus Policy Server Mixer

Notification Service (Event Package, RFC 4575) Participants

SIP Conferencing Framework (RFC 4353): fundamental elements


6

XCON Working Group

Centralized Conferencing (XCON) Extends RFC 4353

Protocol-agnostic (not only SIP) Data Sharing (not only audio/video)

Suite of Protocols Conference Control (CCMP?) Floor Control (BFCP) Call Signaling (SIP/H.323/IAX/etc.) Notification (Event Package?)


7

XCON Framework

Conference Control Client

Floor Control Client

Call Signaling Client

Notification Client

Conference Control Server

FloorControl Server Focus Notification

Service

Conference Object

Conference Object

Conference Object

Conference Control Protocol

Floor Control Protocol

CallSignaling Protocol

NotificationProtocol

Conferencing System

Conferencing Client


8

CONFIANCE CONFerencing IMS-enabled Architecture for

Next-generation Communication Experience http://confiance.sourceforge.net/

Open source implementation of the XCON Framework, compliant with the IMS specification

Extends the Asterisk PBX functionality Enhanced “MeetMe” application

Support for Conference Management (Scheduler) Support for Floor Control (BFCP) Support for BFCP-guided video switching/mixing Support for MSRP (Message Session Relay Protocol)

text chatrooms


10

Why Distributed Conferencing? Centralized Conferencing

Poorly scalable Limited capabilities Single point of failure

Towards distribution: Cascaded Conferencing

Each focus is seen as a participant by the others Only affects mixers' distribution Centralized protocols like BFCP don't work


11

DCON Proposal Distributed Conferencing (DCON)

http://dcon.sourceforge.net/ Orchestrates the operation of a set of XCON “clouds” Overlay network interconnecting the clouds Intra-focus communication

Still based on XCON protocols Inter-focus communication

Exploits Server-to-Server (XMPP) Requirements

Focus discovery Initialization information & spreading of conference events Setup and managing of distributed conferences Transparent dispatching of natively centralized protocols

among the involved conferencing clouds

Focus DCON

Minisip Spark

Integrated client

XMPP

SIP


12

DCON Implementation


14

Tool employed: SIPp SIP traffic generator Capable to reproduce fully customizable call scenarios through

XML configuration scripts Capable to also reproduce actual media flows through the

RTP/pcap replay function

Used to test two different facets of scalability: Maximum number of users who can access the system Resource consumption, given a specific number of users

Testbed:OS: Linux Fedora Core 6, kernel 2.6.15CPU 3,2GHz Intel XEON, RAM 2GB

Performance assessment


15

Asterisk does not allow to open more than 1024 Zaptel pseudo-channels (i.e. abstractions of physical channels) simultaneously

Each conference, upon creation, makes use of two such channels

Each conference participant uses a single pseudo-channel

Quasi-linear growth in the number of users in the presence of distribution

Note well: No RTP traffic involved in such tests just signaling!

Scalability: just signaling


16

0 50 100 150 200 250 3000

10

20

30

40

50

60

70

80

90

100

Calls

CP

U lo

ad [

%]

Centralized case (one single conference)

Focus Calls CPU load (%)

Main 300 99,4

300 users as a maximum limit in the presence of audio streams

Might become critical in case many conferences are activated in a cloud

A reference value for the following tests

Scalability: signalling + audio


17

0 50 100 1500

10

20

30

40

50

60

70

80

90

100

Local calls

CP

U lo

ad [

%]

Main focusRemote focus


Main 150 30,04

Remote 150 20,19

Scalability: 2 islands case


18

0 50 100 1500

10

20

30

40

50

60

70

80

90

100

Local calls

CP

U lo

ad [

%]

Main focusRemote focus 1Remote focus 2

0 10 20 30 40 50 60 70 80 90 1000

10

20

30

40

50

60

70

80

90

100

Local calls

CP

U lo

ad [

%]

Main focusRemote focus 1Remote focus 2


Main 100 20

Remote_1 100 18

Remote_2 100 18


Main 150 31,05

Remote_1 75 12

Remote_2 75 12

Scalability: 3 islands case


19

Migration towards a distributed paradigm allows for a huge reduction in the load of the primary focus

The sum of the CPU levels of all involved foci is less than the CPU level of the single focus in the centralized case

Given a fixed number of local users, remote users distribution among multiple islands adds negligible overhead to the main focus

Number of islands

Number of local users

Number of remote users

Main focus CPU load

Remote focus 1 CPU load



1 300 - 99.4% - - -2 150 150 30.04% 20.19% - -3 100 200 (100/100) 20% 18% 18% -3 150 150 (75/75) 31.05% 12% 12% -4 75 225 (75/75/75) 12.66% 12% 12% 12%4 150 150 (50/50/50) 32.4% 7.8% 7.8% 7.8%

Scalability: figures in summary


20

Future Work

More performance tests: Different media:

Involve video, chat, desktop sharing applications, etc. in the trials

Different protocols Involve BFCP, Conference Control Protocol, etc. in the

trials Different scenarios

Try to reproduce real-world conference configurations Different overlay topologies

Not just full meshes Investigate smart p2p approaches


21

What else?

See all of you at the demo tomorrow! Have a look at DCON up and (hopefully ) running… We also present:

our brand new JAVA-based integrated client our current prototype of the distributed approach to video

mixing

Our contacts: [email protected] [email protected] [email protected] [email protected]