repositorytvants官网

IEEECommunicationsMagazineJune20111540163-6804/11/$25.
002011IEEE1NAPA-WINE(http://napa-wine.
eu)isathree-yearSTREPprojectstartedonFebruary1,2008andsupportedbytheEuropeanCommissionwithinFrameworkPro-gramme7(ICTCall1FP7-ICT-2007-1,1.
5Net-workedMedia,grantNo.
214412).
Thisarticlereflectsitsevolutionafterabouttwoyears.
INTRODUCTIONPeer-to-Peer(P2P)technologyhasbeenrecentlyexploitedtooffervideoserviceoverIP(P2P-TV),asforexampledonebyPPLive,SopCast,TVAnts,CoolStreming/UUSee,andTVUplayer,tonameafewcommercialsystems.
Recently,theinterestoftheresearchcommunityhasstartedtorisethankstotheopportunitiesP2P-TVsystemsoffer[1].
InthiscontextNAPA-WINE(NetworkAwarePeer-to-peerApplicationoverWIseNEt-work),athree-yearproject(STREP)withinthe7-thResearchFrameworkoftheEuropeanCommission,focusesonimprovingtheperfor-manceofP2Plivestreamingdistribution,whileprotectingnetworkresourcesfromexcessiveusage.
InatraditionalP2P-TVsystem,avideosourcechopsthevideostreamintochunksofdata,whicharethenexchangedamongnodesdistributingthemtoallparticipatingpeers.
Peersformanoverlaytopologyattheapplicationlayer,whereneighborpeersareconnectedbyvirtuallinks,overwhichchunksareexchangedusingtheunderlyingIPnetwork.
Twonetwork-inglayerscanbeidentified:theoverlaylayerinwhichpeersexchangecontent,andtheIPlayerinwhichroutersandlinkstransferthepackets.
ThemaingoalofNAPA-WINEisthestudyofnovelPeer-to-PeerarchitecturesandsystemssuitableforHighQualityTVlivestreamingovertheInternet:aP2P-HQTVsystem[2].
NAPA-WINEfocusesonovercomingthelimitationsoftoday'sapproaches,wherethetwolayersarecompletelyindependentandattimesantago-nists.
Instead,weenvisionacooperativeparadigminwhichtheapplicationandnetworklayersinteroperatetooptimizetheserviceofferedtoendusers,asdepictedinFig.
1.
Webelievethatanapproachwheretheover-layandtheIPnetworksignoreeachother,whileacceptableforelasticapplicationsorlow-band-widthstreamingapplications,maycauseintoler-ableperformancedegradationsforhigh-qualityreal-time(evenforsoftreal-time)applicationssuchasP2P-TV.
Ifthenetworkbecomesheavilycongested,theapplicationwillneverbeabletomeetitsminimumrequirements.
Asaconse-quence,theonlysuccessfulparadigmforalargescaleP2P-TVarchitectureisacooperativeparadigm,wherethenetworkandtheapplica-tionjoinforcestomeetthequalityofservicerequirements,andtoreachthelargestpossiblepopulationofusers.
Finally,thereisanadditionalincentivetosuchcooperation.
IntraditionalP2Psystems,onlytwomainactorscanbeidentified—thenetworkprovidersandtheapplicationusers—andtheirinterestsareoftenincontrast.
InthecaseofP2PTV,anewmainactorcomesintoplay:thecontentproducer,whoseinterestsaremainlyindistributingitscontentthroughtheInternetinthesafestpossibleway,thusavoidingeverypossibleproblem,eithertechnicalorlegal,whichcouldinduceuserstomigrateaway.
ThisisamajorshiftwithrespecttocurrentP2Pappli-cations,whereusersprovidecontent,ashiftthatoffersfurtherincentivesfornetworkoperatorsABSTRACTPeertoPeerstreaming(P2P-TV)applica-tionshaverecentlyemergedascheapandeffi-cientsolutionstoproviderealtimestreamingservicesovertheInternet.
Forthesakeofsim-plicity,typicalP2P-TVsystemsaredesignedandoptimizedfollowingapurelayeredapproach,thusignoringtheeffectofdesignchoicesontheunderlyingtransportnetwork.
Thissimpleapproach,however,mayconstituteathreatforthenetworkproviders,duetothecongestionthatP2P-TVtrafficcanpotentiallygenerate.
Inthisarticle,wepresentanddiscussthearchitec-tureofaninnovative,networkcooperativeP2P-TVapplicationthatisbeingdesignedanddevelopedwithintheSTREPProjectNAPA-WINE.
1Ourapplicationisexplicitlytargetedtofavorcooperationbetweentheapplicationandthetransportnetworklayer.
ACCEPTEDFROMOPENCALLRobertBirke,EmilioLeonardi,MarcoMellia,DELEN–PolitecnicodiTorinoArpadBakayandTivadarSzemethy,NetvisorLtd.
CsabaKiralyandRenatoLoCigno,DISI–Universit`adiTrentoFabienMathieuandLucaMuscariello,OrangeLabsSaverioNiccoliniandJanSeedorf,NECLaboratoriesEuropeGiuseppeTropea,LightcommSRLArchitectureofaNetwork-AwareP2P-TVApplication:TheNAPA-WINEApproachMELLIALAYOUT5/19/114:03PMPage154IEEECommunicationsMagazineJune2011155tocooperatewiththecontentprovidersandtheuserstosuccessfullydeliverthevideo.
NotethatcooperationbetweennetworkprovidersandP2PapplicationshasalreadybeeninvestigatedinthecontextoffilesharingP2Papplications(seeforexamplethepioneeringworkin[3]),butithasneverbeenappliedinthecontextofP2P-TVsys-temdesignandperformanceevaluation.
Inthiscontext,theNAPA-WINEprojectisproposinganinnovativenetworkcooperativeP2P-TVarchitecturethatexplicitlytargetstheoptimizationofthequalityperceivedbytheuserswhileminimizingtheimpactontheunder-lyingtransportnetwork.
Thefocusisonthestudy,design,anddevelopmentofaP2P-HQTVsystem,inwhichpeerssetupagenericmeshbasedoverlaytopology,overwhichvideochunksareexchangedaccordingtoaswarming-likeapproach.
Asourcepeerproducesthevideostream,chopsitintochunks,andinjectsthemintotheoverlaywherepeerscooperatetodis-tributethem.
ThearchitectureweenvisionisschematicallyrepresentedintheFig1.
AnimportantelementofthecooperativeP2P-HQTVsystemisrepre-sentedbythebuilt-indistributedmonitoringtoolthatallowstheapplicationtocontinuouslygath-errealtimeinformationbothonnetworkcondi-tionsandonusers'perceivedperformance.
Informationcollectedbythemonitoringtoolcanbeusedtotriggerreconfigurationalgorithmsactingbothatthelevelofthechunkdistributionmechanism(scheduling)andattheleveloftheoverlaytopologyreconfiguration.
Inaddition,potentiallyusefulinformationonthesystemstatecanalsobeexportedtothenetwork,sothatitisawareofthestatusoftheP2P-HQTVsystem.
Thearchitectureweproposealsoallowsthenetworklayertoexposeusefulinformationtotheapplicationlayer.
AspursuedbytheIETFintheALTO[6]workinggroupwiththecontribu-tionofNAPA-WINEpartners,thenetworkproviderisgiventhecapabilitytoguidetheP2Papplication,forexamplebyexplicitlypublishinginformationaboutthestatusofitsnetwork,likelinkcongestionorASroutingpreferences.
THEHIGHLEVELARCHITECTUREThissectiondescribesthemainfunctionsandrequirementsofaP2P-TVsystem,proposingthehigh-levelarchitecturefortheNAPA-WINEsys-tem,whoseblockdiagramisdepictedinFig.
2.
USERMODULEThe"usermodule"(topleftblockinFig.
2)implementstheinterfacebetweentheuserandtheapplication.
BesidestheGraphicalUserInterface(GUI),itisresponsibleofvideocodinganddecoding.
Iftheconsideredpeeristhesourcenode,theinputvideosignalhastobeconvertedintoasequenceofchunks,whicharetheatomicunitofdatathatwillbeexchangedintheP2Poverlay.
Dependingonthetypeofvideosource,thismayincludeanalog/digitalconver-sion,encoding,addingforwarderrorcorrection(FEC)information,etc.
Theusermodulesup-portsanyavailableCODECthankstoastandardinterface.
Furthermore,itimplementsaflexiblechunkingmechanismthatcanexplicitlyconsiderthenatureofthevideo,e.
g.
,formingchunksconsideringframeboundariesandtypes.
Whenthepeeractsasareceiveronly,theusermodulereassemblestheaudioandvideostreamfromreceivedchunks,sothat,afterdecodingandresynchronization,thevideocanbedisplayed.
Theusermodulealsorunsvideoqualitymon-itoringalgorithms,constantlymonitoringthequalityofexperiencetheuserisperceiving.
Finally,severalinstancesoftheusermodulecanrunatthesametime,makingitpossibletowatchachannelwhilerecordinganotherone,ormain-tainingpre-viewsofotherchannelswithreducedquality.
SCHEDULERMODULEThe"schedulermodule"(seeFig.
2)isthecoreoftheinformationdistributionengine.
Itisresponsibleforreceivingandsendingchunks,bothfrom/tootherpeersviathenetwork,andto/fromthelocal"usermodules.
"Differentinstancesofthismodulemightrunatthesametime,eachtakingpartinoneoverlayservingonechannel.
Cross-channelinformationdiffusionisunderconsiderationandmayhelptooptimizeserviceandchannelswitching,butisnotunderdevelopmentsofar.
Theschedulermodulehoststhechunkandpeerschedulingalgorithms,whichselectbothwhatshouldbeoffered(orrequested)andto(from)whom.
Thedecisionisbasedondistribut-edinformation:alocaldatabaseofthestatusofotherpeersstoredintheactivepeersdatabase.
Optionsfordesigningtheschedulerandtheimpactonoverallsystemperformancearedetailedlater.
OVERLAYMODULEWerecallthatinunstructuredsystemspeersformagenerichighlymeshtopology,whichguaranteesgoodresiliencetochurnandgreatflexibility.
The"overlaymodule"(top-rightblockinFig.
2)selectsandupdatesthepeerNeighborhood,i.
e.
,thesetofpeersthelocalpeerexchangesinformationwith.
Afairlylargenumberofneigh-boringpeersaremaintainedtoformawellcon-nectedoverlaystructure,aspeersmayleaveanFigure1.
SchematicrepresentationoftheNAPA-WINEapproach.
Nodesatthenetworklayer(L3)andpeersattheapplicationlayer(L7)formthenet-workandoverlaytopology,respectively.
CooperationamongthetwolayersispossiblethankstomonitoringandcontrolcapabilitiesofferedbytheNAPA-WINEarchitecture.
ControlMonitoringL7-applicationoverlayISP1ISP3ISP2L3-IPnetworkMELLIALAYOUT5/19/114:03PMPage155IEEECommunicationsMagazineJune2011156overlayatanytime,e.
g.
,whentheuserswitcheschannel.
Discoveringnewpeersandestablishingconnectionstothem,aswellasforwardinginfor-mationaboutthemtootherpeers,isthetaskoftheoverlaymodule.
Theselectionofpeersmaybebasedontheinformationstoredintherepositories,which,asdetailedlater,storeinformationaboutbothpeersandthetransportnetwork.
Theoverlayandtheschedulermodulesareinterdependent,andforthisreasontheyaredetailedtogetherlater.
MONITORINGMODULEBoththechunkschedulerandtheoverlayman-agercangreatlybenefitfrominformationaboutthequalityoftheconnectivitywithotherpeers.
Thisincludes,butisnotlimitedto,thedistanceandtheavailablebandwidthbetweentwopeers,orthepresenceofNetworkAddressTranslation(NAT).
The"monitoringmodule"(seeFig.
2)gathersthiskindofinformation.
Itbasicallyhastwomodesofoperation:passivemeasurementsareperformedbyobservingthemessagesthatareexchangedanywaybetweentwopeers,e.
g.
,whenexchangingvideochunksorsignalinginfor-mation;activemeasurements,incontrast,craftspecialprobemessageswhicharesenttootherpeersatthediscretionofthemonitoringmod-ule.
ThedesignofthismonitoringmoduleisoneofthemostinnovativegoalsofNAPA-WINEanditwillbedocumentedlaterindetail.
REPOSITORIESANDREPOSITORYCONTROLLER"Repositories"(inthecenterofFig.
2)aredatabaseswhereinformationabouteachpeerissharedwithallotherpeers.
Indeed,theinforma-tiongeneratedbythemonitoringmoduleisnotonlyusefulforthelocalpeer,butalsoforotherpeersthatcanbenefitfromit.
Therefore,mecha-nismsforexchangingmeasurementvalueswithotherpeersareuseful.
Furthermore,itmaybeusefultohaveaccesstoinformationfromenti-tiesthatarenotpartoftheP2Poverlay,suchastheso-called"networkoracles,"throughwhich,forexample,networkproviderscanshareinfor-mationaboutthestatusofthenetwork.
Theinformationacquiredbyeachpeerislocallystoredandreadilyavailable,anditissummarizedandexported(published)tothe(logically)centralrepository.
Thecontentsoftherepository,anddataimportandexport,areman-agedbytherepositorycontroller,whichimple-mentsasetofAPIstopushandfetchinformationfromtherepositorydatabase.
MESSAGINGLAYERThe"messaginglayer"(seeFig.
2)offersprimi-tivestotheothermodulesforsendingandreceivingdatato/fromotherpeers.
Itabstractstheaccesstotransport(UDP/TCP)protocolsandthecorrespondingserviceaccesspointsofferedbytheoperatingsystembyextendingtheircapabilitiesandprovidinganoverlayleveladdressing,i.
e.
,assigningauniqueidentifiertoeachpeer.
Forexample,itprovidestheabilitytosendachunkofdatatoanotherpeer,whichhastobesegmentedandthenreassembledtofitintoUDPsegments.
Themessaginglayeralsopro-videsaninterfacetothemonitoringmodule,whichisusedforpassivemeasurements:whenev-eramessageissentorreceived,anindicationwillbegiventothemonitoringmodule,whichcanthenupdateitsstatistics.
Figure2.
GlobalNAPA-WINEarchitecture.
User,Scheduler,Overlay,Messaging,Monitoring,andReposi-torymodulesarehighlightedusingdifferentcolors.
Arrowsrepresenttherelationshipamongmodules,dis-tinguishingdatapath(gray),signalingpath(black),andinternalcommunication(brown).
N-repP-repAct.
measPas.
measREPcontrollerMessaginglayer+NAT/FWtraversalIPv4/IPv6+UDP/TCP/SCTP/.
.
.
OverlaymoduleMonitoringmoduleTopologycontrollerMonitoringcontrollerNeighborsetE-repActivepeers'infobaseChunktradinglogicBuffermapexch.
&mngContentingestionControlinterfacePlayerUsermoduleSchedulermoduleChunkbufferTheselectionofpeersmaybebasedontheinformationstoredintherepositories,which,asdetailedlater,storeinformationaboutbothpeersandthetransportnetwork.
Theoverlayandtheschedulermodulesareinterdependent.
MELLIALAYOUT5/19/114:03PMPage156IEEECommunicationsMagazineJune2011157AnotherimportantfeatureofthemessaginglayeristhepresenceofmechanismsforthetraversalofNetworkAddressTranslation(NAT)boxes.
NATmakesitpossibletoattachseveralcomputerstotheInternetusingonlyonepublicIPaddress.
Therefore,itisverypopularwithpri-vatecustomers,whoarealsothemaintargetaudienceforP2PTV.
However,thepresenceofaNATdevicemaypreventpeersfromestablish-ingconnectionstootherpeers.
Therefore,spe-cialNATtraversalfunctionsareofferedbythemessaginglayer.
THEMONITORINGMODULEANDREPOSITORIESThemonitoringmoduleisconceivedtocol-lectandshareinformationusefulforthecon-structionandmaintenanceoftheP2Poverlaytopologyandfortheschedulingprocessofvideochunks.
Themainobjectiveistomaintainup-to-dateinformationonthequalityofthepeers'end-to-endpath,andtoinferinforma-tiononthenetwork'savailableresources.
Repositories,bothlocalandglobal,areusedtostoremetrics,estimates,andmeasureddatarequiringadditionalelaboration.
Furthermore,acertainnumberoffunctionsactonthesedatatoproduceup-to-dateestimatesofvariousparametersthatcanbepublishedonglobalrepositoriesthroughaninterfacenamed"RepositoryController.
"Particularcareistakentooptimizeboththecomputationalandthememoryrequirementofthepreviouslymentionedfunctionalities.
Therepositorycon-trollerlimitstheamountofinformationthatisexchangedamongpeersthroughthenetworktoavoidwasteofbandwidth.
Italsoverifiesthatapeercanaccesstheinformationitisrequesting.
Indeed,eachrepositorystoresdatathatcanremainprivateandlocaltothepeer,orinfor-mationthatismadepubliclyavailable.
Thedis-tinctionbetweenpublicandprivateinformationcouldbebasedonsecurityconsiderations,andalsoonitsusefulnessandthecostofitsdissem-ination.
Forexample,theISPcanshareinfor-mationaboutthestatusofitsnetworkonlywithclientsconnectedtoitsnetwork.
Inthefollowing,wedetailthefunctionalitiesimplementedinthemonitoringmodule.
MONITORINGCOMPONENTSMeasurementsareavailableatthechunkandsegmentlevels,i.
e.
,aboveandbelowthemessag-inglayer.
Severalnetworklayermetricscanbemonitored:Delaybetweenpeers(e.
g.
,RoundTripTimes(RTT),DelayJitter).
Lossprobability.
Pathcapacityandavailablebandwidth.
Numberofhopstraversed.
Othermoresophisticatedmeasuresareunderstudy.
Thankstoasimpleandmodulararchitec-ture,measurementscanbeaddedas(compile-time)plugins,andactivatedondemand.
Themonitoringlayerisimplementedateverypeer,andinformationitcollectsismadeavailabletoallthepeers.
Table1summarizesthenetworklayermeasurementsthatarecurrentlyavailableinthemonitoringmodule.
Themonitoringmoduleisbuiltofthreemaincomponents.
ThePassiveMeasurementsComponent(PaM)—ThePaMimplementsthesetofmea-surementfunctionalitiesneededtopassivelymonitorexchangesbetweenpeers.
Thisfunc-Table1.
SummaryofthenetworklayermeasurementavailableintheMonitoringmodule.
IndexAccuracyUsage/CriticalitiesHopCountHighTopologyoptimizationPacketLossHighTriggeringschedulingandtopologyupdateandQoEmonitoringChunkLossHighTriggeringschedulingandtopologyupdateandQoEmonitoringDelayMeasurementsLatency>10msSourceandstreamabsolutetimealignment/clocksynchronizationbelowNTPprecisionishardtoobtainRTT<1msChunkandpeerscheduling/timestampingaccuracylimitsprecisionJitter<1msDelayjittermaybeanindicationofcongestionBandwidthMeasurementsMidtermthroughputHighNeighborhoodselectionandchunk/peerschedulingCapacityLowPacingchunkschedulingforaltruisticpeerstoavoidcloggingaPHYbottleneck(e.
g.
,ADSLlinksbeyondaLAN)AvailablebandwidthLowFundamentaltoavoidcongestioninthenetwork/difficulttoachievehighaccuracyduetocorre-lationsandthelackofefficientalgorithmstoperformthemeasureMELLIALAYOUT5/19/114:03PMPage157IEEECommunicationsMagazineJune2011158tionispassiveasitreliesonpeers'communica-tionstoreduceasmuchaspossibleanyover-head.
Eachmeasureisinitiatedbythesender,andthereceivercooperatestocompleteit,e.
g.
,sendingbackacknowledgmentmessages.
ResultsofeachmeasurementarethenfedtothesenderMonitoringController,whichpossi-blyelaboratesthembeforepushingresultsintheP-REP(Peer-Repository)andN-Rep(Net-work-Repository).
TheActiveMeasurementComponent(AcM)—TheAcMperformsactivemeasurements,i.
e.
,itcaninjectpuremeasurementmessagesanddatathatdonotcarryanyuserinformation.
Thiscomponentpossiblyrunsanumberofdifferentmeasurementprobes,eitherperiodicallyoronrequest.
Forexample,itmaybeinvokedtoesti-matetheend-to-endstatusbetweenthelocalpeerandaremotepeertowhichnochunkisbeingsent.
Therefore,AcMmayalsobeseenasabootstrapfunctionwhenlimitedknowledgeofthepeersandthenetworkisstoredintheP-REP.
Activemeasurementresultsinawasteofbandwidth,andthereforecaremustbetakenwhenactivatingthem.
TheMonitoringController(MON-Con-troller)—TheMON-ControllerisinchargeofmanagingallthemeasurementsperformedbythePaMandtheAcM.
Itimplementsthealgo-rithmstodecidewhentotriggeraparticularmeasurement,andtoprocesstheresultsofeachend-to-endmeasurement.
Forexample,theMON-Controllercanevaluateaverage,standarddeviationandconfidenceintervalsofagivenindex;itcanidentifyandpossiblydiscardwrongsamples,etc.
Consideringtheglobalnetworkknowledge,itissupposedtoimplementthealgo-rithmsthatinferthenetworkstatus,e.
g.
,byimplementingsomenetworktomographyorvir-tualcoordinatesystemsthatarethenstoredintheN-REP.
Itisalsoresponsibletopushlocallycachedmeasurementresultsintothecentralizedrepositorybysummarizingthemtoavoidexces-sivetrafficoverhead.
ThecommunicationoftheMON-ControllerwiththerepositoriesisgrantedbytheRep-Controller.
MONITORINGEXAMPLEFigure3providesasimpleexampleofmeasure-mentsobtainedwiththecurrentimplementationofthemonitoringmodule.
Itshowsthemeasure-mentsoftheCapacityandofAvailableBand-width(topplot),andthemeasurementsofRoundTripTimeandofLossProbability(bot-tomplot).
Acontrolledtestbedhasbeenused,inwhicha10Mb/sEthernetlinkconnectsasourcepeertoareceiverpeer,whileinterferingtrafficisinjected.
Inparticular,a4Mb/sCBRsourceisactivefromtime300sto600s;attime600s,a7Mb/sCBRsourceisactiveuptotime900s.
Thenfromtime1200suptotime1500s,TCPconnectionsarestartedevery60s.
Fromthefigure,itispossibletoobservethevariationofavailablebandwidth,theincreaseoftheRTT,andthelossesinducedbyinterferingtraffic.
REPOSITORIESIntheNAPA-WINEarchitecture,repositoriesareenvisionedasglobaldatabases,containinginformationtoaidpeerselectiondecisions.
Repositoriesarekeyelementsinthedesigntoachievenetworkawareness.
Theyhaveoneadditionalimportantroleinsolvingtheboot-strappingproblemofP2Psystems:namely,uponstartup,apeerneedstoobtainalistofneighborcandidates.
Repositoriesarewellsuitedforthisrole:thepeeronlyneedstohaveaccesstoafewwell-knownrepositoryserversinitsinitialconfig-uration.
Toincreaserepositoryresilience,vari-ousapproaches(suchasdatabasereplicationandDHT-liketechnologies)canbestudied,whichareoutsideoftheNAPA-WINEproto-typedesignscope.
TheNAPA-WINEarchitecturedefinesthreedifferentrepositoriesbasedontheinformationtheycontain.
P-REP:Thepeerrepositoryisadistributedrepositorystoringinformationaboutthepeers'statusandend-to-endmeasurementsperformedbythepeers'monitoringmodules,forinstance,averagebandwidthoverdifferentperiodsoftime,round-triptime,download/uploadsuccessrates,etc.
Eachpeermeasuresandstoreslocallythesequantities,forinstanceasanN*Nmatrix,Nbeingthenumberofneighborpeers(thosediscoveredandselectedbythetopologymanag-er).
Measurescanbeexportedinanaggregatedformtoaglobal(distributedorcentralized)database,theglobalP-REP,forperformancemonitoringandstatisticalanalysis,possiblyincludinginformationonobtainedquality,visit-edchannels,etc.
Acentralizedprototypehasbeendevelopedandisusedtodisplayonaweb-servicetheswarmtopology,itscharacteristics,andhowdifferentarchitecturalchoicesaffecttheP2P-TVapplication.
N-REP:Networkrepositoriesstorenetwork-wideinformationinferredfromP-REPvalues.
TheinformationstoredbyP-REPishardlycom-pleteaboutallpossibleN2peers'end-to-endpaths.
Indeed,eachpeertypicallycollectsmea-surementsoverasubsetofallpeers.
Inparticu-Figure3.
Measurementsobtainedfromthemonitoringmodule.
2[Mbit/s]046810121416[s]200050[ms],[%]10152040060080010001200140016001800RoundtriptimeLossprobabilityCapacityAvailablebandwidthMELLIALAYOUT5/19/114:03PMPage158IEEECommunicationsMagazineJune2011159lar,whenjoiningagivenchannel,thenewpeerhaslittleornoinformationonthestatusofotherpeers,andoftheend-to-endpathcharac-teristics.
Tosolvethisproblem,"virtualcoordi-nate"[4]systemsandnetworktomography[5]havebeenstudiedintheresearchcommunity,whosegoalistomappeerstonodesintoavirtu-alspace,inwhichdistancesamongnodesreflecttheactualdistancesintherealsystem,ortoinfernetworkpropertiesfromasubsetofmea-surements.
Bothmakeitpossible,forexample,to"predict"thequalityofanend-to-endpathwhichhasneverbeentestedinthepast.
TheN-REPstoresresultsgeneratedbythesesys-tems.
Thetopologymanagerusesthisinforma-tiontogetherwithdistributedalgorithmslikeTmantoachievethedesiredtopologicalproper-ties.
E-REP:Theexternalrepositoryisdedicatedtostoringout-of-the-box,semi-staticinformationonthenetwork.
Itisconceivedfornetworkoperatorsthatcanfillitwithnonpublicinfor-mation,e.
g.
,ASgraphandpeeringpoints,therankingofroutingpaths,routingtables,informa-tionontheroutingoptimization,andthenet-worktopology.
Itcanalsostoreintra-domaininformationofoneormultipleASs.
Clearly,accesstothisinformationmustbeprotectedandgrantedonlytoasubsetofpeers,e.
g.
,toonlyclientsintheASoftheISP.
Therefore,theEREPrunsondedicatedequipmentinstalledandmanageddirectlybythenetworkoperatororcontentprovider.
Forexample,intheidealcase,theE-REPstoresthefullknowledgeontheASnetwork;thewholeISPtopologyisthere-foreexposedtotheP2Papplication.
TheE-REPalsohasaninterfaceforcon-nectingtoApplicationLayerTrafficOptimiza-tion(ALTO)servers.
ThegoalofanALTOservice—ascurrentlybeingstandardizedintheIETF—istoprovideapplicationswithinforma-tiontheycanusetooptimizetheirpeerselec-tion[6].
Thekindofinformationthatismeaningfultoconveytoapplicationsviaanout-of-bandALTOserviceisanyinformationthatapplicationscannoteasilyobtainthemselves(e.
g.
,throughmeasurements)andwhichchangesonamuchlongertimescalethantheinstanta-neousinformationusedforcongestioncontrolonthetransportlayer.
Examplesofsuchinfor-mationareoperator'spolicies,geographicallocationornetworkproximity(e.
g.
,thetopolog-icaldistancebetweentwopeers),thetransmis-sioncostsassociatedwithsending/receivingacertainamountofdatato/fromapeer,ortheremainingamountoftrafficallowedbyapeer'soperator(e.
g.
,incaseofquotasorlimitedflat-ratepricingmodels).
ALTOservicescanbepro-videdbynetworkoperators,thirdparties(e.
g.
,entitiesthathavecollectednetworkinformationorhavearrangementswithnetworkoperatorsthatenablethemtolearnsuchinformation),orevenbyusercommunities.
TheALTO-interfacegivessuchpartiesaconcretemethodformakingthiskindofinformationavailabletotheE-REP.
TheE-REPcanusethestandardinterfaceofALTOservers,providingsuchALTO-informa-tiontoNAPA-WINEpeers.
Rep-Controller:Thepeeraccessesreposito-riesviaitsRepositoryController(Rep-Controller)modules.
ThissoftwarecomponentimplementstherepositoryprotocolandexposesitoveraclientAPI.
AsingleRep-Controllerisabletocommunicatetomultiplerepositoryserverscon-currently,andhasadvancedservicessuchasdatacachingandbatchpublishingofmeasurementdata(tosavepreciousbandwidth).
Therepositoryaccessprotocolisdesignedforthefollowingbasicusecases:Publishmeasurementresultsmadebypeers'monitoringmodules(orNREPprocessors)intotheglobaldatabase.
Thisisasimpleoperation,publishingan(originator,peer1,peer2,measure-mentID,value)record.
Theoriginatoristypicallyapeer(whoseMonitoringModulehasgeneratedthedata),equaltopeer1;peer2isnonnullonlyforpeer-pairmeasurements.
Retrievethelistof"best"PeerIDsaccord-ingtogivencriteria.
Thisisthemain"retrieval"primitive,designedtosupportthetopologyman-agerintheneighborhoodselectionandranking.
Theoperationisspecifiedas(maxPeers,constr1,…,constrn,weight1,…,weightm)whereconstraintsarespecifiedonmeasurementvalues,andweightsformautilityfunctiontheresultlistisorderedby.
Thisallowstheformu-latingofqueriessuchas"returnalistofatmost10peerIDswhichareclosertopeer2than5TTLhopsandhavesmallerroundtriptimetopeer3than500msandsortthelistbythepeers'ownreporteduploadbandwidth.
"Retrievemeasurementresultsorinferredvaluesforfine-tuningtradingalgorithms.
Thisprimitiveallowsthedirectqueryofpublished(measurementorother)valuesrelevanttoagivenpeer.
Retrieverepositorymeta-datasuchasthelistofmeasurementIDstherepositoryhasrecordsfor.
Thisallowsclientpeerstoparameterizetheirpeerlistingqueriesaccordingly.
Sinceinformationstoredintherepositoriesissensitive,therepositorycontrollerenforcessecu-rityandpoliciessothatonlyauthorizedpeerscanretrieveinformation.
Forexample,accesstotheinformationaboutISPtopologyorASrout-ingstoredintheE-REPisgrantedonlytopeersactuallyconnectedtothatISP.
SCHEDULERANDOVERLAYMODULESAP2P-TVclientneedstocommunicateveryefficientlywithotherpeerstoreceiveandredis-tributethehugeamountofinformationembed-dedinavideostream.
Inaddition,TVbeingarealtimeapplication,informationmustarriveinashorttimeandwithsmalldelayvariation.
Theapplicationgoalisthentodeliverallthevideoinformationtoallpeersinthesysteminthesmallestpossibleamountoftime.
Toreachthisgoal,adistributedsystemandalgorithmmustbeadopted.
Thekeyenablingfactorsforefficientcommunicationbyapeerare:whoarethepeerstocommunicatewith,i.
e.
,itsneighboringpeers,andwhatdataisexchangedwithinthisneighbor-hood.
Thefirstfactordrivestheoverlaymanage-mentstrategy,whilethesecondfactordictatesSinceinformationstoredinthereposi-toriesissensitive,therepositorycontrollerenforcessecurityandpoliciessothatonlyauthorizedpeerscanretrieveinformation.
Forexample,accesstotheinformationaboutISPtopologyorASroutingstoredintheE-REPisgrant-edonlytopeersactuallyconnectedtothatISP.
MELLIALAYOUT5/19/114:03PMPage159thegoalsoftheschedulingalgorithmsateachpeer.
Figure4sketchestherelationshipbetweenthefunctionsthatcomposetheoverlaymanage-ment,andthefunctionsthatcomposetheoverallstrategyforofferingandsearchinginformationwithintheneighborhoodofeachNAPA-WINEnode.
Interfacestowardtherepositories,theusermodule,andthemessaginglayerarealsoindicated.
Thedesignarchitecturefollowedallowsflexi-bilityandadaptivity,sothat,forinstance,chunkandpeerselectionstrategiescanbetunedevenatruntimebasedonfeedbackreceivedfromotherpeerseitherviagossipingorthroughtherepositories.
TheNeighborhooddatabase(seeFig.
4)ispopulatedassoonasapeerparticipatesinthedistributionofaTVchannel.
Forthesakeofclaritywedescribebothschedulingandoverlaymanagementasifonlyonechannelispresent,butwearealsostudyingtheextensiontothejointmanagementofmultiplechannels.
AlwaysreferringtoFig.
4,thecomponentsinyellowarerelatedtochunkscheduling,transmis-sionandreception,whilethoseinbluerefertotopologymanagementandsignalingingeneral(exchangeofbuffermaps,i.
e.
,thelistofchunksavailableateachpeer,availabilitytoservicechunks,etc.
).
ThetwofunctionalitiesinteractthroughtheNeighborhooddatabaseaswellasthechunkbuffer(i.
e.
,thestructurewherechunksarestoredfortradingandbeforeplay-out),andtherelatedbuffermapsofneighbors.
BUILDINGANDMAINTAININGNEIGHBORHOODSTheoverlaynetworkinP2Psystemsistheresultofadistributedalgorithmthatbuildsandmain-tainstheneighborhoodateachpeer.
Whenapeerjoinsthesystem,itselectsaninitialsetofneighbors(wecallthisphasebootstrapping);thenthesetofneighborsofeverynodeinthesystemisdynamicallyoptimizedovertime(over-laymaintenance).
ThebootstrappingphaseismostnaturallyhelpedbytheRepositories.
Forthemaintenancephase,basingeverythingonlyontheReposito-riescouldresultinlimitedscalabilityandresilience.
Thisisthereasonwhytopologymain-tenanceisperformedexploitinginformationretrievedfromtherepositoriesaswellasinfor-mationlocallydistributedviaagossiping-basedmechanism(thelattermechanismwillallowthesystemtoworkevenwithRepositoriesabsent).
Cullingofneighborsismainlybasedontheperceived"quality"oftheneighbors;indicesthatimpactthischoicearetheinter-peerthroughput,themeasuredRTT,thechunklossrate,etc.
Theadditionofneighborsisinsteadbasedonamixedstrategyofoptimization(e.
g.
,addingthemoststableandresourcefulpeers)andrandom-izationtoavoidfragiletopologies(e.
g.
,agroupofpeerswithtoofewconnectionstowardtherestoftheoverlay).
Ourarchitecturewillmakeoverlaycreationandmaintenancealgorithmsmuchmoreeffec-tivesinceitoffersthroughtherepositoriescon-tinuouslyfreshinformationtothepeersaboutthepresenceofnewresourcefulpeers.
AsanIEEECommunicationsMagazineJune2011160Figure4.
Logicalorganizationoftheschedulingandtopologymanagementmodules,aroundtheneighbor-hooddata-base.
PushorpullSend/receiveGossippingBuffermapexchangeetc.
ChunkbufferNeighborhoodSelectchunkInter-peercommunicationOthermodulesinterfacesLocalcontrolBuffermapsUsermoduleRepositoriesInformationSignalingStrategyTopologyControlalgorithmTiminganddelaycontrol;TradingstrategyMessaginglayerSelectpeerThedesignarchitec-turefollowedallowsflexibilityandadap-tivity,sothat,forinstance,chunkandpeerselectionstrate-giescanbetunedevenatruntimebasedonfeedbackreceivedfromotherpeerseitherviagos-sipingorthroughtherepositories.
MELLIALAYOUT5/19/114:03PMPage160IEEECommunicationsMagazineJune2011161example,Fig.
5showsdifferentoverlaytopolo-giesobtainedusingdifferentneighborselectionalgorithms.
In5(a),acompleterandomchoiceisperformed;in5(b),peersareselectedaccordingtotheAutonomousSystemstheybelongto,asreportedbytheE-REP;in5(c)peerspreferselectednodeswithlargeuploadbandwidth,asreportedbytheP-REP;in5(d)highuploadbandwidthpeerswithinthesameASarepre-ferred.
SCHEDULINGCHUNKSANDPEERSOnceatopologyhasbeensetup,eachpeerpar-ticipatesinthechunkexchangeprocedure,withthetwingoalofreceivingthestreamsmoothlyandintimeandcooperatinginthedistributionprocedure.
Wedonotdiscusstheproblemsoffairnessandsecurityhere,becausetheyarenotthemainfocusofNAPA-WINE,andthereforeweassumepeersarehonestandcooperative.
Schedulingtheinformationtransferisproba-blythesinglefunctionthatmostaffectsperfor-manceandnetworkfriendliness.
Thisfunctionincludesprotocolaswellasalgorithmicprob-lems.
First,peersneedtoexchangeinformationabouttheircurrentstatustoenableschedulingdecisions.
Thisisarequirementinanunstruc-turedsystem,wherethestreamflowdoesnotfollowstrictlytheoverlaytopology(e.
g.
,atree).
Theinformationexchangedreferstothestateofthepeerwithrespecttotheflow,i.
e.
,amapofwhichchunksare"owned"byapeer,andwhicharemissing.
ThistaskiscarriedoutbytheInfor-mationSignalingStrategyblockinFig.
4.
Thisblockisinchargeof:Sendingbuffermapstoothernodeswiththepropertiming.
Receivingthemfromothernodesandmerg-ingtheinformationinthelocalbuffermapdatabase.
Negotiatingifthisandotherinformationshouldbespreadbygossipingprotocolsornot,andtowhichdepthitshouldspreadinthetopology.
Besidesthebuffermapexchange,thesignalingincludesOffer/Request/Selectprimitivesusedtotradechunks.
Thesemessagescanbepiggy-backedonchunksforefficiency.
AnotherkeyprotocoldecisionisaboutPush-ingorPullinginformation.
Achunkispushedwhenthepeerowningthechunkdecidestosendittosomeotherpeer,whileitispulledwhenapeerneedingthechunkrequestsitfromanotherpeer.
Fromatheoreticalpointofview,asshownin[8],pushingismoreeffective.
Assumingasyn-chronoussysteminwhichpeerscoordinatetoavoidsendingmorethanonecopyofthesamechunk,in[8]wehavedemonstratedtheexis-tenceofanoptimaldistributedschedulingthatachievestheminimumdeliverytimetoallpeers,td=log2(N)+1chunktimes,whereNisthenumberofpeers,whilenosuchalgorithmsareknownforpullingsystems.
Practicalimplementa-tions,however,oftenpreferapullbasedmecha-nism,becauseitguaranteesthatnoconflictsariseatthereceiver.
OtheroptionsincludemixedPush/Pullstrategies[10],andOffer/Selectchunktrading[11]thatcanbeassociatedtobothPushandPullstrategies.
Regardlessoftheprotocolandthesignalingstrategyused,thecoreofascheduleristhealgo-rithmtochoosethechunktobepulledorpushedandthepeertocommunicatewith.
Duringtheprojectwehavedevelopedmanyalgorithmsandstrategiesthatoptimizetheperformanceofthesystemandthatarebeingimplementedinourprototype[7–9].
Forexample,Fig.
6reportsthe95thper-centileofthedeliverydelayofallchunkstoallpeersinanoverlaytopologyinwhicheachpeerhas20neighborsselectedatrandom.
1000peersareconsidered(withdifferentuploadband-width),chunkslast1s,sothatpropagationdelayisnegligiblecomparedtochunktransmissiontime.
Wereporttheperformanceoffivesched-ulers:RUc/RUp:arandomchunkissenttoaran-dompeerthatneedsit.
RUc/BAp:arandomchunkispreferentiallysenttohighuploadbandwidthpeersthatneedit.
LUc/RUp:theyoungestchunkissenttoarandompeerthatneedsit.
DLc/ELp:deadlinebasedalgorithmthatdif-fusesthechunkwiththesmallestdeadline(see[8]fordetails)toapeerthatisinthebestpossiblestatetofurtherdiffuseit.
DLc/BAELp:sameasabove,butpreferen-tiallyselectinghighuploadbandwidthpeers.
Figure5.
a)completelyrandomlychosenneighbors;b)neighborschosenbasedonlocalityinformationprovidedbyE-REP;c)neighborschosenbasedonuploadbandwidthpeerinformation;d)combinationofb)andc).
(a)(b)(c)(d)Figure6.
PerformanceofseveralschedulingpoliciesforimmediatePush.
95thpercentileofthechunkdeliverydelayversusload.
Load0.
60.
5105Delay(95thpercentile)[s]152025303540450.
70.
80.
91RUc/RUpRUc/BApLUc/RUpDLc/ELpDLc/BAELpMELLIALAYOUT5/19/114:03PMPage161IEEECommunicationsMagazineJune2011162Ascanbeseen,moreadvancedschedulersmakeitpossibletoreducethechunkdeliverytime,withimprovementsuptoafactorof5athighload.
NoticethatinformationprovidedbytheP-REP,suchasthepeeruploadbandwidth,leadstoasignificantimprovement.
ImmediatePushingofchunksmayhavedraw-backsinsomescenarios(e.
g.
,whentheRTTsisnotnegligiblecomparedtochunktransmissiontime)andexplicitacceptanceofthechunktrans-fermayguaranteebetterusageofresources.
Wehaveinvestigatedsignalingmechanismswherethetransmitterandthereceiverpeersexplicitlyexchangesignalingmessagestoagreeonthechunktobetransferred;theschemerequiresthesendertomaintainalocalqueueofalreadyscheduledchunkstoseamlesslyexploitpeeruploadbandwidth[11].
CONCLUSIONSANDONGOINGWORKTVapplicationsexploitingtheP2Pcommunica-tionparadigmaregainingmomentumandarealreadyacommercialreality.
Theiroverallarchi-tectureis,however,imprintedbyfile-sharingapplicationsandtheyoperatewithoutanycoor-dinationwiththeIPnetwork,oftenresultinginpoor,evenwastefulresourceusage,tothedetri-mentofbothnetworkandusers,andpreventingthemfromthepossibilitytoscaletoHighQuali-ty(letaloneHighDefinition)TV.
Wehavepresentedinthisarticlethearchi-tectureofaP2P-TVsystemthatisbeingdevel-opedintheNAPA-WINEproject,thatisdesignedwiththegoalofefficiencyandcoopera-tionbetweentheapplicationandboththenet-workoperatorandthecontentprovider,aimingatoptimizingresourceusageandminimizingtheP2P-TVapplicationimpactsonthetransportnetwork.
Thekeyfeaturesare:Thedevelopmentofalgorithmsfortopologymanagementandinformationschedulingthat,startingfromnetworkmeasures,mini-mizetheusageofnetworkresourceswhilepreservingtheapplicationperformance.
Thepresenceofsharedrepositoriesthatcanbeusedtoexchangeinformationbetweenthenetworkandtheapplication,sothatthedecisionstakenbypeersregardingconnec-tivity,topology,signaling,andinformationtransfercanbetakenwiththeappropriateknowledge-base.
Theoverlaytopologymanagementandthechunkschedulingofinformationhasbeenidenti-fiedaskeyfeaturesfortheapplicationtobenet-work-friendly.
Thefirstfunctionmakesitpossibletobuildefficientandrationaloverlaytopologiesthatarecorrectlymappedontopofthetransportnetworkstructure(e.
g.
,consideringtheminimalnumberofhopsbetweenneighbors,localityw.
r.
t.
AutonomousSystems,etc.
).
Thesecondfunctionguaranteesthatthenetworkcapacityisexploitedwithoutwaste(e.
g.
,bymini-mizingretransmissionsandpursuinganefficientdistributionofchunks,etc.
).
Thesekeyfeaturesmust,however,besup-portedbymeasurementsthatinmostcasesaredynamicandcanonlybeimplementedintheapplicationoverlayitself.
Asaconsequence,theMeasurementModuleassumesacentralroleinthesystem,andthedevelopmentofefficientalgorithmsandmethodsformeasurementisjustasfundamentaltotheoverallsystemasefficienttopologymanagementandscheduling.
Thedescribedarchitectureisbeingimple-mentedintheNAPA-WINEprojectandismadepubliclyavailableassoftwarelibrariesunderLGPLlicense,freelydownloadablefromtheprojectwebsite.
ACKNOWLEDGMENTSWearedeeplyindebttoallthepeoplepartici-patinginNAPA-WINEandcontributingtotheproject'ssuccesswiththeirworkandresearch.
REFERENCES[1]L.
Jiangchuanetal.
,"OpportunitiesandChallengesofPeer-to-PeerInternetVideoBroadcast,"Proc.
IEEE,vol.
96,no.
1,Jan.
2008,pp.
11–24.
[2]E.
Leonardietal.
,"BuildingaCooperativeP2P-TVAppli-cationoverAWiseNetwork:theApproachoftheEuro-peanFP-7STREPNAPA-WINE,"IEEECommun.
Mag.
,vol.
46,no.
20,Apr.
2008,pp.
20–22.
[3]V.
Aggarwal,A.
Feldmann,andC.
Scheideler,"CanISPSandP2PUsersCooperateforImprovedPerformance"SIGCOMMComp.
Commun.
Rev.
,vol.
37,no.
3,July2007,pp.
29–40.
[4]T.
S.
E.
NgandH.
Zhang,"PredictingInternetNetworkDistancewithCoordinates-basedApproaches,"Proc.
IEEEInfocom,2001,vol.
1,NewYork,NY,USA,June2002,pp.
170–79.
[5]Y.
Yardi,"NetworkTomography:EstimatingSource-Des-tinationTrafficIntensitiesFromLinkData,"J.
AmericanStatisticsAssociation,1996,pp.
365–77.
[6]J.
Seedorf,S.
Kiesel,andM.
Stiemerling,"TrafficLocal-izationforP2PApplications:TheALTOApproach,"Proc.
IEEEP2P2009,Seattle,WA,USA,Sept.
2009.
[7]A.
CoutodaSilvaetal.
,"ABandwidth-AwareSchedul-ingStrategyforP2P-TVSystems,"Proc.
IEEEP2P2008,Aachen,Germany,Sept.
2008.
[8]L.
Abeni,C.
Kiraly,andR.
LoCigno,"OntheOptimalSchedulingofStreamingApplicationsinUnstructuredMeshes,"Proc.
IFIPNetworking2009,Aachen,Ger-many,May11–15,2009[9]L.
Abeni,C.
Kiraly,andR.
LoCigno,"RobustSchedulingofVideoStreamsinNetwork-AwareP2PApplications,"Proc.
IEEEInt'l.
Conf.
Communications(ICC'09),CapeTown,SouthAfrica,May23–27,2010.
[10]A.
RussoandR.
LoCigno,"Delay-AwarePush/PullPro-tocolsforLiveVideoStreaminginP2PSystems,"Proc.
IEEEInt'l.
Conf.
Commun.
(ICC'09),CapeTown,SouthAfrica,May23–27,2010.
[11]R.
Fortunaetal.
,"QoEinPullBasedP2P-TVSystems:OverlayTopologyDesignTradeoffs,"Proc.
IEEEP2P2010,Delft,TheNetherlands,Aug.
2010.
BIOGRAPHIESROBERTBIRKEreceivedhisPh.
D.
in2009fromPolitecnicodiTorino,whereheiscurrentlyholdingaPostDocposition.
InthepastyearsheparticipatedindifferentItalianandEuro-peanfundedresearchprojectsandcurrentlyheisworkingontheEuropeanNapa-WineprojectaboutP2Ptelevision.
Hisresearchinterestsareinthefieldofnetworkmeasure-mentsandpeertopeerstreamingapplicationdesign.
EMILIOLEONARDIisAssociateProfessorattheDipartimentodiElettronicaofPolitecnicodiTorino.
Hisresearchinterestsareinthefieldof:performanceevaluationofwirelessnet-works,P2Psystems,packetswitching.
HeisthescientificcoordinatoroftheEuropean7-thFPSTREPprojectNAPA-WINE.
MARCOMELLIA[SM'08](mellia@tlc.
polito.
it)receivedhisPh.
D.
degreein2001fromPolitecnicodiTorinowhereheisnowAssistantProfessor.
Hisresearchinterestsareinthefieldsoftrafficmeasurement,P2Papplicationsandgreennetworkdesign.
Hehasco-authoredover150paperspub-lishedininternationaljournalsandconferences,andheThesekeyfeaturesmust,however,besupportedbymea-surementsthatinmostcasesaredynamicandcanonlybeimplementedintheapplicationoverlayitself.
Asaconsequence,theMeasurementMod-uleassumesacentralroleinthesystem.
MELLIALAYOUT5/19/114:03PMPage162IEEECommunicationsMagazineJune2011163participatedintheprogramcommitteesofseveralconfer-encesincludingIEEEInfocomandACMSigcomm.
HeistheWorkPackagescoordinatorintheNAPA-WINEproject.
CSABAKIRALYisresearchassociateatDipartimentodiIngeg-neriaeScienzadell'Informazione,UniversityofTrento,Italy,whereheisresponsibleforthecoordinationofNAPA-WINEactivitiesandchiefdeveloperoftheNAPAwinestreamersandschedulers.
Heisco-authorofseveralscientificpapers.
RENATOLOCIGNOisAssociateProfessoratDipartimentodiIngegneriaeScienzadell'Informazione,UniversityofTren-to,Italy.
Heisco-authorofmorethan120scientificpubli-cationsininternationalconferencesandjournals.
HeisAreaEditorofComputerNetworks(Elseveir).
Hisinterestsareindesignandperformanceevaluationofwiredandwirelessnetworkingprotocolsandapplications.
HeisthecoordinatorofWP2inNAPA-WINE.
ARPADBAKAYreceivedbothhisM.
Sc.
andUniversityDoc-toratedegreesfromtheElectricalEngineeringSchooloftheBudapestTechnicalUniversity.
Sincethenhehasworkedforvariouscommercial,for-profitcompaniesasprojectandproductsarchitect,andlateralsoasexecutiveresponsibleforR&D.
Inthemeantimehealsokeptaca-demicpositionsasresearcherandlectureratvariousHun-garianandforeignuniversities(ELTE—Hungary,Vanderbilt—USA,BTU—Hungary).
HeisthecoordinatorofWP4inNAPA-WINE.
TIVADARSZEMETHYobtainedisPh.
D.
in2006fromVanderbiltUniversity,USA,whereheparticipatedinprojectsrelatedtoModel-IntegratedComputing,Domain-SpecificModel-ingandModelVerification.
Since2006,heworksassoft-wareR&Dconsultant(NETvisorPlc,Hungary)andpart-timelecturerattheUniversityofWestHungary.
FabienMathieuwasastudentattheEcoleNormaleSuperieure,from1998to2002.
HecompletedaPh.
D.
inComputerSciencein2004.
HecurrentlyworksasaresearcheratOrangeLabs.
HisresearchinterestsincludeP2Pcontentdistributionmodelingandperformanceevaluation.
LUCAMUSCARIELLOisseniorresearcheratOrangeLabsonperformanceevaluationofcommunicationnetworks.
Hisresearchinterestsincludesimulationandanalyticalmodel-ingofwiredandwirelessnetworks.
HereceivedaM.
Sc.
andaPh.
D.
degreeinCommunicationEngineeringfromPolitecnicodiTorino.
SAVERIONICCOLINIobtainedhisMasterdegreeinTelecom-municationsandhisPh.
D.
inTelematicsfromtheUniversityofPisain2000and2004respectively.
HeiscurrentlythetechnicalmanageroftheReal-TimeCommunicationsgroupatNECLaboratoriesEuropefocusinghisresearchinterestsonapplication-levelmonitoringtechnologiesfortrustwor-thinessapplications,cost-efficienttrafficmanagementandprogrammablenetworksbasedonOpenFlow.
JANSEEDORFisResearchScientistatNECLaboratoriesEurope,workinginthereal-timecommunicationsgroup.
HereceivedaB.
Sc.
degreein2001andaDiplomadegreein2002inComputerSciencefromtheUniversityofHam-burg,Germany.
Hisresearchinterestsincludedecentralizedcontentdistribution,P2Ptechnologies,andsecurity.
GIUSEPPETROPEAreceivedhisLaureaDegree(M.
Sc.
)inInfor-maticsEngineeringfromUniversityofCatania,Italy,inOctober2002.
HeisinvolvedinseveralEuropeanprojects,bothwithasmallenterprise(LightcommS.
R.
L.
)andtheItalianConsorzioNazionaleInter-universitarioperleTeleco-municazioni(CNIT).
Heisco-authorofseveralresearchpapersdealingwithprivacyprotectionindigitalservicesandvideodistributionforP2Pcommunities.
MELLIALAYOUT5/19/114:03PMPage163