paper (submitted to journal on wireless communications a mobile
TRANSCRIPT
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
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