robust transmission of 3d geometry over lossy networks

Robust Transmission of 3D Geometry over Lossy Networks

Zhihua ChenDept. of Electrical Engineering

and Computer ScienceVanderbilt UniversityNashville, TN 37235

[email protected]

Bobby BodenheimerDept. of Electrical Engineering


[email protected]

J. Fritz BarnesDept. of Electrical Engineering


[email protected]

ABSTRACTThispaperdescribesarobustmechanismfor transmitting3Dmeshesover the Internet. TCP/IPis anexcellentmeansfor reliabletrans-port over theInternet.However, multi-user, real-timegraphicsap-plicationsmay find TCP transmissiondisadvantageouswhen re-ceptionof a meshis time-critical. To improve speedonecoulduseanunreliabletransmissionprotocol.Yet typicalmeshcompressionschemesincreasethefragility of themeshto lossytransmission.Inthispaper, wedevelopahybridmethodof transmittingmeshesovertheInternet,built uponprogressive mesh[17] technology. Thehy-brid methodtransmitsimportantvisualdetail in a losslessmanner,but tradesoff lossof visually lessimportantdetailfor transmissionspeed.Testsof the methodin a lossynetwork environmentshowthat the methodimprovesthe transmissiontime of the meshwithlittle degradationin quality.

1. INTRODUCTIONAs theInternetexpands,demandis growing for high quality 3D

geometryin applications,from gamessuchas Everquest[12] tocollaborative virtual environmentsto multimediaandpurelyweb-basedapplications.Suchapplicationsusehighresolution3Dmeshesto achievetheireffect,andthechallengeof thegrowing demandforthesemeshesis how to storeandtransmitthelargeamountof datacontainedin them.Therearetwo traditionalmethodsfor obtaininghigh resolution3D meshesfor theseapplications:(1) assumethatin atraditionalclient-servermodeltheclientalreadyhasthemodel;(2) wait for themodelto bedownloadedover theInternet.

Bothmethodshavedrawbacks.Thetraditionalclient-servermodelassumesall modelsareavailablelocally, andthereforeis appropri-atefor suchapplicationsasgameswheremodelsnever change,butit is lessappropriatefor distributedapplicationswherenew modelsmaybecreatedby usersandincorporatedinto theenvironmentinreal-time.Likewise,downloadingmaybeappropriatein somesce-narios,but even if thedatais compressedit cantake anunaccept-ably long time to receive a complex model. For example,onlinevideogamingtypically usesthefirst methodin obtainingits 3D ge-ometry, becausesmoothnavigationandincreasedusersatisfactionresultwhenthereareno delaysin renderingcausedby not having

themodel.A partialsolutionto thesedrawbacksis thatof Hoppeandothers,

to progressively transmitthe geometricdata[17]. In this method,the server initially sendscoarseshapeinformationto a client thatcanbe reconstructedandrenderedvery quickly. Then increasingdetailin themodelis transmittedto theclient,allowing theclient toprogressively refinetheinitial modelinto thefull resolutionmodel.If, for example,theobjectis initially far away, thena usercannotperceive the loss of detail in the model causedby renderingtheinitial model. More generally, the useris ableto seeandinteractwith the coarsemodel immediately, and thus the delaywhile themodelis beingrefinedis not asperceptuallydisturbingasdelayintheactionwhile themodelis fully downloaded.In its basicform,progressive transmissiondoesnot reduce the amountof datathatneedsto betransmitted,but it orders thedatafrom mostimportantto leastimportant. The crux of our methodlies in this ordering:lossof datathat is lessvisually importantmay be tolerableif themodelis transmittedfaster.

Variousauthors[23, 32, 20] have combinedmeshcompressiontechniqueswith progressive transmissionto reducethe amountofdatathat needsto be sent. Typically, thereis a tradeoff betweencompressionratioandthefragility of thecompressedmesh.For ex-ample,if evenonepacket is lost in a highly compressedmeshthentheentiregeometrymaynotbereconstructablefrom whatremains.This fragility mandatestheuseof a reliable transmissionmethod,andthe commonprotocol for suchtransmissionis TCP, which isgenerallyerror-free. However, usingTCPcanresult in non-lineardelayswhen transmittingdataover lossy network environments.Alternative transmissionprotocolssuchasUDP areunacceptablebecausethey may not deliver all packets to the receiver. In manycollaborative virtual environments[22, 14], a singlesendersendsdata to multiple recipientsover the InternetMulticast Backbone(MBONE) [8]. This techniqueallows a host to scalablytransferinformationto multiple recipients.However, multicastcommuni-cationoften doesnot supportreliablecommunicationbecauseofthe complex andprohibitive costassociatedwith developingreli-ablemulticasttransport.

In this paper, we arenot addressingthe issueof meshcompres-sion. Rather, we develop the ideaof hybrid transmission:reliablewhereit is needed,but allowing packet losswhereit canbetoler-ated.In particular, weexploreahybridschemefor combiningTCPandUDP transmissionmodes,exploiting thepropertyof progres-sivemeshesthatimportantdetailis transmittedfirst, andthelossofsomepacketsmaybetolerableif theoverallqualityof theresultingmeshis good.

Whenpacketsare lost, geometryis lost. Our methodattemptsto tradeoff the possibility of improving the meshwith new re-finementsasadditionalinformationarrivesversusthepossibilityof

��

��

Figure1: Vertex split transformation.

causingsomeamountof meshcorruption.Thistradeoff canbereg-ulated. Additionally, our methodcould be appliedin conjunctionwith meshcompressiontechniquesto further reducebandwidth.Thus,we only considerthe basicprogressive mesh(PM) schemeof Hoppe[17], as more advancedschemeswould typically havesimilar resultsin differentratios.Wedemonstrateonanactualcon-gestednetwork thatour schemeoutperformsa pureTCPtransmis-sionin thetime it takesto receive anacceptablequality mesh,andoutperformstransmissionvia strict UDP in thequality of thefinalmesh.

The paperis organizedin the following manner. In Section2we placeour work in the context of what hasbeendonein thisareaanddiscussthe different transportprotocolsused. Section3discussesourhybrid transmissionprotocol.Section4 discussestheexperimentalsetupusedto conductour tests,andprovidesdetailsof theexperimentswe ran. Section5 presentsthe resultsof thoseexperimentswith an analysisof them. Finally, in Section6 wediscussour resultsandfuturework we intendto investigate.

2. OUR WORK IN CONTEXTThePM schemewasdevisedby Hoppein [17, 19], andwe have

implementedthe basicversionwithout the modificationsof laterwork [18, 26]. This sectionintroducesHoppe’s notationfor thePM methodthat is relevant to our work; for a completediscus-sion, the readeris referredthe works mentionedpreviously. ThePM representationof amesh� is storedasacoarsemesh�

anda sequenceof detail recordscalled vertex splits. Thesevertexsplits indicatehow to incrementallyrefine �

so that after the vertex splits have beenprocessed,the original mesh � is recov-ered. In fact, thePM representationdefinesa sequenceof meshes� �� which provide increasinglyaccurateapproxi-mationsof � .

A vertex split is a basic transformationthat addsa vertex tothe mesh. The basicprogressive meshschemeis implemented,but for the purposesof this paper, a vertex split doesnot containnormal,texture,or materialinformation. Eachvertex split is a 30bytequantityconsistingof a faceindex, �� , anindex �� !�"( #%$&�� ' ��!�"($*) ), anencoding��+ +-,/. , andtwo vertex positiondeltas,��0��1 and ��0��2 . In our experiments,thesevertex splits arepackedinto 1400bytepackets.Thus,eachpacket containsroughly46 vertex splits.

Figure1 illustratesa PM vertex split transformation.Eachver-tex split operationintroducesa new vertex ��3 andtwo new faces,asshown. Thelocationof a vertex split is parameterizedby ��2 , � 1 ,and ��4 . By default, the PM datastructuredoesnot include inci-denceinformationin thevertex to facedirection.Thevertex valuesaredeterminedthroughthe fields �� , �� ' ��!�" , and ��5+ +-,-. .To determinethe vertex beingsplit ( ��2 ), the threeverticesof the

face �� aresortedby their index valuesandstoredinto an or-deredlist. They are indexed by �� !�" . Vertex � 1 is the nextvertex clockwiseon the face �� . The vertex ��4 is determinedby ��+ +-,/. , thenumberof clockwiserotationsabout ��2 from �61 to�64 .

Othermethodsfor progressivetransmissionof mesheshavebeendeveloped.A morecomplicatedschemeinvolving decomposingameshinto a setof overlappingellipsoidsandpoint samplingtheshapehasbeenproposedby by Bischoff andKobbelt[5]. We arecurrentlyevaluatingtheirmethodin thecontext of ourexperiments,but we expectsimilar resultssincetheir methodallows oneto se-lectively refine areasof the meshfor which information was re-ceived,andnot refineareasfor which informationwaslost. ChenandNishita[9] have constructeda streamingmeshformat for pro-gressive transmissionwith quality of service(QoS)control. ThisQoS control gives them advantagesin anticipatingnetwork con-gestion,but their transmissiontechniqueis still built uponTCPandsuffersthedrawbacksof it. Usingforwarderrorcorrectionfor com-pressed progressivemeshes[23] hasbeeninvestigatedby Al-RegibandAltunbasak[1]. Conceptually, this work is similar to our own.However, Al-Regib andAltunbasakconsiderthemeshasbeingde-composeda priori into discretelevelsof detail. If thebit streamofoneof theselevelsof detail is lost, thereis anamountof distortionintroducedinto therenderedmeshcorrespondingto theselevelsofdetail.Ourmethod,in contrast,is moreopportunisticin thatit maylosemoredata,but renderswhat it canat a finer granularity, de-terminedby the amountof datalost. An additionaldifferenceisthatwe have testedour methodon a wide areanetwork with sim-ulatedbackgroundtraffic, whereastheir resultscomeentirelyfromsimulations.

In the context of progressive transmissionmuchof thework inthe graphicscommunityhasfocusedon methodsfor bettercom-pressionof geometricdataratherthanonrobusttransmission.Taubinetal. [32] achievehighercompressionratiosthanPM attheexpenseof a morecomplex refinementoperation.PajarolaandRossignac[23] refine the meshin batches,which allows them to compressthesebatcheseffectively at the expenseof someapproximationqualityadvantagesof thePM andTaubinmethods.Khodakovsky etal. [20] achieve muchbettercompressionby remeshingthemodelinto a semi-regularmesh.They thengeneraterefinementsthrougha wavelettransformandentropy encoding.Alliez andDesbrun[3]employ a valencedriven decimationalgorithm to achieve highercompression.Finally, GandoinandDevillers [15] usea kd-treeal-gorithmthatallows themto encodevolumetricinformationaswellasnon-manifoldmeshesbetterthanprevious results.All of thesetechniquesare complementaryto our own, in that they could fitwithin thetechniquesproposedhereto achievehighertransmissionrates.

2.1 TransmissionControl ProtocolIn thissection,wereview thetransmissioncontrolprotocol(TCP)

and its effect on network transmissionover congestednetworks.Only material that is pertinentto this applicationis presented;amorethoroughdescriptioncanbefoundin bookswrittenbyStevens[31] or Comer[10]. In particular, this sectionlooks at why usingTCP, a reliabletransportprotocol,to transmitdataover congestedlinks resultsin significantdelaysandevenunreliableservice.

Usingwideareanetworks(WANs),suchastheInternet,to trans-mit dataintroducessignificantdelays(30ms-300ms)and loss ofdataduring transmission.Thesedelaysaffect the maximumrateat which a TCPconnectioncansendinformation. Thepacket lossalso limits the rateof transmissionand can result in exponentialdelaysin thetransmissionof data.

Pkt6Pkt8 Pkt7

Pkt9Pkt10

Ack6Ack5 Ack7 Ack8Receive Buffer

ReceiverSender

Figure2: TCP Flow Control

Time

Lost packet

ACK

ACK

ResendLost Packet

Sender Receiver

Figure3: TCP FastRetransmit

The limit on transmittabledataover TCPoccursbecauseof theinteractionbetweenlong round-trip-timesbetweensenderandre-ceiver andTCP’s flow control algorithm. TCP usesflow controlto guaranteethat thesenderdoesnot overwhelmthereceiver withdata. This behavior is necessaryso that a fast sendersendingapacket every tenthof a second,for example,doesnot fill up thebuffers on a slow receiver that only receives from thosebuffersevery second. Thesebuffers can be definedby the application.Without modificationsto TCP, suchaswindow-scaling,the max-imum sizeof thesebuffersis 64 kB. This sizelimits how fastTCPsendsduringcongestion.Congestionincreasestheround-triptimerequiredto senda packet to the receiver andreceive an acknowl-edgement.TCPlimits thetransmissionratesothatasendingappli-cationdoesnot sendinformationwhenthereceiver’s buffer is full.For example,considerFigure2. If thebuffer sizeof thereceiver issix packets,the sendercannotsendany additionalpacketsuntil itreceivesanacknowledgmentfrom thereceiver. This first decreasein performancelimits themaximumTCPperformance.In applica-tions that transmit3D geometry, this featureof TCPis not neededsincetheapplicationshouldeasilybeableto consumeinformationquickly enoughthatbufferswill not fill up at thereceiving host.

The seconddecreasein WAN performanceis dueto lost pack-ets. TCP usesacknowledgmentsto determinewhen packet lossoccurs. The senderwill sendthe dataandwhen the receiver re-ceivesa packet it will sendan acknowledgmentthat indicatesthesmallestsequencenumberthat thereceiver hasnot received. TCPusestheseacknowledgmentsto detectpacket loss througheithertheabsenceof anacknowledgmentor thefastretransmissionalgo-rithm. If thepacket hasnot beenacknowledgedwhenthe timeoutoccurs,the senderwill resendthat packet. The timeout mustbelargeenoughthatapacket thatis not lostwould arriveat theserverandbeacknowledgedbeforethetimeoutexpires.TCPdynamicallyadjuststhetimeoutwhenit doesnot receive anacknowledgement.Typical network stacksexponentiallyincreaselengthof the time-out. Becausecongestednetworksoftencauseseveralpacket lossesto occurconsecutively, this canresult in large delays,e.g., thirtysecondsor more.

Fast retransmissionrecognizesthat the senderknows a packetwaslost becauseit receivesduplicateacknowledgmentsfor a pre-vious packet. Thus,fastretransmissioncanavoid delaysincurred

waiting for timeouts.An exampleis shown in Figure3 wherethetwo packetssentafter the lost packet includean acknowledgmentnumberto the beginning of the lost packet. Theseduplicateac-knowledgmentsoccurbecausewhenever a packet arrivesTCPwillacknowledgethepacket andindicatethenext byte it expectsto re-ceive,whichwill bethelostpacket in thisexample.As aresult,thesendercantake whatever actionsneedto be performedwhenthatpacket hasbeenlost. TheTCPspecificationstatesthatwhenthreerepeatedacknowledgmentshave beenreceived, thesendercanre-sendthepreviouspacket.

Lost packetsnot only requireretransmissionof the lost packetbut alsoaffect the transmissionrateof the server. The TCP con-gestioncontrolalgorithmusespacket lossto determinewhenanet-work link is congested.When a packet is lost, TCP halves thenumberof packetsthat it sendsacrossthenetwork beforeexpect-ing an acknowledgment.Therefore,packet losswill decreasethesendingrateof theTCPsenderandaffect the transmissionperfor-manceover congestednetworks. Combiningtheeffect of reducedtransmissionratesand exponentialtimeoutsresultsin significantdelaysthatmayevencausethefailureof thenetwork link betweenthesenderandreceivereventhoughthephysicallink still existsandunreliabletransmissionwould succeed.

2.2 Real-timeData TransmissionMany papershave exploredhow to reliably senddatathrough

unreliablenetworks [27, 16, 13, 30]. Essentially, thereare twoapproaches.In the first case,oneaddsadditionalinformation topacketssuchthat thesenderandreceiver candetermineif packetshave beenlost andthereceiver canrequesta retransmissionof anylost data. In the secondcase,oneaddsredundantinformationtopacketssuchthatthereceiving processcanreconstructlostpacketsfrom datacontainedin otherpackets that this processhasalreadyreceived. The drawbacksof using TCP are that it increasesthetime of transmissionof dataandcannotscalefor theusein multi-casttransmissions.An exampleof thesecondcaseis forwarderrorcorrectioncodes.Theprimarydisadvantageof thesetechniquesistheadditionof redundantdatain thetransmission.

Researchinto the transmissionof multimediastreams[25, 28]hasconsideredtechniquesthat dynamicallyadjustthe amountofinformationencodedin the multimediastreamto meetthe band-width availablebetweenthesenderandthereceiver. In many cases,theseschemescannotafford to drop packetsor useforward-errorcorrectionmechanisms.This approachdiffers from the transmis-sionof 3D geometricinformationthatwe studyin this paper. Al-ternative researchin multimediadelivery systemshasexploredtheuseof transmissionover partially orderedtransportprotocols[11]andincreaseduseof buffers for supportinglong-lived multimediastreams[2].

Additional researchhasinvestigatedwhetheronecanguaranteethequalityof network transmissions.Guaranteedqualityhasanob-vious andimportantimpacton meshtransmission.Specificworkincludesintegratedanddifferentiatedservices[33, 7, 6] within theInternet. Theseproposalsprovide mechanismsthat couldbe usedto control the numberof packets lost in the network. As a result,the useof thesemechanismscould eliminateconcernsaboutlostpackets.Unfortunately, deploymentanduseof integratedor differ-entiatedservicesis not currentlyavailable.

3. HYBRID TRANSMISSIONIn this section,we discussour hybrid protocolfor transmission

of meshdata. The progressive meshformatcreatesan alternativerepresentationof the 3D geometry. Onesignificantadvantageofthis representationis that somepacketscontainingmeshdataare

0 2000 4000 6000 8000 10000 12000 140000

1

2

3

4

5

6

7

8

9x 10

−3

Number of Faces in PM Approximation

Hau

sdor

ff D

ista

nce

Hausdorff Distance vs. Number of Faces in a PM Approximation

Figure 4: The Hausdorff distanceof the Cessnamodel for dif-ferent PM approximationsby number of facesin the model.

moreimportantthanotherpackets. An exampleof this differencein packet priority appearsin Figure 4. This figure comparestheHausdorff distancebetweentheoriginal3D modelandamodelde-rivedby performingasubsetof thevertex splitsonthebasemodel.TheHausdorff distanceis astandardwayto measurethedifferencebetweentwo surfaces,andcalculatesthe farthestdistancefrom apoint in one surfaceto its closetpoint in the other surface[21].WecalculatethesurfacedeviationusingthealgorithmdescribedinAspertet al. [4]. Notice in thegraphthat the initial splitsprovidesignificantimprovementsin theHausdorff metric,while latersplitsprovide decreasingbenefits.

Themethodimplementedherehasoneadditionto thebasicPMstrategy. In additionto thevertex splits,eachpacketcontainsafourbyteheaderthatstorestheindex numberof thefirst faceof themeshthatwill be introducedby thefirst vertex split in this packet. Theclient rendererusesthisnumberasa“poor man’s” errorcorrection,to givefacesgeneratedby vertex splitsafterlostpacketstheir indexnumberin the full resolutionmesh. This processis doneso thatfuture splits whosefaceindex, ��5�� , referencesthesefaceswillbe able to find them. This headeris a monotonicallyincreasingnumber, andcanalsobeusedto detectout-of-orderpackets. Thisschemeis simple,andallows us to reconstructmuchmoreof themeshthanif this headerwerenot included.

Our hybrid techniqueleveragesthe inherentdifferencesin theeffect thatvertex splitshave on theresultingvisualaccuracy of thereconstructedmesh. Thus, in this scheme,we begin by transmit-ting datausingthe TCP protocol. Part-way throughthe transmis-sion, the hybrid senderclosesthe TCP connectionand transmitsthe remainingdatausingUDP. This allows the senderto reliablytransferthebasemeshandsomeof theinitial splitsanduseamoreaggressive techniqueto transferlessimportantsplits.

TCPcontrolstheratethatpacketsaresentto maintainflow con-trol andminimize congestion.As a result,TCP doesnot providetheend-usercontrolof thesendingrate. Whenwe considerusingUDPfor transmissionof data,theend-userhassignificantinfluenceover thesendrate.Therefore,our applicationmustcarefullyselectthesendrate. If thesendrateexceedsthecapacityof thechannel,we will increasethe numberof packets lost. However, if we de-creasethesendrate,we will not loseany packetsbut the transferof informationwill take muchlongerthanaTCPconnectionmighttake. WeexperimentallydetermineUDPsendratesto usein appli-cations.In futurework, we will investigateautomaticmechanismsfor settingtheUDPsendrate.

An issueof concernin implementingthis ideais thatthesendercanbegin sendingUDP datato the receiver while the receiver isstill readingdatafrom theTCP connection.This behavior causesa problemsincethe initial datawill fill up the operatingsystem’s

NRcv7 NSnd8

PSnd NSnd7 NRcv8

PRcv

SW7

SW8BRG

Figure5: TestbedSetup

buffer for incoming network dataand start droppingUDP pack-etsthatarrive. Therefore,thehybrid protocoladdsa delaybeforesendingtheUDPdatauntil thereceiver hasreceivedall TCPdata.

4. EXPERIMENT AL DESIGNIn this section,we presentthedesignof anexperimentaltestbed

to exploretheuseof TCPandseveralhybridprotocols(TCP/UDP)to transmit3D geometriesof two differentmodelsacrossa con-gestednetwork. Weuseanetwork testbedthatallowsusto emulatethenetwork behavior of congestedlinks. Thetestbedconsistsof abridgemachineandfour hostsusedto generatebackgroundnoisetraffic acrossthebridge.

4.1 TestbedSetupFigure5 shows the setupof our testbed.Our testenvironment

consistsof two usermachines(PSnd,PRcv),four backgroundloadmachines(NSnd , NRcv , NSnd9 , NRcv9 ), one bridge machine(BRG)andtwo 100Mbpsswitches(SW , SW9 ).

Processor Memory OS

PSnd,PRcv 800Mhz AMD1 256MB Redhat7.3NSnd , NRcv 800Mhz AMD 256MB Redhat7.3NSnd9 , NRcv9 800Mhz AMD 256MB Redhat7.1BRG 1 GhzPentiumIII 512MB FreeBSD4.3

Table 1: Specificationsfor machinesusedin experiments.

The bridge runs the FreeBSDoperatingsystemand its kernelis compiledwith optionsBridge,Dummynet,HZ=1000andNMB-CLUSTERS=10,000.TheBridgeandDummynetoptionsallow theuseof this machineto emulatea WAN characteristicsfor packetssentbetweenSW andSW9 . TheHZ option improvestheresolu-tion of theoperatingsystem’s timer. TheNMBCLUSTERSoptionis setpreventkernelfrom runningoutof mbuf clusters.

The parametersrmem_max and wmem_max in a Linux net-working corearechangedfrom 64kB to 8 MB. Theseparametersspecifythemaximumamountof memoryasocket read/writebuffercan use,respectively. Increasingthem allows sockets to specifylarger buffer sizesthan the default maximumof 64kB. PSndandPRcvenableTCPwindow scalingandsettheread/writebuffer sizeto 8 million bytes. This option reducesperformancelimits intro-ducedby flow control asdescribedin Section2.1. Most userap-plicationswouldnothave theflexibility to resetthesystemsettingsand thereforewould be limited to using lessbandwidth. In ourexperiments,wehave tunedtheTCPsystemto obtainthebestpos-sibleresultsfor wide-areanetwork transmission. AMD/Duron Processor

As shown in Figure5, PSnd,NSnd andNRcv9 areconnectedwith SW: . PRcv, NRcv andNSnd9 areconnectedwith SW9 . ThebridgeroutespacketsbetweenSW andSW9 .4.2 Emulated WAN

Thesetupdescribedabove emulatesa WAN. TheWAN is emu-latedfor severalspecificreasons.First, it providesanenvironmentin which repeatableexperimentscan be conducted. If this weredeployedover a truewide-areanetwork, two differentexperimentscouldhavesignificantlydifferentamountsof packet lossandqueu-ing delays.An alternativeapproachwouldbeto useanetwork sim-ulatoror modelto analyticallyevaluatetheperformanceof differenttransmissionmethods.Theanalytictechniquesuffersfrom thedis-advantagethatmany network modelsfail to adequatelycapturetheunderlyingcharacteristicsof real networks andthe interactionsofcomplex protocolssuchasTCP.

Dummynet[29] providesastandardimplementationfor emulat-ing WANs. It allows usersto createpipesof communicationwithspecifiedbandwidthlimits andpropagationdelays.Thesepipesaredefinedby matchingheaderinformationsuchassourceanddesti-nationIP addresses.

In all experiments,Dummynetlimits the bandwidthand addspropagationdelaysto packetssentbetweenswitchesSW andSW9 .Specifically, we createtwo pipes,eachwith a bandwidthlimit of50Mbps and 25mspropagationdelay. Most WAN communica-tion will involve muchlongerpropagationdelays.As a result,wehave erredon thelow end,which will improve theperformanceofthe TCP transmissionin our experiments.The traffic from PSnd,NSnd andNRcv9 sharesonepipeandthetraffic fromPRcv, NRcv andNSnd9 sharesthe other. Two pipesarenecessaryto emulatetheout-boundandin-boundbandwidthbetweenthesenderandre-ceiver. If thenoisegeneratedis notgreaterthanthechannelcapac-ity, thenpacketswill not belost on theemulatednetwork. In otherwords,acongestednetwork requiresmoredatato besentthanthereis channelcapacityavailable.

4.3 Background LoadThe backgroundload generatorconsistsof two UDP compo-

nents,a senderand a receiver. The backgroundload generatorsimulatesthe network characteristicsof a large numberof exter-nal applications,communicatingover a shareddata link. Previ-ousresearchhasestablishedthatthetimebetweenpacketsarrivingat a routermatchesa Paretodistribution [24]. This distribution isheavy-tailed, in that most of the inter-arrival times are small butthereareperiodsof significantdelay. TheParetodistribution cre-atesself-similarbehavior in the network, i.e., therearetime scaleindependentburstsof packet activity.

Eachof the two pairsof backgroundloadmachineshasa noisesenderanda noisereceiver. ThenoisesendersendsUDP packetsof size1400bytesto the thenoisereceiver, sleepingfor a randomamountof timebeforesendingthenext packet. TherandomtimeitwaitsfollowsaParetodistribution,whichfavorsshorterwait times.This effect causesthepacketsto have a higherprobabilityof beingsentin burststhanevenly spaced.

5. EXPERIMENT AL RESULTSWe testedour transmissionmethodsby runninga setof exper-

imentswith varying levels of backgroundload usinga variety ofmodels.Wereportresultsfor two models,the“happy Buddha”anda modelof a Cessna.TheBuddhamodelcontains1.08M facesinits full modeland1998facesin its basemesh.TheCessnamodelhas13546facesand338 in its basemesh.Experimentsinvolvingthe Buddhamodelconsistof six runsof the experiment. Experi-

85 90 95 100 105 110 115 120 125 130 1350

50

100

150

Average Channel Capacity Used by Noise (expressed as % of total)

Tim

e (s

)

Average Time of Transmission vs. Channel Capacity with UDP send rate = 11.424 Mbps

0% TCP12.5% TCP25% TCP50% TCP100% TCP

Figure 6: The average time of transmission of the Buddhamodel versus the channel capacity for the differ ent transmis-sionschemes(TCP/UDP ratios). The UDP sendrate was11.424Mbs.

mentsinvolving theCessnamodelconsistof tenrunsof theexper-iment. We presenttypical resultsin this sectionanddiscussthem,but graphsof theresultsof all experimentscanbefoundin theAp-pendix. The resultsarediscussedin termsof the averagevaluesacrossa setof runs. Someexperimentstimed out, i.e., they didnot complete,sotheaverageis theaverageof theexperimentsthatcompletedin under200seconds.In theexperiments,we measurethetime takento transmittheprogressive mesh,theactualnumberof vertex splitsreceivedby thereceiver, andthenumberof facesinthefinal meshreconstructedby thereceiver. Thenumberof facesis importantbecausesomeof the vertex splits that arrive may beunusablebecauseof a previously droppedpacket. We alsocom-putethe Hausdorff distancefrom the reconstructedmeshesto theoriginal full mesh.Finally, thesuiteof experimentswasrun usingdifferentsendratesfor theUDPportionof themodeltransmission.

5.1 Resultsfor Buddha ModelFigure 6 shows the averagetransmissiontime for the various

transmissionschemes,andFigure7 shows theaveragenumberoffacesreceived versuschannelcapacity. In thesefigures,the UDPsendratewas11.424Mbps,andTCPwasusedto transmitthebasemeshplus0 to 50%of therestof themodel.Notethatthelineshavedifferentlengthbecauseat certainpoints,noneof theexperimentsfor thatdatapointcompletedwithin thetimeoutperiod.Theimpor-tantresultin Figure6 is thatthetransmissiontimeto sendthemodelusing pure TCP is the longest. Moreover, as the ratio of pack-etssentby TCP decreases,the transmissiontime improvesfor allgiven levels of noise. To explain this behavior, onemustconsiderwhat happenswhenwe increasethe amountof noise. When thenoiseexceedsthechannelcapacity, thechannelis full, andbuffersin thenetwork becomesaturated.This saturationresultsin packetloss.As discussedin in Section2, packet losscausesTCPto incurtimeoutsor apply the fastretransmissionscheme.Thus,thetrans-missiontimeusingTCPincreases.As afinal note,the0%TCPplotin this figure is not quiteconstantbecause,asmentioned,thebasemeshis transmittedreliablyusingTCP.

This transmissiontime improvementcomesat a cost,however.Figure7 shows thenumberof facesin thereceivedmodelfor each

85 90 95 100 105 110 115 120 125 130 135200

300

400

500

600

700

800

900

1000

1100


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)Average Number of Faces in Received Model vs. Channel Capacity for UDP send rate = 11.424 Mbps


Figure 7: The number of facesreceived of the Buddha modelversuschannelcapacity for the differ ent transmissionschemes(TCP/UDP ratios). The UDP sendrate was11.424Mbs.

of thesetransmissionmethods.NotethatTCP, sinceit is a reliabletransportprotocol,alwaystransmitsall the faces.Whena portionof the packetsaresentusingUDP, significantpacket losscanoc-cur, and this loss becomesworseas the noiseincreases.There-fore theselectionof anappropriatehybrid protocolwill dependonthetradeoff betweenthetransmissiontime andthevisualdegrada-tion that occurswhenpacketsarelost. The visual degradationofthis processis shown in the Buddhamodel in Figure8. This fig-ure shows themodelsthatwerereceived in oneexperimentusinga UDP sendrateof 11.424Mbps andwherethe noiseconsumed109%of the channelcapacity. In particular, the visual quality ofthemodelis excellentwhen50%of it is transmittedvia TCP. TCPtook on average131 secondsto transmitat this noiselevel, whiletheaveragetransmissiontimefor the50%schemewas73seconds,aconsiderablesavings.Hausdorff distancesbetweenthefull modelandthesemodelsareshown in Table2.

In Figure 9, we seean exampleof the benefitof sendingthemodel via the hybrid transmissionscheme. The graphplots theHausdorff distancebetweenaPM representationwith theindicatednumberof facestransmittedandthefull model.Thegraphshows amodelwhereonly 25%of it is transmittedvia TCP, andonetrans-mitted completelyvia TCP. The dottedline indicatesthe point atwhich thegraphswill begin to diverge.Botharemonotonicallyde-creasing.It takeson average120secondsto sendthemodelfullyvia TCP, whereasthehybridscheme’s averagetransmissiontime isonly 70 seconds.Thus,we get improvementin themodelasmea-suredby theHausdorff distanceatasavingsof 50secondsin trans-missiontime. Notethatsending25%of themodelvia TCPtakesonaverage36 seconds,andsending50%of themodelvia TCPtakeson average70 seconds.Theseresultsshow thatto have a moreac-curatemodeltransmittedby TCPtakesconsiderablylonger, almost50 seconds.Alternatively, thenumberof facesin themodelmustbe reducedby half for pure TCP transmissionto transmitin thesameamountof time asthehybrid method,andthefidelity of thepureTCPmodelthustransmittedis lower.

A significantconcernin any transmissionschemeis thattheband-width of the schemeis minimal. In Figure 10, we comparethenumberof bytesusedto transmittheBuddhamodelby both TCPandUDP aswe increasethe amountof backgroundnoise. UDP

0 2 4 6 8 10 12

x 105

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1x 10

−4

Hau

sdor

ff D

ista

nce

Number of Faces in Transmitted Model

Hausdorff Distance vs. Number of Faces in Transmitted Model

25% TCP100% TCP

Figure9: The Hausdorff distanceversusnumber of facesin theBuddha modelfor thecaseswhenthemodelis transmitted com-pletely by TCP and 75% of the model is transmitted via UDP.The UDP sendrate was 2.285Mbs and the network load was110% averagechannel capacity. The dotted line indicates thepoints where the graphs diverge, i.e., where 25% of the modelhasbeentransmitted via TCP.

is constantby design—itis equivalent to the TCP 0% line in thepreviousfigures.NotethatTCPusesmorebandwidthasthenoiseincreases,from 1.3 to 4.6%. This resultis unsurprisingsinceTCPmust re-sendlost packets, requiresthe useof acknowledgments,andhasa largerheadersizethanUDP packets.Notethatthecom-parisonin Figure10doesnot includethebandwidthof packetsusedto acknowledgereceiptof databy thePM receiver.

5.2 Resultsfor CessnaModelAnalogousto theprevioussection,Figure11 shows theaverage

transmissiontimeof theCessnamodelfor thevarioustransmissionschemes,andFigure12showstheaveragenumberof facesreceivedversuschannelcapacity. In thesefigures,the UDP sendratewas7.616Mbps. Thevisualdegradationof themodelscanbeseeninFigure13. Theseresultsaresimilar to thosefor theBuddhamodel,

% Sent UDPSendRate(Mbs)TCP 15.232 11.424 7.616 2.285

BuddhaModel0 6.5300 2.4100 4.2400 2.420012.5 0.1360 0.1510 0.1020 0.089925.0 0.0475 0.0470 0.0360 0.023750.0 0.0236 0.0195 0.0175 0.0113

CessnaModel0 2.1095 2.2971 1.5034 2.655912.5 2.3495 1.1153 0.9845 0.548125.0 1.2377 2.3151 1.3259 0.489550.0 2.0762 0.7406 2.0183 1.5599

Table 2: Hausdorff distancebetweentransmitted model (Bud-dha first, followed by Cessna)and full model for various trans-missionschemes(TCP/UDP ratios) in units of ;�#�<�= .

Figure 8: The Buddha model after transmissionover a lossynetwork: (a) the full model assentby TCP; (b) model received when50% transmitted by TCP; (c) modelwhen25% sentby TCP; (d) modelwhen12.5%sentby TCP; (e)modelwhenfully sentvia UDP.

80 85 90 95 100 105 11015.9

16

16.1

16.2

16.3

16.4

16.5

16.6

16.7


Num

ber

of B

ytes

(M

B)

Total Bytes Sent by TCP and UDP

Figure 10: Total bytes sent by TCP (dashed line) and UDP(solid line) versusnoisein the channel.Note that the UDP sendrate is constant,but the number of bytessentby TCP increasesasit must resenddata due to lost packets.

however thereis considerablymorevariancein the results. Thisvarianceis largely dueto thesignificantlysmallernumberof TCPpackets transmitted,becausethe Cessnamodelis roughly two or-dersof magnitudesmallerthantheBuddhamodel.As a result,thebasemeshfor theCessnamodelonly consistsof threeor four pack-ets.Therefore,if theinitial SYN2 requestis lost, theresultscanbesignificantlyskewed. This skewing occursbecausetheLinux TCPimplementationsignificantlyincreasesthe packet timeoutvalueifoneof the SYN packetswaslost. Therefore,whenan additionalpacket is lost during transmission,a long timeoutoccurs(on theorderof fiveto fifteenseconds)thatsignificantlyeffectstheresults.If aninitial packet is not lost, thetimeoutswill only beontheorderof 400ms.Note thatwe do not counttheconnectionsetuptime inour results,thereforeour resultsdo not includetheSYN timeouts.

5.3 Discussionof Image ResultsBoth theBuddhaandCessnamodelshave uncharacteristicflaws

in the reconstruction.Theseflaws are apparentin Figures8 (d)and(e) andin Figures13 (c) and(d). Visually, the flaws appearto bemissingtriangles.However, theseflaws areaneffect of self-intersectionsof themeshsurface,i.e.,certaintrianglespiercingthemodel.Theinwardfacingnormalsof thesetrianglesmaketheflawsnoticeable.Thesurfaceself-intersectionsaretheresultof thePMencodingschemeandthelost transmissionpackets.

Since �� !�" is the relative order of the index value of ��2amongthe threeverticeson �� , whenpacketsare lost the re-constructionprogramoccasionallyfails andsplits the wrong ver-tex. When a packet is lost, subsequentvertex splits may arriveat the receiver in differentcontexts from thosein the original PMrepresentation,i.e., theverticesadjacentto thesplit vertex �62 maybe different. This information loss can causegeometriccorrup-tion, asshown in Figure14. In Figure14 (a), without packet loss,intermediatevertex splits changethe threeverticesof face �/>?> to65, 96 and 114. A subsequentvertex split with ��5�� =66 and�� !�" =1 splitsvertex 96 becauseits index is thesecondsmall-

9 TCPusestheSYN packetsto initiate a requestusinga three-wayhandshake.

Figure 13: The Cessnamodel after transmissionover a lossynetwork: (a) the full model assentby TCP; (b) model received when50% transmitted by TCP; (c) modelwhen25% sentby TCP; (d) modelwhen12.5%sentby TCP; (e)modelwhenfully sentvia UDP.

85 90 95 100 105 110 115 120 125 130 1350

10

20

30

40

50

60


Tim

e (s

)



Figure 11: The average time of transmission of the Cessnamodel versus the channel capacity for the differ ent transmis-sion schemes(TCP/UDP ratios). The UDP sendrate was7.616Mbs.

85 90 95 100 105 110 115 120 125 130 1355

6

7

8

9

10

11

12

13

14


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)

Average Number of Faces in Received Model vs. Channel Capacity for UDP send rate = 7.616 Mbps


Figure 12: The number of facesreceived of the Cessnamodelversuschannelcapacity for the differ ent transmissionschemes(TCP/UDP ratios). The UDP sendrate was7.616Mbs.

(a)

(b)

f @ @ =

=f @ @

f @ @

20

f @ @45

96

11465

f @ @

65

f @ @

Figure 14: Illustration of self-intersectionoccurrence: (a) Nopacket loss,intermediate vertex splits changethe thr eeverticesof face � >?> to 65, 96 and 114; (b) Packets containing the in-termediate vertex splits are lost, the thr eevertices of face �/>?>remain unchangedas65,20,45.

est. Whenthe intermediatesplits are lost, asshown in Figure14(b), the threeverticesof face �/>?> remainunchangedas65, 20, 45.Vertex 45 hasthesecondsmallestindex amongtheverticesof � >?>now. The samesplit with �� =66 and �� !�" =1 thensplitsvertex 45 andcausesthe facesconnectedwith theaddedvertex topiercethroughthetop right face.

A pessimisticreceiver would try to identify all out-of-contextsplitsandthrow themaway. Implementingthis pessimisticpolicyrequiresadditionalbandwidthto transmitthe context informationfor eachvertex split, however. Also, pessimisticpolicieswill causemany splitsto bediscardedat moderatepacket losslevels.

In our protocoldesign,we choseto minimize theadditionalin-formationsentfrom senderto receiver. As a result,our reconstruc-tion programdiscardssplitswhose��5� fieldsreferencefacesthatarenot reconstructedbecausethevertex splits to reconstructthosefacesare lost, andsplits whose ��+ +-,-. fields have valueslargerthanthedegreeof ��2 becauseprevioussplitsto addfacesconnectedwith � 2 arelost. All otherreceivedsplits,whichmayincludesomeout-of-context splits,areapplied.This receiver behavior tradesoffpotentialcorruptionof themeshagainstthepotentialimprovementin themodelwhenthevertex orderingsarevalid.

Wearecurrentlyinvestigatingwaystoapplyout-of-context splitswithout corruptingthemesh.

6. CONCLUSIONIn thispaper, wehavedemonstratedthatusingahybridapproach

to send3D geometryover congestednetworks can improve thetransmissionperformance. Additionally, the hybrid schemecan

2 4 6 8 10 12 14 1615

20

25

30

35

40

45

50

55

60

UDP Send Rate (Mbs)

Tim

e (s

)

Transmission Time vs. UDP Send Rate for 7/8 of Buddha Model sent via UDP

Figure 15: Transmission time of the the Buddha model with87.5% of the modelsentvia UDP versusthe UDP sendrate.

result in a higherquality result than transmittingvia TCP for anequivalent amountof time, asshown in Figure9. This improve-ment in performancecomesat the costof lost packets. The pro-gressive meshrepresentationallows us to minimize thevisual im-pactwhenpacketsarelost,althoughsomesurfacecorruptionis of-tenvisible. We arecurrentlyinvestigatingmethodsof representingandreconstructingtheprogressive meshthateliminatethis corrup-tion with lessoverheadthanemploying a forwarderrorcorrection(FEC)codearbitrarilyon thedata.

Therearemany avenuesfor futureresearch.Onedirectionis toexploretherefinementschemeof Bischoff andKobbelt[5] andin-vestigateits incorporationinto our transmissionprotocol.Anotherdirection is to determinehow muchmodel degradationusersarewilling to tolerate,andusethis knowledgeto selectanappropriateUDP sendratefor our hybrid approach.Onesignificantresult isthatwhentransmittingsmallmodelssuchastheCessnamesh,thepoorperformanceof theTCPconnectionhasadisproportionateef-fecton thetotal transmissiontimeof themodel.In futurework, weplan on consideringa FEC codethat couldbe usedto encodethebasemesh.TheFECcodewould allow reconstructionof thebasemesheven whensomepackets have beenlost, and thus we maypotentiallyabandonTCPasa protocolaltogether.

Additionally, determinationof an optimal UDP sendrate is aninterestingopenproblem.ThatanoptimalUDP sendrateexists isevidencedby Figure15, wherethe transmissiontime of the Bud-dhamodelis shown for variousUDPsendrates,when12.5%of themodelis transmittedvia TCP. Wewouldliketo automaticallydeter-minethekneeof this curve. In particular, we would like to evolvethe methodinto an adaptive scheme,where the sendingmecha-nismautomaticallydetectsthenetwork conditionandoptimizesthesendratefor boththestateof thenetwork andthemodelin a TCP-friendly manner.

APPENDIX

A. COMPLETE DATA OF TRANSMISSIONTIMES AND FACES

Figures16through27detailtheaverageresultsfor all theexper-imentsrun.

B. REFERENCES[1] AL -REGIB, G., AND ALTUNBASAK , Y. An unequalerror

protectionmethodfor packet lossresilient3-dmeshtransmission.In Proceedings of INFOCOM 2002 (2002).

[2] ALLEN, A. D. Optimaldeliveryof multi-mediacontentovernetworks.In Ninth ACM Multimedia Conference (Ottawa,Ontario,Canada,30 Sept.–5Oct.2001),pp.79–88.

85 90 95 100 105 110 115 120 125 130 1350

20

40

60

80

100

120

140


Tim

e (s

)



Figure 16: The average time of transmission of the Buddhamodel versus the channel capacity for the differ ent transmis-sionschemes(TCP/UDP ratios). The UDP sendrate was15.232Mbs.

85 90 95 100 105 110 115 120 125 130 135100

200

300

400

500

600

700

800

900

1000

1100


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




85 90 95 100 105 110 115 120 125 130 1350

5

10

15

20

25

30

35

40

45


Tim

e (s

)



Figure 18: The average time of transmission of the Cessnamodel versus the channel capacity for the differ ent transmis-sionschemes(TCP/UDP ratios). The UDP sendrate was15.232Mbs.

85 90 95 100 105 110 115 120 125 130 1354

5

6

7

8

9

10

11

12

13

14


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




85 90 95 100 105 110 115 120 125 130 1350

10

20

30

40

50

60


Tim

e (s

)



Figure 20: The average time of transmission of the Cessnamodel versus the channel capacity for the differ ent transmis-sionschemes(TCP/UDP ratios). The UDP sendrate was11.424Mbs.

85 90 95 100 105 110 115 120 125 130 1355

6

7

8

9

10

11

12

13

14


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




85 90 95 100 105 110 115 120 125 130 1350

20

40

60

80

100

120

140

160

180

200


Tim

e (s

)



Figure 22: The average time of transmission of the Buddhamodel versus the channel capacity for the differ ent transmis-sion schemes(TCP/UDP ratios). The UDP sendrate was7.616Mbs.

85 90 95 100 105 110 115 120 125 130 135200

300

400

500

600

700

800

900

1000

1100


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




85 90 95 100 105 110 115 120 125 130 1350

20

40

60

80

100

120

140


Tim

e (s

)



Figure 24: The average time of transmission of the Buddhamodel versus the channel capacity for the differ ent transmis-sion schemes(TCP/UDP ratios). The UDP sendrate was2.285Mbs.

85 90 95 100 105 110 115 120 125 130 135400

500

600

700

800

900

1000

1100


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




85 90 95 100 105 110 115 120 125 130 1350

5

10

15

20

25

30

35

40

45

50


Tim

e (s

)



Figure 26: The average time of transmission of the Cessnamodel versus the channel capacity for the differ ent transmis-sion schemes(TCP/UDP ratios). The UDP sendrate was2.285Mbs.

85 90 95 100 105 110 115 120 125 130 1358

9

10

11

12

13

14


Num

ber

of F

aces

in R

ecei

ved

Mod

el (

thou

sand

s)




[3] ALL IEZ, P., AND DESBRUN, M. Progressive compressionfor losslesstransmissionof trianglemeshes.In Proceedingsof ACM SIGGRAPH 2001 (July2001),ComputerGraphicsProceedings,AnnualConferenceSeries,ACM Press/ ACMSIGGRAPH/ AddisonWesley Longman,pp.195–202.

[4] ASPERT, N., SANTA-CRUZ, D., AND EBRAHIMI , T. Mesh:Measuringerrorsbetweensurfacesusingthehausdorffdistance.In Proceedings of the IEEE InternationalConference in Multimedia and Expo (ICME) (2002),pp.705–708.http://mesh.epfl.ch.

[5] BISCHOFF, S., AND KOBBELT, L . Streaming3dgeometryover lossycommunicationchannels.In Proceedings of theIEEE International Conference on Multimedia and Expo(2002).

[6] BLAKE, S., BLACK , D. L ., CARLSON, M. A., DAVIES, E.,WANG, Z., AND WEISS, W. An architecturefordifferentiatedservices.Requestfor Comments,RFC2475,1998.

[7] BRADEN, R., CLARK , D., AND SHENKER, S. Integratedservicesin theinternetarchitecture:anoverview. RequestforComments,RFC1633,1994.

[8] CASNER, S., AND DEERING, S. First IETF Internetaudiocast.ACM Computer Communication Review 22, 3(July1992),92–97.

[9] CHEN, B.-Y., AND NISHITA , T. Multiresolutionstreamingmeshwith shapepreservingandqos-like controlling.InProceeding of the 7th International Conference on 3D WebTechnology (2002),pp.35–42.

[10] COMER, D. E. Internetworking with TCP/IP, Principles,Protocols, and Architectures, fourthed.PrenticeHall, 2000.

[11] CONRAD, P. T., CARO, A., AND AMER, P. ReMDoR:Remotemultimediadocumentretrieval over partialordertransport.In Ninth ACM Multimedia Conference (Ottawa,Ontario,Canada,30Sept.–5Oct.2001),pp.169–180.

[12] http://everquest.station.sony.com.[13] FLOYD, S., JACOBSON, V., L IU, C.-G., MCCANNE, S.,

AND ZHANG, L . A reliablemulticastframework forlight-weightsessionsandapplicationlevel framing.IEEE/ACM Transactions on Networking 5, 6 (1997).

[14] FRECON, E., GREENHALGH, C., AND STENIUS, M. TheDIVEBONE — anapplication-level network architectureforInternet-basedCVEs.In Proceedings of the ACM Symposiumon Virtual Reality Software and Technology (VRST) (London,UK, 20–22Dec.1999),pp.58–65.

[15] GANDOIN, P.-M., AND DEVILLERS, O. Progressivelosslesscompressionof arbitrarysimplicial complexes.ACMTransactions on Graphics 21, 3 (July2002),372–379.ISSN0730-0301(Proceedingsof ACM SIGGRAPH2002).

[16] GARLICK , L . L ., ROM , R., AND POSTEL , J. B. Reliablehost-to-hostprotocols:problemsandtechniques.InProceedings of the Fifth Data Communications Symposium.Applications, Technologies, Architectures, and protocols forComputer Communication (Snowbird, Utah,USA, 1977).

[17] HOPPE, H. Progressive meshes.In Proceedings ofSIGGRAPH 96 (New Orleans,Louisiana,August1996),ComputerGraphicsProceedings,AnnualConferenceSeries,ACM SIGGRAPH/ AddisonWesley, pp.99–108.ISBN0-201-94800-1.

[18] HOPPE, H. View-dependentrefinementof progressivemeshes.In Proceedings of SIGGRAPH 97 (LosAngeles,California,August1997),ComputerGraphicsProceedings,AnnualConferenceSeries,ACM SIGGRAPH/ Addison

Wesley, p. I198. ISBN 0-89791-896-7.[19] HOPPE, H. Efficient implementationof progressive meshes.

Computers & Graphics 22, 1 (February1998),27–36.ISSN0097-8493.

[20] KHODAKOVSKY, A., SCHRODER, P., AND SWELDENS, W.Progressive geometrycompression.In Proceedings of ACMSIGGRAPH 2000 (July2000),ComputerGraphicsProceedings,AnnualConferenceSeries,ACM Press/ ACMSIGGRAPH/ AddisonWesley Longman,pp.271–278.ISBN 1-58113-208-5.

[21] KLEIN, R., L IEBICH, G., AND STRASSER, W. Meshreductionwith errorcontrol.In IEEE Visualization ’96(1996),R. YagelandG. M. Nielson.,Eds.,pp.311–318.

[22] MACEDONIA , M. R., ZYDA , M. J., PRATT, D. R.,BRUTZMAN, D. P., AND BARHAM , P. T. Exploiting realitywith multicastgroups.IEEE Computer Graphics andApplications 15, 5 (Sept.1995),38–45.

[23] PAJAROLA , R., AND ROSSIGNAC, J. Compressedprogressive meshes.IEEE Transactions on Visualization andComputer Graphics 6, 1 (January- March2000),79–93.ISSN1077-2626.

[24] PARK , K., K IM , G., AND CROVELLA , M. On therelationshipbetweenfile sizes,transportprotocols,andself-similarnetwork traffic. In Proceedings of the FourthInternational Conference on Network Protocols (ICNP ’96)(October1996).

[25] PEJHAN, S., HAO CHIANG, T., AND ZHANG, Y.-Q.Dynamicframeratecontrolfor videostreams.In SeventhACM Multimedia Conference (Orlando,FL, USA,30 Oct.–5Nov. 1999).

[26] POPOVIC, J., AND HOPPE, H. Progressive simplicialcomplexes.In Proceedings of SIGGRAPH 97 (Los Angeles,California,August1997),ComputerGraphicsProceedings,AnnualConferenceSeries,ACM SIGGRAPH/ AddisonWesley, pp.217–224.ISBN 0-89791-896-7.

[27] POSTEL , J. Transmissioncontrolprotocol.RFC793,http://www.rfc-editor.org/rfc/rfc793.txt,Sept.1981.

[28] REJAIE, R., HANDLEY, M., AND ESTRIN, D. Qualityadaptationfor congestioncontrolledvideoplaybackover theinternet.In ACM SIGCOMM Conference. Applications,Technologies, Architectures and Protocols for ComputerCommunications. (Cambridge,MA, USA, 30Aug.–3Sept.1999),vol. 29(4)of Computer Communication Review.

[29] RIZZO, L . Dummynet:asimpleapproachto theevaluationofnetwork protocols.ACM SIGCOMM ComputerCommunication Review 27, 1 (Jan.1997).

[30] SINHA , P., NANDAGOPAL , T., VENKITARAMAN, N.,SIVAKUMAR, R., AND BHARGHAVAN, V. WTCP:Areliabletransportprotocolfor wirelesswide-areanetworks.Wireless Networks 8, 2/3 (Mar.–May2002).

[31] STEVENS, W. R. UNIX Network Programming, NetworkingAPIs: Sockets and XTI, secondeditioned.PrenticeHallPTR,1998.

[32] TAUBIN, G., GUEZIEC, A., HORN, W., AND LAZARUS, F.Progressive forestsplit compression.In Proceedings ofSIGGRAPH 98 (Orlando,Florida,July1998),ComputerGraphicsProceedings,AnnualConferenceSeries,ACMSIGGRAPH/ AddisonWesley, pp.123–132.ISBN0-89791-999-8.

[33] ZHANG, L ., DEERING, S., ESTRIN, D., SHENKER, S.,AND ZAPPALA , D. RSVP:A new resourceReSerVation

Protocol.IEEE Network 7, 5 (Sept.1993),8–18.

robust transmission of 3d geometry over lossy networks

Documents