Multimedia Multicast Transport Servicefor Groupware

�

Chockler, GregoryV., Huleihel,Nabil, Keidar, Idit, andDolev, Danny,TheHebrew Universityof Jerusalem,Jerusalem,Israel

�

1.0 Abstract

Reliability carriesdifferentmeaningsfor differentapplications.For example,in a replicateddatabasesetting,reliability meansthatmessagesarenever lost,andthatmessagesarrive in thesameorderat all sites. In orderto guaranteethis reliability property, it is acceptableto sacri-fice real-timemessagedelivery: somemessagesmaybegreatlydelayed,andat certainperiodsmessagetransmissionmayeven beblocked. While this is perfectlyacceptablebehavior for areliabledatabaseapplication,this behavior is intolerablefor a reliablevideoserver. For a con-tinuousMPEGvideoplayer[20, 19], reliability meansreal-timemessagedelivery, at a certainbandwidth;It is acceptablefor somemessagesto be lost, aslong asthe availablebandwidthcomplieswith certainpredeterminedstochasticassumptions.Introducingdatabasestyle relia-bility (i.e. messagerecovery andorderconstraints)may violate theseassumptions,renderingtheMPEGdecodingalgorithmincorrect.Many CSCWgroupwareandmultimediaapplicationsrequirequalityof servicemulticastfor mostof theirmessages,andmaygreatlybenefitfrom re-liablemulticastfor asmallportionof “critical” messages.Furthermore,suchapplicationsoftenneedto befault-tolerant,andneedto supportsmoothreconfigurationwhenpartiesjoin or leave.Groupcommunication[1] is a powerful tool for theconstructionof fault-tolerantapplications,providing reliablemulticastandmembershipserviceswith strongsemantics.In this paper, weincorporateMultimedia Multicast TransportServicethat supportsmultiple quality of serviceoptionswithin theframeworkof groupcommunicationssystems.Thisway, asingleapplicationcanexploit multiplequalityserviceoptions,andcanalsobenefitfrom thegroupcommunicationsemantics.

2.0 Intr oduction

In this paperwe presenta novel communicationparadigmthat provides multiple quality ofservice(QoS)optionsfor multimediaandComputerSupportedCooperativeWork (CSCW)[18]applications,e.g. video conferencing.The MultimediaMulticast TransportService(MMTS)consistsof multiple QoSoptionsincorporatedin the groupcommunicationframework. TheMMTS extendsgroupcommunicationsystems(GCSs)thatprovide reliablemulticastservices

�Thiswork wassupportedby Ministry of Scienceof Israel,grantnumber032-7658�

Email: ������� ������ ���������� ����� �� � ���"!$#�%�&'�(��) �*�+(,) ����) ��Url: �-.-/1032�2�454546)3�(��) �*�+(,)3����) ��"2 �879���.�� ������37:��������;�379"� "�. 1�37'������!<#�%

with strongorder constraintsas well as group membershipservices. The MMTS allows tomulticasta bunchof messageswith a specificQoSoption,independentlyof messagesthatarenot part of thebunch. Eachmessagebunchis transmittedwith the QoSguaranteesrequestedfor this bunch,asfastasthis QoSallows. Strongerordersemanticsarepreservedfor theentirebunchandnot for singlemessagesin it. This allows usto selectively imposeorderguaranteesrelative to a subsetof themessages,independentlyof othermessages.

Our approachis mostsuitablefor applicationsthat requirehigh bandwidthfastmulticast,with differentQoSrequirementsfor differentmessages,e.g. wheremostof the multicasthasweak order and reliability constraints,but for a small portion of “critical” messagesrelia-bility andstrongorderconstraintsarevital. For example,negotiation and re-negotiation ofQoS[14, 13] is a majorchallengein thedesignof videomulticastapplications;it requiresallthecommunicatingpartiesto agreeon certainQoSparameters,adjustedto actualcapabilitiesof thecommunicatingparties.Thestrongsemanticsandthereliableorderedmulticastprovidedby theGCSfor the“critical” messagesprovidesa simpleandefficientsolutionfor QoSnegoti-ation.Furthermore,it canmaketheservicefault-tolerant,withoutslowing down themassof themessages.GCSmembershipservicesallow thesystemto smoothlyreconfigurewhenpartiesjoin or leave.

Fig. 1 A New PartyJoiningaVideoConference

Typicalapplicationsthatmaybenefitfrom theconceptpresentedin thispaperincludevideoconferencing,videomulticast(payTV), replicatedvideoon demandservers,cooperative net-work management,andmany more.Fig. 1 depictsavideoconferencingapplication,with anewpartywishing to join thediscussion.In Section6.0 we describeseveral examplesof applica-tionsthatcanbenefitfrom ourservicesamongwhich is amultimediaanddesktopconferencingapplication[18].

2.1 The Benefitsof Group Communication

Groupcommunicationsystems(GCSs)arepowerful toolsfor thedevelopmentof fault-tolerantdistributedapplicationsandfor CSCWgroupwareandmultimediaapplications.GCSsprovidethe applicationbuilder with reliablemulticastserviceswith several usefulmessageorderingparadigms,e.g. totally ordered= multicastgreatlyfacilitatescoordinationandQoSnegotiationin video applications. GCSsalso provide group membershipservicesthat guaranteestrongsemantics,which areuseful for the constructionof fault tolerantapplications. Someof theleadingGCSstodayare: Transis,Totem, ISIS, Horus,Psync,Relacs,RMP, andNewtop; Asurvey of GCSsmaybefoundin [1].

GCSsintroducethe notion of the group abstraction that allows the applicationbuilder totreatmultiple communicatingpartiesasa singleconnection.Membersmay dynamicallyjoinandleave thegroup(i.e. subscribeandunsubscribeto theconnection).Thegroupabstractionallows for smoothreconfigurationof discussiongroups:a processthatsendsmessagesto thegroup doesnot needto keeptrack of the changesin its membership.A multicastgroup isidentifiedby the logical nameassignedto it whenthegroupis created.Eachmessagetargetedto the group’s logical nameis guaranteedto be deliveredto all the currentlyconnectedandoperationalgroup’s members.The groupabstractionmay alsobe exploited for reducingthetransmissionratefor slow receiversby multicastingthevideoconcurrentlyto differentgroupsfor receiverswith differentQoScapabilities[7]. Receiverscandynamicallyswitchfrom groupto group,accordingto the bandwidththey have available. Anotherapproachto reducingthebandwidthfor slow receiversis basedonfiltering [14]: thevideoframesaremulticastto severaltargetgroups,onegroupreceivesaself-containedlow bandwidth(andhencelow quality)videofilm, all thereceiverssubscribeto this group. Incrementframesthatimprove thevideoqualityaremulticastto theothergroups.Receiverswith higherprocessingcapabilitiessubscribeto oneor morethesegroups,andthusimprove thequalityof thevideothey receive,accordingto theircapabilities.

Othermultimediatransportservices,e.g. ACCOPI[13] alsousegroupabstractionfor mul-timediamulticast,but they usuallysupportonly >@?5A B logical topologies(onesender, manyreceivers). This is justified becausecomplex connectionsin the transportservicecomplicatethedesignof thetransportprotocol.However, usinga GCSarbitraryconnectiontopologiesaresimpleandefficient to implement.This allows to provide eachapplicationwith the topologymostsuitablefor its needs.

2.2 Curr ently, GCS is Problematic

In spiteof theirstrengths,GCSsarerarelyusedfor applicationsthatutilize highthroughputfastmulticast,andrequirereliability for only a smallportionof their multicasts.Many multimediaapplicationsarein this category. For example,in videomulticastapplications,reliability andordersemanticsarerequiredfor coordinationandfor QoSnegotiationmessages,but not for thevideotransmission.

Suchapplicationsdo not useGCSsbecausethey requireQoSthat is not provided by theGCS.Strongsemantics,orderandreliability guaranteessignificantlyslow down theapplicationwhich is adequatelysupportedby a “mostly reliable” multicast. Most GCSsprovide only re-liable multicastservices.Reliability requiresmessagebuffering, managingacknowledgmentsfor messagesandretransmissions;Thusmessagedelivery is delayed,especiallywhenmessages

CTotally orderedmulticastis alsocalledatomicmulticast.

arelost. Orderconstraintsfurtherincreasethedelay. Consequently, smallerbandwidthis avail-able.This cannegatively affect theapplicationif, for example,theATM constantbit rateQoSis requested.Furthermore,thenotionof reliability for a videoapplicationis ironically differ-entthantheGCSnotionof reliability: videodecodingalgorithmsmakeassumptionsregardingstochasticnetworkbandwidthvariability. Theintroduceddelaysmayviolatetheseassumptions,renderingthedecodingalgorithmincorrect.

SomeGCSsprovide unorderedandunreliablemulticastservicesthatpreserve theunderly-ing networkproperties.However, suchanapproachis inadequatefor theapplicationsmentionedabove. Thisapproachsuffersfrom onemaindrawback:There’snopossibilityto selectively en-forceorderguaranteesrelative to a subsetof the messages,independentlyof othermessages.Thus, with a GCS,a messageis eitherdelayedby all messageswith strongerorderingcon-straints,or, alternatively, is deliveredindependentlyof all othermessages.

Often,neithersolutionis appropriate:e.g. in a typicalmultimediaapplication,severaltypesof datastreams(e.g. video,audio,translationsubtitles)areeachmulticastindependently[20],asshown in Fig. 2, andaresynchronizedat thereceiving server. Orderingconstraintsmustbepreserved within eachstream,but messagesfrom differentstreamsshouldnot interferewitheachother. Anotherexampleis video transmission:an MPEG-encodedvideo consistsof afew full imageswhich mustbereliably delivered[19], followedby incrementalupdateframeswhich canbe sentunreliably. The incrementalupdateframesmust follow the correspondingfull pictureframeonly, andhave norestrictionsw.r.t. othermessages.

time

D D D D DD D D D DD D D D DD D D D DE E E E E EE E E E E EE E E E E EE E E E E E

F F F F FF F F F FF F F F FF F F F FG G G G G GG G G G G GG G G G G GG G G G G G

H H H H HH H H H HH H H H HH H H H H

I I I I I I II I I I I I II I I I I I IJ J J J J J J JJ J J J J J J JJ J J J J J J J

K K K K K K K KK K K K K K K KK K K K K K K K

L L L L L L LL L L L L L LL L L L L L LM M M M M M M MM M M M M M M MM M M M M M M M

N N N N N N N NN N N N N N N NN N N N N N N N

O O O O O O O O O O O O O OO O O O O O O O O O O O O OO O O O O O O O O O O O O O

P P PP P PP P P

Q Q QQ Q QQ Q Q

R R R R R R R R R RR R R R R R R R R RR R R R R R R R R R

Videostream

Audio−left stream

Audio−right stream

Textstream

Fig. 2 DataStreamsin aMultimediaApplication

2.3 Multimedia Multicast Transport ServicewithinGroup Communication Systems

We incorporatea MultimediaMulticastTransportService(MMTS) thatprovidesseveralQoSoptions into the group communicationframework. The basicobject in MMTS is a bunch.A bunchis a containerobject that consistsof messages.All the messagesin the buncharemulticastby the samesource,have the samemulticastgroupof targetsandobey to the sameQoSrequirementsassignedto thebunch.A bunchmaydirectlyprovidetheunderlyingnetworkproperties,e.g. theconstantbit rateQoSof ATM. Alternatively, messageswithin a bunchmaybe recoveredto provide reliablemulticast. A bunchmay beunorderedor FIFO ordermay beenforced.The messageswithin a bunchneitherinterferewith messagesfrom otherbunches,norwith othermessagesmulticastvia theGCS.

TheGCSservesasa coordinationobjectfor coordinatingdifferentinstancesof thebunchobject. The coordinationobject (GCS) interactsonly with the bunchobjectas a whole and

doesnot interactwith individual bunchmessages.Eachbunchis “wrapped”with a shell thatis multicastvia thereliableservicesof theGCS,andthussemanticsareprovidedfor theentirebunch,asif it wereasinglemessage(or two messages:begin andend). Thiswaytheapplicationmaybenefitfrom thepowerful semanticsof membershipservice,andorderguaranteesmaybeenforcedamongbunchesandregularreliablemessages.Themessageswithin thebunchesaretransmittedindependentlyof theregularmessageflow in theGCS.

The challengewasto provide thesesemanticswithout imposinga high overheadon mes-sageswithin bunches,sothattheoverall performancewill notbedegradedbecauseof thesup-port for coordination.Messagesareonly delayedwithin a buncheitherdueto an applicationrequestto ordertheentiremessagebunchrelative to othermessagesor becauseof othermes-sagesin the samebunch, due to the reliability or order constraintof the particularbunch’sQoS.In otherwords,thesystemimposestheminimumdelayneededto enforceonly theorderconstraintsexplicitly requestedby theapplication.

TheintegrationbetweenthegroupcommunicationandMMTS thefollowing advantages:S A singleapplicationcanexploit assortedQoSoptions.

S Applicationscanbemadefault tolerantusingpowerful groupcommunicationsemantics.Thesesemanticshold for thebunchasawhole,not for specificmessageswithin abunch.This is usuallywhattheapplicationrequires.

S The entirebunchis orderedwith respectto reliablemessagesandotherbunches.Thisfeatureis usefulfor CSCWapplications.

S TheGCSprovidessupportfor dynamicreconfiguration.This allowscooperatingpartiesto freely join/leave multicastgroupsandthereforeoffersa goodabstractionfor CSCWgroupwareapplications.

S Reliable“critical” messagesmaybeusedfor coordinationandcheckpointing,e.g. QoSnegotiationandre-negotiation.

Theobject-orienteddesignof oursystemhasthefollowingadvantages:First,animplemen-tationof a specificQoSis encapsulatedin thecorrespondingbunchobjectandhiddenfrom thecoordinationobject.This allows thecoordinationobjectto manipulatedifferentbunchobjectsin thegenericway accordingto theapplicationdefinedcoordinationpolicy. Second,theappli-cationbuilder caneasilycombinedifferentQoSoptionsto form theQoSmixturedesirablefortheapplication.Finally, new QoSoptionscanbesmoothlyintegratedinto thesystem.

3.0 The Envir onmentand Model

A setof processescommunicateover the network. The systemis asynchronous:thereis noboundon relativeprocessspeedsor messagedelay.

We considerthefollowing typesof failures:Processesmaycrashandrecover. Thenetworkmaypartitioninto several componentsT , andremerge. A messagemaybelost by all membersof a component,or only by partof them.Thenetworkmayduplicatemessages,andit providesno messagesequencingguarantees.We assumethat failuresare detectedusing a (possiblyunreliable)fault detector, e.g. a timeoutmechanism.U

A componentis sometimescalleda partition . In our terminology, a partitionsplitsthenetworkinto severalcomponents.

3.1 Multicast Services

Thebasicoperationin a multicastservice,is to postamessageto a setof processes.A processmaysenda messageto any subsetof theprocesses.Themulticastservicedeliversthemessageto its multiple targets. Multicast servicesarecharacterizedby two properties:reliability andorderconstraints.

Reliability A multicastserviceis reliable if it delivers eachmessageexactly onceto eachof its currentlyoperationalandconnectedtargetsV , overcomingmessageomissionandduplication.Otherwisetheserviceis unreliable.

Order constraints Thereexist variouslevelsof constraintson theorderof messagedelivery.Typical examplesof orderconstraintsare:

None – noorderconstraints.

FIFO messagesfrom asinglesourcearedeliveredin theorderof their transmission.

Causal messagesaredeliveredin an orderpreservingthe “happenedbefore” (causal)partialorderdefinedby Lamport[12]. Thecausalorderis definedasthetransitiveclosureof: W XZY([]\;^?_A Wa` if b�c�d;eZfgc�h<i�j(Wlk'Anm$c�opbqi�j(Wa`�k or if m$c�opbpi�j(Wlk'A m<c�opbri�j(Wa`�k .

Totally Ordered (Atomic) messagesaredeliveredin thesameorderat all targets.Thisorderpreservesthecausalpartialorder.

Orderconstraintscausea delay in messagedelivery: e.g. if a processsendstwo reliableFIFO messagesW = and W T , and W = is lost, thedeliveryof W T will bedelayeduntil therecoveryof W = . Moreover, messagesmaybefurtherdelayedby strongerorderconstraintsof precedingmessages.

3.2 Group Multicast and Membership

Group communicationsystemsprovide several levels of reliable multicastservices,as wellasgroupmembershipservices.A group communicationsystem(GCS)supportsreliablemul-ticast communicationamonggroupsof processes. The basiccommunicationprimitive is topost(send) a messageto a group. TheGCSmulticaststhemessageover thenetworkto otherinstancesof the GCS.The instancesof the GCSreceive the messagefrom the network,anddeliver themessageto all themembersof thegroup.

After a group is created,the group undergoesmembershipchangeswhen new membersareaddedto the groupandwhenmembersaretakenout of the group. The membershipser-vice of theGCSreportsthesechangesto theapplicationthroughspecialmembershipchangemessages,thatcontaina uniquemembershipidentifieranda list of connectedprocesses.Mem-bershipchangemessagesaredeliveredamongthestreamof regular messages.Thus,duringtheexecutionof an application,theGCSdeliversto it a sequenceof regularmessagesinterposedby membershipchangemessages.

The taskof the GCSis to simulateto the applicationan environmentin which messagedelivery is reliable within the set of reachable(live and connected)processes,and give the

sReliablemulticastis sometimesdefinedto guaranteedelivery at all correct targets. This definition is not

appropriatefor systemsthat toleratenetworkpartitions,wheretwo processesmaybedisconnected,andyet botharecorrect. In this paperwe requiredelivery at connectedtargetsonly. This reliability guaranteeis sometimescalledatomic.

applicationan indicationwhich processesarereachableat any given time. The Virtual Syn-chrony [6], StrongVirtual Synchrony [9] andExtendedVirtual Synchrony [16] modelsprovidepowerful semantics,that greatlyfacilitateapplicationdesign[6, 2, 10, 3]. For example,theyguaranteethatif two processest and u deliver thesametwo consecutive membershipchangesv

= ,v

T , then for every messageW that t delivers betweenv

= andv

T , u also delivers Wbetween

v= and

vT .

GCSstodayhave begun to exploit new technologies,and to run over fast networkse.g.ATM [5] in WAN environments.

4.0 Multimedia Multicast Transport Service (MMTS)

Weproposeto incorporateMultimediaMulticastTransportService(MMTS)into groupcommu-nicationsystems(GCSs)thatprovidereliablemulticast.TheGCSis extendedwith MultimediaMulticastTransportServiceproviding QoSmulticast.

ThebasicMMTS objectis abunch. A bunchis acontainerobjectthatconsistsof messages.Themessageswithin a specificMMTS bunchneitherinterleave nor interferewith the regularflow of messagesin theGCSor in otherbunches,andthereforearenot delayedby them. Thewholebunchis orderedrelativeto reliablemessagesandotherbunches.Theapplicationbuilderdefinesthe inter-bunchcoordinationpolicy in termsof thegeneralbunchobject. EachbunchobjectimplementingaspecificQoStypeinheritsfrom this object.

A messagebunch is “wrapped” with two reliablemessages:begin-bunch andend-bunchthat aremulticastvia the GCS.The applicationbuilder chooseswhich of the variousreliablemulticastservicesprovided by the GCSto usefor thesemessages,in orderto guaranteetheorderconstraintsrequiredfor his application.Thestructureof GCSwith MMTS is depictedinFig. 3.

w w w ww w w ww w w w w w w ww w w ww w w w w w w ww w w ww w w w w w w ww w w ww w w w w w w ww w w ww w w w w w w ww w w ww w w w w ww ww wx x x xx x x x x x x xx x x x x x x xx x x x x x x xx x x x x x x xx x x x x x x xx x x x x xx xy y y yy y y yy y y y y y y yy y y yy y y y y y y yy y y yy y y y y y y yy y y yy y y y y y y yy y y yy y y y y y y yy y y yy y y y y yy yy y

z z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z zz z z z

z zz zz zz zz zz zz zz zz zz z{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {{ { { {

| } ~ � � �} � �QoS send

Reliable send

Active Bunches

Applicationbunchcontrol

GCS

Fig. 3 TheMMTS Structure

Notation: For bunch � we denotebyv��

the setof messagessentvia the bunch � , by � �thesenderof

v��. begin-bunch

�andend-bunch

�arethecorrespondingbegin-bunch andend-

bunch messages.

4.1 QoSMulticast BunchesTypesand Structur es

A QoSbunchis characterizedby thefollowingparameters:theorderinglevel of its shell(begin-bunch andend-bunch messages)andtheQoSrequirementsof themessageswithin thebunch.Messagesbelongingto thesamebuncharedeliveredbeforethe end-bunch messageandafterthebegin-bunch message,andall have thesameQoSconstraints.A bunchis labeledaccordingto theconstraintson messageswithin thebunch.Thefollowing areexamplesof QoStypesfora bunch � :

UnreliableUnordered The unreliableunorderedQoSbunchpreserves the propertiesof theunderlyingnetwork.thenetwork.

UnreliableFIFO For any W =�� W T@�v��

suchthat W = wassentbefore W T : if bothmessagesaredeliveredthen W = is deliveredbeforeW T .

ReliableUnordered All themessagesinv �

areguaranteedto bedeliveredexactly once.Noorderingconstraintsareguaranteedfor any messagein

v��.

ReliableFIFO All the messagesinv �

areguaranteedto be deliveredexactly onceandtheFIFO deliveryorderis preserved.

Prioritized Bunch implementsamorecomplex QoStype,especiallydesignedfor videotrans-mission[11]. Thisserviceis basedonthecyclic-UDP[22] protocol,whichisabest-effortpriority-drivennetworkprotocol. Theprioritizedbunchis unreliable, but it doesusere-transmissionsin orderto increasethe probability of successfuldelivery. The messageswithin thebuncharesortedaccordingto theirpriority: thefirst multicastmessagehasthehighestpriority, andthelastmessage– thelowest.Theprobabilityof successfuldeliveryof a messageis proportionalto its priority.

TheMMTS allowstheapplicationwriter notonly to easilyincorporatenew QoStypesintothe systembut also to alter the bunch’s structurein order to createmore sophisticatedQoStypes. For instance,interestingQoStypescanbecreatedif nestingof bunchesis supported.Unreliableandprioritizedbunchesmaybenestedwithin reliablebunches:thebegin-bunch andend-bunch of the inner buncharedeliveredasreliablemessageswithin the outerbunch,andnot via the GCS(seeFig. 4). This allows order constraintsto be enforcedamongbuncheswithout introducingredundantconstraints,andthusincreasestheliberty to selectively chooseorderdependencies.

reliable fifo bunch

unreliable bunch prioritized bunch

begin beginend end

Fig. 4 Nestingof Bunches

For example,anMPEGvideoserver multicastspictureframes,eachfollowedby unreliableincrementalupdateframes. The pictureframesdelivery mustbe FIFO andreliable,while the

incrementframesmay be unreliable,andareorderedw.r.t. the precedingpictureframe. Pic-ture framescanbe multicastvia a reliableFIFO bunch,andincrements– in nestedunreliablebunches.This implementationimposestheorderrelationshipbetweenpicturesandincrements,andimposesno orderconstraintsw.r.t. othermessagesor bunches.Videorepresentationlan-guages(e.g. Rivl [21]) canbenaturallyextendedto “compile” into this form of representation,for videotransmission.

4.2 MMTS in Presenceof Membership Changes

The membershipmessagesof the GCShave an importantrole in providing strongsemanticssuchasvirtual synchrony. Thesesemanticsrestrict the orderof membershipmessagesw.r.t.regularmessages.MMTS providesthesesemanticsfor theentirebunch,andnot for particularmessageswithin thebunch.This is usuallywhattheapplicationrequires.

Whenever amembershipchangeoccursthefollowing situationsarepossiblefor bunch � :

S Someprocesst disconnectsfrom � � beforeend-bunch�

is received. In this case,tdeliversa specialbroken-bunch

�notification,indicatingthatsomemessagesin

v��are

unrecoverablylost. Thebroken-bunch�

messageautomaticallyforces� to beclosed.

S Someprocesst proceedstogetherwith � � . In this case,� � continuesto multicastand tcontinuesto deliver � ’smessages.

S Somenew processt joins � � . In this case,t deliversa specialjoin-bunch�

notification,andfollowing it deliverstheremainderof

v��.

5.0 MMTS Incorporation in Transisand Horus

We now presenttheincorporationof MMTS in theTransisandHorus[1] GCSs.MMTS couldbesimilarly incorporatedinto otherGCSs.

The main datastructureof the TransisGCSis a directedacyclic graph,DAG, basedonTrans[15] andonPsync[17]. Thenodesin theDAG representmessages,andthearcsrepresentacknowledgments.The DAG is usedto provide variousreliablemulticastservices. We ex-tendtheDAG datastructureof Transisto incorporateMultimediaMulticastTransportService.The begin-bunch andend-bunch messagesaremulticastusingthe DAG. The regular bunch’smessagesarepassed“in the background”anddo not intervenewith the regular flow of mes-sagesin theDAG. Intuitively, thismechanismresemblesa three-dimensionalDAG, asdepictedin Fig. 5(a). The TransisDAG delivers GCS messagesin one dimension,and the bunch’smessagesaredeliveredin anotherdimension,after thecorrespondingbegin-bunch messageisdeliveredandbeforetheend-bunch messageis delivered.

TheHorussystemhasa layeredstructure.Eachtypeof multicastserviceis implementedasa separatelayer, stackedon topof weakerservicelayers.MMTS maybeeasilyincorporatedinHorus.Theserviceopensseveralconnectionsto Horusasdepictedin Figure5(b):

S Onereliableconnectionstackedon top of variousreliableservicelayersanda member-ship layer. MMTS multicastsregularmessages(thatarenot part of any bunch)via thisconnection.This connectionis alsousedfor begin-bunch andend-bunch messages,andfor gettinganindicationof themembership.Thisguaranteesvirtual synchrony semanticsof entirebunchesw.r.t. otherbunches,regularmessages,andmembershipchanges.

� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � � � � � �

t i m e

begin−bunch

end−bunch

(a)TheMMTS 3-D DAG in Transis

C A U S A L

TOTAL

� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �

COM

COM

NACK

FRAG

MBRSHIP

S T A B L E

FC

� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �

NACK

FRAG

STABLE

FC

� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �

COM

NACK

FRAG

STABLE

FC

� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �� � � � � �

COM

M M T S

...

Horus connections

Re

liab

le m

ulti

cast

Un

relia

ble

bu

nch

es

Reliable bunches

N e t w o r k

MBRSHIP MBRSHIP

(b) MMTS in Horus

Fig. 5 MMTS Incorporationin GroupCommunicationSystems

S Oneunreliableunorderedconnection(bypassingall reliablelayers),for unreliablebunches.

S A separatereliableconnectionfor eachreliablebunch.

TheMMTS serviceneedsonly takecareof orderingbunchmessagesw.r.t. thecorrespond-ing begin-bunch andend-bunch messages.

6.0 Applications

In thispaper, wepresentedthenotionof MultimediaMulticastTransportService(MMTS) thatsupportsmultiple quality of serviceoptions(QoS)in groupcommunicationsystems(GCSs).Below wedescribea few applicationsthatmayexploit MMTS within GCSs.

Video multicastapplicationare concernedwith more than just multicastinga streamofvideo. Suchapplicationalsoneedto exchangemessagesfor connectionestablishment,flowcontrol andnegotiationandre-negotiationof QoS(agreementon QoSparameters).Further-more,it is desirableto introducereplicationin orderto makesuchapplicationsmoreavailableandfault tolerant.Replicationarisestheneedfor loadbalancing,andin orderto achieve faulttolerance,theserversmustconsistentlyshareinformation. In our approach,thevideo is mul-ticastin QoSbunches,andtheothertasks(e.g. QoSnegotiation,loadbalancingandconsistentinformationsharing)exploit theGCSservices.

Wearecurrentlyimplementingareplicatedvideoondemandserver[4], thatexploitsMMTSQoSbunchesto transmitvideo.If oneservercrashesor detachesfrom aclient,theotherserversget an indication,andcansmoothlytakeover. The groupabstractionis usedto guaranteeatransparenttransition: the client continuesto sendits requestto the samelogical connection(representedby a GCSgroup),andis unawareof thechangein server behindthis connection.Thegroupabstractiontogetherwith theGCStotally orderedmulticastserviceareusedfor loadbalancing:eachclient requestis multicastto thegroupof servers,andtheserversdeterministi-cally decidewhichof themwill serve theclient.

Multimediaand desktopconferencingsystemsaredescribedin the survey of CSCWsys-tems[18]. Sucha systemconsistsof severalconferees(users),thatcooperatively usea varietyof applicationsuchasa meetingroom(videoandaudio),sharedwork space(e.g. cooperativeeditingor drawing on a board),etc. Theconferenceagentcontrolsthecommunicationamong

theconfereesandtheapplications.Thedistributedagentcanexploit GCSwith MMTS to pro-videtheserviceslistedin [18], e.g. floorcontrol,dynamicreconfiguration,consistentworkspacereplicationandmanagement,andloggingthesession.In thefull paper[8] wediscusstheseser-vicesin moredetail.

7.0 Concluding Remarks

Theperformanceof anMMTS applicationgreatlydependson thesizeof thebunches,andonthe mixture of differentQoSoptions,aswell ason the propertiesof the underlyingnetwork.Thereis a tradeoff in determiningthe ideal bunchsize: if bunchesaresmall the overheadofhandlingbegin-bunch andend-bunch messagesis high. On theotherhand,largebunchesarelessfault tolerant:failuresmaycauselossof synchronization,andapplicationsre-synchronizeat the endof bunches.The longerthe bunch, the longer it takesto re-synchronize.It is ourhopethatfurtherwork on this topic will identify bunchsizesthatinducelow overheadandyetprovidereasonablequalityof servicefor specificapplications.

8.0 Acknowledgments

We arethankful to Ken Birman for his helpful commentsandsuggestions.SpecialthankstoTal Anker, David Breitgand,ZoharLevy andtheothermembersof theTransisprojectfor theirvaluableremarks.

9.0 References

[1] Communicationsof the ACM 39(4), special issueon Group CommunicationsSystems,April 1996.

[2] Y. Amir, D. Breitgand,G. Chockler, andD. Dolev. GroupCommunicationasan Infras-tructurefor DistributedSystemManagement.In InternationalWorkshopon ServicesinDistributedandNetworkedEnvironment, number3, pages84–91,June1996.

[3] Y. Amir, D. Dolev, P. M. Melliar-Smith,andL. E.Moser. RobustandEfficientReplicationusingGroupCommunication.TechnicalReportCS94-20,Instituteof ComputerScience,TheHebrew Universityof Jerusalem,Jerusalem,Israel,1994.

[4] T. Anker, D. Breitgand,G. Chockler, D. Dolev, andI. Keidar. ReliableVideoMulticastServices.In preparation.

[5] T. Anker, D. Breitgand,D. Dolev, andZ. Levy. TheWAN accordingto GARP. In prepa-ration.

[6] K. BirmanandT. Joseph.ExploitingVirtual Synchrony in DistributedSystems.In Symp.OperatingSystemsPrinciples, number11,pages123–138.ACM, Nov 87.

[7] S. Y. Cheung,M. H. Ammar, and X. Li. On the Use of DestinationSet GroupingtoImprove Fairnessin Multicast Video Distribution. In 15th InternationalConferenceonComputerCommunication(Infocom’96), March1996.

[8] G.Chockler, N. Huleihel,I. Keidar, andD. Dolev. SupportingMultiple Qualityof ServiceOptionswith High PerformanceGroupware.TR 96-3,Instituteof ComputerScience,TheHebrew Universityof Jerusalem,March1996.

[9] R. FriedmanandR. V. Renesse.StrongandWeakVirtual Synchrony in Horus. TR 95-1537,dept.of ComputerScience,CornellUniversity, August1995.

[10] I. KeidarandD. Dolev. EfficientMessageOrderingin DynamicNetworks.In ACM Symp.onPrin. of DistributedComputing(PODC), pages68–76,May 1996.

[11] D. Kozen,Y. Minsky, andB. Smith.EfficientAlgorithmsfor OptimalVideoTransmission.TR 95-1517,ComputerScienceDepartment,CornellUniversity, May 1995.

[12] L. Lamport.Time,Clocks,andtheOrderingof Eventsin a DistributedSystem.Commu-nicationsof theACM, 21(7):558–565,July78.

[13] L. Mathy. Featuresof theACCOPIMultimediaTransportService.In EuropeanWorkshoponInteractiveDistributedMultimediaSystemsandServices(IDMS),(LNCS,1045), pages175–194,1996.

[14] L. MathyandO. Bonaventure.QoSNegotiationfor MulticastCommunications.In Multi-mediaTransportandTeleservices,InternationalCOST237Workshop,(LNCS,882), pages199–218,November1994.

[15] P. M. Melliar-Smith,L. E. Moser, andV. Agrawala. BroadcastProtocolsfor DistributedSystems.IEEETrans.Parallel & DistributedSyst., (1), Jan1990.

[16] L. E. Moser, Y. Amir, P. M. Melliar-Smith,andD. A. Agarwal. ExtendedVirtual Syn-chrony. In InternationalConferenceon DistributedComputingSystems, number14th,June1994.

[17] L. L. Peterson,N. C. Buchholz,andR. D. Schlichting. PreservingandUsing ContextInformationin InterprocessCommunication.ACM Trans.Comput.Syst., 7(3):217–246,August89.

[18] T. Rodden.A survey of CSCWsystems.Interactingwith Computers, 3(3):319–353,1991.

[19] L. A. Rowe,K. D. Patel,B. C. Smith,andK. Liu. MPEGVideoin Software:Representa-tion,Transmission,andPlayback.In High SpeedNetworkingandMultimediaComputing,IS&T/SPIESymp.onElec.ImagingSci.& Tech., February1994.

[20] L. A. Rowe andB. C. Smith. A ContinousMediaPlayer. In Int. Workshopon NetworkandOSSupportfor Digital AudioandVideo, number3, November1992.

[21] B. C. Smith. RIVL: A ResolutionIndependantVideoLanguage.

[22] B. C. Smith. ImplementationTechniquesfor ContinousMediaSystemsandApplications.PhDthesis,Universityof Californiaat Berkeley, 1994.