Gamma:A Content-Adaptation Server for Wireless

MultimediaApplications

Yui-WahLee,Girish Chandranmenon,ScottC. Miller

Bell Laboratories

101CrawfordsCornerRoad,HolmdelNJ 07733USA

Email:�leecy,girishc,scm � @bell-labs.com

Abstract

An important technique for wireless multimedia is content adaptation – the on-demand

transcoding of multimediafrom one format to another or from onefidelity to another so as

to fit the specific needs of different wirelessterminals, which typically have limited band-

widths andresources. In this paper, we present the design, implementation, andevaluation

of a content-adaptation server calledGamma,which supports the automatic andtransparent

transcoding for individual usersaccording to their pre-configureduser profiles. While there

have beenother works on multimedia transcoding in the literature, Gammais novel in three

aspects. First, we pay special attention to allow the incorporation of third-party transcoding

programs.This openapproachhasbeenvery important in therealworld. As a result, Gamma

canaccommodateabroadspectrumof third-partytranscodingutiliti esfor video, image,audio,

presentation, documents, etc. Second,we abstractout content-adaptation asa generic service

1

for wirelessapplicationsanddecoupletheformer from thelatter. Gammathuscansupport four

differentwirelessapplications that needtranscoding services: emailproxy, webproxy, email

recomposer, andemail outbox. Third, we addressthe difficult problemsof how userprofiles

arecreated andhow these profilesareusedto trigger automatic personalized transcoding. In

this paper, we alsopresent experimental evaluation on the benefitsof transcoding with a real

163.2-Kbps3G1X RTT airlink. Wealsoevaluatetheoverheadandscalability of thesystem.

Index terms: Multimedia, wireless, content-adaptation server, transcoding server, design

andimplementation, table-drivenarchitecture,personalizedprofile,3G1X RTT.

1 Intr oduction

Thereis a genuineneedto deliver multimediadataover wirelessdatanetworks. For example,

the industry consortium 3GPP(Third GenerationWirelessPartnershipProject)hasdefinedthe

standardfor Multimedia MessagingService(MMS) [2]. However, thereare several technical

challengestobeaddressedbeforewirelessmultimediaservicescanbedeployedeffectively. Firstly,

wirelessterminals– cell phones,PDAs (personaldigital assistants), notebookcomputers,andsub-

notebooks– areinherentlyresource-limited.Comparingto desktopcomputerswith LAN (local

areanetwork) connections,thesewirelessterminalshavesmallerform factors,limitedcomputation

powers,andnarrower bandwidths on their network links. Theselimited resourcescaneasilybe

overwhelmedby bulky multimediadatathatareoriginally intendedfor wirelinecomputers.

Secondly, thecomposition of wirelessuserterminalsareheterogeneous.Theseterminalsrun

differentoperatingsystems, have differentform factors,andmay have installed differentsetsof

applications. Furthermore,they mayusesomeproprietarymultimediaformatsthatotherterminals

2

donotuse.As aresult,it becomesmoreandmoredifficult for theprovidersof multimediacontent

to decidea priori what file formatsor form factorsaresuitablefor the terminalsof the intended

audience.

Thirdly, differentusersmayhave differentneeds.They usedifferentterminalsandhave their

own preferencesasto how multimediadatashouldbereceived. Eventerminalsof thesametype

mayhavedifferentcapabilities,sinceusersmayinstalldifferentapplications on theseterminals.

An importanttechniqueto addressthesechallengesis content adaptation – the on-demand

transcodingof multimediadatafrom oneformatto anotheror from onefidelity to anothersoasto

suit theparticularneedof a userandherterminal.A transcodingserver canbeplacedon theedge

of wired network that is interfacingto thewirelessnetwork. With individual personalizedprofile

configuredontheserverdatabase,transcodingcanbedonebeforeamultimediaobjectis delivered

over the wirelessnetwork to a userterminal. Thesetranscodingcanbe doneautomaticallyand

transparentlyto thesendersandreceivers. Therearemany potentialbenefitsof transcoding,and

Figure1 detailsexactlywhatthesebenefitsare.

However, while therehave beenother works on the individual componentsof multimedia

transcodingin the literature,not muchhasbeenreportedon how to build a content-adaptation

server to provide theoverall transcodingservices.In thispaper, wepresentthedesign,implemen-

tation,andevaluationof ourservercalledGamma.1 In Section2 wewill highlightthedifferenceof

ourwork with someprevious works. In anutshell,Gammais novel in thefollowing threeaspects.

First, we emphasizeon the incorporationof third-party transcodingutiliti es. Theseutilit ies

aretheprogramsthatcanperformthespecifictranscodingtasks.We do not assumethatwe can

developall typesof transcodingcapabilities,nordoweassumethatpeoplewill re-writetheir pro-1Gammastandsfor GeneralArchitecture for Multimedia Adaptation.

3

1 Transcode for streaming: Transcoding a video (or audio) clip to a streaming format en-ables the client to start viewing the clip as soonas the first few bytes arrive, instead ofwaiting for the entire clip to be downloaded. Thus,streaming insteadof downloadingre-duces the perceived latency in viewing a clip. Besides, somestreaming formats(such asMPEG4)aremore friendly to wireless channels thanother formats. Transcoding allowsdifferentusersto choose their own preferedstreaming formats.

2 Transcodeto a viewable format: Whenenddevicesarenotcapableof viewing adocumentin theoriginal format,transcodingcanconvert thedocumentto a formatthat theenddeviceunderstands. For example, an end device may not have a player for the RealVideo, butmay have a player for the H.263 format. Similarly, a device may not be equippedwith aMicrosoft PowerPointsoftwarebut it mayhave a webbrowser.

3 Transcodeto fit smaller form factors: Thereis probablynogood reason to sendanimagewith aresolution of 1024x768to auser usingaPDA of ascreen resolution230x200. In thiscase, we canre-scalethe imageto a smallersize. Theadvantageis two-folded. First, thelower-resolution imagewill have a smaller datasizeandcanbemoreeasilydeliveredon awireless network. Second,theuser will not needto play with scroll bars whenshereceivesanimagethatfits exactly herterminal’s screensize.

4 Transcode to a differ ent modality that the user terminal understands: A monochromePDA does not needto receive an imagein color; a PDA that canview imagesbut cannotview video doesnot need to receive a video clip. However, the usermay like to seewhattheobjectis, evenif it is seenin adifferentmodality. In thefirst case,wecantranscodethecolor imageinto a monochromeone. In the second case, we cantranscodethe video clipinto a sequenceof thumbnail images.

5 Split a large object into smaller sub-objects: For example,whena long Microsoft Pow-erPoint slide is split into multiple HTML pages, theusercanview anddownload only thepages thatsheis interestedin.

6 Avoid transmitting an unviewable object: In somecases, the usermay prefer not todownload certain types of multimedia objects. Typically, this happens whenthe object isunviewableon theterminal. For example, whentheobject is a PDFfile while theterminalhasno PDFviewer.

7 Reducenetwork traffic : In many cases, transcoding reduces the network traffic. Thishappenswhenthe transcodedobject hasa lower resolution, a lower quality, or whentheobject hasa moreefficient format(e.g.by compression).

8 Reducethe accesslatency of a multimedia object. Whenvideo/audio streaming is en-abled, or whenthenetwork traffic is reduced,intuitively theusershould perceive a smalleraccesslatency of the multimedia object. However, if the transcoding is doneon demand,it is alsopossible that the transcoding time is very slow andmayoffset any gain obtainedfrom a moreefficient transmission.We performedanexperimentin our evaluation sectionto addressthis concern.We foundthat in commoncasestranscodinggivesimprovementinaccesslatency (Section 9.2).

Figure1: BenefitsThatMay Be AchievedBy Transcoding

4

Type Input Output Transcoding Platform Providerobject object util ities

(wrappers)

MPEGto RealVideo video streaming rmbatch.exe WinNT RealNetworksvideo (mpeg2ram.bat)

MPEGto H263 video streaming mpeg trans.exxe WinNT LucentInternalvideo (mpg2jvs.bat)

MPEGto H263D/L video video mpeg trans.exe WinNT LucentInternal

CMF to MPEG video video cmf convertor.exe WinNT Casio Internalmplex.exe WinNT LucentInternal(cmf2mpg.bat)

AVI to H263 video streaming mpeg trans.exe WinNT LucentInternalvideo (mpg2jvs.bat)

MPEGto thumbnail video image mpeg trans.exe WinNT LucentInternal

CMF to audio video audio cmf convertor.exe WinNT Casio Internal

JPEGrescale image low-resolution convert Linux ImageMagickimage Studio [12]

JPEGlow quality image low-quality convert Linux ImageMagickimage Studio

JPEGgrayscale color grayscale convert Linux ImageMagickimage image Studio

TIFF to JPEG image image convert Linux ImageMagickStudio

PPMto JPEG image image cjpeg Linux IndependentJPEGGroup[8]

GIF to JPEG image image convert Linux ImageMagickStudio

GIF rescale image low-resolution convert Linux ImageMagickimage Studio

WAV to GSM audio audio sox Linux L. Norskog &C. Bagwell [3]

WAV low quality audio audio sox Linux L. Norskog &C. Bagwell

AU to WAV audio audio sox Linux L. Norskog &C. Bagwell

PPTto HTML Microsoft HTML & msconvert.exe WinNT LucentInternalPowerPoint image (ppt2html.bat)

DOC to HTML Microsoft HTML & msconvert.exe WinNT LucentInternalWord image (doc2html.bat)

Figure2: TranscodingCapabilitiesof theGammaSystem

Transcoding capabilities that have currently beenincorporated into the Gammasystem. In thecolumn of Transcoding util ities, the nameof the wrapper program is include in a parenthesis ifthereis one.In thecolumnof Platform,we list only thecomputerplatformthatwerun theutil ity intheGammasystem– theutil ity mayactually run in morethanoneplatform. In theGammasystem,eachof thecapability listed mayin turn make multiple capabiliti esin theMasterTable(Section7).For example, a JPEGimagemay be rescaledto fit the screen resolution of different types of userterminals. Eachof these will usea differentcommandline argumentandis considered a differentcapabilities in theMasterTable.

5

gramsaccordingto someAPI (applicationprogramming interface)that we would have defined.

We believe that takingout thesetwo assumptionsarevery important for practicaldeploymentof

transcodingservice. They arenot second-orderdetailsto be ignored,but they have often been

overlooked by otherworks,asdiscussionin Section2. Becausewe madevery few assumptions

abouttranscodingutiliti es,we caneasilyincorporatetheminto our system,aswe will explain in

Section4. As shown in Figure2, Gammaprovidesa very broadspectrumof transcodingcapabil-

ities – for video,image,audio,presentationslides,documentsetc. To thebestof our knowledge,

Gammais theserver thatprovidesthebroadestrangeof transcodingcapabilities.

Second,we do not tie transcodingservicesto a specificwirelessapplications.We believe that

theneedof contentadaptationis genericin thewirelessmultimediaworld. Differentwirelessap-

plications, suchasemailandweb,needthesamesetof transcodingservices.Therefore,wedesign

Gammato bea general-purposecontent-adaptation server. It offers transcodingservicesthrough

a GammaAPI, andit declaresits transcodingcapabilitiesthrougha systemtable. Theresultis a

veryflexiablearchitecturethatcurrentlyalreadyprovidesservicesto four differentwirelessappli-

cations:email proxy, web proxy, email recomposer, andemail outbox. The architecturewill be

describedin moredetailsin Sections3, 5, and7; Theapplicationswill bepresentedin Section6.

Third, weaddressthedifficult problemsof how userprofilesareusedautomatically andtrans-

parentlyfor personalizedtranscodingandhow theseprofilesarecreatedin the first place. Our

designdoesnot requireany changesmadeto the softwareon the sendernor the receiver sides.

Sections6 and8 will examine thesetwo problemsrespectively.

Besidesthese,Gammahasa table-drivenarchitectureandrunson a clusterof network com-

puters. It is thusvery extensible andscalable.The Gammasystemhasbeenoperationalin our

6

laboratorysinceJanuary2001. It was demonstratedin the 3GSM World Congressin Cannes,

Francein February2001.In Section9, we will presentexperimentalevaluation on thebenefitsof

transcodingwith a real3G1X RTT airlink (163.2Kbps). We will alsoevaluate theoverheadand

scalabilityof thesystem.

2 RelatedWork

TranSendis oneof theearlywork thatsuggestedon-the-flyadaptationby active transformational

proxies[6, 7]. TranSenditself only doeslossy Web imagecompression(as a servicefor UC

Berkeley dial-up users),althoughthe authorhasgeneralizedthe model of architecture(which

they call TACCfor Transformation, Aggregation,CachingandCustomization),whichcanbeused

in otherapplications. TranSend’s developersclaim that addingsupportof new datatypesis as

simple asaddinga new worker (a building block specializingin a particulartasksuchasscaling

or ditheringof imagesin a particularformat),but theseworkersneedto bewritten to theworker

API. Also, they seemsto have assumedthatall workersrunsonly on Unix platforms.In Gamma,

wedonothave thesetwo requirements.

Theteamof Quality-AwareTranscodingby Chandraet al. at Duke University hasdonesome

work to understandthe tradeoff characteristicsof transcodingof images:the informationquality

loss,the computational overheadrequiredin computing the transcoding,andthe potentialspace

benefits[5].

Maheshwari etal. emphasizedtheimportanceof integratingtranscodingserviceswith caching

proxies[11]. They pointedout thefact thatmany origin transcodingserver will mark transcoded

contentasun-cacheable.This markingpreventcachingto happenin proxies.Many advantagesof

7

caching,suchasreductionof network latency andreductionof server workload,will thusbelost.

They built a transcodingandcachingproxy calledTranSquid. TranSquidonly handletwo types

of objects:imageandHTML files – it canreducesdimensionandresolutionof image,andit can

replaceunwantedadvertisementsandbuttonsinto text links. Thetranscodingmodulein TranSquid

is tied togetherwith theweb-cachingproxy, while in our work Gammais a separatedtranscoding

server thatcanservedifferentapplicationssuchaswebproxiesor emailproxies.

Thereis an industrialeffort calledInternetContentAdaptationProtocol(ICAP) that tries to

standardizetheoff-loadingof valued-addedservices[1], [10]. Contentadaptationis oneof those

services,but otherservicessuchasvirusscanning,advertisementinsertion,human-languagetrans-

lation, and contentblocking are also possible. EssentiallyICAP is a lightweight HTTP-based

remote-procedure-callprotocolwhich allows a proxy to call out compute-intensive taskto a ded-

icatedserver. In Section6.2, we will presenthow we placea Gammaserver behindan ICAP

interface. The Gammaprovidestranscodingservicesto the ICAP server, who in turn offers the

servicesto awebproxyusingtheICAP protocol.

Of all thepreviousresearchworks, IBM’ s WebSphereTranscodingPublisheris probablythe

closestto our work [9]. Like our work, they advocatea pluggable infrastructure. However, their

plug-and-playarchitectureismoretightly-coupledthanours.Specifically, toaddanew transcoding

capability, a developerhasto usetheir developer’s toolkit to develop or re-developa programso

asto make the programpluggableinto their system. Whereasin our system,we canreuseany

existing transcodingexecutablesby simply installing theminto oursystemandaddinganentryto

ourconfigurationtable.

Probablydueto thesedifferentchoicesof plug-and-playarchitecture,oursystemprovidesmore

8

differenttypeof transcodingcapabilitiesthantheirsystem.While they mainlyprovidetranscoding

capabilitieswith respectto varioustypeof markup languagesandimages;weprovidetranscoding

capabilitieswith respectto videos, images,audio, and Microsoft-Office documents (Word and

PowerPoint).We alsooffer theenablingof videostreamingasa transcodingservice.

3 Ar chitectur e

Email Recomposer

SMTPPOP3

IMAP4

Email Proxy

Gam

ma A

PI

WirelessUserTerminals

Gam

ma A

PI Master Table

Stream

ing Video

HTTP SMTP

Web ProxyEmail

Outbox

Gam

ma A

PI

Gam

ma A

PI

File

File

File

File

mpg2ram mpeg_trans

cmf2mpg

cjpegsox

convert doc2html

Applications

Core GammaServer

User-TerminalProfiles

Transcoding Utilities

1

2

3

Figure3: ArchitecturalOverview

An architectural overview of the our system. It comprisesof threecomponents:(1) a collection of third-party transcoding utili ties, (2) the core Gammacontent-adaptation server, and (3) wirelessapplications. The mastertable and the userprofilesarekey system tables.

Figure3 shows an architecturaloverview of our system. Thereare threemain components.

Thefirst componentis a collectionof transcoding utilities (alsocalledtranscodingprograms).As

9

discussedin Section1, eachof theseis a third-partyprogramthat canperformcertainspecific

transcodingtasks. For example,the programconvert canconvert imagefrom oneformat to

another(suchasfrom GIF to JPEG).Thesetranscodingutilities arepluggedinto thecore Gamma

content-adaptation server, which is thesecondcomponentof thesystem.The interfacebetween

the coreGammaserver andthe transcodingutilit ies is theexec function (programinvocation)

of the operatingsystems. The core Gammaserver providesa transcodingAPI to the wireless

applications, whichconstitutethethird component.TheinterfacebetweenthecoreGammaserver

andthewirelessapplications is aGammaAPI togetherwith a tablecalledmaster table, which lists

thetranscodingcapabilitiesthattheGammaserver is configuredto offer.

We have implementedfour wirelessapplicationsusingGamma:anemailproxy, a webproxy,

an email recomposer, andan email outbox. Eachof the applications providesa specificservice

usingtheirownapplicationspecificprotocols.Forexample,theemailproxytranscodesmultimedia

attachmentsof emailmessagesbeforedelivering themessagesto auserusingtheIMAP4 or POP3

protocols.

Differentusersown differenttypesof terminals,andthey havedifferentpreferences asto how

multimediaobjectsshouldbetranscoded.Thesearedefinedin theper-uesr-and-per-terminal-type

userprofilesthatareconsultedby theapplicationsbeforemakingtranscodingdecisions.

Thereis aspecialcasefor videoobjectswhenthey aretranscodedinto streamingformats(such

asthe RealVideo format) – the Gammaserver alsohoststhe streamingservers. In this case,the

transcodedobject is cachedon a streamingserver, and the wirelessapplicationreturnsa URL

(uniformresourcelocator)to theuser, whocanthenusetheURL to startavideostreamingsession

from theGammaserver.

10

In the following sections,we aregoingto discussin moredetailsthe threemaincomponents

(Sections4, 5, and6), themastertable(Section7, andtheuserprofiles(Section8).

4 Transcoding Utilit ies

Wemadetwo importantdesigndecisionsregardingthetranscodingutilit iesin thesystem. First,we

did not assumethatwe would develop all thetranscodingutili tiesneededby our system.Second,

we did not assumethatpeoplewill write or re-writetheir transcodingprogramsto anAPI thatwe

would have defined.As discussedin thesectionof RelatedWork, many previous researchworks

have implicitly or explicitly madetheabove two assumptions.

Given our designdecisions,we needto definea strategy to accommodatea wide array of

differenttranscodingprograms.We know thattheexec functionsareavailableon mostcommon

operatingsystems.Therefore,a naturalchoiceto interfacetheGammaserver with theutili ties is

to usethesefunctions. Usingexecs, we canaccommodateany transcodingprogramswith the

following threeproperties:(1) Theprogramcanbeinvokedby a shellcommand.(2) It runson a

commoncomputing platformsuchasWindows NT, Windows 2000,or Linux. (3) It takesinput

filenamesandoutput filenamesascommand-linearguments.

Examplesof theseshellcommandsare

cjpeg -quality 40 -outfile <outfile> <infile>

mpeg_trans -H <outfile> -d 6 -r 64000 <infile>

Thesethreepropertieshavebeenverycommonto mostapplications. As of thetimeof writing,

theGammasystemcanaccommodateeighttranscodingprogramsandprovides19 differenttypes

11

of transcodingcapabilities,asshown in Figure2. Theseprogramsarefrom six differentproviders.

5 The CoreGammaServer

5.1 GammaAPI

As explainedin Section3, a wirelessapplicationrequestsa transcodingservicefrom theGamma

server using a GammaAPI (applicationprogramminginterface),which is basedon the HTTP

protocol.

To requesta specific transcodingtask, the requestingapplicationpicks a conversion label

(convLabel) definedin theMasterTable(Figure6). It embedsthelabelin a HTTP POSTcom-

mand,togetherwith the input filenameandoutput filename,it thenPOSTsthe commandto the

coreGammaserver. Uponreceiving thecommand,thecoreGammaserver will expandthecom-

mandinto a shellcommandandinvoke a transcodingutili ty (or its wrapperprogram)to carryout

therequestedtranscodingtask. Whenthetaskis completed,it will returntheresultin a response

to theHTTP POSTcommand.

The currentversionof the API assumesthat both the wirelessapplicationsand the Gamma

serveraresharingthesamenetworkfile system.Thismeansthatthey candeposittheinputfilesand

outputfiles into thefile systemandjust passaroundthefilenamesin theAPI. This is a reasonable

assumption sincetheapplicationsandtheGammaserver arelikely to beco-located.In future, if

thereis a needto remove this co-locationassumption, we canextendtheGammaAPI sothat the

multimediaobjectswill beembeddedobjectsin thePOSTcommandandthePOSTresponse.

12

5.2 GammaInter nal

Network File System

Dispatcher

H263

Real T

M

ConversionServer: Win1

ConversionServer: Linux1

cjpeg

convert

sox

cmf2mpg

mpeg_trans

mpg2ram

Stream

ingV

ideo

TranscodingUtilities

Master Table

ConverterTable

Wireless Applications

Wireless Clients

IPC

File

File

File

File

File

File

TranscodingUtilities

exec exec

…

…

…

IPC

1

2

3

4

ab

Figure4: InternalOrganizationof theGammaServer

In the core Gammaserver, thereare four main componentsof the core Gammaserver: (1) dispatcher, (2) conversion Servers, (3) transcoding utili ties, and (4)video-streamingservers. Therearealsotwo main system tables: (a) mastertableand(b) convertertable.

Figure4 zoomsinto the coreGammaserver of Figure3 andrevealsanotherlevel of details

abouttheserver. Therearetwo mainsystemtables– themaster table andtheconverter table – and

13

four mainsystemcomponents: (1) thedispatcher, (2) thecollectionof conversion servers, (3) the

collectionof transcoding utilities, and(4) somestreaming servers. Thefigure depictstheserver

asonebox,but in implementationall thesecomponentsarejustprocessesrunningonanetwork of

computers.In theevaluationsection(Section 9) sometypicalsetupswill beshown in Figures8.

The mastertabledefinesthe transcodingservicesofferedby theserver andwill bediscussed

in moredetailsin Section7. Theconvertertabledefineshow thesetranscodingservices(indexed

by their conversionlabels)are locatedin differentmachines(eachrepresentedby a conversion

server). Typically a transcodingservicecanrun only on a specifictypeof platform. For example,

mpeg2ram runson a Windows NT but not a Linux platform. By configuringthe deployment

table,thesystemadminstratorassignsa transcodingmachineof theright platform. Note that the

sametranscodingservicecanbehostedby morethanoneconversionmachines.Thisdesignmakes

Gammascalable,sinceit is veryeasyto increasetheprocessingpower– thesystemadministrator

simply addsmoremachinesinto thesystemandeditstheconvertertable.Scalabilityisanimportant

concernsincetranscodingtasksarepotentially processor-intensive. In Section9.6characterisesthe

scalabilityof thesystem.

The dispatcheris the centralcoordinatorof the system. Using the GammaAPI, it accepts

transcodingrequestsfrom the wirelessapplications,it then consults the converter table to see

which conversionserversoffer the requestedtranscodingcapabilities,anddispatchsthe tasksto

theright machines.Thedispatchercurrentlyusesa simple round-robinapproachto dispatchtasks

to differentmachines.In future,wemayuseotherload-balancingalgorithms.

A conversionserver representsa machinein the network that hostssometranscodingcapa-

biliti es. It acceptsthe dispatcher’s requestusinga file-basedIPC (interprocess-communication)

14

andinvokesthetranscodingprogramusingtheexec functionof theoperatingsystem. It consults

the mastertableto expanda conversionlabel into a invocationcommand(Section7). Finally, it

returnstheresultof theexecutionto thedispatcher. Themultimediaobjectsarepassedaroundin

thesystemonanetwork file systemusingthefile-basedIPC mechanism.

As discussed in Section4, a collectionof transcodingutilties provide the actualtranscoding

capabilitiesof the system.They cancomefrom third partiesasbinary executables. The system

administrator simply installs theminto the conversion machinesand thenconfiguresthe master

table.

5.3 StreamingVideo

To caterfor thespecialcaseof streamingvideo,oursystemalsoaccommodatesstreamingservers

in thecoreGammasystem.For transcodingtasksresultingin streamingvideoobjects,theutili ty

cachestheobjecton a streamingserver, andreturnsa URL (uniform resourcelocator)to thedis-

patcher. Currently, we incorporatetwo servers– for theH.263formatandtheRealVideo format

respectively. TheH.263serverwasdevelopedinternallyby ourcompany, but theRealVideoserver

wasdevelopedby a third party(RealNetworks,Inc.).

Whena multimediaobject is offered in a non-streamableformat from the origin server, the

wholeobjecthastobedownloadedtoGammabeforeit canbetranscodedintoastreamablefashion.

We expectthe origin server andGammaareconnectedby wireline Internetwith relatively good

bandwidth,sonormally thedownloadingshouldnot introducetoomuchlatency whentheobjectis

small.Oncetheobjectis transcodedintoastreamableobject,thewirelessusercanenjoy thebenefit

of streamingandview theobjectwithout beinghinderedtoomuchby thelimitedbandwidthof the

15

wirelessnetwork. We will characterisethe performancein an end-to-endfashionin Section9.

Whentheobjectis huge(e.g.a full movie), thedownloadingfrom origin server to Gammamaybe

time consuming.In this particularcasetheGammaserver maynotbeableto improve theend-to-

enduserexperience.In general,thetransferof any largedataobjectsin anon-streamingfashionis

difficult.

5.4 Implementation Details

ThecoreGammaserver is implementedasagroupof processesrunningonaclusterof computers.

The whole systemis gluedtogetherby a LAN (local areanetwork), a network file system, and

a file-basedIPC (interprocesscommunication) mechanism,which wasinternallydeveloped. We

usecommodity personalcomputersrunningWindows NT (version4.0) andLinux (distribution

of RedHat7.x) in the cluster. The commonnetwork file systemusesNFS to link up the Linux

machines,andSambato link up theWindows machines.Thefile-systemserversmayor maynot

be part of the Gammaserver. The dispatcherandthe conversionServersareimplementedusing

the Java Language.The former is a Java servletrunningin a Tomcatservletcontainer, andthe

latter arestandalone Java programs.SinceJava programsrun on both Windows andLinux, we

canrun theconversionserversonbothplatforms.Typically sometranscodingutilit iesrunonly on

Windows andsomeothersrun only on Linux. Therefore,we expecta typical installation to have

at leasttwo conversionmachines– say, oneWindows NT andthe otherLinux – andeachhasa

conversionserver runningon it. Thedispatchercanberunonany machinesthatrunJava.

16

6 Applications

As discussedin Section1, onekey novelty of Gammais thatwedonotcoupletranscodingservice

to a specificwirelessapplication.Rather, we abstractout theserviceandmake it generallyusable

by multiple applications.In this section,we will presentthe four applications thatmake usesof

thecontentadaptationserviceofferedby Gamma.

6.1 Email Proxy

WirelessUserTerminals

GammaServer

OriginEmail Server

IMAP4/POP3

IMAP4/POP3G

amm

aA

PI

Streaming Server

EmailProxy

RTSP

(a)

User-TerminalProfiles

Consult

WirelessUserTerminals

ICAPServer

GammaServer

OriginWeb Server

HTTP HTTP

Gamma API

Streaming Server

WebProxy

ICAPClient

RTSP

(b)

User-TerminalProfiles

ICAP

Consult

Figure5: WirelessApplications ThatUseGammaServices:(a)EamilProxy, (b) WebProxy.

Email Proxy is an application that enhancesa wirelessuser’s experienceof accessingmulti-

mediaemail.Typically, auserretrievesheremailto herterminalsfrom anincomingemailserver2

usingoneof thetwo commonprotocols– IMAP4 or POP3.Her incoming mail maycontainsome

multimediaattachmentsusinga formatdefinedin theMIME standard(MultipurposeInternetMail

Extensions). Theseattachmentsmay be hugeandmay overwhelmthe limited resourcesof the

wirelessuser(network bandwidthand/orterminal computation/storagecapacity). Email Proxy2Not to be confusedwith an outgoing email server, which offers the SMTP protocol for an email client to send

outgoing emails.

17

improvestheuser’s experienceby interceptingtheIMAP4 or POP3exchangesandthentranscod-

ing multimediaattachmentsfrom oneformat to anotheraccordingthe userprofile (per userand

perterminal-type).Figure5adepictstheoperation.

To usetheserviceof ourEmailProxy, auserconfiguresheremailclient to useanEmailProxy

server asan incoming server. Whensheretrievesher email, the client will usesthe IMAP4 or

POP3protocolto talk to theEmailProxyserver, whowill thenobtaintheusernameandpassword

of theuserin a regular IMAP4/POP3exchange.AssumingEmail Proxyknows alsothe terminal

type(seebelow), it canthenlook uptheuserprofileto know whattranscodingservicesaredesired.

TheEmailProxyserverwill thenrelayall theuser’s IMAP4/POP3requeststo theuser’sorigin

incomingemail server. When a responsecomeback, it will examinethe MIME type of each

attachment.If anattachmentneedsto be transcoded,it will requestthe transcodingservicefrom

Gamma,andfinally it will returnthetranscodedobjectsto theclient.

Streamingvideo objectsarehandledspecially– if a video object is to be transcodedinto a

streamingvideo format,Gammawill cachethe streamableobjectin an internalstreamingvideo

server andreturna URL (uniform resourcelocator) throughEmail Proxy to the client. On the

client, a streamingvideo playerwill be invoked whenthe userclicks on the returnedURL. The

videoplayerthenusesRTSP(real-timestreamingprotocol)to startthevideostreamingsession.

The determinationof the terminal type of the user is currently tricky. Unlike HTTP (Sec-

tion 6.2),thecurrentIMAP4 andPOP3protocoldonotprovideaway to communicatethetypeof

terminaltype,therefore,we areforcedto usethefollowing workaroundtechnique.For eachtype

of userterminal,we run an instanceof Email Proxy, eachlisteningon a differentnetwork port.

Correspondingly, we configurethe email clientson the terminal to talk to the portsof the right

18

proxies. In this setup,whenanemail proxy receivesa request,it knows that the requestis from

an email client of a particulartype of terminal. Togetherwith the usernameinformation in the

IMAP4/POP3exchange,theproxycanthenloadtheright userprofile. In thelong run,we expect

amechanismfor declaringtheterminaltypewill beaddedto thetwo protocols.

Email Proxyis implementedusingtheC Language.We run it on a Linux system(distribution

RedHat7.x).

6.2 WebProxy

WebProxyisanapplicationthatenhancesawirelessuser’sexperienceof accessingtheWorldWide

Web. Whena useris browsing theWeb,his webbrowserusesHTTP (hypertext transferprotocol)

to interactwith someoriginwebservers.A WebProxyserverinterceptstheseHTTPexchangesand

transcodesmultimediaobjectsaccordingto theuser’s preference,asshown in Figure5b. Again,

theGammaserverprovidesthetranscodingservicesto WebProxy.

It is possibleto designawebproxysothatit communicatesto Gammadirectly. However, since

the InternetContentAdaptationProtocol(ICAP) may becomean industry-standardway for off-

loadingvalue-addedservicessuchastranscoding.WestructureourGammaservicebehinda layer

of ICAP interface.In otherwords,theGammaserverbecomesaback-endengineof a transcoding

ICAP server.

To usetheserviceof a Web Proxy server, a userconfiguresher web browserto usethe Web

Proxy server. The first time sheaccessesthe server, it will indicateto the browser that proxy

authenticationis required. The browserwill thenpop up a dialog box for the userto enterher

usernameandpassword. This login procedureis neededonly onceper web session.The type

19

of the userterminal is communicatedto the Web Proxy server using the User-Agent headerof

HTTP. OncetheWebProxyserverknowstheusernameandtheterminaltype,it canloadtheright

per-user-per-terminal-typeprofile, from which it knowswhattranscodingservicesaredesired.

Likein theEmailProxycase,videoobjectstranscodedintoastreamingvideoformatareserved

on a Gamma-internalstreamingvideo server. Web Proxy andthe ICAP client are implemented

in the C Languageand run on a Linux system(distribution RedHat7.x). The ICAP server is

implementedin theJavaLanguageandrunsonany platformsthathaveJavaVirtual Machines.

6.3 Email Recomposer

What if a userwants transcodingserviceswhen shesends email? Shemay want transcoding

servicewhensendingemailwhenherterminalis a“producer”of multimediaobjectsof uncommon

formats.For example,herterminalmaybeaCasioCassiopeiaPDA equippedwith avideocamera,

which producesvideo in the proprietaryCMF format. To sendvideo clips in themorecommon

MPEGformat,shecanconfigureheroutgoingemail server to beour Email Recomposer. Email

RecomposerspeakstheSMTPprotocolandis a just a specialmail-transfer-agent(MTA). It will

examinethe MIME attachmentfor every email messagedeliveredthroughit. If any of these

attachmentsis a CMF video attachment,it will transcodethe attachmentinto an MPEG video,

recomposethemessage,thenforwardthemessageout likea regularMTA.

Sinceemail recomposingis a relatively specialservice,we do not useinformation aboutthe

useror theterminaltypeto provide customizedtranscodingserviceasin thecaseof Email Proxy

and Web Proxy. We assumeall clients connectingto the Email Recomposerrequirethe same

CMF-to-MPGtranscoding.Email Recomposeris implementedusingsendmail with a special

20

rulesettogetherwith somePerlScripts.

6.4 Email Outbox

Email Outbox,alsocalledMultimediaMessageBox, is anotherproject in our laboratory. More

detailsaboutthe projectwill be discussedin a separatepaper[4], herewe only provide a brief

overview. The key idea is to avoid the delivery of hugemultimediaattachmentsinto the email

inbox of a recipient.Electronicmail, aswe know, traditionally emphasizeson theinbox anduses

a “copy” and “store-and-forward” semanticswhenpassinga message.Whena sendersendsa

messageto arecipient,acopy of themessageis madeanddeliveredinto theinboxof therecipient.

Furthermore,if the samemessageis to be sentto, say, 10 differentrecipients,then10 copiesof

the samemessagewill be madeanddeliveredto the 10 inboxesof the recipients. This “copy”

semanticsis not a problemwhentheemailmessageis small. However, whentheemailmessage

is huge– for example,whenit containsa 10-MB videoattachment,the traditionalapproachcan

imposea severeload on the system(the inbox serversof the recipientsandall the intermediate

store-and-forwardemailtransferagents).

To overcomethedrawback,anEmailOutboxsystemprovidesa“link” semanticswhenpassing

amessage.WhenasenderA sendsamessageto arecipientB, thesystemwill automaticallycache

the messageon an outbox of A, andwill sendto B’s inbox only a link (URL). If thereare10

recipients,10 links will besentto therecipient,but only onecopy of themessageis cachedin A’s

outbox. Email Outboxcansignificantlysave the resourcedemandsof multimediaemail in both

wirelessandwirelinesystems.

The role of Gammain Email Outboxis to provide personalizedtranscodingwhenrecipients

21

view thecontentthroughOutbox. For example,for thesamevideoclip cachedon Outbox,some

may prefer to receive it as MPEG, while othersmay prefer to view it as streamingRealVideo

format.Gammaprovideson-demandtranscodingto suit theneedsof differentrecipients.

7 Master Table

A mastertable(an exampleof which is shown in Figure6a) servesmultiple purposes.First, it

allows the coreGammaserver to announcethe conversioncapabilitiesthat it exports. Eachof

thesecapabilitiesis identifiedby a conversion label. Second,it allows thesystemadministratorto

defineexactlyhow eachtranscodingutility canbeinvokedontheconversion servermachine.This

is definedin thecolumnlabeled“Program”. Thesystemadministrator lists in this columnthefull

pathto invoke theutility aswell astheneededcommand-line arguments.Two specialtokensare

allowedin thecolumn:%i meansinput filenameand%o meansoutputfilename.Thedispatcher

will usethiscolumnto constructtheactualcommand-linestringthatis sentto aconversionserver.

Finally, amastertableis asourcefrom whichauserprofileis built, asdiscussedin thenext Section.

8 UserProfiles

In a givenGammasystem,a certaininput type(e.g. video/mpeg) canbetranscodedinto different

outputtypes(e.g.RealVideoformator H.263format).Themappingisone-to-many becausediffer-

entusersmaydesiredifferenttranscodings.Eventhesameusermaydesiredifferenttranscodings

whensheis usingdifferentterminals.

For a givenuserusinga particularterminal,however, themappingshouldbeone-to-one.Sev-

22

a) MasterTable(portion only)

ConvLabel Input Input Output Output ProgramMIME Extension MIME Extension

mpeg2ram video/ .mpg application/ .ram cmd /c mpg2ram.batmpeg vnd.rn- %i %o /T 0,1

realmediampg2h263 video/ .mpg video/ .263 cmd /c c:\jillb\mpeg_trans

mpeg h263 -H %o -d 6 -r 64000 %i

cmf2mpg application .cmf video/ .mpg cmd /c cmf2mpg.batx-casio- mpeg %i %ocmf

small JPGCASIO image/ .jpg image .jpg /usr/X11R6/bin/convertjpeg jpeg -geometry 230x200

jpg:%i jpg:%osmall JPGSONGPB image/ .jpg image .jpg /usr/X11R6/bin/convert

jpeg jpeg -geometry 300x400jpg:%i jpg:%o

jpgStripColor image/ .jpg image/ .jpg /usr/X11R6/bin/convertjpeg jpeg -colorspace GRAY

jpg:%i jpg:%o

b) UserProfileof User“Cl ementLee” Terminal“Cassiopeia” (portion only)

ConvLabel Input Input Output Output ProgramMIME Extension MIME Extension

mpg2h263 video/ .mpg video/ .263 cmd /c c:\jillb\mpeg_transmpeg h263 -H %o -d 6 -r 64000 %i

cmf2mpg application .cmf video/ .mpg cmd /c cmf2mpg.batx-casio- mpeg %i %ocmf

small JPGCASIO image/ .jpg image .jpg /usr/X11R6/bin/convertjpeg jpeg -geometry 230x200

jpg:%i jpg:%o

Figure6: MasterTablevs. UserProfile

This figureshows portionsof a mastertable(a) anda userprofile (b). In amastertable, thesameinput MIME type canhave multiple output MIMEtype. In auserprofile, thesameinput MIME typecanonly haveoneoutputMIME type.

23

eralfactorsaffectwhichparticularoutputtypeis to bechosen:

1. Characteristicsof theterminal(e.g.screenresolution,coloror black-and-whitescreen,etc.)

2. Availability of applicationson the terminal (e.g. whethera RealPlayeror a H.263 video

playeris installed)

3. Theuser’spreferences(e.g.whetheror not to resizeanimageto screensize)

4. Policy of thewirelessserviceprovider (e.g.disablingthedownloadingof unviewablemulti-

mediaobjects)

The outcomeof the decisionprocessis representedas a per-user-per-terminal-typeprofile,

which preciselydefineshow eachinput typeshouldbeconvertedinto a certainoutput type. The

profile is asub-tableof themastertablewith thespecialrestrictionthateachinputMIME typecan

only bemappedto oneoutputMIME type. An exampleof theprofile is shown in Figure6b. As

discussedin thepreviousSection6, theEmail ProxyandWebProxyapplicationsusetheprofiles

to determinewhatparticulartranscodingserviceis neededfor agiveninputMIME type.

We built a web-basedprofile generatorto help usersto constructtheir own userprofiles. It

factorsin theabove four factorswhengeneratinguserprofiles(Figure7).

9 Evaluation

We performedthreeexperiments to evaluation our system. In ExperimentI, we measuredthe

quantitativebenefitsof transcoding,specificallythereductionin latenciesandnetwork traffic when

accessingmultimediaobjectsover a real3G1XRTT wirelesslink. In ExperimentII, wemeasured

24

Figure7: TheGUI for EditingUserProfiles

25

Configurations:WebClient: Mobile PII 364MHz (Linux)

with Qualcomm 3G1X prototype cellphone

Microcell: Lucent Flexant CDMA 3G1X prototype microcell

IWF: Lucent 3G1X IWF emulatorWebProxy/ICAPClient:

PIII 500MHz (Linux)ICAPServer: PII 400MHz (WinNT)Dispatcher: PIII 500MHz (WinNT)WinNT ConvServer: PIII 500MHzLinux ConvServer: PIII 500MHzWeb Server: PIII 500MHz (WinNT)

3G1X Access Network WebProxy

Gamma

Origin Web ServerWebClient

Microcell IWF

WebProxy/ICAPClient

ICAPServer

Dispatcher

WinNTConvServer

LinuxConvServer

163.2 Kbps

(a) Experiment I

Configurations:WebClient: PII 450MHz (Linux)

with 100-Mbps EthernetWebProxy/ICAPClient:

PIII 500MHz (Linux)ICAPServer: PII 400MHz (WinNT)Dispatcher: PII 400MHz (Linux)WinNT ConvServer: PIII 500MHzLinux ConvServer: PIII 500MHzWeb Server: PIII 500MHz (WinNT)

WebProxy

Gamma

Origin Web ServerWebClient

WebProxy/ICAPClient

ICAPServer

Dispatcher

WinNTConvServer

LinuxConvServer

(b) Experiment II

Configurations:PostMulti: PII 450MHz (Linux)

with 100-Mbps EthernetDispatcher: PIII 930MHz (Linux)L1 ConvServer: PII 400MHz (Linux)L2 ConvServer: PII 400MHz (Linux)L3 ConvServer: PII 400MHz (Linux)

GammaPostMulti

Dispatcher

L1 L3L2

(c) Experiment III

Figure8: ExperimentSetups

Thesetupsfor experimentsI, II, andIII respectively. In thediagrams,PII andPIIIstandfor Pentium II andPentium III respectively.

the overheadof the Gammasystem. In ExperimentIII, we characterizedthe scalabilityof the

system.

9.1 Experiment I: TestSetup

In this experiment,we measuredthe network traffic andlatenciesfor accessingweb multimedia

objectsover a wirelesslink. For eachtest,therearetwo cases:without andwith transcoding.In

theformercase,theclient just issuedanHTTP requestdirectly to a webserver. For thelatter, the

26

Test Type Name Without transcoding With transcodingof Access Accessobject latency Sizein latency Sizein

in secs. bytes in secs. Change bytes Change(s.d.) (s.d.) in % in %

T1a MPEGto RealVideo room.mpg 29.365 599,414 14.515 -51% 70 -(1.297) (1.598)

T1b MPEGto RealVideo allofus.mpg 15.408 271,364 11.311 -27% 70 -(0.310) (0.837)

T2a MPEGto H263 room.mpg 29.365 599,414 8.602 -71% 58 -(1.297) (0.724)

T2b MPEGto H263 allofus.mpg 15.408 271,364 6.118 -60% 58 -(0.310) (0.334)

T3a JPEGrescale beach.jpg 17.088 277,034 6.607 -41% 15,199 -94%(1.015) (0.358)

T3b JPEGrescale liberty.jpg 62.468 1,064,246 10.654 -83% 5,532 -99%(1.110) (0.546)

T4a Stripping Color beach.jpg 17.088 277,034 22.019 +29% 145,122 -48%(1.015) (0.909)

T4b Stripping Color liberty.jpg 62.468 1,064,246 32.189 -48% 218,438 -79%(1.110) (0.406)

T5a Word to HTML wds.doc 1.037 34,816 13.851 +1,236% 893 -(0.034) (0.424)

T5b Word to HTML wireless.doc 10.268 385,024 21.338 +107% 915 -(0.622) (0.624)

T6a PPTto HTML wds.ppt 1.597 38,912 5.154 +223% 923 -(0.189) (0.520)

T6b PPTto HTML wap.ppt 28.035 770,048 65.084 +132% 210 -(0.486) (0.091)

T7a MPEGto thumbnail room.mpg 29.365 599,414 6.593 -77% 8,833 -98%(1.291) (0.629)

T7b MPEGto thumbnail allofus.mpg 15.408 271,364 5.109 -67% 5,766 -98%(0.310) (0.350)

T8a PPMto JPG teapot.ppm 4.867 196,623 4.396 -10% 10,448 -95%(0.249) (0.246)

T8b PPMto JPG pond.ppm 34.343 589,839 10.412 -70% 57,046 -90%(1.345) (0.565)

T9a Stripping file j2me.pdf 2.958 62,028 1.774 -40% 641 -99%(0.057) (0.048)

T9b Stripping file njtransit.pdf 22.874 415,550 2.388 -90% 641 -99%(0.048) (0.060)

T10a MPEGto H263D/L room.mpg 29.365 599,414 16.130 -45% 94,183 -84%(1.297) (0.575)

T10b MPEGto H263D/L allofus.mpg 15.408 271,364 11.760 -24% 57,913 -79%(0.310) (0.464)

Figure9: QuantitativeBenefitsof Transcoding

This table reports the quantitative benefitsof using transcoding: reduction in accesslatency and/or thereduction in network traffic. The measurementswere doneover a 163.2-kbps 3G1X airlink. Eachtestwasrepeatedthreetimes,andthe samplestandarddeviation (s.d.) is shownin a parethesis. In testsT3aandT3b, theoriginal images wereof resolutions 1280x960 and1536x1024respectively, the result imageswereof resolution 230x200. In testsT9a andT9b, the Web Proxy returned a HTML file that explainedthat the requestedPDF file wasnot downloaded asper the setting in the user’s profile. In T2a andT2b,the result objects werein a streamableH263 format,while in T10aandT10b, the result objectswerein anon-streamable H263format.

27

client issuedthe samerequestbut via Web Proxy. Basedon the userprofile, Web Proxy in turn

requestedtheGammaserver for transcodingservices,andreturnedthe transcodedobjectsto the

client.

Althoughexperimentshavebeenperformedin previousworksabouttranscodingperformance

of individual components,this experimentis importantsinceit measuredthe end-to-endperfor-

manceof arealsystemusingarealwirelesslink (3G1XRTT link). Specifically, all componentsof

thetranscodingprocess– from transmission of themultimediaobjectto thetriggeringof transcod-

ing to theactualtranscodingcomputation– aremeasuredin thisexperiment.

Figure8aillustratesthetestconfigurationthatwe usedfor this experiment.The3G1X access

network is availablein our facilitiesin Holmdel,New Jersey andhasa bandwidthof 163.2Kbps.

All arrows in the figure indicateinformation flow (control anddataflow) anddo not reflect the

topology of thenetwork, whichcomprisesourcorporateintranetandthesubnetsin our laboratory.

The wireline network hada muchhigherspeed(100-Mbpsethernet)thanthe airlink andshould

notbeabottleneckin thesystem.

Wemeasuredtheaccesslatenciesaswell asthedatetraffic incurredin eachtest.Eachtestwas

repeatedthreetimes.Ontheclientmachine,weusedatestprogramcalledWebClient – butnota

regularwebbrowserlikeNetscapeCommunicator– to issuetheHTTPrequests.Thereasonis that

wewantto excludetherenderingtimes:thetimefor screenupdateaswell asthetimefor launching

anotherhelperapplication(like in thecasethataRealPlayeris launchedto view aRealVideoclip).

Theserenderingtimesareorthogonalto the accesslatenciesthat we want to measureandhave

interferedwith our measurements.UsingWebClient,our measuredtime includesthetranscoding

timeandthetime to transmitthetranscodedmultimediaobjectto theclientover the3G1Xairlink

28

but not therenderingtime. If thetranscodedobjectis asingleobject,thetransmission time for the

wholeobjectis included. If the transcodedobjectis a URL (suchasa URL to a videoclip on a

streamingserver),or thetranscodedresultcomprisemultiple objects(suchasmultiple webpages

for anMS-Word document),thenthetransmission time includesonly thetime for thefirst object.

Roughly, thesemeasuredtimescorrespondto the user-perceived responsetimesof web objects.

This is becausetheextra transmissiontime neededfor streamingor for thefollowing objectswill

overlapwith theuserviewing timeandwill notbeperceivedaslatency.

9.2 Experiment I: Resultsand Discussions

Figure9 shows theresultsof ExperimentI. We canseethatin 15 outof 20of thetests,theaccess

latencieswerereducedsignificantly. In theextremecase,theaccesslatency wasreducedby 83%

(TestT3b). They demonstratedonemajor benefitof transcoding– althoughtime is neededfor

computation, overall the accesslatency is reducedby virtue of the reductionin objectsize(e.g.

TestT3b)or by thefactthatstreamingis enabled(e.g.Test1a).

Understandlytherewerealsoa few exceptions(TestsT4a, T5 andT6) to the above general

pattern.Thereweredueto thefactthatthetranscodingcomputationwastooslow andit offsetthe

saving in transmission time(e.g.TestT4a).

As to network traffic, 12 out of the 20 testshadlessnetwork traffic whenusingtranscoding.

In theextremecase,thenetwork traffic wasreducedby 99%(TestT3b). For theothereight test

cases,the objectsreceived by the client arepointers(URLs) to a streamingserver (T1 andT2)

or portionsof the accessedobjects(first pagesof multi-pagedocumentsin the casesof T5 and

T6). Thatmeanssomemorenetwork traffic areneededfor accessingthefull objects.Wetherefore

29

cannotconcludehow muchnetwork traffic wasreducedin thesetestcases.

Note thateven thoughthe trancodingservicesfor sometestcasesdid not resultin any quan-

titative benefits(suchasin TestsT5 andT6), they maystill beconsideredusefulbecauseof their

qualitative benefits(seeFigure1). For example,the transcodingservicesin T5 andT6 enablea

userto view a documenteven whenher terminalhasonly a web browserbut not the otherwise

requiredMicrosoftWordor MicrosoftPowerPointsoftware.

9.3 Experiment II: TestSetup

In this experiment,we characterizedtheperformanceof theGammasystem. Figure8b shows the

testconfigurationfor ExperimentII. Unlikein ExperimentI, whereweusedareal3G1Xairlink for

end-to-endmeasurements,hereweuseda100-MbpsEthernetconnectionto link upthewebclient.

Thereasonis thatin ExperimentII wewerefocusingontheperformanceof theGammasystembut

not theend-to-endperformance.We performed20 differenttests,eachwasa specifictranscoding

task. For eachtest,we measuredthe Gammatime ( � ) and the Exec time ( � ). The former is

the time durationfrom the momentthe Gammadispatcherreceivesa requestto the momentit

responsesthe request– after completingthe transcodingtask. The latter is the time durationfor

theexecutionof thetranscodingutili ty. WedefinetheGammaoverheadto be � - � . Eachtestwas

repeatedthreetimes.

As in ExperimentI, we useda testclient WebClient to initiatiate the webrequests.There

weresomeconfigurationchangesfrom ExperimentI to ExperimentII. Wechangedto useaLinux

dispatcherinsteadof a WinNT dispatcher, andwe moved thefile server to thedispatchermachine

(in ExperimentI we were using an outsidefile server). We also choseto usesmallerpolling

30

Gamma Exec GammaTest Type Object time time overhead

Name in secs. (s.d.) in secs. (s.d.) in secs. (s.d.)� � �����T11a MPEGto RealVideo room.mpg 7.231 (0.006) 7.073 (0.009) 0.158 (0.009)T11b MPEGto RealVideo allofus.mpg 6.843 (0.005) 6.679 (0.012) 0.164 (0.012)T12a MPEGto H263 room.mpg 2.260 (0.016) 2.094 (0.016) 0.181 (0.030)T12b MPEGto H263 allofus.mpg 2.005 (0.006) 1.860 (0.001) 0.145 (0.006)T13a JPEGrescale beach.jpg 1.794 (0.346) 1.711 (0.341) 0.083 (0.005)T13b JPEGrescale liberty.jpg 2.607 (0.395) 2.513 (0.401) 0.094 (0.011)T14a StrippingColor beach.jpg 7.715 (0.023) 7.618 (0.005) 0.097 (0.022)T14b StrippingColor liberty.jpg 10.258 (0.017) 10.152 (0.013) 0.106 (0.012)T15a Word to HTML wds.doc 10.628 (0.012) 10.473 (0.024) 0.155 (0.013)T15b Word to HTML wireless.doc 16.551 (0.049) 16.401 (0.055) 0.151 (0.009)T16a PPTto HTML wds.ppt 1.421 (0.002) 1.245 (0.009) 0.176 (0.010)T16b PPTto HTML wap.ppt 81.483 (1.379) 81.177 (1.598) 0.306 (0.250)T17a MPEGto thumbnail room.mpg 0.303 (0.017) 0.156 (0.000) 0.147 (0.017)T17b MPEGto thumbnail allofus.mpg 0.352 (0.012) 0.193 (0.009) 0.159 (0.018)T18a PPMto JPG teapot.ppm 0.200 (0.008) 0.108 (0.003) 0.092 (0.006)T18b PPMto JPG pond.ppm 0.308 (0.006) 0.211 (0.004) 0.097 (0.006)T19a Strippingfile j2me.pdf n/a n/a n/a n/a n/a n/aT19b Strippingfile njtransit.pdf n/a n/a n/a n/a n/a n/aT20a MPEGto H263D/L room.mpg 4.005 (0.006) 3.844 (0.000) 0.161 (0.006)T20b MPEGto H263D/L allofus.mpg 3.984 (0.017) 3.818 (0.010) 0.167 (0.007)

Figure10: Overheadof Gammasystem

This tablereports the overheadof the Gammasystem, which is definedasthe differencebetweenthe Gammaconversiontime ( ) andthe execution time of the transcoding util ity ( ). The mea-surementsweredonein a100-MbpsEthernet environment. Eachtestwasrepeatedthreetimes,andthe sample standarddeviation (s.d.) is shownin a parethesis. We do not have datafor T19aandT19bsince the decisionsto strip off thePDFfiles weredonein theWebProxy (basedon the userprofile) – theGammaserver did not receivedany transcoding requestsin thesecases.

intervalsfor thefile-basedIPC mechanism. Thereforetheperformanceof Gammaweredifferent

in thetwo experiments.

9.4 Experiment II: Resultsand Discussions

Figure10showstheresultsof ExperimentII. Fromthe � column,wecanseethatthesetranscoding

utilit ies typically needup to a few secondsto completea transcodingtask. Sincethesearethird-

partyprograms,wedonothavemuchcontrolon theirperformance.Whatwestriveto minimizeis

31

theGammaoverhead��� � , which canbeimprovedby carefullyengineeringtheGammaserver

implementation.Our testsconfirmedthat theGammaoverheadis very modest.Exceptonecase,

theGammaoverheadwassmallerthan � 180mill iseconds.Comparedto theexecutiontimeof the

utilites,theoverheadshould beacceptable.Theseresultsvalidatedourdesignandimplementation

of theGammasystem.

9.5 Experiment III: TestSetup

In this experiment,we tried to characterizethescalabilityof theGammasystem.In otherwords,

we wantedto validatethatwe canput moreCPUsinto thesystemasconversionserver machines

so as to copewith a higher work load. As shown in figure 8c, we put threeequally-powered

Linux machines(PentiumII 400 MHz) as conversionserver machines,and then we ran three

sub-experiments, eachutilizing one, two, and threeof the machinesrespectively. In eachsub-

experiments, weuseda testprogramPostMulti to postmultiplesimultaneousGammarequests

to the Gammaserver. The specifictranscodingtaskwasto rescalea JPEGimage(of resolution

1280x960)to a resolution of 230x200. We thenmeasuredtheturnaroundtimesof theserequests.

Sincethereisnodependenciesbetweentheseparallellyprocessedtranscodingtasks,weexpectthat

Gammawill behavesimilarlywhenit is subjectedtoaworkloadwith amix of differenttranscoding

tasks.Eachtestcaseof agiven numberof simultaneousrequestswasrepeatedthreetimes.

9.6 Experiment III: Resultsand Discussions

Figure11 shows the resultsof this experiment. Eachdatapoint is a meanof threerepeatedex-

periments. Thereare threecurves, eachfor the sub-experimentsof one, two, and threeCPUs

32

Gamma Conversion Time

0

5

10

15

20

25

0 1 2 3 4 5 6 7 8 9

Number of tasks

Mea

n t

urn

aro

un

d t

ime

(sec

s) 1 CPU2 CPUs3 CPUs

Figure11: GammaConversionTimeUsingDifferentNumberof CPUs

respectively. Thebasecaseis 1-CPU,andwecanseethatasthenumberof tasksincreased,sodid

the turnaroundtime. Whenwe put onemoreCPU into the system,we observed that thesystem

couldcompletetwo simultaneoustasksroughlyin thesameturnaroundtime asin thecaseof one

singletask. Whenmoretaskswererequested,the turnaroundtime increased,but consistently it

wasroughlyhalf of thevalueasin the1-CPUconfiguration.Similarly, the3-CPUconfiguration

completedthreesimultaneoustasksasquickly asonesingletask. For testcasesof moresimulta-

neoustasks,it gave lower turnaroundtimescomparedto the2-CPUand1-CPUconfigurations–

roughly66%and33%respectively. This resultservedasa preliminary validation that indeedwe

canscaleup theperformanceof aGammasystemby puttingin moreCPUsasconversionservers.

33

10 Conclusions

In this paper, we presentedthedesign,implementation, andevaluation of theextensible andscal-

ableGammacontent-adaptationserver. The designof Gammais novel in threeaspects.First,

we emphasizeon the incorporationof third-party transcodingutilities. Second,we abstractout

content-adaptationasagenericservicefor wirelessapplicationsanddecoupletheformerfrom the

latter. Third, we addressthe difficult problemsof how userprofilesare createdandhow these

profilesareusedto triggerautomatic personalizedtranscoding.

Gammausesa table-driven architecture.Adding a new transcodingcapability is aseasyas

installing a new utility into theconversion-server machineandthenaddinganentryto themaster

tableanddeploymenttable. Gammaoffersa broadspectrumof transcodingcapabilitiescovering

video,audio,image,MS-PowerPoint,andMS-Word, etc. As a genericserver, Gammasupports

four differentwirelessapplications: emailproxy, webproxy, emailrecomposer, andemailoutbox.

Thesewirelessapplications usea per-userper-terminal-typeprofile to know thespecificneedof a

userandrequesttheappropriatetranscodingfor theuser. In ourexperimentsof accessingmultime-

diaobjectsovera real3G1Xairlink, Gammadeliveredverysignificantperformanceimprovement

– reductionof accesslatency up to 83% andreductionof network traffic up to 99%. In another

setof experiments, we foundthatGammais scalableandhasa smalloverhead– aslow as � 180

milli secondspertranscodingtask.

34

Acknowledgments

Wewouldliketo thankJill Boycefor herH.263transcodingutili ties.Weareindebtedto theLucent

Next GenerationNetwork Innovation Centerin Holmdel,New Jersey who allowedusto perform

our evaluation on their 3G1X airlink. This project is not possible without the contribution from

the pastmembersof our group: HansenWang,Jie Li, andSalim Virani. We alsothankMili nd

Buddhikot andSumiChoi for their contribution in theEmailOutboxapplication.

References

[1] ICAP Forum. http://www.i-cap.org.

[2] MultimediaMessaging Service(MMS): FunctionalDescription.TS 23.140,3GPP, 2002.

[3] ChrisBagwell. Sox– SoundeXchange.Availablefrom

http://home.sprynet.com/̃cbagwell/sox.html,2002.

[4] Mili ndBuddhikot,SumiChoi,GirishChandranmenon,ScottMill er, andYui-WahLee.Mul-

timedia Outbox(MMB): An Architecturefor Next GenerationMultimediaMessagingover

theInternet.Bell Labs Technical Report, in perparation.

[5] SurendarChandra,CarlaSchlatterEllis, andAmin Vahdat.Application-Level Differentiated

MultimediaWeb ServicesUsing Quality Aware Transcoding. IEEE Journal on Selected

Areas in Communications - Special Issue on QoS in the Internet, 2000.

35

[6] A. Fox, S. Gribble,Y. Chawathe,andE. Brewer. Adaptingto network andclient variation

usingactive proxies: Lessonsand perspectives. IEEE Personal Communications (invited

submission), August1998.

[7] ArmandoFox, Ian Goldberg, David C. LeeStevenD. Gribble,Anthony Polito, andEric A.

Brewer. Experiencewith TopGunWingman,A Proxy-BasedGraphicalWebBrowserfor the

USRPalmPilot. In Proceedings of the IFIP International Conference on Distributed Systems

Platforms and Open Distributed Processing (Middleware 98), September1998.

[8] IndependentJPEGGroup.http://www.ijg.org/.

[9] IBM Inc. Webspheretranscodingpublisher.

http://www-3.ibm.com/software/webservers/transcoding/about.html.

[10] Network ApplianceInc. Whitepaper– internetcontentadaptationprotocol(icap). Available

from http://www.i-cap.org/docs.

[11] Anuj Maheshwari, AashishSharma,Krithi Ramamritham,andPrashantShenoy. Transquid:

Transcoding andCachingProxyfor HeterogenousE-CommerceEnvironments. In Proceed-

ings of the 12th IEEE Workshop on Research Issues in Data Engineering (RIDE’02), San

Jose,CA, Feb2002.

[12] ImageMagickStudio.http://www.imagemagick.org, 2002.

36