passedfavicon

NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation169NaKika:SecureServiceExecutionandCompositioninanOpenEdge-SideComputingNetworkRobertGrimm,GuyLichtman,NikolaosMichalakis,AmosElliston,AdamKravetz,JonathanMiller,andSajidRazaNewYorkUniversityAbstractMakingtheinternet'sedgeeasilyextensiblefosterscol-laborationandinnovationonweb-basedapplications,butalsoraisestheproblemofhowtosecuretheexecutionplatform.
ThispaperpresentsNaKika,anedge-sidecomputingnetwork,thataddressesthistensionbetweenextensibilityandsecurity;itsafelyopenstheinternet'sedgetoallcontentproducersandconsumers.
First,NaKikaexpressesservicesasscripts,whichareselectedthroughpredicatesonHTTPmessagesandcomposedwitheachotherintoapipelineofcontentprocessingsteps.
Second,NaKikaisolatesindividualscriptsfromeachotherand,insteadofenforcinginexiblea-prioriquotas,limitsresourceconsumptionbasedonoverallsystemcongestion.
Third,NaKikaexpressessecuritypoliciesthroughthesamepredicatesasregularapplica-tionfunctionality,withtheresultthatpoliciesareaseas-ilyextensibleashostedcodeandthatenforcementisanintegralaspectofcontentprocessing.
Additionally,NaKikaleveragesastructuredoverlaynetworktosupportcooperativecachingandincrementaldeploymentwithlowadministrativeoverhead.
1IntroductionWeb-basedapplicationsincreasinglyrelyonthedynamiccreationandtransformationofcontent[5].
Scalingsuchapplicationstolargeandoftenglobalaudiencesrequiresplacingthemclosetoclients,attheedgeoftheinter-net.
Edge-sidecontentmanagementprovidestheCPUpowerandnetworkbandwidthnecessarytomeettheneedsoflocalclients.
Asaresult,itreducesloadonori-ginservers,bandwidthconsumptionacrosstheinternet,andlatencyforclients.
Italsoabsorbsloadspikes,e.
g.
,theSlashdoteffect,forunderprovisionedservers.
Basedonsimilarobservations,commercialcontentdistributionnetworks(CDNs)alreadyofferedge-sidehostingser-vices.
Forexample,Akamaihostscustomer-suppliedJ2EEcomponentsonedge-sideapplicationservers[1].
Furthermore,manyISPsprovidevalue-addedservices,suchas"webaccelerators",bydynamicallytransformingwebcontentontheedge.
However,commercialCDNsandISPshavelimitedreach.
Tomanagethetrustnec-essaryforexposingtheirhostinginfrastructuretootherpeople'scode,theyrelyontraditional,contract-basedbusinessrelationships.
Asaresult,commercialCDNsandISPsareill-suitedtocollaborativeandcommunity-baseddevelopmentefforts;theybestserveasampliersof(large)organizations'webservers.
Atthesametime,manycommunity-basedeffortsareexploringtheuseofweb-basedcollaborationtoaddresslarge-scalesocietalandeducationalproblems.
Forin-stance,researchersatseveralmedicalschools,includingNewYorkUniversity's,aremovingtowardsweb-basededucation[10,43,45]toaddressnationallyrecognizedproblemsinmedicaleducation[28,49].
Thebasicideaistoorganizecontentalongnarrativelinestore-establishcontextmissinginclinicalpractice,complementtextualpresentationwithmoviesandanimationstobetterillus-tratemedicalconditionsandprocedures,andleverageelectronicannotations(post-itnotes)anddiscussionsforbuildingacommunityofstudentsandpractitioners.
Fur-thermore,suchweb-basededucationalenvironmentsdy-namicallyadaptcontenttomeetstudents'learningneedsandtranscodeittoenableubiquitousaccess,independentofdevicesandnetworks.
Acrucialchallengefortheseeffortsishowtocombinethecontentandservicescre-atedbyseveralgroupsandorganizationsintoaseamlesslearningenvironmentandthenscalethatenvironmenttonotonlythe67,000medicalstudentsintheU.
S.
,butalsothe850,000physiciansintheeldaswellastomedicalpersonnelinothercountriesfacingsimilarproblems.
Takingacuefrompeer-to-peerCDNsforstaticcon-tent,suchasCoDeeN[47,48]andCoral[13],NaKika1targetscooperativeeffortsthatdonot(necessarily)havetheorganizationalstructureornancialresourcestocon-tractwithacommercialCDNorclusteroperatorandseekstoprovideanedge-sidecomputingnetworkthatisfullyopen:AnyonecancontributenodesandbandwidthtoNaKika,hosttheirapplicationsonit,andaccesscon-tentthroughit.
Inotherwords,byopeningupthein-ternet'sedge,NaKikaseekstoprovidethetechnologicalbasisforimprovedcollaborationandinnovationonlarge-scaleweb-basedapplications.
Inthispaper,weexplorehowNaKikaaddressesthecentralchallengeraisedbysuchanopenarchitecture:howtosecureourexecutionplatformwhilealsomakingiteasilyextensible.
NaKika,similartootherCDNs,mediatesallHTTPin-1OursystemisnamedaftertheoctopusgodoftheGilbertIslands,whoputhismanyarmstogooduseduringthegreatearthconstructionproject.
teractionsbetweenclientsandserversthroughedge-sideproxies.
AlsosimilartootherCDNs,individualedge-sidenodescoordinatewitheachothertocachecontent,throughastructuredoverlayinourcase.
NaKika'skeytechnicaldifference—andourprimarycontribution—isthatbothhostedapplicationsandsecuritypoliciesareexpressedasscriptedeventhandlers,whichareselectedthroughpredicatesonHTTPmessagesandcomposedintoapipelineofcontentprocessingstages.
Ourarchi-tecturebuildsonthefactthatHTTPmessagescontainconsiderableinformationaboutclients,servers,andcon-tenttoexposethesamehigh-levellanguageforexpress-ingfunctionalityandpoliciesalike—withtheresultthatpoliciesareaseasilyextensibleashostedcodeandthatenforcementisanintegralaspectofcontentprocessing.
AseconddifferenceandcontributionisthatNaKika'sresourcecontrolsdonotrelyona-prioriquotas,whicharetooinexibleforanopensystemhostingarbitraryserviceswithvaryingresourcerequirements.
InsteadNaKikalimitsresourceconsumptionbasedonconges-tion:Ifanode'sresourcesareoverutilized,ourarchi-tecturerstthrottlesrequestsproportionallytotheirre-sourceconsumptionandeventuallyterminatesthelargestresourceconsumers.
Ouruseofscriptingandoverlaynetworksprovidesseveralimportantbenets.
First,scriptingprovidesauni-formandexiblemechanismforexpressingapplicationlogicandsecuritypoliciesalike.
Second,scriptingsim-pliesthetaskofsecuringouredge-sidecomputingnet-work,aswecanmoreeasilycontrolasmallexecutionengineandasmallnumberofcarefullyselectedplat-formlibrariesthanrestrictingageneral-purposecomput-ingplatform[20,41].
Third,scriptingfacilitatesanAPIwithlowcognitivecomplexity:NaKika'sevent-basedAPIisnotonlyeasytousebut,moreimportantly,al-readyfamiliartoprogrammersversedinwebdevelop-ment.
Fourth,theoverlayensuresthatNaKikaisin-crementallyscalableanddeployable.
Inparticular,theoverlaysupportstheadditionofnodeswithminimalad-ministrativeoverhead.
Italsohelpswithabsorbingloadspikesforindividualsites,sinceonecachedcopy(ofei-therstaticcontentorservicecode)issufcientforavoid-ingoriginserveraccesses.
Atthesametime,NaKikadoeshavelimitations.
No-tably,itisunsuitableforapplicationsthatneedtoprocesslargedatabases,asthedatabasesneedtobemovedtotheinternet'sedgeaswell.
Furthermore,sinceNaKikaexposesallfunctionalityasscripts,applicationswhosecodeneedstobesecretcannotutilizeit(thoughobfus-cationcanhelp).
Next,byutilizingNaKika,contentproducersgaincapacitybutalsogiveupcontrolovertheirsites'performance.
Weexpectthatanydeploymentofouredge-sidecomputingnetworkisregularlymon-itoredtoidentifypersistentoverloadconditionsandtorectifythembyaddingmorenodes.
Finally,whileNaKikaprotectsagainstuntrustedapplicationcode,itdoestrustedge-sidenodestocorrectlycachedataandexecutescripts.
Asaresult,itiscurrentlylimitedtodeploymentsacrossorganizationsthatcanbetrustedtoproperlyad-ministerlocalNaKikanodes.
WereturntothisissueinSection6.
2RelatedWorkDuetoitspalpablebenets,severalprojectshavebeenexploringedge-sidecontentmanagement.
Amajor-ityoftheseefforts,suchasACDN[33],ColTrES[8],Tuxedo[38],vMatrix[2],andIBM'sWebSphereEdgeServer[17](whichisusedbyAkamai),explorehowtostructuretheedge-sidehostingenvironment.
Sincetheyaretargetedatclosedandtrusteddeployments,theydonotprovideanextensionmodel,nordotheyincludethesecurityandresourcecontrolsnecessaryforhostingun-trustedcode.
Incontrast,theOPESarchitectureforedge-sideservicesrecognizestheneedforextensibilityandservicecomposition[4,23].
Whileitdoesnotspecifyhowcompositionshouldbeachieved,OPESdoesdenepotentialsecuritythreats[3].
TheirscopeandmagnitudeisillustratedbyexperienceswiththeCoDeeNopencon-tentdistributionnetwork[48].
Next,ActiveCache[9]andSDT[19]enablecontentprocessinginproxycaches.
Whiletheydonotprovideanextensionmechanism,theydoprovideprecisecon-troloveredge-sideprocessingthroughserver-speciedHTTPheaders.
Furthermore,whileSDTenforcesonlycoarse-grainedresourcecontrolsforPerlandnoneforJava,ActiveCacheexecutesJavacodewithresourcelim-itsproportionaltothesizeofthecontentbeingprocessed.
Unlikethesesystems,Paietal.
'sproxyAPI[31]pro-videsne-grainedextensibilityforwebproxiesthroughanevent-basedAPIakintoours.
Atthesametime,theirworkfocusesonenablinghigh-performanceextensionsintrusteddeployments,whileourworkfocusesoncon-tainingarbitraryextensionsinuntrusteddeployments.
Finally,ActiveNames[46]areexplicitlydesignedforextensibilityandservicecomposition,chainingprocess-ingstepsinamannercomparabletoNaKika'sscriptingpipeline.
Infact,byintroducinganewnaminginterface,ActiveNamesoffermoreexibilityforcontentprocess-ingthanourwork.
However,theyalsorequireanewserviceinfrastructure,whileNaKikaintegrateswiththeexistingweb.
Whilecooperativecachinghasitslimitations[50],coordinationbetweenedge-sidenodesisstillimpor-tantforscalingasystem,inparticulartobalanceloadandabsorbloadspikes.
Tothisend,CoDeeN[47],ColTrES[8],andTuxedo[38]areexploringtheuseofdomain-specictopologiesandalgorithms.
Incontrast,NaKikaleveragespreviousworkonstructuredoverlayNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation170networks[13,16,35,42,52]forcoordinatingbetweenlocalcaches.
Webelievethatstructuredoverlaysprovidearobustandscalablealternativetodomain-specicco-ordinationstrategies.
Additionally,structuredoverlayshavealreadybeenusedsuccessfullyforcachingstaticcontent[13,18].
Inmostedge-sidesystems,nodescannotbeentrustedwiththesolecopiesofapplicationdata,andhardstaterequiringstrongerconsistencythantheweb'sexpiration-basedguarantees(orlackthereof)mustremainonori-ginservers.
Incontrast,ACDN[33]reducesaccessla-tencyforsuchdatabyreplicatingitacrossedgenodesandbyprovidingfullserializabilitythroughaprimaryreplica.
Gaoetal.
[14]explorealternativereplicationstrategiesbyexposingasetofdistributedobjectsthatmakedifferenttrade-offsbetweenconsistency,perfor-mance,andavailability.
Alternatively,thecontinuousconsistencymodelprovidesaframeworkforexpress-ingsuchtrade-offsthroughauniforminterfacetohardstate[51].
NaKika'ssupportforapplicationstatebuildsonGaoetal.
'sapproach,withtheprimarydifferencethatreplicatedstateissubjecttoNaKika'ssecurityandre-sourcecontrols.
Webcontentprocessingis(obviously)notlimitedtoedgenodesandcanbeperformedonserversandclientsaswell.
Forexample,NaKikahasseveralsimilaritieswiththecluster-basedTACCarchitecture[12].
BothNaKikaandTACCrelyonapipelineofprogramsthatpro-cesswebcontent,andbothbuildontheexpiration-basedconsistencymodelofthewebtocachebothoriginalandprocessedcontent.
NaKikadiffersinthatittargetsprox-iesdistributedacrossthewideareaandandthusneedstocarefullycontainhostedcode.
ComparabletoNaKika,DotSlash[53]helpsabsorbloadspikesbymovingscriptexecutiontootherserversina"mutual-aidcommunity".
UnlikeNaKika,ithasnoextensionmodelanddoesnotprovidesecurityandresourcecontrols.
Attheotherend,clientsideincludes[34](CSI)movetheassemblyofdy-namiccontenttotheclient,whichcanimprovelatencyforclientsrelyingonlowbandwidthlinks.
However,duetotheirfocusonassemblingcontentfragments,CSIarenotsuitableforcontentprocessingingeneral.
Theun-derlyingedgesideincludes[29,44](ESI)caneasilybesupportedwithinNaKika.
Finally,basedontherealizationthatsystemsecuritycanclearlybenetfromadedicatedandconcisespec-icationofpolicies,aconsiderablenumberofeffortshaveexploredpolicyspecicationlanguages.
Forex-ample,domainandtypeenforcement[7],XACML[22],andtrustmanagementsystemssuchasPolicyMaker,KeyNote,andSPKI[6,11]includelanguagesforex-pressingandenforcingpolicies.
Allthesesystemsre-quireexplicitlyprogrammedcallstotherespectiveref-erencemonitor.
Incontrast,previousworkonsecurityFigure1:IllustrationNaKika'sarchitecture.
Edge-sideproxiesmediateallHTTPinteractionsbetweenclientsandserversbyexecutingscripts;proxiesalsocoordinatewitheachotherthroughanoverlaynetwork.
forextensiblesystemsadvocatestheseparationofpoli-cies,enforcement,andfunctionalityandreliesonbinaryinterpositiontoinjectaccesscontroloperationsintoex-ecutingcode[15,39].
TheWebGuardpolicylanguagereliesonasimilarapproachforsecuringweb-basedap-plications[40].
SinceNaKika'sprogrammingmodelisalreadybasedoninterposition,weleveragethesamepredicateselectionmechanismforapplicationlogicandpolicies,thuseliminatingtheneedforaseparatepolicyspecicationlanguage.
3ArchitectureLikeotherextensionstothebasicwebinfrastructureandasillustratedinFigure1,NaKikareliesonprox-iesthatmediateHTTPinteractionsbetweenclientsandservers.
Toutilizetheseproxies,contentproducersandconsumersneedtochangeexistingwebpracticesalongtwolines.
First,contentproducersneedtopublishthenecessaryedge-sideprocessingscriptsontheirwebsites.
Contentproducersneednotprovidescriptsforanen-tiresiteatonce.
Rather,theycantransitiontoNaKikapiecemeal,startingwithcontentwhosecreationortrans-formationexertsthehighestresourcedemandsontheirservers.
Second,linksneedtobechangedbyappend-ing".
nakika.
net"toaURL'shostname,sothatNaKika'snameserverscanredirectclientsto(nearby)edgenodes.
Asdescribedin[13],URLscanbemodiedbycontentpublishers,thirdpartieslinkingtoothersites,aswellasbyusers.
Furthermore,URLscanberewrittenthroughaserviceinourarchitecture.
WhileNaKikaalsosupportsstaticproxycongurationinbrowsers,wepre-ferURLrewritingasitallowsformorene-grainedloadbalancingbetweenedgenodesandpresentsauniform,location-independentinterfaceforusingourarchitecture.
NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation1713.
1ProgrammingModelThefunctionalityofhostedservicesandapplicationsisspeciedthroughtwoeventhandlers,whicharewrit-teninJavaScript.
Ourarchitecturedoesnotdependonthechoiceofscriptinglanguageandcouldsupportsev-erallanguages.
WechoseJavaScriptbecauseitalreadyiswidelyusedbywebdevelopers.
Additionally,wefounditsC-likesyntaxandprototype-basedobjectmodelhelpfulinwritingscriptsquicklyandwithlittlecode;thoughwehadtoaddsupportforbytearraystoavoidun-necessarilycopyingdata.
TheonRequesteventhan-dleracceptsanHTTPrequestandreturnseitherare-questforcontinuedprocessingoraresponserepresent-ingthecorrespondingcontentorerrorcondition.
TheonResponseeventhandleracceptsanHTTPresponseandalwaysreturnsaresponse.
ApairofonRequestandonResponseeventhandlersmimicsthehigh-levelorganizationofanyHTTPproxyandrepresentstheunitofcompositioninNaKika:ascriptingpipelinestage.
InprovidingtwointerpositionpointsforHTTPpro-cessing,NaKikadiffersfromothersystems,suchasActiveCache[9],SDT[19],andTACC[12],whichonlyinterposeonHTTPresponses.
Interpositiononre-questsisnecessaryforHTTPredirectionand,moreim-portantly,asarst-linedefenseforenforcingaccesscon-trols.
Italsoismoreefcientifresponsesarecreatedfromscratch,asitavoidsaccessingaresourcebeforeedge-sideprocessing.
Tofacilitatethesecurecomposi-tionofuntrustedservices,NaKikareliesonfewereventhandlersthanPaietal.
'sproxyAPI[31];thoughitdoesprovidesimilarexpressivity,notably,tocontroltheproxycache,throughitsplatformlibraries.
SimilartoASP.
NETandJSP,requestsandresponsesarenotpassedasexplicitargumentsandreturnvalues,butarerepresentedasglobalJavaScriptobjects.
Us-ingglobalobjectsprovidesauniformmodelforaccess-ingfunctionalityanddata,sincenative-codelibraries,whichwecallvocabularies,alsoexposetheirfunctional-itythroughglobalJavaScriptobjects.
NaKikaprovidesvocabulariesformanagingHTTPmessagesandstateandforperformingcommoncontentprocessingsteps.
Inparticular,itprovidessupportforaccessingURLcom-ponents,cookies,andtheproxycache,fetchingotherwebresources,managinghardstate,processingregu-larexpressions,parsingandtransformingXMLdocu-ments,andtranscodingimages.
Weexpecttoaddvo-cabulariesforperformingcryptographicoperationsandtranscodingmoviesaswell.
Figure2illustratesanex-ampleonResponseeventhandler.
ForHTTPresponses,thebodyalwaysrepresentstheentireinstance[25]oftheHTTPresource,sothatthere-sourcecanbecorrectlytranscoded[19].
Iftheresponserepresentsanunmodiedorpartialresource,itisinstan-tiated,forexample,byretrievingitfromthecache,whenonResponse=function(){varbuff=null,body=newByteArray();while(buff=Response.
read()){body.
append(buff);}vartype=ImageTransformer.
type(Response.
contentType);vardim=ImageTransformer.
dimensions(body,type);if(dim.
x>176||dim.
y>208){varimg;if(dim.
x/176>dim.
y/208){img=ImageTransformer.
transform(body,type,"jpeg",176,dim.
y/dim.
x*208);}else{img=ImageTransformer.
transform(body,type,"jpeg",dim.
x/dim.
y*176,208);}Response.
setHeader("Content-Type","image/jpeg");Response.
setHeader("Content-Length",img.
length);Response.
write(img);}}Figure2:AnexampleonResponseeventhandler,whichtranscodesimagestotontothe176by208pixelscreenofaNokiacellphone.
Itreliesontheimagetrans-formervocabularytodotheactualtranscoding.
There-sponsebodyisaccessedinchunkstoenablecut-throughrouting;thoughthetransformervocabularydoesnotyetsupportit,withthescriptbufferingtheentirebody.
ascriptaccessesthebody.
EventHandlerSelectionToprovidescriptmodularityandmakeindividualpipelinestageseasilymodiable,stagesdonotconsistofaxedpairofeventhandlers;rather,theparticulareventhandlerstobeexecutedforeachstageareselectedfromacollectionofeventhandlers.
Tofacilitatethisselec-tionprocess,pairsofonRequestandonResponseeventhandlersareassociatedwithpredicatesonHTTPrequests,including,forexample,theclient'sIPaddressortheresource'sURL.
Conceptually,NaKikarsteval-uatesallofastage'spredicatesandthenselectsthepairwiththeclosestvalidmatchforexecution.
Theassociationbetweeneventhandlersandpredi-catesisexpressedinJavaScriptbyinstantiatingpol-icyobjects.
AsillustratedinFigure3,eachpolicyobjecthasseveralpropertiesthatcontainalistofal-lowablevaluesforthecorrespondingHTTPmessageelds.
EachpolicyobjectalsohastwopropertiesfortheonRequestandonResponseeventhandlersandanoptionalnextStagespropertyforschedulingad-ditionalstagesasdiscussedbelow.
ListsofallowablevaluessupportprexesforURLs,CIDRnotationforIPNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation172p=newPolicy();p.
url=["med.
nyu.
edu","medschool.
pitt.
edu"];p.
client=["nyu.
edu","pitt.
edu"];p.
onResponse=function(p.
register();Figure3:Anexamplepolicyobject.
ThepolicyappliestheonResponseeventhandlertoallcontentonserversatNYU'sorUniversityofPittsburgh'smedicalschoolsaccessedfromwithinthetwouniversities.
Thecalltoregister()activatesthepolicy.
addresses,andregularexpressionsforarbitraryHTTPheaders.
Whendeterminingtheclosestvalidmatch,dif-ferentvaluesinaproperty'slistaretreatedasadisjunc-tion,differentpropertiesinapolicyobjectaretreatedasaconjunction,andnullpropertiesaretreatedastruthval-ues.
Furthermore,precedenceisgiventoresourceURLs,followedbyclientaddresses,thenHTTPmethods,and-nallyarbitraryheaders.
Nulleventhandlersaretreatedasno-opsforeventhandlerexecution,thusmakingitpossi-bletoprocessonlyrequestsorresponsesortouseastagesolelyforschedulingotherstages.
SelectingeventhandlersbydeclaringpredicatesonHTTPmessagesavoidslongsequencesofif-elsestate-mentsinasingle,top-leveleventhandler,thusresultinginmoremodulareventprocessingcode.
WhencomparedtotheadditionalHTTPheadersusedbyActiveCacheandSDTforselectingedge-sidecode,predicate-basedscriptselectionalsoenablestheinterpositionofcodenotspeciedbytheoriginserver,anessentialrequire-mentforbothcomposingservicesandenforcingsecurity.
WhiledesigningNaKika,wedidconsideradomain-speciclanguage(DSL)forassociatingpredicateswitheventhandlersinsteadofusingJavaScript-basedpolicyobjects.
WhileaDSLcanbemoreexpressive(forexam-ple,byallowingdisjunctionbetweenproperties),were-jectedthisoptionbecauseitaddstoomuchcomplexity—bothforwebdeveloperstargetingNaKikaandforimple-mentorsofourarchitecture—whileprovidinglittleaddi-tionalbenets.
WealsoconsideredperformingpredicateselectiononHTTPresponses,butbelievethatpairingeventhandlersresultsinasimplerprogrammingmodel,withlittlelossofexpressivity.
Alsomatchingresponsesrequiresaverysimplechangetoourimplementation.
ScriptingPipelineCompositionBydefault,eachscriptingpipelinehasthreestages.
Therststageprovidesadministrativecontroloverclients'accesstoouredge-sidecomputingnetwork.
Itcan,forexample,performratelimiting,redirectrequests,orre-jectthemaltogether.
Thesecondstageperformssite-specicprocessing,whichtypicallyservesasasurrogateprocedureEXECUTE-PIPELINE(request)forward←EMPTYbackward←EMPTYStartwithadministrativecontrolandsite-specicstagesPUSH(forward,"http://nakika.
net/serverwall.
js")PUSH(forward,SITE(request.
url)+"/nakika.
js")PUSH(forward,"http://nakika.
net/clientwall.
js")repeatSchedulestagesandexecuteonRequestscript←FETCH-AND-EXECUTE(POP(forward))policy←FIND-CLOSEST-MATCH(script,request)PUSH(backward,policy)ifpolicy.
onRequest=NILthenresponse←RUN(policy.
onRequest,request)Ifhandlercreatesresponse,reversedirectionifresponse=NILthenexitrepeatendifendififpolicy.
nextStages=NILthenAddnewstagesPREPEND(forward,policy.
nextStages)endifuntilforward=EMPTYifresponse=NILthenFetchoriginalresourceresponse←FETCH(request)endifrepeatExecuteonResponsepolicy←POP(backward)ifpolicy.
onResponse=NILthenRUN(policy.
onResponse,response)endifuntilbackward=EMPTYreturnresponseendprocedureFigure4:Algorithmforexecutingapipeline.
Thealgo-rithminterleavescomputingapipeline'sschedulewithonRequesteventhandlerexecution,sothatmatchingcantakeintoanaccountwhenaneventhandlermodiestherequest,notablytoredirectit.
fortheoriginserverandactuallycreatesdynamiccon-tent.
Forexample,thisstageadaptsmedicalcontentinaweb-basededucationalenvironmenttoastudents'learn-ingneeds.
Thethirdstageprovidesadministrativecon-troloverhostedscripts'accesstowebresources.
Similartotherststage,itcanredirectorrejectrequests.
Toperformadditionalprocessing,eachpipelinestagecandynamicallyschedulefurtherstagesbylistingthecorrespondingscriptsinapolicyobject'snextStagesproperty.
AsshowninFigure4,thedynamicallysched-uledstagesareplaceddirectlyaftertheschedulingstagebutbeforeother,alreadyscheduledstages.
Asite-specicscriptcanthusdelaycontentcreationuntilalater,dynamicallyscheduledstage,whilealsoschedul-ingadditionalprocessingbeforethatstage.
Examplesforsuchintermediateservicesincludeprovidinganno-tations(electronicpost-itnotes)fortextualcontentandtranscodingmoviesforaccessfrommobiledevices.
Toputitdifferently,eachsitecancongureitsownpipelineandthushasfullcontroloverhowitscontentiscre-atedandtransformed—withintheboundsofNaKika'sadministrativecontrol.
Atthesametime,newservices,NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation173suchasvisualizationofthespreadofdiseases,caneas-ilybelayeredontopofexistingservices,suchasgeo-graphicalmapping,evenwhentheservicesareprovidedbydifferentsites:thenewservicesimplyadjuststhere-quest,includingtheURL,andthenschedulestheoriginalserviceafteritself.
BothservicesareexecutedwithinasinglepipelineonthesameNaKikanode.
Thescriptsforeachstagearenamedthroughregu-larURLs,accessedthroughregularHTTP,andsubjecttoregularHTTPcaching.
AsshowninFigure4,theadministrativecontrolscriptsareaccessedfromwell-knownlocations;thoughadministratorsofNaKikanodesmayoverridethesedefaultstoenforcetheirown,location-specicsecuritycontrols.
Site-specicscriptsareaccessedrelativetotheserver'sdomain,inalenamednakika.
js,whichiscomparabletotheuseofrobots.
txtandfavicon.
icoforcontrollingwebspidersandbrowsericons,respectively.
Allotherser-vices,thatis,dynamicallyscheduledpipelinestages,canbehostedatanyweblocationandareaccessedthroughtheirrespectiveURLs.
Incombiningcontentcreationwithcontenttransfor-mation,ourarchitecture'sscriptingpipelineisreminis-centoftheApachewebserverandJavaservlets.
Atthesametime,bothApacheandJavaservletshaveamorecomplicatedstructure.
Theyrstprocessare-questthroughachainofinputlters,thencreateare-sponseinadedicatedmodule(thecontenthandlerforApacheandtheactualservletforJavaservlets),and-nallyprocesstheresponsethroughachainofoutputl-ters.
InmirroringanHTTPproxy'shigh-levelorgani-zation,NaKika'sscriptingpipelinestageshaveasim-plerinterface—requiringonlytwoeventhandlers—andarealsomoreexible,asanyonRequesteventhan-dlercangeneratearesponse.
Furthermore,thecontentprocessingpipelinesforApacheandJavaservletscanonlybeconguredbycodeoutsidethepipelines,whileeachstageinNaKika'sscriptingpipelinescanlocallyscheduleadditionalstages—withtheoverallresultthatNaKikaismoreexibleandmoreeasilyextensible,eveninthepresenceofuntrustedcode.
NaKikaPagesWhileourarchitecture'sevent-basedprogrammingmodelissimpleandexible,alargeportionofdynamiccontentonthewebiscreatedbymarkup-basedcontentmanagementsystems,suchasPHP,JSP,andASP.
NET.
Tosupportwebdevelopersversedinthesetechnologies,NaKikaincludesanalternativeprogrammingmodelforsite-speciccontent.
Underthismodel,HTTPresourceswiththenkpextensionortext/nkpMIMEtypearesubjecttoedge-sideprocessing:alltextbetweentheendtagsistreatedasJavaScriptandreplacedbytheoutputofrunningthatcode.
Thesebmj="bmj.
bmjjournals.
com/cgi/reprint";nejm="content.
nejm.
org/cgi/reprint";p=newPolicy();p.
url=[bmj,nejm];p.
onRequest=function(){if(!
System.
isLocal(Request.
clientIP)){Request.
terminate(401);}}p.
register();Figure5:AnexamplepolicythatpreventsaccesstothedigitallibrariesoftheBMJ(BritishMedicalJournal)andtheNewEnglandJournalofMedicinefromclientsout-sideaNaKikanode'shostingorganization.
The401HTTPerrorcodeindicatesanunauthorizedaccess.
so-calledNaKikaPagesareimplementedontopofNaKika'sevent-basedprogrammingmodelthroughasim-ple,60linescript.
Weexpecttoutilizeasimilartech-niquetoalsosupportedgesideincludes[29,44](ESI)withintheNaKikaarchitecture.
3.
2SecurityandResourceControlsNaKika'ssecurityandresourcecontrolsneedtopro-tect(1)theproxiesinouredge-sidecomputingnetworkagainstclient-initiatedexploits,suchasthoseencoun-teredbyCoDeeN[48],(2)theproxiesagainstexploitslaunchedbyhostedcode,and(3)otherwebserversagainstexploitscarriedthroughourarchitecture.
Weaddressthesethreeclassesofthreatsthroughadmissioncontrolbytheclient-sideadministrativecontrolstage,re-sourcecontrolsforhostedcode,andemissioncontrolbytheserver-sideadministrativecontrolstage,respectively.
Ofcourse,itisdesirabletodroprequestsearly,beforeresourceshavebeenexpended[26],and,consequently,requeststhatareknowntocauseviolationsofNaKika'ssecurityandresourcecontrolsshouldalwaysberejectedattheclient-sideadministrativecontrolstage.
BecausethetwoadministrativecontrolstagesmediateallHTTPrequestsandresponsesenteringandleavingthesystem,theycanperformaccesscontrolbasedonclientandservernamesaswellasratelimitingbasedonrequestratesandresponsesizes.
ThecorrespondingpoliciesarespeciedasregularscriptsandcanthusleveragethefullexpressivityofNaKika'spredicatematching.
Forin-stance,Figure5showsapolicyobjectrejectingunau-thorizedaccessestodigitallibraries,whichisonetypeofexploitencounteredbyCoDeeN.
Formoreexibility,securitypoliciescanalsoleveragedynamicallysched-uledstages.
Forexample,thetwoadministrativecontrolstagescandelegatecontentblockingtoseparatestageswhosecode,inturn,isdynamicallycreatedbyascriptbasedonablacklist.
Toenforceresourcecontrols,aresourcemanagerNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation174procedureCONTROL(resource)priorityq←EMPTYifIS-CONGESTED(resource)thenTrackusageandthrottleforsiteinACTIVE-SITES()doUPDATE(site.
usage,resource)ENQUEUE(priorityq,site)THROTTLE(site,resource)endforelseifIS-RENEWABLE(resource)thenTrackusageforsiteinACTIVE-SITES()doUPDATE(site.
usage,resource)endforendifWAIT(TIMEOUT)LetthrottlingtakeeffectifIS-CONGESTED(resource)thenTERMINATE(DEQUEUE(priorityq))KilltopoffenderelseUNTHROTTLE(resource)RestorenormaloperationendifendprocedureFigure6:Algorithmforcongestioncontrol.
TheCON-TROLprocedureisperiodicallyexecutedforeachtrackedresource.
Notethatourimplementationdoesnotblockbutratherpollstodetecttimeouts.
tracksCPU,memory,andbandwidthconsumptionaswellasrunningtimeandtotalbytestransferredforeachsite'spipelines.
Italsotracksoverallconsumptionfortheentirenode.
AsshowninFigure6,ifanyofthesere-sourcesisoverutilized,theresourcemanagerstartsthrot-tlingrequestsproportionallytoasite'scontributiontocongestionand,ifcongestionpersists,terminatesthepipelinesofthelargestcontributors.
Asite'scontribu-tiontocongestioncapturestheportionofresourcescon-sumedbyitspipelines.
Forrenewableresources,i.
e.
,CPU,memory,andbandwidth,onlyconsumptionunderoverutilizationisincluded.
Fornonrenewableresources,i.
e.
,runningtimeandtotalbytestransferred,allcon-sumptionisincluded.
Ineithercase,theactualvalueistheweightedaverageofpastandpresentconsumptionandisexposedtoscripts—thusallowingscriptstoadapttosystemcongestionandrecoverfrompastpenalization.
Tocompleteresourcecontrols,allpipelinesarefullysandboxed.
Theyareisolatedfromeachother,running,forexample,withtheirownheaps,andcanonlyaccessselectplatformfunctionality.
Inparticular,allregularop-eratingsystemservices,suchasprocesses,les,orsock-ets,areinaccessible.
Theonlyresourcesbesidescomput-ingpowerandmemoryaccessiblebyscriptsaretheser-vicesprovidedbyNaKika'svocabularies(thatis,native-codelibraries).
WebelievethatNaKika'scongestion-basedresourcemanagementmodelismoreappropriateforopensys-temsthanmoreconventionalquota-basedresourcecon-trolsfortworeasons.
First,opensystemssuchasNaKikahaveadifferentusagemodelthanmoreconven-tionalhostingplatforms:theyareopentoallcontentproducersandconsumers,withhostingorganizationsef-fectivelydonatingtheirresourcestothepublic.
Inotherwords,servicesandapplicationsshouldbeabletocon-sumeasmanyresourcesastheyrequire—aslongastheydonotinterferewithotherservices,i.
e.
,causeconges-tion.
Second,quota-basedresourcecontrolsrequireanadministrativedecisionastowhatresourceutilizationislegitimate.
However,evenwhenquotasaresetrelativetocontentsize[9],itishardtodetermineappropriatecon-stants,astheresourcerequirementsmayvarywidely.
Wedidconsidersettingne-grainedquotasthroughpredi-catesonHTTPmessages,comparabletohowourarchi-tectureselectseventhandlers.
However,whilepredicate-basedpolicyselectionisexible,italsoampliesthead-ministrativeproblemofwhichconstantstochooseforwhichcode.
Ourarchitecture'sutilizationofscriptinghastwoad-vantagesforsecurityandresourcecontrolwhencom-paredtootheredge-sidesystems.
First,administrativecontrolscriptssimplifythedevelopmentanddeploymentofsecuritypolicyupdates.
Onceaxtoanewlydiscov-eredexploitorabusehasbeenimplemented,theupdatedscriptsaresimplypublishedontheNaKikawebsiteandautomaticallyinstalledacrossallnodeswhencachedcopiesoftheoldscriptsexpire.
Incontrast,CoDeeNandotheredge-sidesystemsthathardcodesecuritypoliciesrequireredistributionofthesystembinariesacrossallnodes.
ThoughNaKikastillrequiresbinaryredistribu-tiontoxsecurityholesinnativecode.
Second,provid-ingassurancethathostedservicesandapplicationsareeffectivelysecuredissimplerforscriptsthanforJavaornativecode.
Ourstartingpointisabarescriptingen-ginetowhichweselectivelyaddfunctionality,throughvocabularies,ratherthantryingtorestrictageneralpur-poseplatformafterthefact.
3.
3HardStateTheweb'sexpiration-basedconsistencymodelforcachedstateissufcienttosupportarangeofedge-sideapplications,includingcontentassembly(through,forexample,edge-sideincludes[29,44])orthetranscod-ingofmulti-mediacontent.
However,acompleteplat-formforedge-sidecontentmanagementalsorequiressupportformanaginghardstatesuchasedge-sideaccesslogsandreplicatedapplicationstate.
Edge-sideloggingprovidesaccurateusagestatisticstocontentproducers,whileedge-sidereplicationavoidsaccessingtheoriginserverforeverydataitem.
NaKikaperformsaccessloggingonaper-sitebasis.
Loggingistriggeredthroughasite'sscript,whichspeci-estheURLforpostinglogupdates.
Periodically,eachNaKikanodescansitslog,collectsallentriesforeachspecicsite,andpoststhoseportionsofthelogtotheNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation175speciedURLs.
NaKika'ssupportforedge-sidereplicationbuildsonGaoetal.
'suseofdistributedobjects,which,internally,relyondomain-specicreplicationstrategiestosynchro-nizestateupdatesandsupportbothpessimisticandop-timisticreplication[14].
LikeGaoetal.
,NaKika'shardstatereplicationreliesonadatabaseforlocalstor-ageandareliablemessagingserviceforpropagatingup-dates,whichareexposedthroughvocabularies.
UnlikeGaoetal.
,NaKika'shardstatereplicationisimple-mentedbyregularscripts.
Updatesareacceptedbyascript,writtentolocalstorage,andthenpropagatedtoothernodesthroughthemessaginglayer.
Uponreceiptofamessageonanothernode,aregularscriptprocessesthemessageandappliestheupdatetothatnode'slocalstorage.
Asaresult,NaKikaprovidescontentproduc-erswithconsiderableexibilityinimplementingtheirdomain-specicreplicationstrategies.
Forexample,thescriptacceptingupdatescanpropagatethemonlytotheoriginservertoensureserializabilityortoallnodestomaximizeavailability.
Furthermore,thescriptacceptingmessagescaneasilyimplementdomain-specicconictresolutionstrategies.
Tosecurereplicatedstate,NaKikapartitionshardstateamongstsitesandenforcesresourceconstraintsonpersistentstorage.
Sinceupdateprocess-ingisperformedbyregularscripts,italreadyissubjecttoNaKika'ssecurityandresourcecontrols.
3.
4OverlayNetworkTheNaKikaarchitecturereliesonastructuredover-laynetworkforcoordinatinglocalcachesandforen-ablingincrementaldeploymentwithlowadministrativeoverhead.
Fromanarchitecturalviewpoint,theoverlayistreatedlargelyasablackbox,tobeprovidedbyanexistingDHT[13,16,35,42,52].
Thisreectsacon-sciousdesigndecisiononourendandprovidesuswithatestcaseforwhetherDHTscan,infact,serveasro-bustandscalablebuildingblocksforaglobal-scaledis-tributedsystem.
OurprototypeimplementationbuildsonCoral[13],whichiswell-suitedtotheneedsofourarchi-tecture,asCoralexplicitlytargetssoftstateandincludesoptionalsupportforDNSredirectiontolocalnodes.
AswedeployNaKika,weexpecttorevisitthefunctional-ityprovidedbytheDHT.
Notably,loadbalancing,whichiscurrentlyprovidedattheDNSlevel,canlikelybenetfromapplication-specicknowledge,suchasthenum-berofconcurrentHTTPexchangesbeingprocessedbyanode'sscriptingpipelines.
3.
5SummaryTheNaKikaarchitectureleveragesscriptingandoverlaynetworkstoprovideanopenedge-sidecomputingnet-work.
First,NaKikaexposesaprogrammingmodelal-readyfamiliartowebdevelopersbyorganizinghostedservicesandapplicationsintoapipelineofscriptedeventhandlersthatprocessHTTPrequestsandresponses.
Sec-ond,itprovidesasecureexecutionplatformbymedi-atingallHTTPprocessingunderadministrativecontrol,byisolatingscriptsfromeachother,andbylimitingre-sourceutilizationbasedonoverallsystemcongestion.
Third,itprovidesextensibilitybydynamicallyschedul-ingeventhandlerswithinapipelinestageaswellasad-ditionalpipelinestagesthroughpredicatematching.
Fi-nally,itprovidesscalabilitybyorganizingallnodesintoanautomaticallyconguredoverlaynetwork,whichsup-portstheredirectionofclientsto(nearby)edgenodesandtheadditionofnewnodeswithlowadministrativeover-head.
Atthesametime,webintegrationisnotentirelycom-plete,asURLsneedtoberewrittenforNaKikaaccess.
Asalreadydiscussed,URLscanbeautomaticallyrewrit-tenbywebbrowsers,hostedcode,aswellasserversand,consequently,theneedformanualrewritingwilldecreaseovertime.
Furthermore,whileourarchitec-tureprotectsagainstclient-andscript-initiatedexploits,itdoesnotcurrentlyprotectagainstmisbehavingedge-sidenodes.
Inparticular,nodescanarbitrarilymodifycachedcontent,whichisespeciallyproblematicforad-ministrativecontrolscripts.
Wereturntotheissueofcon-tentintegrityinSection6.
4ImplementationOurprototypeimplementationofNaKikabuildsonthreeopensourcepackages:theApache2.
0webserver,theMozillaproject'sSpiderMonkeyJavaScriptengine[27],andtheCoraldistributedhashtable[13].
WechoseApacheforHTTPprocessingbecauseitrepresentsama-tureandcross-platformwebserver.
Similarly,Spider-Monkeyisamatureandcross-platformimplementationofJavaScriptandusedacrosstheMozillaproject'swebbrowsers.
Additionally,ourprototypeincludesaprelim-inaryimplementationofhardstatereplication,whichre-liesontheJava-basedJORAMmessagingservice[30]andexposesavocabularyformanaginguserregistra-tions,asrequiredbytheSPECweb99benchmark.
Ourimplementationaddsapproximately23,000linesofCcodetothe263,000linesofcodeinApache,the123,000linesinSpiderMonkey,andthe60,000linesinCoral.
ThemajorityofchangesistoApacheandmostlycon-tainedinApachemodules.
OurmodiedApachebinary,includingdynamicallyloadedlibraries,is10.
6MBytelargeandtheCoralDHTserveris13MByte.
AsalreadymentionedinSection3.
1,Apachestruc-turesHTTPprocessingintoachainofinputltersthatoperateonrequests,followedbyacontenthandlerthatgeneratesresponses,followedbyachainofoutputl-tersthatoperateonresponses.
Ourprototypeimple-mentsthescriptingpipelinebybreakingeachstageNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation176intoapairofinputandoutputlters,whichexecutetheonRequestandonResponseeventhandlers,re-spectively,andbydynamicallyinsertingthepairintoApache'slterchain.
Thecontenthandlerisamodi-edversionofApache'smodproxy,whichimplementstheproxycacheand,inourversion,alsointerfaceswiththeDHT.
IfanonRequesteventhandlergeneratesanHTTPresponse,ourimplementationsetsaagthatpre-ventstheexecutionofscriptsinlaterpipelinestagesandoftheproxycachingcode,whilestillconformingwithApache'ssequencingofinputlters,contenthandler,andoutputlters.
Toprovideisolation,ourimplementationexecuteseachpipelineinitsownprocessandeachscript,inturn,initsownuser-levelthreadandwithitsownscriptingcontext,includingheap.
Scriptingcontextsarereusedtoamortizetheoverheadofcontextcreationacrossseveraleventhandlerexecutions;thisissafebecauseJavaScriptprogramscannotforgepointersandtheheapisautomat-icallygarbagecollected.
Aseparatemonitoringprocesstrackseachpipeline'sCPU,memory,andnetworkcon-sumptionandperiodicallyexecutesthecongestioncon-trolalgorithminFigure6.
Tothrottleasite'spipelines,themonitoringprocesssetsaaginsharedmemory,whichcausestheregularApacheprocessestorejectre-questsforthatsite'scontentwithaserverbusyerror.
Toterminateasite'spipelines,themonitoringprocesskillsthecorrespondingApacheprocesses,thusputtinganim-mediatestoptoprocessingevenifapipelineisexecutingavocabulary'snativecode.
Employingper-scriptuser-levelthreadsalsohelpsin-tegratescriptexecutionwithApache,whilestillexposingasimpleprogrammingmodel.
Inparticular,Apache'sse-quenceofinputlters,contenthandler,andoutputltersisnotnecessarilyinvokedoncompleteHTTPrequestsandresponses.
Rather,eachlterisinvokedonchunksofdata,theso-calledbucketbrigades,asthatdatabecomesavailable.
Asaresult,Apachemayinterleavetheexe-cutionofseveralonRequestandonResponseeventhandlers.
Per-scriptuser-levelthreadshidethispiece-mealHTTPprocessingfromscriptdevelopers,provid-ingtheillusionofscriptsrunningtocompletionbeforeinvokingthenextstage.
ToavoidcopyingdatabetweenApacheandthescriptingengine,ourimplementationaddsbytearraysasanewcoredatatypetoSpiderMon-key.
Wheneverpossible,thesebytearraysdirectlyrefer-encethecorrespondingbucketbrigadebuffers.
Thepolicymatchingcodetradesoffspacefordynamicpredicateevaluationperformance.
Whileloadingascriptandregisteringpolicyobjects,thematcherbuildsadeci-siontreeforthatpipelinestage,withnodesinthetreerepresentingchoices.
Startingfromtherootofthetree,thenodesrepresentthecomponentsofaresourceURL'sservername,theport,thecomponentsofthepath,theNameDescriptionProxyAregularApacheproxy.
DHTTheproxywithanintegratedDHT.
AdminANaKikanodeevaluatingonematchingpred-icateandexecutingemptyeventhandlersforeachofthetwoadministrativecontrolstages.
Pred-nTheAdmincongurationplusanotherstageevaluatingpredicatesfornpolicyobjects,withnomatches.
Match-1TheAdmincongurationplusanotherstageevaluatingonematchingpredicateandexecut-ingthecorresponding,emptyeventhandlers.
Table1:Thedifferentmicro-benchmarkcongurations.
componentsoftheclientaddress,theHTTPmethods,and,nally,individualheaders.
Ifapropertyofapol-icyobjectdoesnotcontainanyvalues,thecorrespondingnodesareskipped.
Furthermore,ifapropertycontainsmultiplevalues,nodesareaddedalongmultiplepaths.
Whenallpropertieshavebeenaddedtothedecisiontree,theeventhandlersareaddedtothecurrentnodes,onceforeachpath.
Withthedecisiontreeinplace,dynamicpredicateevaluationsimplyisadepth-rstsearchacrossthetreeforthenodeclosesttotheleavesthatalsoref-erencesanappropriateeventhandler.
Decisiontreesarecachedinadedicatedin-memorycache.
Theimplemen-tationalsocachesthefactthatasitedoesnotpublishapolicyscript,thusavoidingrepeatedchecksforthenakika.
jsresource.
5EvaluationToevaluateNaKika,weperformedasetoflocalmicro-benchmarksandasetofend-to-endexperiments,whichincludewideareaexperimentsonthePlanetLabdis-tributedtestbed[32].
Themicro-benchmarkscharac-terize(1)theoverheadintroducedbyNaKika'sDHTandscriptingpipelineand(2)theeffectivenessofourcongestion-basedresourcecontrols.
Theend-to-endex-perimentscharacterizetheperformanceandscalabilityofareal-worldapplicationandofamodiedSPECweb99benchmark.
Wealsoimplementedthreenewservicestocharacterizetheextensibilityofouredge-sidecom-putingnetwork.
Insummary,ourexperimentalresultsshowthat,eventhoughthescriptingpipelineintroducesnoticeableoverheads,NaKikaisaneffectivesubstratebothforscalingweb-basedapplicationsandforextend-ingthemwithnewfunctionality.
5.
1Micro-BenchmarksTocharacterizetheoverheadsintroducedbyNaKika'sDHTandscriptingpipeline,wecomparetheperfor-manceofaNaKikanodewitharegularApacheproxycacheforaccessingasingle,static2,096bytedoc-umentrepresentingGoogle'shomepage(withoutin-NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation177CongurationColdCacheWarmCacheProxy31DHT51Admin162Pred-0192Pred-1202Match-1212Pred-10222Pred-50302Pred-100412Table2:Latencyinmillisecondsforaccessingastaticpageunderthedifferentcongurations.
lineimages).
Sincestaticresourcesarealreadywell-servedbyexistingproxycachesandCDNs,thesemicro-benchmarksrepresentaworst-caseusagescenarioforNaKika.
Afterall,anytimespentintheDHTorinthescriptingpipelineaddsunnecessaryoverhead.
Forallexperiments,wemeasuredthetotaltimeofaclientac-cessingthestaticwebpagethroughaproxy—withclient,proxy,andserverbeinglocatedonthesame,switched100Mbitethernet.
TheproxyrunsonaLinuxPCwitha2.
8GHzIntelPentium4and1GBofRAM.
Weperformed18experiments,representing9differ-entcongurationsunderbothacoldandawarmproxycache.
ThedifferentcongurationsaresummarizedinTable1anddeterminetheoverheadofDHTintegration,baselineadministrativecontrol,predicatematching,andeventhandlerinvocation,respectively.
ForthecoldcachecaseoftheAdmin,Pred-n,andMatch-1congurations,theadministrativecontrolandsite-specicscriptsarefetchedfromthelocalserverandevaluatedtoproducethecorrespondingdecisiontree.
Forthewarmcachecase,thecacheddecisiontreeisused.
Resourcecontrolisdisabledfortheseexperiments.
Table2showsthelatencyinmillisecondsforthe18differentexperiments.
Eachnumberistheaverageof10individualmeasurements.
Overall,theresultsclearlyil-lustratethebasiccostofutilizingNaKika:itsscript-ingpipeline.
ForthePred-nandMatch-1congura-tionsunderacoldcache,loadingtheactualpagetakes2.
9msandloadingthescripttakesbetween2.
5msand5.
6ms,dependingonsize.
Additionally,thecreationofascriptingcontexttakes1.
5ms.
Finally,parsingandexecutingthescriptletakesbetween0.
08msand17.
8ms,again,dependingonsize.
However,theresultsalsoillustratethatourimplementation'suseofcaching—forresources,scriptingcontexts,anddecisiontrees—iseffective.
RetrievingaresourcefromApache'scachetakes1.
1msandretrievingadecisiontreefromthein-memorycachetakes4s.
Re-usingascriptingcon-texttakes3s.
Finally,predicateevaluationtakeslessthan38sforallcongurations.
However,theseop-erationsalsoresultinahigherCPUload:theNaKikanodereachescapacitywith30load-generatingclientsat294requests/second(rps)underMatch-1,whiletheplainApacheproxyreachescapacitywith90clientsat603rpsonthesamehardware.
Sincebothresourcesandscriptsonlyneedtobeaccessedwhenreachingtheirex-pirationtimes,weexpectthatrealworldperformanceisclosertowarmcachethancoldcacheresults.
Further-more,mostwebresourcesareconsiderablylargerthanGoogle'shomepage,sothatnetworktransfertimeswilldominatescriptingpipelinelatency.
ResourceControlsTocharacterizetheeffectivenessofNaKika'scongestion-basedresourcemanagement,wecom-paretheperformanceofaNaKikanodewithandwithoutresourcecontrolsunderhighload,suchasthatcausedbyaashcrowd.
Fortheseexperiments,theNaKikaproxyrunsonthesameLinuxPCasbefore.
Loadisgeneratedbyaccessingthesame2,096bytepageundertheMatch-1congurationinatightloop.
With30loadgenerators(i.
e.
,attheproxy'scapacity),wemeasure294rpswithoutand396rpswithresourcecontrols.
With90loadgenerators(i.
e.
,underoverload),wemeasure229rpswithoutand356rpswithresourcecontrols.
Ifwealsoaddoneinstanceofamisbehavingscript,whichconsumesallavailablememorybyrepeatedlydoublingastring,thethroughputwith30loadgeneratorsdropsto47rpswithoutbutonly382rpswithresourcecontrols.
Forallexperiments,therunswithresourcecontrolsrejectlessthan0.
55%ofallofferedrequestsduetothrottlinganddroplessthan0.
08%duetotermination,includingtheonetriggeringthemisbehavingscript.
TheseresultsillustratethebenetsofNaKika'sresourcecontrols.
Eventhoughresourcemanagementisreactive,throttlingiseffectiveatensuringthatadmittedrequestshavesufcientresourcestoruntocompletion,andterminationiseffectiveatisolatingtheregularloadfromthemisbehavingone.
5.
2Web-basedMedicalEducationToevaluateareal-worldapplicationrunningonNaKika,wecomparetheSurgicalInteractiveMultimediaMod-ules[43](SIMMs)intheiroriginalsingle-servercon-gurationwithaninitialporttoouredge-sidecomput-ingnetwork.
TheSIMMsareaweb-basededucationalenvironmentthatisbeingdevelopedbyNYU'smedi-calschool.
EachSIMMfocusesonaparticularmedi-calconditionandcoversthecompleteworkupofapa-tientfrompresentationtotreatmenttofollow-up.
Itcon-sistsofrich-mediaenhancedlectures,annotatedimagingstudies,pathologydata,andanimatedandreal-lifesur-gicalfootage—comprisingaround1GBofmultimediacontentpermodule.
TheveexistingSIMMsalreadyareanintegralpartofthecurriculumatNYU'smedicalschoolandarealsousedatfourothermedicalschoolsinNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation178Figure7:Cumulativedistributionfunction(CDF)forla-tencytoaccessHTMLcontentintheSIMMs'single-serverandNaKikacoldandwarmcachecongurations.
theU.
S.
andAustralia,withmoreinstitutionstofollow.
TheSIMMsrelyheavilyonpersonalizedandmultimediacontentbutdonotcontainanyrealpatientdata(withitscorrespondentprivacyrequirements),thusmakingthemgoodcandidatesfordeploymentonNaKika.
TheSIMMsareimplementedontopofApacheTom-cat5.
0andMySQL4.
1.
TheyutilizeJSPandJavaservletstocustomizecontentforeachstudentaswellastotrackherprogressthroughthematerialandthere-sultsofsectionalassessments.
Tofacilitatefuturein-terfacechangesaswellasdifferentuserinterfaces,cus-tomizedcontentisrepresentedasXMLand,beforebe-ingreturnedtotheclient,renderedasHTMLbyanXSLstylesheet(whichisthesameforallstudents)2.
Theini-tialNaKikaportoff-loadsthedistributionofmultimediacontent,sinceitislarge,andthe(generic)renderingofXMLtoHTML,sinceitisprocessorintensive,toouredge-sidecomputingnetwork.
Contentpersonalizationisstillperformedbythecentralserver;weexpectthatfu-tureversionswillalsomovepersonalizationtotheedge.
TheportwasperformedbyoneofthemaindevelopersoftheSIMMsandtooktwodays.
Thedeveloperspentfourhoursontheactualport—whichentailedchangingURLstoutilizeNaKika,makingXMLandXSLcon-tentaccessibleovertheweb,andswitchingfromcookiestoURL-basedsessionidentiersaswellasfromHTTPPOSTstoGETs—andtherestofthetwodaysdebug-gingtheport.
Infact,themainimpedimenttoafasterportwastherelativelackofdebuggingtoolsforourpro-totypeimplementation.
Theportadds65linesofcodetotheexistingcodebaseof1,900lines,changes25lines,andremoves40lines.
Thenewnakika.
jspolicycon-sistsof100linesofJavaScriptcode.
Toevaluateend-to-endperformance,wecomparethe2Anearlierversionreliedonacustom-builtMacromediaDirectorclientforrenderingXML.
Itwasabandonedinfavorofregularwebbrowsersduetotheextraeffortofmaintainingadedicatedclient.
single-serverversionwiththeNaKikaportaccessedthroughasingle,localproxy—whichletsuscomparebaselineperformance—andwiththeNaKikaportrun-ningonproxiesdistributedacrossthewidearea—whichletsuscomparescalability.
Forallexperiments,wemea-surethetotaltimetoaccessHTMLcontent—whichrep-resentsclient-perceivedlatency—andtheaverageband-widthwhenaccessingmultimediales—whichdeter-mineswhetherplaybackisuninterrupted.
Loadisgen-eratedbyreplayingaccesslogsfortheSIMMscollectedbyNYU'smedicalschool;logreplayisaccelerated4*toproducenoticeableactivity.
Forthelocalexperiments,werelyonfourload-generatingnodes.
Forthewide-areaexperiments,12load-generatingPlanetLabnodesaredistributedacrosstheU.
S.
EastCoast,WestCoast,andAsia—thussimulatingageographicallydiversestu-dentpopulation—and,forNaKika,matchedwithnearbyproxynodes.
ForNaKika,wedirectclientstorandomlychosen,butclose-byproxiesfromapreconguredlistofnodelocations.
Forthelocalexperiments,theoriginserveristhesamePCasusedinSection5.
1;forthewide-areaexperiments,itisaPlanetLabnodeinNewYork.
Thelocalexperimentsshowthat,underacoldcacheandheavyload,theperformanceofthesingleNaKikaproxytrailsthatofthesingleserver.
Notably,for160clients(i.
e.
,40instancesofthelogreplayprogramrun-ningoneachof4machines),the90thpercentilela-tencyforaccessingHTMLcontentis904msforthesingleserverand964msfortheNaKikaproxy.
Thefractionofaccessestomultimediacontentconsistentlyseeingabandwidthofatleast140Kbps—theSIMMs'videobitrate—is100%forbothcongurations.
How-ever,whenaddinganarticialnetworkdelayof80msandbandwidthcapof8Mbpsbetweentheserverononesideandtheproxyandclientsontheotherside(tosimulateawide-areanetwork),thesingleNaKikaproxyalreadyoutperformsthesingleserver,illustratingtheadvantagesofplacingproxiesclosetoclients.
For160clients,the90thpercentilelatencyforHTMLcon-tentis8.
88sforthesingleserverand1.
21sfortheNaKikaproxy.
Furthermore,only26.
2%ofclientsseesufcientbandwidthforaccessingvideocontentforthesingleserver,while99.
9%dofortheNaKikaproxy.
AsillustratedinFigure7,theadvantagesofouredge-sidecomputingnetworkbecomemorepronouncedforthewide-areaexperiments.
For240clients(i.
e.
,20pro-gramsrunningoneachof12machines),the90thper-centilelatencyforaccessingHTMLcontentis60.
1sforthesingleserver,31.
6sforNaKikawithacoldcache,and9.
7swithawarmcache.
Forthesingleserver,thefractionofclientsseeingsufcientvideobandwidthis0%andthevideofailurerateis60.
0%.
ForNaKikawithacoldcache,thefractionis11.
5%andthefailurerateis5.
6%.
Withawarmcache,thefractionis80.
3%andNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation179thefailurerateis1.
9%.
ForNaKika,accessestomul-timediacontentbenettoagreaterextentfromawarmcachethanaccessestoHTML,sincePlanetLablimitsthebandwidthavailabletoeachhostedproject.
5.
3HardStateReplicationTofurtherevaluateend-to-endperformanceinthewidearea,wecomparetheperformanceofasingleApachePHPserverandthesameserversupportedbyNaKikarunningamodiedversionoftheSPECweb99benchmark.
Forthisexperiment,were-implementedSPECweb99'sserver-sidescriptsinPHPandNaKikaPages.
Thesingle-serverversionreliesonPHPbe-causeitisthemostpopularadd-onforcreatingdynamiccontenttothemostpopularwebserver[36,37].
TheNaKikaversionreliesonreplicatedhardstatetoman-ageSPECweb99'suserregistrationsandproles.
WithclientsandveNaKikanodesontheU.
S.
WestCoastandtheserverlocatedontheEastCoast,80%dynamicrequests,160simultaneousconnections,andaruntimeof20minutes,thePHPserverhasameanresponsetimeof13.
7sandathroughputof10.
8rps.
Withacoldcache,theNaKikaversionhasaresponsetimeof4.
3sandathroughputof34.
3rps.
AdditionalexperimentsshowthattheresultsareverysensitivetoPlanetLabCPUload,thusindicatingthatNaKika'smainbenetfortheseex-perimentsistheadditionalCPUcapacityunderheavyload(and,conversely,thatNaKikarequiresampleCPUresourcestobeeffective).
OurSPECweb99compliancescoreis0duetothelimitedbandwidthavailablebetweenPlanetLabnodes.
Nonetheless,thisbenchmarkshowsthatNaKikacaneffectivelyscaleacomplexworkloadthatincludesstaticcontent,dynamiccontent,anddis-tributedupdates.
5.
4ExtensionsToevaluateNaKika'sextensibility,weimplementedthreeextensionsinadditiontotheNaKikaPagesex-tensiondiscussedinSection3.
1:electronicannotationsfortheSIMMs,imagetranscodingforsmalldevices,andcontentblockingbasedonblacklists.
Asdescribedbe-low,ourexperienceswiththeseextensionsconrmthatNaKikais,infact,easilyextensible.
Inparticular,theyillustratetheutilityofpredicate-basedeventhandlerse-lectionanddynamicallyscheduledpipelinestages.
Fur-thermore,theyillustratethatdeveloperscanbuildusefulextensionsquickly,eveniftheyarenotfamiliarwithNaKikaorJavaScriptprogramming.
Ourrstextensionaddselectronicannotations,i.
e.
,post-itnotes,totheSIMMs,thusprovidinganotherlayerofpersonalizationtothisweb-basededucationalenviron-ment.
TheextendedSIMMsarehostedbyasiteoutsideNYU'smedicalschoolandutilizedynamicallysched-uledpipelinestagestoincorporatetheNaKikaversionoftheSIMMs.
Thenewfunctionalitysupportselec-tronicannotationsbyinjectingthecorrespondingdy-namicHTMLintotheSIMMs'HTMLcontent.
ItalsorewritesrequestURLstorefertotheoriginalcontentandURLsembeddedinHTMLtorefertoitself,thusin-terposingitselfontotheSIMMs.
Theresultingpipelinehasthreenon-administrativestages,oneeachforURLrewriting,annotations,andtheSIMMs.
Theannotationsthemselvesarestoredonthesitehostingtheextendedversion.
Thisextensiontookonedeveloper5hourstowriteanddebugandcomprises50linesofcode;itlever-agesapreviouslydevelopedimplementationofelec-tronicannotations,whichcomprises180linesofcode.
Incontrasttotheextensionforelectronicannotations,whichrepresentsonesitebuildingonanothersite'sser-vice,oursecondextensionrepresentsaservicetobepub-lishedonthewebforusebythelargercommunity.
ThisextensionscalesimagestotonthescreenofaNokiacellphoneandgeneralizestheonResponseeventhan-dlershowninFigure2tocachetransformedcontent.
Theextensioncaneasilybemodiedtosupportothertypesandbrandsofsmalldevicesby(1)parameterizingtheeventhandler'sscreensizeand(2)addingnewpolicyobjectsthatmatchotherdevices'User-AgentHTTPheaders.
ThisextensiontookanoviceJavaScriptdevel-operlessthantwohourstowriteanddebugandcom-prises80linesofcode.
Ourthirdextensiondoesnotprovidenewfunctional-ity,butratherextendsNaKika'ssecuritypolicywiththeabilitytoblocksitesbasedonblacklists.
ItsintendeduseistodenyaccesstoillegalcontentthroughNaKika.
Theextensionisimplementedthroughtwodynamicallyscheduledpipelinestages.
TherstnewstagereliesonastaticscripttodynamicallygeneratetheJavaScriptcodeforthesecondnewstage,which,inturn,blocksaccesstotheURLsappearingontheblacklist.
ThestaticscriptreadstheblacklistfromapreconguredURLandthengeneratesapolicyobjectforeachURLappearingonthatblacklist.
TheonRequesteventhandlerforallpol-icyobjectsisthesamehandler,denyingaccessasillus-tratedinFigure5.
Thisextensiontook4.
5hourstowriteanddebug,withanadditional1.
5hoursforsettingupatestbed.
Sincethisextensionrepresentsthedeveloper'srstNaKikaaswellasJavaScriptcode,the4.
5hoursincludeonehourmostlyspentfamiliarizinghimselfwithJavaScript.
Theextensioncomprises70linesofcode.
6DiscussionandFutureWorkAspresentedinthispaper,NaKikaassumesthatedge-sidenodesaretrusted,whicheffectivelylimitstheor-ganizationsparticipatinginadeployment.
ToallowNaKikatoscaletoalargernumberofedgenetworksandnodes,wearecurrentlyworkingtowardseliminatingthisrequirementbyautomaticallyensuringtheintegrityNSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation180ofcontentservedbyouredge-sidecomputingnetwork.
Contentintegrityisimportantforproducersandcon-sumerssothat,forexample,theresultsofmedicalstud-iescannotbefalsied.
Italsoisimportantfortheop-erationofthenetworkitself,asscripts,includingthoseusedforadministrativecontrol,areaccessedthroughandcachedwithinNaKika.
Fororiginalcontent,protectingagainstinadver-tentormaliciousmodicationreducestodetectingsuchchangesandthenretrievingtheauthoritativever-sionfromtheoriginserver.
However,usingcryp-tographichashes,forexample,throughself-certifyingpathnames[24]assuggestedin[13],isinsufcient,astheycannotensurefreshness.
Toprovidebothintegrityandfreshness,wehavealreadyimplementedanalterna-tivesolutionthatintegrateswithHTTP'scachecontrolbyaddingtwonewheaderstoHTTPresponses.
TheX-Content-SHA256headerspeciesacryptographichashofthecontentforintegrityand,toreduceload,canbeprecomputed.
TheX-Signatureheaderspeciesasignatureoverthecontenthashandthecachecontrolheadersforfreshness.
OursolutionrequirestheuseofabsolutecacheexpirationtimesinsteadoftherelativetimesintroducedinHTTP/1.
1[21]asnodescannotbetrustedtocorrectlydecrementrelativetimes.
Forprocessedorgeneratedcontent,contentintegritycannotbeestablishedthroughhashesandsignaturesalone,ascontentprocessingisperformedbypotentiallyuntrustednodes.
Instead,weareexploringaprobabilisticvericationmodel.
Underthismodel,atrustedregistrymaintainsNaKikamembership.
Todetectmisbehav-ingnodes,clientsforwardafractionofcontentreceivedfromNaKikaproxiestootherproxies,whichthenre-peatanyprocessingthemselves.
Ifthetwoversionsdonotmatch,theoriginalproxyisreportedtotheregistry,whichusesthisinformationtoevictmisbehavingnodesfromtheedge-sidecomputingnetwork.
7ConclusionsEdge-sidecontentmanagementreducesloadonoriginservers,bandwidthconsumptionacrosstheinternet,andlatencyforclients.
Italsoabsorbsloadspikesforunder-provisionedservers.
Tomakethesebenetsavailabletoallcontentproducersandconsumersandthustofostercollaborationandinnovationonweb-basedapplications,NaKikaprovidesanopenarchitectureforedge-sidecon-tentcreation,transformation,andcaching.
ServicesandapplicationshostedbyNaKikaareex-pressedthroughscriptedeventhandlers.
EventhandlersareselectedthroughpredicatesonHTTPmessagesandarecomposedintoapipelinethatcombinesadministra-tivecontrolandsite-specicprocessing.
Theresultingprogrammingmodelisnotonlyfamiliartowebdevel-opersversedinclient-sidescriptingandthecontentpro-cessingpipelinesofApacheandJavaservlets,butitalsoismoresecureandmoreeasilyextensible.
Toprovidesecurity,NaKika'sscriptingpipelinemediatesallre-questsandresponsespassingthroughthesystem.
Fur-thermore,allhostedservicesandapplicationsareiso-latedfromeachotherandtheunderlyingoperatingsys-temandsubjecttocongestion-basedresourcemanage-ment:hostedcodecanconsumeresourceswithoutre-strictionaslongasitdoesnotcauseoverutilization.
Toprovideincrementalscalability,allNaKikanodesareor-ganizedintoastructuredoverlaynetwork,whichenablesDNSredirectionofclientstonearbynodesandcoop-erativecachingofbothoriginalandprocessedcontent.
TheexperimentalevaluationdemonstratesthatNaKika'sprototypeimplementationiseffectiveatreducingloadonoriginserversandlatencyforclients,supportingsigni-cantlylargeruserpopulationsthanasingledynamicwebserver.
ItalsodemonstratesthatNaKikais,infact,easilyprogrammableandextensible.
AcknowledgmentsBillHollowayportedtheSIMMstoNaKikaandJakeAvileshelpedwiththeirevaluation.
RobertSouleimple-mentedstaticcontentintegrityandthesecuritypolicyex-tension.
Ourshepherd,EminG¨unSirer,andtheanony-mousreviewersprovidedvaluablefeedbackonearlierversionsofthispaper.
ThismaterialisbasedinpartuponworksupportedbytheNationalScienceFoundationun-derGrantNo.
0537252andbytheNewYorkSoftwareIndustryAssociation.
References[1]AkamaiTechnologies,Inc.
Adeveloper'sguidetoon-demanddistributedcomputing,Mar.
2004.
[2]A.
AwadallahandM.
Rosenblum.
ThevMatrix:Anetworkofvirtualmachinemonitorsfordynamiccontentdistribution.
InProc.
7thIWCW,Aug.
2002.
[3]A.
Barbir,O.
Batuner,B.
Srinivas,M.
Hofmann,andH.
Or-man.
Securitythreatsandrisksforopenpluggableedgeservices(OPES).
RFC3837,IETF,Aug.
2004.
[4]A.
Barbir,R.
Penno,R.
Chen,M.
Hofmann,andH.
Orman.
Anarchitectureforopenpluggableedgeservices(OPES).
RFC3835,IETF,Aug.
2004.
[5]L.
Bent,M.
Rabinovich,G.
M.
Voelker,andZ.
Xiao.
Characteri-zationofalargewebsitepopulationwithimplicationsforcontentdelivery.
InProc.
13thWWW,pp.
522–533,May2004.
[6]M.
Blaze,J.
Feigenbaum,J.
Ioannidis,andA.
D.
Keromytis.
Theroleoftrustmanagementindistributedsystemssecurity.
InJ.
VitekandC.
D.
Jensen,eds.
,SecureInternetProgramming,vol.
1603ofLNCS,pp.
185–210.
Springer,1999.
[7]W.
E.
BoebertandR.
Y.
Kain.
Apracticalalternativetohierar-chicalintegritypolicies.
InProc.
17thNCSC,pp.
18–27,1985.
[8]C.
Canali,V.
Cardellini,M.
Colajanni,R.
Lancellotti,andP.
S.
Yu.
Cooperativearchictecturesandalgorithmsfordiscoveryandtranscodingofmulti-versioncontent.
InProc.
8thIWCW,Sept.
2003.
[9]P.
Cao,J.
Zhang,andK.
Beach.
ActiveCache:Cachingdynamiccontentsontheweb.
InProc.
Middleware'98,pp.
373–388,Sept.
1998.
NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation181[10]D.
M.
D'Alessandro,T.
E.
Lewis,andM.
P.
D'Alessandro.
Ape-diatricdigitalstorytellingsystemforthirdyearmedicalstudents:Thevirtualpediatricpatients.
BMCMedicalEducation,4(10),July2004.
[11]C.
M.
Ellison,B.
Frantz,B.
Lampson,R.
Rivest,B.
Thomas,andT.
Ylonen.
SPKIcerticatetheory.
RFC2693,IETF,Sept.
1999.
[12]A.
Fox,S.
D.
Gribble,Y.
Chawathe,E.
A.
Brewer,andP.
Gau-thier.
Cluster-basedscalablenetworkservices.
InProc.
16thSOSP,pp.
78–91,Oct.
1997.
[13]M.
J.
Freedman,E.
Freudenthal,andD.
Mazi`eres.
DemocratizingcontentpublicationwithCoral.
InProc.
1stNSDI,Mar.
2004.
[14]L.
Gao,M.
Dahlin,A.
Nayate,J.
Zheng,andA.
Iyengar.
Appli-cationspecicdatareplicationforedgeservices.
InProc.
12thWWW,pp.
449–460,May2003.
[15]R.
GrimmandB.
N.
Bershad.
Separatingaccesscontrolpolicy,enforcementandfunctionalityinextensiblesystems.
ACMTOCS,19(1):36–70,Feb.
2001.
[16]I.
Gupta,K.
Birman,P.
Linga,A.
Demers,andR.
vanRenesse.
Kelips:BuildinganefcientandstableP2PDHTthroughin-creasedmemoryandbackgroundoverhead.
InProc.
2ndIPTPS,vol.
2735ofLNCS,pp.
160–169.
Springer,Feb.
2003.
[17]IBMCorporation.
WebSphereEdgeServerAdministrationGuide.
3rdedition,Dec.
2001.
[18]S.
Iyer,A.
Rowstron,andP.
Druschel.
Squirrel:Adecentralizedpeer-to-peerwebcache.
InProc.
21stPODC,pp.
213–222,July2002.
[19]B.
Knutsson,H.
Lu,J.
Mogul,andB.
Hopkins.
Architectureandperformanceofserver-directedtranscoding.
ACMTOIT,3(4):392–424,Nov.
2003.
[20]D.
Kotz,R.
Gray,S.
Nog,D.
Rus,S.
Chawla,andG.
Cybenko.
AGENTTCL:Targetingtheneedsofmobilecomputers.
IEEEInternetComputing,1(4):58–67,Jul.
/Aug.
1997.
[21]B.
Krishnamurthy,J.
C.
Mogul,andD.
M.
Kristol.
Keydiffer-encesbetweenHTTP/1.
0andHTTP/1.
1.
InProc.
8thWWW,May1999.
[22]M.
Lorch,S.
Proctor,R.
Lepro,D.
Kafura,andS.
Shah.
FirstexperiencesusingXACMLforaccesscontrolindistributedsys-tems.
InProc.
2003XMLSEC,pp.
25–37,2003.
[23]W.
-Y.
Ma,B.
Shen,andJ.
Brassil.
Contentservicesnetwork:Thearchitectureandprotocols.
InProc.
6thIWCW,June2001.
[24]D.
Mazi`eresandM.
F.
Kaashoek.
Escapingtheevilsofcentral-izedcontrolwithself-certifyingpathnames.
InProc.
8thSIGOPSEurop.
Workshop,pp.
118–125,Sept.
1998.
[25]J.
C.
Mogul.
ClarifyingthefundamentalsofHTTP.
InProc.
11thWWW,pp.
25–36,May2002.
[26]J.
C.
MogulandK.
K.
Ramakrishnan.
Eliminatingreceivelive-lockinaninterrupt-drivenkernel.
ACMTOCS,15(3):217–252,Aug.
1997.
[27]MozillaFoundation.
SpiderMonkey(JavaScript-C)engine.
http://www.
mozilla.
org/js/spidermonkey/.
[28]NationalCenterforPostsecondaryImprovement.
Beyonddeadreckoning:ResearchprioritiesforredirectingAmericanhighereducation.
http://www.
stanford.
edu/group/ncpi/documents/pdfs/beyonddeadreckoning.
pdf,Oct.
2002.
[29]M.
NottinghamandX.
Liu.
Edgearchitecturespeci-cation,2001.
http://www.
esi.
org/architecturespec1-0.
html.
[30]ObjectWeb.
JORAM.
http://joram.
objectweb.
org/.
[31]V.
S.
Pai,A.
L.
Cox,V.
S.
Pai,andW.
Zwaenepoel.
Aexibleandefcientapplicationprogramminginterfaceforacustomiz-ableproxycache.
InProc.
4thUSITS,Mar.
2003.
[32]L.
Peterson,T.
Anderson,D.
Culler,andT.
Roscoe.
Ablueprintforintroducingdisruptivetechnologyintotheinternet.
InProc.
1stHotNets,Oct.
2002.
[33]M.
Rabinovich,Z.
Xiao,andA.
Aggarwal.
Computingontheedge:Aplatformforreplicatinginternetapplications.
InProc.
8thIWCW,Sept.
2003.
[34]M.
Rabinovich,Z.
Xiao,F.
Douglis,andC.
Kalmanek.
Movingedge-sideincludestotherealedge—theclients.
InProc.
4thUSITS,Mar.
2003.
[35]A.
RowstronandP.
Druschel.
Pastry:Scalable,distributedobjectlocationandroutingforlarge-scalepeer-to-peersystems.
InProc.
Middleware'01,pp.
329–350,Nov.
2001.
[36]SecuritySpace.
Apachemodulereport.
http://www.
securityspace.
com/ssurvey/data/man.
200501/apachemods.
html,Feb.
2005.
[37]SecuritySpace.
Webserversurvey.
http://www.
securityspace.
com/ssurvey/data/200501/index.
html,Feb.
2005.
[38]W.
Shi,K.
Shah,Y.
Mao,andV.
Chaudhary.
Tuxedo:Apeer-to-peercachingsystem.
InProc.
2003PDPTA,pp.
981–987,June2003.
[39]E.
G.
Sirer,R.
Grimm,A.
J.
Gregory,andB.
N.
Bershad.
De-signandimplementationofadistributedvirtualmachinefornet-workedcomputers.
InProc.
17thSOSP,pp.
202–216,Dec.
1999.
[40]E.
G.
SirerandK.
Wang.
Anaccesscontrollanguageforwebservices.
InProc.
7thSACMAT,pp.
23–30,June2002.
[41]N.
Spring,D.
Wetherall,andT.
Anderson.
Scriptroute:Apublicinternetmeasurementfacility.
InProc.
4thUSITS,pp.
225–238,Mar.
2003.
[42]I.
Stoica,R.
Morris,D.
Karger,M.
F.
Kaashoek,andH.
Balakr-ishnan.
Chord:Ascalablepeer-to-peerlookupserviceforInter-netapplications.
InProc.
2001SIGCOMM,pp.
149–160,Aug.
2001.
[43]M.
M.
Triola,M.
A.
Hopkins,M.
J.
Weiner,W.
Holloway,R.
I.
Levin,M.
S.
Nachbar,andT.
S.
Riles.
Surgicalinteractivemul-timediamodules:Anovel,non-browserbasedarchitectureformedicaleducation.
InProc.
17thCBMS,pp.
423–427,June2004.
[44]M.
Tsimelzon,B.
Weihl,andL.
Jacobs.
ESIlanguagespecica-tion1.
0,2001.
http://www.
esi.
org/languagespec1-0.
html.
[45]S.
H.
J.
Uijtdehaage,S.
E.
Dennis,andC.
Candler.
Aweb-baseddatabaseforsharingeducationalmultimediawithinandamongmedicalschools.
AcademicMedicine,76:543–544,2001.
[46]A.
Vahdat,M.
Dahlin,T.
Anderson,andA.
Aggarwal.
ActiveNames:Flexiblelocationandtransportofwide-arearesources.
InProc.
2ndUSITS,pp.
151–164,Oct.
1999.
[47]L.
Wang,V.
Pai,andL.
Peterson.
TheeffectivenessofrequestredirectiononCDNrobustness.
InProc.
5thOSDI,pp.
345–360,Dec.
2002.
[48]L.
Wang,K.
Park,R.
Pang,V.
Pai,andL.
Peterson.
ReliabilityandsecurityintheCoDeeNcontentdistributionnetwork.
InProc.
2004USENIX,pp.
171–184,June2004.
[49]S.
A.
Wartman.
Researchinmedicaleducation:Thechallengeforthenextdecade.
AcademicMedicine,69(8):608–614,1994.
[50]A.
Wolman,G.
M.
Voelker,N.
Sharma,N.
Cardwell,A.
Karlin,andH.
M.
Levy.
Onthescaleandperformanceofcooperativewebproxycaching.
InProc.
17thSOSP,pp.
16–31,Dec.
1999.
[51]H.
YuandA.
Vahdat.
Designandevaluationofacontinuousconsistencymodelforreplicatedservices.
InProc.
4thOSDI,pp.
305–318,Oct.
2000.
[52]B.
Y.
Zhao,L.
Huang,J.
Stribling,S.
C.
Rhea,A.
D.
Joseph,andJ.
D.
Kubiatowicz.
Tapestry:Aresilientglobal-scaleoverlayforservicedeployment.
IEEEJ-SAC,22(1):41–53,Jan.
2004.
[53]W.
ZhaoandH.
Schulzrinne.
DotSlash:Providingdynamicscal-abilitytowebapplicationswithon-demanddistributedqueryre-sultcaching.
Tech.
ReportCUCS-035-05,ColumbiaUniversity,Sept.
2005.
NSDI'06:3rdSymposiumonNetworkedSystemsDesign&ImplementationUSENIXAssociation182