peer-to-peer multipoint videoconferencing on the internet

ARTICLE IN PRESS

0923-5965/$ - se

doi:10.1016/j.im

�Correspondi

E-mail addr

[email protected]

(T. C- elebi).

Signal Processing: Image Communication 20 (2005) 743–754

www.elsevier.com/locate/image

Peer-to-peer multipoint videoconferencing on the Internet

M. Reha Civanlar, Oznur Ozkasap�, Tahir C- elebi

Department of Computer Engineering, Koc University, 34450 Istanbul, Turkey

Received 29 April 2005; accepted 2 May 2005

Abstract

A peer-to-peer architecture for multipoint videoconferencing is presented. Each conference participant may have

asymmetric and dissimilar bandwidth connections to the Internet. The solution does not require additional hardware,

as in multipoint control units, or network infrastructure support such as multicast. Without creating any additional

demand on the networking and computing resources needed for a point-to-point videoconference, this architecture can

extend it into a multipoint one. A protocol for a completely distributed implementation has been developed and tested

on a prototype system extending a point-to-point video phone to a multipoint one. The architecture of the prototype

system along with the details of the protocol optimization is discussed. Several performance results are presented.

r 2005 Elsevier B.V. All rights reserved.

Keywords: Multipoint videoconferencing; Peer-to-peer

1. Introduction

Large bandwidth demands of video transportand associated high networking costs are amongthe leading reasons for the current unpopularity ofvideoconferencing in general and multipoint (MP)videoconferencing in particular. Problems withimplementing MP videoconferencing can be ob-served, for example, in the video enhanced instantmessaging (IM) applications. Recently, several IM

e front matter r 2005 Elsevier B.V. All rights reserve

age.2005.05.003

ng author.

esses: [email protected] (M.R. Civanlar),

du.tr (O. Ozkasap), [email protected]

implementations started to allow participants ofchat rooms establish pair-wise video communica-tions along with text-based chat. Using thistechnology in a multi-party video-chat, whereeveryone wants to see everyone else, however,increases both the send and the receive bandwidthdemands for all participants for each added partyto the MP conference. For low bandwidthconnections, e.g., connections over ordinary mod-ems, the bandwidth is barely enough for transport-ing video between two participants and clearlywill not be sufficient as the number of parti-ciants increases. Consequently, users with modemconnections cannot participate in MP video-conferences. Considering that low bandwidth

d.

www.elsevier.com/locate/image

ARTICLE IN PRESS

M.R. Civanlar et al. / Signal Processing: Image Communication 20 (2005) 743–754744

connections still constitute a significant percentageof the Internet access lines, a solution to thisproblem is needed for the wide-scale usability ofMP videoconferencing.

One approach to reduce the bandwidth demandof an MP videoconferencing system is to usenetwork-based devices called multipoint controlunits (MCU) [1]. An MCU is a central devicewhich has a larger bandwidth Internet connectionthan a regular participant and it receives allparticipants’ video signals and disseminates them.An MCU prepares a video representation, e.g.,collages of low-resolution video and sends it to allparticipants. However, their costs and manage-ment complexities make MCUs suitable only forlarger business applications.

Another way to reduce the bandwidth require-ment is to use multicasting when it is supported bythe underlying network. An additional advantageof a multicasting-based solution is the reducedoperation complexity due to its distributed nature[6]. Unfortunately, due to the fact that wide-scaledeployment of native mode multicasting on theglobal Internet has still not been realized, thisoption is not a viable choice either.

In this paper, we present a new fully distributedpeer-to-peer (P2P) approach for multipoint video-conferencing. Our initial assumption, namely 1-1I/O constraint, dictates that a participant can onlyreceive, send and produce a single video signal atany given time. Then, we further consider the casewhere all participants can receive and produce asingle video signal, but send/relay one or morevideo signal(s) at any given time. This approachtakes the heterogeneity of the Internet environ-ment into consideration. We built a prototype ofour system by extending an H.263-based, point-to-point video telephony implementation to MPvideo. The resulting system can be used for MPvideoconferencing among participants with mod-em connections to the Internet without requiringmulticast support or MCUs and it can be used forextending most other point-to-point systems also.Our system has no need for additional hardware,as in MCUs, or underlying network support likemulticast. Besides, our solution is fully distributedand does not suffer from single point of failures.With almost no additional demand on the

networking and computing resources needed fora point-to-point videoconference, our system canmake it possible to extend a point-to-pointconference to an MP videoconference, where eachparticipant can see one other selected participantunder most practical cases.

P2P techniques are becoming extremely popularand finding diverse applications. Use of P2Ptechniques for videoconferencing through anend-system-based multicast implementation hasbeen reported before [4]. However, such systemsassume availability of larger upstream bandwidthsfor each participant. In [11] another P2P solutionfor MP videoconferencing based on a centralizedarchitecture is presented. Our implementation, byfocusing on the needs of those users withsymmetric, low bandwidth connections, presentsa totally distributed solution with no single pointof failure and central server maintenance.

The article is organized as follows. In the nextsection, an overview of P2P media distributionapproaches is presented. Section 3 presents themain algorithm for a distributed P2P MP video-conferencing arrangement for participants with asingle video input/output. Section 4 discusses theimplementation details of our prototype system.Section 5 addresses optimizing the resulting systemfor delay. A solution for the case where someparticipants have multiple video outputs is dis-cussed in Section 6. Finally, Section 7 presentsresults and conclusions.

2. Related work

Most of the recent techniques for P2P mediastreaming on the Internet utilize multicast modelat the application layer. The main benefit ofimplementing application layer multicast is over-coming the lack of large-scale IP multicastdeployment at the network layer. In addition toP2P models, there exist other application layermulticast solutions adapting an overlay-based(infrastructure level) approach. Overlay-basedapproaches require the existence of dedicatedservers as opposed to P2P ones. They are scalablesince the receivers can get the content from thededicated servers acting as software routers, which

ARTICLE IN PRESS

M.R. Civanlar et al. / Signal Processing: Image Communication 20 (2005) 743–754 745

would decrease the bandwidth consumption at thesource as well.

Most of the publications on P2P media dis-tribution so far focus on streaming applications.Capacity analysis of a P2P media streamingsystem, and the two key problems of these systems,namely the media data assignment for a multi-supplier P2P streaming session and the fastamplification of the P2P streaming capacity, arediscussed in [21]. Various methods have beenproposed to address the asynchrony of userrequests and the synchronous nature of the multi-cast paradigm [9]. A recent study [8] proposes alayered P2P streaming mechanism for on-demandmedia distribution. Asynchrony of user requestsand heterogeneity of peer network bandwidth arethe two main issues that this work points out. Asthe solution, cache-and-relay and layer-encodedstreaming techniques are proposed. The solutionhas been shown to be efficient at utilizing peers’bandwidth, scalable at saving server bandwidthconsumption, and optimal at maximizing stream-ing quality of peers.

ZIGZAG is a P2P system developed for single-source media streaming to a large group ofparticipants on the Internet [20]. It proposes anefficient failure recovery and control protocol formaintaining the application layer multicast treeagainst network dynamics and unpredictable clientbehaviors. Failure recovery is performed locally,and control overhead is constant. In addition, thesystem addresses the issue of minimizing end-to-end delay from source to receivers. The studyincludes a theoretical analysis together with asimulation study and comparison with NICEprotocol [2], an application layer multicast techni-que for P2P streaming. NICE and ZIGZAG aredifferent in their multicast tree construction andmaintenance mechanisms. They both focus onlarge P2P networks. The system in [20] is based onone of the first P2P streaming techniques called‘‘chaining’’ [18]. It allows a source to server chainof clients using a single data stream. In chaining,the delivery tree is built rooted at the source, and ituses the source’s bandwidth efficiently by utilizingother peers’ bandwidth to stream media to others.

CoopNet [13] proposes a hybrid approachintegrating the client-server and P2P models for

both live and on-demand streaming media. Foron-demand media, clients make use of cachingcontent that they viewed recently. For live mediastreaming, clients form a distribution tree rootedat the source. In particular, CoopNet considers theproblem of server overload by a large number ofrequests from clients. In such a case, it utilizes P2Pmodel and clients cooperate to distribute contentto decrease the load on the server. In addition,CoopNet uses a multiple description codingmethod for the media content, which improvesrobustness and balances load among peers.

Another study [4] explores the impact ofapplication requirements on end system multicastarchitecture in which end systems in a multicastgroup self-organize into an overlay structure. Inthe context of audio and videoconferencingapplications, techniques proposed are incorpo-rated into Narada [5], which is a self-organizingand self-improving protocol that adapts to net-work dynamics. Narada constructs overlay struc-ture in two phases. First, it maintains a connectedgraph called mesh among the peers, and thenconstructs a shortest path spanning tree on themesh whenever a source wants to transmit contentto a set of receivers. Each member has a limitednumber of neighbors on the mesh determined bythat member’s connection bandwidth to theInternet. This limitation regulates the fan-out ofmembers when constructing trees, and reduces theoverhead when running routing algorithms on themesh. Benefits of the two-phase approach are thatgroup management is maintained on the meshrather than on trees per source, and a mesh is moreresilient to the failure of members. Mesh-basedapproach is also motivated to better supportmulti-source applications. Constructed tree for avideo source aims to optimize metrics such asstress (number of identical copies of a packetcarried over a physical link), relative delay penalty(ratio of the delay between two members along theoverlay to the unicast delay between them), andresource usage. Results indicate that end systemmulticast is a promising approach for enablingconferencing applications in dynamic and hetero-geneous Internet settings. The study demonstratesthe necessity for self-organizing protocols to adaptto both latency and bandwidth metrics. In

ARTICLE IN PRESS


practice, end system multicast is widely andsuccessfully used for single source video streamingon the Internet. Although its applicability tomulti-source videoconferencing is mentioned, tothe best of our knowledge, its practical usage inthis context is not that common and relatedperformance results are not reported. Differentthan this study, we target multi-source videocon-ferencing sessions in particular.

Finally, [11] proposes an approach for multi-sender 3D videoconferencing using end-systemmulticast, which has a problem domain similarto our study. It maintains a conference sessionprotocol for small number of participants whereeach participant can act as video source for therest, and frequent changes are handled quickly. Italso offers a method of soft-join which involveslocating a new participant into the multicast treeas fast as possible. Unlike video sharing, multicasttree construction in [11] is done via rendezvouspoints (RP) acting as central machines. This makesdecision-making fast and reliable. However, due tothe nature of centralized solutions, it suffers fromsingle point of failures. In addition, multicast treeconstruction involves controlling all multicasttrees which increases operational complexity andcost. While constructing multicast trees, the RPcan choose one idle/available participant foracting as a reflector node (node that relays otherparticipant’s video without watching) without itsconsent.

Our approach differs from the prior workdiscussed above in a number of ways. First ofall, it is not based on an application layer multicastmodel or overlay-based approaches requiring theavailability of dedicated servers. Our solutionemploys a fully distributed model utilizing P2Pprinciples for the dissemination of media content.Hence, problems of single point of failure andserver overload are avoided. As discussed in thefollowing section, our main assumption dictatesthat each conference participant can produce andreceive only one video signal at any given time andsend/relay one or more video signal(s) based on itscomputing power and Internet connection speed.This, together with the P2P media disseminationmodel, leads to balanced overhead at the partici-pants. A solution should be efficient in utilizing

participants’ bandwidth and scalable at savingmedia sources’ bandwidth consumption. Oursystem achieves this via the spanning tree config-uration and management of conference partici-pants. Besides, our approach does not allowresource sharing without a participant’s consent.

3. Peer-to-peer approach for video transmission for

participants with single video I/O

In our P2P approach to MP videoconferencing,we assumed that each participant can produce,send, and receive only one video signal at anygiven time. This way the networking and thecomputing resources needed for an MP conferencestay the same as that of a point-to-point con-ference. In order to enable MP video, however, aparticipant receiving a video signal may have topass it to another participant who also wants toreceive the same video signal. Relaying thereceived video signal to another participant doesnot bring any additional computational burdenbeyond sending the participant’s own video signal,but it uses up the entire available upstreambandwidth. Thus, a participant who is sending itsown video signal cannot act as an intermediatepeer passing a video signal to another peer, and anintermediate peer cannot send its own video signalto anyone else.

As shown in Fig. 1, in an MP videoconferenceamong three participants, a P2P configuration canalways be found such that any participant can seeany other participant at any given time. Asdemonstrated in Fig. 2 for a conference with fourparticipants, however, there are cases where thiswill not be possible when the number of partici-pants is four or larger.

3.1. A distributed solution

Our distributed architecture can be used toimplement a P2P MP videoconferencing systemthat can configure itself to allow each participantto see any other participant whenever possible, i.e.,when the resulting configuration is achievable. Inthis architecture, we assumed that the usual tasksof setting and controlling a multipoint conference

ARTICLE IN PRESS

1 2 3 1

3

1 4

Fig. 2. Participant number 4 cannot see participant number 2

in this configuration.

1 2 3

2

1

1

1 2 3

1

2

2

1 2 3

2

1

3

1 2 3

2

2

3

1 2 3

1

3

1

1 2 3

1

3

2

1 2 3

3

1

3

1 2 3

3

3

2

Fig. 1. In a P2P MP videoconference with three participants each participant can see any other participant. (The numbers on the

arrows indicate which participant’s video signal is being transmitted over the corresponding link.)


are handled by the appropriate protocols asdescribed in the Internet multimedia architecture.Therefore, tasks such as inviting participants toconferences, distributing, and managing the list ofactive participants, etc. are outside the scope ofthis description. Also, transmission of any othermedia associated with the video such as textmessages is not addressed but can be carried outin a similar manner.

The state of our P2P MP videoconferencingsystem is defined on the basis of an object called a‘‘chain.’’ In this context, a chain defines the videoflow configuration between the participants of aconference receiving the same video signal at agiven time. All the chains involved in a P2P MPvideoconference define the conference’s currentstate. The video flow configurations, i.e. chains,change during a session as a response to ‘‘config-

uration messages’’ sent between the participants.

3.1.1. Chains

A chain is an ordered list of identificationnumbers of the conference participants whoreceive the same video signal, in the order theyreceive it. The first entry in this list, called the

‘‘head,’’ is the video source for the rest of theparticipants in the list. Every participant getsassigned a unique identification (ID) number whenthey join the conference. Each chain has anadditional binary valued attribute called ‘‘extensi-

bility.’’ A chain is extensible (e) if its last member isnot a head for another chain, non-extensible (e)otherwise.

Each chain member knows the head of the chainand the receiver ID if it relays video. The headknows about the entire chain. A participant whodoes not send or receive video is a member of anextendible chain containing only its own IDnumber. Fig. 3 shows the chains correspondingto the conferencing arrangements shown in Figs. 1and 2.

3.1.2. Configuration messages

The heads play a central management role fortheir chains. For example, if a new participantwants to receive video, the head needs to configureits chain by sending the necessary messages toother affected participants. If a chain memberlooses video, it waits for a ‘‘modify chain’’ messagefrom the head and if such a message does notarrive within a timeout period, the head is assumedto be non-functional and the chain is dissolved.

There are eight configuration messages as out-lined below:

(i)
Video request message: Sent by any partici-pant to request video from another partici-pant. The recipient may already be the headof a chain, in which case the chain needs to

ARTICLE IN PRESS

Fig. 3. Chains corresponding to the configurations in Figs. 1(a) and 2(b).


be reconfigured if possible. Otherwise, a newchain can be created. A video requestmessage carries the ID of the requestor andan attribute indicating whether the requestoris sourcing video to any other participant ornot. A participant already receiving videocannot send a video request message unless itreleases its current video successfully. Var-ious actions resulting from a video requestmessage are outlined in the pseudo-codebelow.

Participant k receives a video requestmessage from participant m

if k is a headif k’s chain is extensible

append m to chainelse

if m can pass through videoinsert m in chain

elsedeny the request

elseif k is a chain member

if the chain is extensiblemove k to the endstart new chain

else deny the request

Since the extensibility of a chain maychange, the head checks this with the lastmember before adding a new member orreconfiguring the chain.

(ii)
Video request ack/nack message: This messageis sent as a response to a video request message.If the requestor has to pass the video that itreceives to another participant, the ID of thisparticipant is included in the acknowledgement.If the video cannot be sent at the currentconfiguration, a nack message is sent back.
(iii)
Release request message: When a participantdecides to stop receiving, it must send a‘‘release request’’ message to the head. If the‘‘release request’’ message is not from thelast chain member, the head reconfigures itschain by sending a ‘‘modify chain’’ messageto the member sending video to the source ofthe ‘‘release request’’ message. This messageincludes the ID of the successor if any. If thelast participant wants to stop the video, thepeer before the last is sent a ‘‘modify chain’’message with a zero argument.
(iv)
Extensibility check message: A head sendsthis message to the last member of the chainto determine if the chain is extensible.
(v)
Extensibility ack/nack message: Sent as aresponse to an ‘‘extensibility check’’ mes-sage.
(vi)
Modify chain message: Sent by the head toonly one participant at a time to change itsvideo receiver. This message includes thenew recipient’s ID.
(vii)
Keep alive: Used to determine if a participantis still in the session. This is among the dutiesof the conference management protocol;however, getting this information fromconference management may take too long,resulting in a prolonged loss of video forseveral members. A participant starts send-ing ‘‘keep alive’’ messages to its recipient assoon as it joins a chain. The last membersends its ‘‘keep alive’’ message to the head. Ifa participant does not receive a ‘‘keep alive’’message for a pre-determined time period, itnotifies the head so that it can make therequired changes on the chain. If a partici-pant discovers that the head is non-func-tional, then it notifies all other participantsin the chain to dissolve the chain.

ARTICLE IN PRESS


(viii)
Dissolve: Sent by any chain member to otherchain members to dissolve a chain when thehead is determined to be non-functional.
4. Implementation

Our P2P MP videoconferencing prototype hasfive main modules as demonstrated in Fig. 4. Thefirst module is for conference management.Although a standard conference managementapplication can be used for this purpose, in thisprototype, a simple conference management ap-plication of our own with basic functionalitiessuch as conference creation and joining in andleaving a conference is developed. Another re-sponsibility for this module specific to ourapplication is to establish the unique session IDsfor each conference participant.

The second module, P2P manager, communi-cates with the conference manager to send currentchain status (to be displayed on the screen), andspecific events like user login/logout and peercrashes. A user interacts with the system using thegraphical user interface (GUI) module which isimplemented as an integral part of the conferencemanager in the prototype system. Video requestsfrom other participants are given to the systemthrough the GUI.

ConMaGUI

P2P VM

G

Video Codec

RTP/RTCPStack

RTP/RTCP

IA

Fig. 4. General structure of the P2P

The P2P video manager is responsible fordeciding how to multicast its local video. For thispurpose, it includes a unit to construct the chains.P2P manager does the remote updates by sendingconfiguration messages as well. Another responsi-bility of P2P manager is listening to the keep-alivemessages of the participant in the same videochain. If it detects a crushed participant, (i) and ifit is the head node, then it determines a new chainand implements the required changes by sendingconfiguration messages, (ii) else, it notifies the headnode about the crushed peer. P2P manager alsoruns the delay measurement unit which has a vitalimportance for the chain optimization process.

The video module handles video capture,compression/decompression, display and trans-mission over the network. In our prototype, wehave used a proprietary implementation of anH.263-based video codec. This system is designedto operate over a best-effort network, and, hence,can gracefully handle stops in its input video bitstreams and changes of the video sources during asession without a need to rapidly stop and restartthe codec that may be problematic for many videocodec systems. Video device is configured by theP2P video manager to stop/start capture/displayvideo.

P2P gateway application is a simple socket-based program which just sends and receives

ference nager

ideo Conf. anager

P2Pateway

IC

IB

Conference Messages

(SIP)

RTP/RTCP

P2P Configuration Messages

MP videoconference prototype.

ARTICLE IN PRESS


packets to and from pre-determined UDP sockets.It sends the local packet from the video unit totheir destinations, and it may re-send (relay) thepackets it receives to another destination or passthem to the video module depending on its currentrole in a chain.

5. Chain optimization

The chain construction algorithm describedabove and in [7] does not consider the networkdelays between the participants. This may result inlonger than necessary overall delays. For instance,assume that three users located at differentnational networks participate in a conferencesession. At a given time, user@US may have achain as shown in Fig. 5(a) which has a longdetour. Using the chain given in Fig. 5(b) insteadcan decrease the overall delay significantly. Thisreordering may also help to reduce the total packetloss rate because the longer routes will be moresusceptible to congestion. To address this issue, weadded a step to the chain construction method tosearch for the optimal chain orderings minimizingthe total delay on a chain.

We ignore the computing power parameter of aparticipant and concentrate on the network delayin re-constructing the chains. Since we need thenetwork delays between peers to determine theoptimal chain, we implemented a delay measure-ment protocol which is based on a clock synchro-nization algorithm described in [19]. The delays aremeasured for a participant as soon as it registers to

User @

US

User @ China

User @ Canada

User @

US

User @ Canada

User @ China

(a)

(b)

Fig. 5. Chain reconstruction example: (a) erroneous ordering;

(b) reconstructed ordering.

a conference. All participants except the newregistered one wait for a random time (to eliminatecollisions) and run the delay calculation for thenewly registered participant. All participants’delay matrices are updated after the delay mea-surements are complete.

We implemented the chain-order optimizationas part of a more general solution described in thenext section where some of the peers have thecapability to transmit more than one video signal.The solution is based on a two-stage heuristic andmay not be necessary for short chains where a fullenumeration is viable.

A separate thread is reserved for chain re-construction and it runs the optimization algo-rithm mentioned above periodically. Whenever aparticipant joins into a chain, it is tried to belocated immediately without regarding the opti-mized network delays. The re-construction foroptimized delays is performed later when the chainhead becomes available. This concept is calledsoft-join.

Delays are assumed to be static and they arecalculated only once at the conference login.However, they may change during a conferencesession. The delays reported by the RTCPmessages may be used to assist in handling varyingdelays. So as a further improvement, the delayoptimization process may be run when the delaysreported by RTCP change dramatically.

6. P2P MP videoconferencing for participants with

multiple video outputs

Single I/O model and its optimization offer agood solution for MP videoconferencing for manypractical cases where all participants are connectedover low bandwidth links or do not want to handlemore than one video. However, it is natural toexpect that some of the participants may havelarger access bandwidths and computing powers tosource more than one video signal at a given time.Clearly, having such participants can help in caseswhere the single I/O system cannot fulfill all videorequests.

In the literature, finding a multicast tree for amulti-sourced conference where the number of

ARTICLE IN PRESS


node outputs is limited is known as the minimumcost degree-constrained spanning tree problem andidentifying such a tree is computationally NP-hard[17]. Thus, several heuristics have been offered tofind a qualified solution under time or computingpower constraints. One such solution is aniterative search for eliminating degree-constraintswhile considering the total delay [10]. Another oneis a randomized approach that mainly focuses onthe delay problem without disturbing the I/Oconstraints [15,16]. The iterative solution, whichhas been implemented and ported to the currentapplication [3], is described in the next section.

6.1. Two-stage heuristic

We consider the two-stage heuristic algorithmreported in [10] for the solution of the generalizedMP videoconferencing problem. The first stageinvolves constructing a minimum spanning tree(MST) from a complete graph (this graph isconstructed using global delay matrix describedin the optimization part above) without consider-ing the degree constraints. The second stagemodifies the spanning tree to satisfy the given I/Oconstraints (degrees) for all participants. Thedetails of the algorithm and its procedures areoutlined in Fig. 6. In the first step, an MST can becalculated in polynomial time using greedy algo-rithms like Kruskal’s [12] or Prim’s [14]. Afterimplementing the first step, the constructed tree isprocessed to adjust the I/O constraints of thenodes. This step involves selecting a node thatviolates the I/O constraint disconnecting the high-est-cost edge from this node. Next, the sub-tree

Fig. 6. Algorithm for two-stage heuristic.

created by this operation is re-attached to thecurrent tree. This operation goes on until all nodeshave valid number of I/O connections. Thisheuristic is not guaranteed to find a solution underall cases. That is, when it fails to find a solution, itdoes not mean that no solutions are available.However, we will declare no solution in thesesituations. As stated in the previous section,optimization of the single I/O case can also behandled by this algorithm.

The advantages of this approach are that it issimple and easy to use. Results of this algorithmshow that it is feasible to use when the participantcount is less than or equal to 20 [10].

7. Results and conclusions

We implemented and tested the feasibility of asystem for P2P multipoint videoconferencing. Itcan be used to extend almost any point-to-pointvideoconferencing system to a multipoint one withminimal increase in the complexity and noadditional hardware support.

The system architecture allows us to use off-the-shelf software components for most of the systemelements. We tried to stay compliant with thestandards whenever possible.

We verified the feasibility of our architectureand the validity of our P2P protocol using ourprototype system with up to seven real partici-pants. We also run automated conference sessionsto check the consistency of the system’s behaviorfor larger number of participants and videoswitching activity. Fig. 7 shows theoretical andsimulation results obtained for the percentage ofunachievable configurations, i.e., configurationsfor which one or more participants cannotreceive video from another participant of theirchoice (as a percentage of all configurations)as a function of the number of conferenceparticipants for the single I/O case. The theoreticalvalues are determined by generating allpossible requests for the given number of users,determining if a solution is available, and enumer-ating the solutions. When compared to thetheoretical values, the simulation resultsshow that, as the number of participants gets

ARTICLE IN PRESS

0 1 2 3 4 5 6 7 8 9 100

10

20

30

40

50

60

70

80

Simulation

AllRequests

Granted Requests

Rejected Requests

4

5 16

6 12

7 38

8 13

9 23

All State States

Invalid States States

Dead lock-free States

3

4

5

6

7

0 1 2 3 4 5 6 7 8 9 100

10

20

30

40

50

60

70

80Theoretical

Others

3

States Valid Deadlock

Simulation results

Theoretical results

788 780 5

809 597 196

1001 725 264

1210 789 283

1176 859 304

1600 1139 438

27

256

3125

46656

823543

27

232

2405

29616

42383

0

24

720

17040

400260

0

66

1692

34840

712110

54

630

7928

113240

1827588

Fig. 7. Theoretical and simulation results for the single video I/O case: unachievable configurations’ percentage (y-axis) for a given

number of conference participants (x-axis). N is the number of participants.

Fig. 8. Run-time cost of the P2P application: measured

parameters are CPU idle time (upper line) and UDP bytes per

second (lower line).


larger, the percentage of unachievable configura-tions does not increase as much. This is becausethe number of feasible configurations is larger thanthe infeasible ones when a random request isgenerated starting from a feasible configuration (ascompared to starting from a completely discon-nected configuration).

The computational burden caused by the P2Papplication on the system is observed to beinsignificant (less than 1% CPU time on a2.4GHz Pentium).

Another runtime test for the application iscalculating the network traffic and memory loadin the system stemmed from the application. Fig. 8shows the run-time cost of the P2P application for15 s while both incoming and outgoing channelsare busy. CPU idle time (upper line) has beenmeasured and it shows that our P2P applicationleads to a 5–7% computational load. Anotherlogged criterion is network utilization. Just for thesake of dial-up users, the P2P prototype encodesthree frames per second which are MPEG4encoded using ffmpeg codec (freely distributed

@ www.sourceforge.net). For this case, the video(UDP) transmission load is almost 60–70Kbps.

We ran a formal verification study confirmingour protocol. We verified the feasibility of theoptimization algorithm that we used for reducing

http://www.sourceforge.net

ARTICLE IN PRESS

Tree Construction Feasibility

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

4 6 7 8 9Participant Count

Per

cen

tag

e o

f F

easi

bili

ty

E_FeasibilityM_FeasibilityD_Feasibility

(in msecs) ETREE DTREE

4

5

6

7

8

9

5

1.25

1.39

4.39

31.87

207.8

1621.55

1.42

0.48

0.63

0.62

0.31

1.1

CPU times in millisecondsfor algorithm run times.

Benchmarked algorithms are(E)numeration and (D)egree

Contrained using Two StageHeuristic

Feasibility benchmark of 3 methods; Kruskal MST,Enumeration of all chains, Two Phase Heuristic

(a) (b)

Fig. 9. (a) Chain feasibilities and (b) CPU-cost test results. Test machine is Intel (R) Pentium (R) 4 CPU 2.60GHz, 512MB of RAM,

MS Windows XP Pro v.2002.


the delay on long chains (two-stage heuristic)performing some tests on randomly generatedchains and the results are displayed in Figs. 9(a)and (b). For each test (that means for each entry ofthe horizontal axis), 5000 sample chains have beengenerated and all of the algorithms have beenforced to find a solution. Horizontal axis showsthe participant count and the vertical axis showsthe feasibility percentage. Fig. 9(a) depicts thecomparison of the three algorithms offered for treeconstruction. First algorithm Kruskal MST (upperline) has the best results since it does not take intoaccount the degree constraints. On the other hand,for a chain, the best solution can be found byenumerating (intermediate line) all states andselecting the minimum cost state. Finally, two-stage heuristic (lower line) has a feasibility levelnearly approaching 50% for the original cost.

Fig. 9(b) shows the CPU times for the enumera-tion and the heuristic solutions. As the number ofparticipant increases, enumeration suffers from thetime needed to find the best solution. Unlikeenumeration, heuristic-based search for chainreconstruction finds a feasible solution in areasonable time.

We believe that a potential solution for wide-scale deployment of MP videoconferencing is

through using P2P systems. Our protocol andprototype demonstrates the feasibility of suchapproaches. The next step will be organization oflarge scale trials on the Internet. An extension ofour system could be the utilization of scalablevideo to handle heterogeneous Internet accesstechnologies of the conference participants. Forinstance, some participants might prefer to viewtwo high-quality videos instead of one. Scalablevideo techniques may also be used to adapt thevideo bit rate at each node based on the upstreambandwidth. As another optimization, locating arelay node, with a high bandwidth, close to thevideo source would be useful to avoid thedegradation of the video quality for the successivenodes in the chain.

References

[1] ITU-T Study Group XV—Recommendation H.231, Mul-

tipoint Control Units for audiovisual systems using digital

channels up to 1920 kbits/s, March 1993.

[2] S. Banerjee, B. Bhattacharjee, C. Kommareddy, Scalable

application layer multicast, Proceedings of ACM SIG-

COMM’02, Pittsburgh, Pennsylvania, August 2002.

[3] T. Celebi, M.R. Civanlar, O. Ozkasap, P2P multi-point

videoconferencing on the Internet. IASTED PDCN 2005,

International Conference on Parallel and Distributed

ARTICLE IN PRESS


Computing and Networks, Innsbruck, Austria, February

2005.

[4] Y. Chu, S.G. Rao, S. Seshan, H. Zhang, Enabling

conferencing applications on the Internet using an overlay

multicast architecture, Proceedings of ACM SIG-

COMM’01, San Diego, California, August 2001.

[5] Y. Chu, S. Rao, H. Zhang, A case for end system

multicast, in: Proceedings of ACM Sigmetrics, June 2000.

[6] M.R. Civanlar, R.D. Gaglianello, G.L. Cash, Efficient

multi-resolution, multi-stream video systems using stan-

dard codecs, J. VLSI Sig. Proc. 17 (2–3) (1997) 269–279.

[7] M.R. Civanlar, O. Ozkasap, T. Celebi, Peer-to-peer multi-

point videoconferencing, ICIP, IEEE International Con-

ference on Image Processing, Singapore, October 2004.

[8] Y. Cui, K. Nahrstedt, Layered peer-to-peer streaming,

Proceedings of NOSSDAV’03, Monterey, California, June

2003.

[9] D. Eager, M. Vernon, J. Zahorjan, Minimizing bandwidth

requirements for on-demand data delivery, IEEE Trans.

Knowledge Data Eng. 13 (5) (2001).

[10] N. Funabiki, J. Kawashima, A. Kubo, K. Okayama, T.

Higashino, A proposal of a two-stage heuristic algorithm

for peer-to-peer multicast routing problems in multihome

networks, The Fifth Metaheuristics International Con-

ference (MIC-2003), August 2003, pp. 20-1-6.

[11] M. Hosseini, N.D. Georganas, Design of a multi-sender

3D videoconferencing application over an end system

multicast protocol, ACM, Multimedia 2003, Berkeley, CA,

November 2003.

[12] J.B. Kruskal, On the shortest spanning subtree of a graph

and the traveling salesman problem, Proc. Am. Math. Soc.

7 (1) (1996) 48–50.

[13] V.N. Padmanabhan, H.J. Wang, P.A. Chou, K. Sripanid-

kulchai, Distributing streaming media content using

cooperative networking, Proceedings of NOSSDAV’02,

Miami, Florida, May 2002.

[14] R. Prim, Shortest connection networks and some

generalizations, Bell System Technical J. 36 (1957)

1389–1401.

[15] G.R. Raidl, An efficient evolutionary algorithm for

the degree-constrained minimum spanning tree problem,

in: C. Fonseca, et al. (Eds.), Proceedings of the 2000 IEEE

Congress on Evolutionary Computation, IEEE Press,

2000, pp. 104–111.

[16] G.R. Raidl, B.A. Julstrom, A weighted coding in a genetic

algorithm for the degree-constrained minimum spanning

tree problem, in: J. Carroll, et al. (Eds.), Proceedings of the

2000 ACM Symposium on Applied Computing, ACM

Press, 2000, pp. 440–445.

[17] R. Ravi, M.V. Marathe, S.S. Ravi, D.J. Rosenkrantz, H.B.

Hunt, Many birds with one stone: Multi-objective

approximation algorithms, in: Proceedings of 25th Annual

ACM STOCS, 1993, pp. 438–447.

[18] S. Sheu, Kien A. Hua, W. Tavanapong, Chaining: A

generalized batching technique for video-on-demand,

Proceedings of the IEEE International Conference on

Multimedia Computing and System, Ottawa, Ontario,

Canada, pp. 110–117, June 1997.

[19] A.S. Tanenbaum, M.V. Steen, Distributed Systems—

Principles and Paradigms, Prentice Hall, New Jersey,

2002, pp. 247–249.

[20] D.A. Tran, K.A. Hua, T. Do, ZIGZAG: An efficient peer-

to-peer scheme for media streaming, Proceedings of IEEE

Infocom, 2003.

[21] D. Xu, M. Hefeeda, S. Hambrusch, B. Bhargava, On peer-

to-peer media streaming, Proceedings of the 22nd Inter-

national Conference on Distributed Computing Systems

(ICDCS’02), 2002.

peer-to-peer multipoint videoconferencing on the internet

Documents