USF Libraries
USF Digital Collections

Design and evaluation of a green bittorrent for energy-efficient content distribution

MISSING IMAGE

Material Information

Title:
Design and evaluation of a green bittorrent for energy-efficient content distribution
Physical Description:
Book
Language:
English
Creator:
Blackburn, Jeremy
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla
Publication Date:

Subjects

Subjects / Keywords:
P2P
Peer-to-peer
Data center
Set-top-box
Power management
Dissertations, Academic -- Computer Science and Engineering -- Masters -- USF   ( lcsh )
Genre:
non-fiction   ( marcgt )

Notes

Abstract:
ABSTRACT: IT equipment has been estimated to be responsible for 2% of global CO2 emissions and data centers are responsible for 1.2% of U.S. energy consumption. With the large quantity of high quality digital content available on the Internet the energy demands and environmental impact of the data centers must be addressed. The use of peer-to-peer technologies, such as BitTorrent, to distribute legal content to consumers is actively being explored as a means of reducing both file download times and the energy consumption of data centers. This approach pushes the energy use out of the data centers and into the homes of content consumers (who are also then content distributors). The current BitTorrent protocol requires that clients must be fully powered-on to be participating members in a swarm. In this thesis, an extension to the BitTorrent protocol that utilizes long-lived knowledge of sleeping peers to enable clients to sleep when not actively distributing content yet remain responsive swarm members is developed. New peer states and events required for the protocol extension, the implementation the new protocol in a simulation environment, and the implementation of the protocol extension in a real client are described. Experiments on a simulated swarm of 51 peers transferring a 1 GB and a real swarm of 11 peers transfer- ring a 100 MB file were run. To validate the simulation a simulated swarm of 11 peers transferring a 100 MB file is compared to the real swarm of 11 peers. The results of standard BitTorrent are compared to the new Green BitTorrent by examining download times, sleep time, and awake time. The results of the experiment show significant energy savings are possible with only a small penalty in download time. Energy savings of up to 75% are shown with download time increases as little as 10%. These energy savings could equate to over $1 billion dollars per year in the US alone if Green BitTorrent is used instead of standard BitTorrent for future rollouts of legal distribution systems.
Thesis:
Thesis (M.S.C.S.)--University of South Florida, 2010.
Bibliography:
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
Statement of Responsibility:
by Jeremy Blackburn.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains X pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
usfldc doi - E14-SFE0003475
usfldc handle - e14.3475
System ID:
SFS0027790:00001


This item is only available as the following downloads:


Full Text

PAGE 1

DesignandEvaluationofaGreenBitTorrentforEnergy-EfcientContentDistribution by JeremyH.Blackburn Athesissubmittedinpartialfulllment oftherequirementsforthedegreeof MasterofScienceinComputerScience DepartmentofComputerScience&Engineering CollegeofEngineering UniversityofSouthFlorida MajorProfessor:KenChristensen,Ph.D. AdrianaIamnitchi,Ph.D. AbrahamKandel,Ph.D. DateofApproval: April6,2010 Keywords:P2P,peer-to-peer,datacenter,set-top-box,powermanagement c Copyright2010,JeremyH.Blackburn

PAGE 2

Dedication Thisthesisisdedicatedtomyclosefriendsandfamilywhocontinuallyinspireandencouragemetoreach mypotential.Inparticular,I'dliketothankZachKingandDanielNishijimaforrefusingtoletmequitwhen thingslookeddark. Tomyparents,BobandJanet,I'dliketothankyouforalwayspushingmetoachievemypotentialand nevergivinguponme.WithoutyourunconditionalloveandguidanceIcouldnothavemadeittothispoint. Finally,tomywife,Lauren.Youneverletmegiveintomydoubts,neverletmequestionmyability,and aboveallhaveservedasmymotivationtonotonlyaskquestions,buttosearchforanswers.

PAGE 3

Acknowledgments IwouldliketothankDr.KenChristensenattheUniversityofSouthFloridaforprovidingmetheopportunitytowritethisthesis.ForseveralyearsDr.Christensenservedasasoundingboardand,motivator,and moreimportantlyamentor.HehelpedmeprogressthroughanUndergraduateResearchposition,graduate levelresearch,publicationand,nowtoadefendingMastersstudent. IwouldalsoliketothankDr.MiguelLabradorandtheentireUniversityofSouthFloridaResearch ExperienceforUndergraduatesprogram.ThisthesisbeganasaprojectfromtheREUprogramandthe encouragementofallindividualsinvolvedfacilitatedmytransitionfromundergraduateresearchtograduate research. ManythankstoDrs.IamnitchiandKandelforbothbeingmembersofmycommitteeaswellasmentors intheclassroom,bothforundergraduateandgraduatestudies. ThedevelopmentofthismaterialisbaseduponworksupportedbytheNationalScienceFoundation undergrant0754537BlackburnandCNS-0520081Christensen.Iwouldalsoliketoacknowledgetheuse ofhighperformancecomputationalservicesprovidedbyResearchComputing,UniversityofSouthFlorida. Finally,Iwouldliketothankmybrother,Dr.BryanBlackburnoftheUniversityofMarylandforprovidingmewithauniqueviewofacademicresearchandprovidingregularrealitychecks.Withouthisexample andourrelationshipwhichallowedforhonestandfrankmeta-discussionsofacademia,thisthesiswouldnot havebeenpossible.

PAGE 4

TableofContents ListofTables iii ListofFigures iv Abstract vi Chapter1:Introduction 1 1.1DataCentersforContentDistribution1 1.2ContentDistributionNetworks2 1.3Peer-to-PeerforContentDistribution3 1.4EnergyUseofContentDistribution4 1.4.1DataCenters5 1.4.2Peer-to-Peer5 1.5Motivation 5 1.5.1OpportunityforSavings7 1.6Contribution7 1.7OrganizationofthisThesis8 Chapter2:BackgroundandLiteratureReview9 2.1Client-ServerContentDistribution9 2.2Peer-to-PeerContentDistribution10 2.3Thens-2BitTorrentSimulator14 2.4TheBitTornadoBitTorrentClient15 2.5RelatedWork21 2.6ChapterSummary22 Chapter3:GreenBitTorrentProtocolExtension23 3.1WhatisaGreenBitTorrent?23 3.2NewPeerStates23 3.3NewPeerEvents24 3.4BackwardsCompatibility26 3.5ChapterSummary26 Chapter4:ImplementationofGreenBitTorrent27 4.1Changestons-2BitTorrentSimulation27 4.1.1PeerStates27 4.1.2PeerEvents27 4.2ChangestoBitTornado29 4.2.1PeerStates29 4.2.2PeerEvents30 4.3ChapterSummary31 i

PAGE 5

Chapter5:EvaluationofGreenBitTorrent33 5.1SimulationExperiments33 5.1.1DescriptionofExperiment34 5.1.2ResultsfromExperiment35 5.1.3DiscussionofResults38 5.2RealClientExperiments39 5.2.1DescriptionofExperiment41 5.2.2ResultsfromExperiment41 5.2.2.1SimulationValidation45 5.2.3DiscussionofResults47 5.3ChapterSummary48 Chapter6:SummaryandFutureWork49 6.1GreenBitTorrentEnergySavings49 6.2DirectionsforFutureResearch49 References 51 ii

PAGE 6

ListofTables Table1.Powerconsumptionofvariousdevices6 Table2.BitTorrentprotocolmessages13 Table3.IncreaseindownloadtimeforGreenBitTorrentversusstandardBitTorrentsimulation38 Table4.IncreaseindownloadtimeforGreenBitTorrentcomparedtostandardBitTorrent44 Table5.Downloadtimeofrealclientversussimulationclient47 iii

PAGE 7

ListofFigures Figure1.Datacentermodelforcontentdistribution2 Figure2.ContentDistributionNetworkmodelforcontentdistribution3 Figure3.P2Pmodelforcontentdistribution4 Figure4.HighlevelviewofaBitTorrentswarm11 Figure5. Torrent classdiagram15 Figure6. Downloader classdiagram16 Figure7. SingleDownload classdiagram17 Figure8. Uploader classdiagram19 Figure9. Encoder classdiagram20 Figure10. Connecter classdiagram20 Figure11.Descriptionofchangedpeerdisconnectdetectionevent24 Figure12.BitTornadopeerdisconnectevent[12]24 Figure13.Descriptionofchangedpeerdiscoveryevent25 Figure14.Descriptionofnewpeerinactivityandsleepevent25 Figure15.Descriptionofnewpeerwakeupevent26 Figure16.ClasshierarchydiagramforGreenBitTorrentimplementationinBitTornado29 Figure17. GreenConnector#connection lost method30 Figure18. GreenEncoder#start connection method30 Figure19. GreenConnector#connection made method31 Figure20. GreenTorrent#try to sleep and GreenTorrent#go to sleep methods31 Figure21. GreenTorrent#wake up method31 Figure22.DownloadtimeforstandardBitTorrentsimulation36 Figure23.SleeptimeforstandardBitTorrentsimulation36 Figure24.Sleeptimeforpeer25standardBitTorrentsimulation37 iv

PAGE 8

Figure25.DownloadtimeforGreenBitTorrentsimulation37 Figure26.SleeptimeforGreenBitTorrentsimulation37 Figure27.Sleeptimeforpeer25GreenBitTorrentsimulation38 Figure28.Computershostingrealclientexperiments40 Figure29.DownloadtimeforstandardBitTorrent42 Figure30.SleeptimeforstandardBitTorrent43 Figure31.Sleeptimeforpeer5standardBitTorrent43 Figure32.DownloadtimeforGreenBitTorrent43 Figure33.SleeptimeforGreenBitTorrent44 Figure34.Sleeptimeforpeer5GreenBitTorrent44 Figure35.DownloadtimeforstandardBitTorrentsimulationvalidation45 Figure36.SleeptimeforstandardBitTorrentsimulationvalidation45 Figure37.Sleeptimeforpeer5standardBitTorrentsimulationvalidation46 Figure38.DownloadtimeforGreenBitTorrentsimulationvalidation46 Figure39.SleeptimeforGreenBitTorrentsimulationvalidation46 Figure40.Sleeptimeforpeer5GreenBitTorrentsimulationvalidation47 v

PAGE 9

DesignandEvaluationofaGreenBitTorrentforEnergy-EfcientContentDistribution JeremyH.Blackburn ABSTRACT ITequipmenthasbeenestimatedtoberesponsiblefor2%ofglobalCO 2 emissionsanddatacenters areresponsiblefor1.2%ofU.S.energyconsumption.Withthelargequantityofhighqualitydigitalcontent availableontheInternettheenergydemandsandenvironmentalimpactofthedatacentersmustbeaddressed. Theuseofpeer-to-peertechnologies,suchasBitTorrent,todistributelegalcontenttoconsumersisactively beingexploredasameansofreducingbothledownloadtimesandtheenergyconsumptionofdatacenters. Thisapproachpushestheenergyuseoutofthedatacentersandintothehomesofcontentconsumerswhoare alsothencontentdistributors.ThecurrentBitTorrentprotocolrequiresthatclientsmustbefullypowered-on tobeparticipatingmembersinaswarm. Inthisthesis,anextensiontotheBitTorrentprotocolthatutilizeslong-livedknowledgeofsleepingpeers toenableclientstosleepwhennotactivelydistributingcontentyetremainresponsiveswarmmembersis developed.Newpeerstatesandeventsrequiredfortheprotocolextension,theimplementationthenew protocolinasimulationenvironment,andtheimplementationoftheprotocolextensioninarealclientare described. Experimentsonasimulatedswarmof51peerstransferringa1GBandarealswarmof11peerstransferringa100MBlewererun.Tovalidatethesimulationasimulatedswarmof11peerstransferringa100MB leiscomparedtotherealswarmof11peers.TheresultsofstandardBitTorrentarecomparedtothenew GreenBitTorrentbyexaminingdownloadtimes,sleeptime,andawaketime.Theresultsoftheexperiment showsignicantenergysavingsarepossiblewithonlyasmallpenaltyindownloadtime.Energysavingsof upto75%areshownwithdownloadtimeincreasesaslittleas10%.Theseenergysavingscouldequateto over$1billiondollarsperyearintheUSaloneifGreenBitTorrentisusedinsteadofstandardBitTorrentfor futurerolloutsoflegaldistributionsystems. vi

PAGE 10

Chapter1: Introduction Maintainingasustainablesocietyisoneofthemorepressingchallengesfacingourmodernsociety. WhiletheInternetrevolutionhasgenerallybeenapositiveforceintheworld,untilrecentlytheimpacton theenvironmenthasbeenoverlooked.ITequipmentisalargeconsumerofenergyandthegreenhouse gassesgeneratedhavebeenestimatedtoaccountfor2%ofglobalemissions[20].Asmoreandmorecontent isdelivereddigitally,sotoowilltheenergyconsumedbythedistribution,storage,andgenerationofthe contentincrease.Thisthesisexploresasolutiontodigitalcontentdistributionthataddressesandattemptsto minimizetheenergyconsumed.BydecouplingapplicationstatefromnetworkconnectionstateinBitTorrent, signicantenergysavingscanbeachievedwithminimalincreaseindownloadtime. Anestimated1.2%ofU.S.electricityconsumptionin2006wasdirectlyattributabletodatacenters[29]. Thisenergyusagecorrespondstoapproximately$4.5billionatcommercialenergyrates[39].Whiledata baseandapplicationserversalsomakeuseofdatacenters,contentdistributionisquicklybecomingaheavy load.Forexample,theiTunesStoreiscurrentlythetopmusicretailerintheUS,havingsoldoverfourbillion songsfromApril2003toApril2008[6].AstheentiretyoftheiTunesStorecatalogueisdigitalcontent,an extremelyconservativeestimateof3MBpersongtranslatestoover11PBofdatatransferredovera5year period,or2.2PBperyearintheUSalone.Whiledigitalmusicwasthesoleoriginalproductsoldviathe iTunesStore,asofApril2007,theiTunesStorehassoldover50millionTVshowsandtwomillionmovies [7]. 1.1DataCentersforContentDistribution TheiTunesStoredistributescontentviaalargecentralizedarchitecture[33].Thiscentralizedarchitecture isreferredtoasadatacenterandiscurrentlytheprevalentmethodofcontentdistribution.Adatacenteris alargecollectionofcomputersoperatedbyasingleentitymostoftenhousedinthesamephysicallocation actingasasinglelocationfromwhichcontentisdownloaded.Allthecontentavailableisstoredatthissingle locationandanynumberofcontentconsumerswillaccessthedatacentertodownloadtheircontentatany giventime.Figure1showsadatacenterdistributionmodel.Ofnoteisthesingledistributionentitythedata 1

PAGE 11

Figure1.Datacentermodelforcontentdistribution centerresponsiblefordistributionofcontentwitheachofthedataconsumersactingonlyas receivers of content. Ingeneral,datacentersmakeuseofeconomyofscaleforbothhardwarecostsandassociatedcosts e.g.,cooling.Ofgreatinterestisthatthepowerandcoolingcostsofdatacenterssurpassthecostsofthe equipmentitself[11].Thishasleadtoasearchforanalternativetodatacentersforcontentdistribution. 1.2ContentDistributionNetworks Whiledatacentersareacollectionofcomputersatasinglelocation,aContentDistributionNetwork CDNisalogicalgroupingofcomputersthatmayormaynotbelocatedtogether.TheusageofCDNs ismotivatedbytheneedforhighavailabilityandlowaccesstimestocontent.Becauseofvariationsin geographiclocation,crossnetworklatency,andthenumberofpeopleaccessingcontentatanygiventime cachingisoftenused.Acachingsystemreplicatescontentonnumerousserverswiththegoalofbeingable toprovideacopyofthecontenttoauserfromageographicallycloselocation.Theresultfromcachingis reduceddownloadtimesfromtheperspectiveoftheuser,lessredundantdatatransferredoverthenetwork, andareducedloadonserversoverall[30]. Akamai[2]isthelargestcommercialCDNprovider.TheAkamaiCDNoperatesbyAkamaizing URLstoprovidecontextualinformationtoAkamai'sservers.AnAkamaizedURLhasanAkamaidomain prependedtotheoriginalURLaswellasmetadatawhichisusedtodeterminewhichserverintheCDN 2

PAGE 12

Figure2.ContentDistributionNetworkmodelforcontentdistribution shouldrespondtotherequestandwhetherornotinformationintheCDNscacheshouldbeupdated.Akamai'sproductsdealwithawiderangeofcontentdeliveryincludingstaticandstreamingmediaaswellas webapplications. WhenausermakesarequestforcontenttheCDNlocatesanappropriatelycloseCDNserver.The denitionofcloseissomewhatmalleableasnumerousmeasuresforclosenesscanbeused.Theprimary measuresofclosenessaregeographicallocation,topological,andnetworklatency[30].InFigure2homes areservedbythedatacenterintheCDNthatisclosesttothem.WhileCDNsmakeabestefforttoserver userswithcontentviaalowlatencyconnectioninpracticethesub-optimalserversareoftenchosen.However, whileinasmallnumberofcasesuserswouldbebetterservedbyorigini.e.,nonCDNservers,CDNshave beenshowntohaveameasurableimpactonperformancebyservingcontentfromreasonablygoodservers inthegeneralcase[28]. 1.3Peer-to-PeerforContentDistribution Anemergingalternativetodatacentersforcontentdistributionispeer-to-peerP2Ptechnologies.The deningcharacteristicofP2Pdistributiontechnologiesisthatcontentconsumersdonotreceivecontentfrom 3

PAGE 13

Figure3.P2Pmodelforcontentdistribution acentralizedlocationbutratherfromothercontentconsumers.InaP2Pdistributionschemethereisnoclear delineationbetweencontentdistributorandcontentconsumer.AsseeninFigure3eachcontentconsumernot only receives contentbutalso distributes it,reducingthenumberofservershousedindatacentersnecessary todistributecontent. Someestimatesattributebetween18%and35%ofallInternettrafctoBitTorrent[35]makingitthe dominantP2Pdistributionprotocolintheworldtoday.ThesuccessofP2PingeneralandBitTorrentinparticularhasnotbeenlostoncontentdistributors[38].AsP2Pblursthelinebetweenconsumeranddistributor iteffectivelyremovesthecostofcontentdistributionoutofthedatacenterandintotheconsumershome. BitTorrentmakesevenmoresenseasthequantityofdigitalcontentincreases.Inparticular,theproblemof ashcrowds areprevalentindatacenters.Aashcrowdoccurswhensomeparticularcontentbecomespopularveryquicklyresultinginasuddenincreaseinthenumberofdownloadsoverashortperiodoftime[17]. Iftheeffectsofaashcrowdareunderestimatedloadonthedatacenterserverscanbecomeveryhighand downloadtimeswillincreasesubstantially.Thisscalingproblem,however,doesnotexistinBitTorrent.As eachBitTorrentpeerinvolvedinthetransferofcontentcontributesresourcesinadditiontoconsumingthem thedistributionnetworkbecomesstrongerasmorepeersparticipateinaashcrowd. 1.4EnergyUseofContentDistribution About2%oftheglobalCO 2 footprinthasbeenattributedtotheITindustry[20].Thisisapproximately thesameCO 2 outputoftheaviationindustry[20].The10millioncomputershousedatdatacentersconsume 4

PAGE 14

anestimated61TWhofelectricityperyear[29].Thesenumbersgiverisetothedesiretoreducethegrowing energyconsumptionoftheITindustry. 1.4.1DataCenters Contentdistributioninparticularisaninterestingproblemfordatacenters.Duetothesporadicnatureof ondemandcontentconsumptionhabits,datacentersmayverywellhavelowutilizationlevels[31].Forexample,inordertohavethebandwidthandcomputingpowertoservetheneedsofanewdigitalmovierelease itisnecessarytoestimatethepeakdemandforthemovie.Thisestimationofresources,ordimensioning, resultsintheresourcesprovisionedforadatacenter.Toolowofanestimationwillleavecontentconsumers frustratedwithlongdownloadtimeswhiletoohighofanestimationwillresultinwastedresources.Important tonotehoweveristhatthisestimationmustbeapeakdemandestimation.Whileitistruethat atsomepoint intime thedemandmightbehigh,therewillbenumerousothertimesthatthedemandwillbemuchlower. Duetothedifcultiesofdimensioning,serversindatacentersgenerallyrunat30%utilization[15].Thelow utilizationofserversinadatacenterisimportantbecauseacomputerislessenergyefcientthelowerits utilizationis[9].Evenanenergyefcientserverisconsumingabouthalfofitspeakpowerconsumptionat 50%utilization. 1.4.2Peer-to-Peer P2Pmakessensewithrespecttotheprovisioningandutilizationlevelsofdatacenters,howevertheissue isnotentirelyunequivocal.Asof2006thereareanestimated102.5millionhomebroadbandusers,orabout 72%penetration[10].Ifcontentdistributorsfollowthroughonplanstomoveawayfromdatacentersand towardsP2Pdistribution,the22TWh/yrofpowerusediscomparabletothedirectpowerconsumptionof computersindatacentersperyearto30TWh[32].Ashomebroadbandpenetrationincreasessotoowill thecostsplacedonconsumers. 1.5Motivation Fittingwithcontentdistributorsdesiretomovedistributionoutofthedatacenterandintotheconsumer's home,afuturewherededicatedlesharingdevices,eitherasastandaloneunitonthesideofahouseoras acomponentofsettopboxes,becomingtheprimarymethodofcontentdistributionisforeseen.Thisdevice couldbeownedbytheoperatorandwouldprovideforondemandcontentdeliverytothecustomeraswellas ameansforoperatorownedcontenttobedistributedtoothercustomers.Commercialofferingssuchasthe 5

PAGE 15

Table1.Powerconsumptionofvariousdevices Device PowerConsumptionwatts AnnualEnergyConsumptionkWh/yr VolumeServer[29] 183 1,600 Mid-rangeServer[29] 423 3,705 High-endserver[29] 4874 42,696 DesktopPC 100 876 HDReceiverwithDVR[23] 35 350 Stand-aloneDVR[23] 23 200 Mediareceiverbox[23] 4 35 P2Plesharingdevice 25 219 VUDUon-demandmovieservice[43]arealreadyavailabletoconsumersallowingaccesstodigitalcontent viaaP2Pnetworkandrunson24W[43].Thesepowerconsumptionoftheselesharingdeviceswouldbe muchlessthanatypicalPC.Thepowerconsumptionofservers,PCs,set-top-boxes,andapossibleP2Pbox canbeseeninTable1.At100millionhomesand25WperlesharingdeviceaP2Pcontentdistribution systemresultsinapproximately22TWhand$2.2billionperyearatconsumerelectricityratesof$0.10per KWhofenergyuseprovidingtheimpetusforinvestigationintomethodsforincreasingtheenergyefciency ofP2P. CurrentP2Psystemsmaketheassumptionthatpeersparticipatinginthedistributionofcontentarealwayson.Inotherwords,ifapeerisinvolvedindistributingcontentitwillbefullypoweredonandavailable fornetworkcommunications.Unfortunatelythisassumptionprecludesputtingpeersnotcurrentlyneededto sleepasiftheyareneededinthefuturetheywillnotbeavailableandthusdeemednotinterestedindistributioncontent.Infact,peersgoingtosleeptosaveenergywouldhavedisastrousconsequencesincurrentP2P distributionschemesastheoverlaynetworkwouldbreakdownfromthelackofavailablepeers.Keytothe removalofacentralizeddownloadlocationisthatcontentisreplicatedacrossnumerouspeersinadistributed fashion.Thatis,peersmustbeaccessibleinanondemandfashiontodistributecontent.P2Pcontentdistributionmakesprovisionsforanenvironmentwherepeersmaybecomeunavailable,howevertheassumption remainsthatifapeerisinvolvedindistributingcontentitwillremainavailableandanpeer'sunavailability indicatesapeerwillnotparticipateindistributingcontent.Thisdistinctionbetweeninterestanddisinterest indistributioniswhatleadstothedemandforafullypowereduppeer.Peerscannotsimplysleepwhenthey arenot actively distributingcontentastheabilitytoestablishanetworkconnectionisnecessarytoparticipate incontentdistribution.Atminimum,priortoanydatatransferoccuringpeersmustinitiateaTCPconnection tocommunicateover.AsleepingpeerisunreachableandthusnoTCPconnectiontoitcanbeinitialized. 6

PAGE 16

Further,theTCPconnectionsofapeerthattransitionstoasleepstatewillnotbemaintainedandthusall channelsofcommunicationtootherpeerswillbeclosed. Additionallythereisverylittlecomputationthatisinvolvedincontentdistribution.Whilethereare computationaltasksinvolvedsuchashashestochecktheintegrityoftransferreddataandpossiblyencryption forsecurityorDigitalRightsManagementpurposes,thevastmajorityofaP2Pcontentdistributionprocess involvesdatatransferoverthenetwork,leavingtheprocessorofthedeviceatrelativelylowutilization.More importantly,P2Pcontentdistributionutilizationtendstobesporadic.Asinthedatacentermodel,downloads arenotconstantlyoccurringandincontrasttothedatacentermodel,itisveryunlikelythatanysinglele sharingdevicewillhavealocalcopyof all contentavailablefordistributionfurtherreducingthenumberof possibledownloadsatanygiventime. 1.5.1OpportunityforSavings IsthereanyinherentreasonthatP2Pdevicesmustbefullypoweredonatalltimes?Aspreviouslynoted, thisrequirementisduetotheassumptionthatapeerinvolvedinthedistributionofcontentcanbeavailable viathenetworkatanytime,andthusfullypoweredon.Instead,itisproposedthatpeersinthenetworkbe awareofthepossibilitythatthepeerbeingcommunicatedwithmaybesleepingtosaveenergy.Withthisnew knowledge,peersinaP2Pcontentdistributionsystemcanbehaveinatrulyondemandfashion;sleeping whenresourcesareunneededandwakingupwhentheyare.Inthismanner,theenergyoverheadofdata centersisreducedwhilealsoreducingtheinefcienciesofP2Pdistributionschemes. 1.6Contribution Byaddressingthemotivationoutlinedintheprevioussection,thisresearchcontributesthefollowing: 1.ThedesignofaGreenBitTorrentProtocolExtensiontothestandardBitTorrentprotocolthatremoves theassumptionthatapeerinvolvedinthedistributionofcontentisfullypoweredonandawake. 2.TheimplementationofarealGreenBitTorrentClient.BymodifyinganexistingBitTorrentclient tomakeuseoftheprotocolextensionboththefeasibilityandrealworldenergysavingspossibleare shown. 3.AnevaluationofGreenBitTorrentthatthroughbothrealandsimulatedresultsshowstheenergysavings possibleaswellastheminimalpenaltiesassociatedwiththeprotocolextension. 7

PAGE 17

1.7OrganizationofthisThesis Theremainderofthisthesisisorganizedasfollows: Chapter2containsbackgroundandaliteraturereviewdescribingcurrentresearchintotheenergy efciencyofcontentdistributionandareviewoftheBitTorrentprotocol. Chapter3describesthenewGreenBitTorrentaswellasthedesignoftheGreenBitTorrentprotocol extension Chapter4describestheimplementationoftheGreenBitTorrentprotocolextensionasbothasimulation andarealclient. Chapter5describesanevaluationoftheGreenBitTorrentprotocolextension. Chapter6concludesthethesiswithadiscussionofthebenetsofthecontributionsanddirectionfor futureresearch. 8

PAGE 18

Chapter2: BackgroundandLiteratureReview Inordertounderstandhowenergycanbesaveditisrstnecessarytounderstandwhereitiswastedand theconstraintsthatleadtoitswaste.Thischapterdiscussestheinformationnecessarytounderstandhowthe ideaspresentedinthefollowingchapterresultinenergysavings. 2.1Client-ServerContentDistribution Byfarthemostcommonclient-servercontentdistributionsystemistheWorldWideWeb.Thearchitectureofthewebistheprototypicalclient-servermodel:contentisstoredonawebserverandviatheHTTP protocoltransferredtowebbrowseronusers'machines.Themajorityofcontentservedviathewebissmall, butlargecontentisalsodistributed[3][21][36].Whilewebserverscanfunctionasdistributorsoflarge contentthereareseveralreasonswhydoingsoisnotdesirable.Asdiscussedpreviouslytheproblemsofover provisioning,thehighcostofinducedpowerusageindatacenters,andscalabilityareallissues. Besidesstaticcontentforwhichthedownloadmustbefullycompletedbeforethecontentcanbeused, therealsoexistsstreamingcontent.Streamingcontentisaccessedwhileitisbeingtransferred.Forexample, acontentconsumermightbeginwatchingamoviebeforetheentiretyhasbeendownloaded.Whileonly1% ofoverallrequestsforcontentareofthestreamingvariety,theyrepresentapproximately20%ofthedata transferredfromCDNsoverHTTP[30].Youtube.comstreamswellover100millionvideosadaywithusers uploading20hoursofnewvideoeveryminute[44].WhileYoutube'scontentisusergenerated,servicessuch asHulu.comdelivercommerciallyproducedstreamingTVandmoviestocontentconsumers.Streamedcontentisdeliveredovernumerousprotocolsandformats,includingHTTP,MicrosoftMediaServicesMMS, AppleQuicktime,andFlashVideo.Specializedserverapplicationsexistforeachoftheseprotocolsandformats.Adobeprovidestwoclassesofstreamingservers:FlashMediaInteractiveServerwhichisintendedfor realtimestreamsandFlashMediaStreamingServerforlesscomplexstreams.Inadditiontothesestreaming formatswhicharetypicallydeliveredtocomputersviaawebbrowserplugin,anewsetofdedicatedstreamingserviceshasarisen.NetixStreaming,telecomVideoonDemandofferings,andconsumerproductssuch asAppleTValldelivercontenttoconsumersinastreamingfashion.Butthesestreamingdistributionmecha9

PAGE 19

nismsarestillinherentlyclientserver.Contentisplacedonaservertowhichclientsconnect.Whenaclient connectsandrequestsastreamtheserverbeginssendingdatagramswhichmayormaynotarriveattheclient. Uponreceivingadatagramtheclientdecodesitanddisplaysthecontent. 2.2Peer-to-PeerContentDistribution NapsterwastherstwellknownP2Psystem,characterizedbyitscentralizedcontentlook-upserver whichkepttrackofwhichpeershadwhichcontent.ANapsterpeerlookingtodownloadcontentwould rstquerythiscentralizedserverwhichwouldreturnalistofpeersthecontentmightberetrievedfrom. TheNapsterpeerwouldthenchooseasinglepeerfromthislistandbegindownload.Gnutellaisanother popularrstgenerationP2Psystem.Insteadofacentralizedlook-upserver,Gnutellaqueriesarehandledin apeer-to-peerfashion. AswarmingP2PsystemworksinadifferentfashionthanrstgenerationP2Psystems.Whilepeers inrstgenerationsystemsbothreceiveanddistributecontentthisbehaviorisonaone-to-onebasis.For anygivenpieceofcontentapeerwillreceiveitfromasingleotherpeer.InaswarmingP2Psystempeers downloadfrommultiplepeersatatime. WhilethecoolingcostsassociatedwithdatacentersdonotfullydisappearwithP2P,theyaregreatly reduced.Simplyput,becauseP2Pnodesarenotcongregatedinacentrallocationtheexistinginplace coolingatthelocationofP2Pnodessufceandnospecialcoolingconcernsmustbeaddressed.Ascooling accountsforabout50%ofthepowerconsumptionofdatacentersitisapparentthatP2Psystemshaveatleast onebenet.Further,whileP2Pdevicesobviouslyrequire some coolingitcanbearguedthatthisneedismet withtheambientcoolingprovidedbyairconditioningforusebyhumans[33]. WhiletheenergyconsumptionofaP2Psystemhasbeenmodeledpreviously[33],adifferentassumption ismadeastotheavailabilityofpeersinthesystem.TheassumptionismadethatP2Pclientswillrunontop ofalreadyonmachines,anditisexplicitlynotedthatnomachineswillbekeptawakesolelytoparticipatein contentdistribution.TheconclusionsdrawnfromthismodelarethatP2Psystemsaremoreefcientinterms ofthepowerconsumeddirectlyandindirectlybythemachinesparticipatingincontentdistributionwhile centralizedsystemsi.e.,datacentersfarebetterwithpowerconsumedbythenetwork. TheBitTorrentprotocolhasbecomethedominantswarmingP2Pprotocolintheworld.ThemajordifferencebetweenBitTorrentandotherswarmingP2Pprotocolsisthetit-for-tatmechanismthatBitTorrentuses toenforceresourcessharing.PeersdistributingcontentviaBitTorrentactasbothclientsandserverswhilethe 10

PAGE 20

Figure4.HighlevelviewofaBitTorrentswarm tit-for-tatmechanismattemptstoensurebothanoptimalresourcedistributionaswellasmanagescalability issues. WhilethemeaningofpeerinBitTorrentisessentiallythesameasinotherP2Psystems,duetoits swarmingnaturepeersarefurtherdividedintotwodistinctclassications: seeds and leeches .Seedsarepeers thathaveacompletecopyofthecontentbeingdistributedwhileleechesdonotyethaveacompletecopy. Leechesparticipateinaswarmbybothuploadinganddownloadingpieceswhileseedsonlyupload.Next discussedaretheworkingsoftheBitTorrentprotocolandhowthedistinctionbetweenseedandleechmakes energysavingspossible. TheunderlyingworkingsofBitTorrentareasfollows.Aclientseekingtoretrievecontentacquiresa .torrentlethroughameansoutsideofBitTorrentoftenanHTTPserver.The.torrentleitselfisthe metadatadescribingthecontenttobedistributedherebyknownasatorrent.Atorrentlecontainsthehost nameofoneormoretrackersandalistofpiecesandtheirchecksumsofthetorrent.A piece issimplya subdivisionofthecontentdescribedinthetorrent.A tracker isahostthatcontainsalistofpeersregistered ashavinginterestinthedistributionofthetorrentassociatedwithaparticulartorrentle.Thecollectionof allpeersinterestedinatorrentacrossalltrackersisknownasa swarm 11

PAGE 21

AhighlevelviewofaBitTorrentswarmcanbeseeninFigure4.Aleisbrokenupintofourpieces. Thereisoneseedthathasallthepiecesandtwoleeches;onewithtwopiecesandonewithnopieces.The seedistransferringpiece1totheleechwithnopiecesaswellaspiece3toleechwithtwopieces.The leechwithtwopiecesistransferringpiece2totheleechwithnopieces.Again,theabilitytouploadwithout havingacompletecopyofthelebeingtransferrediswhatmakesBitTorrentuniqueamongswarmingP2P protocols. Onceaclienthasdownloadedatorrentleandregistereditsinterestwithatrackermakingitapeerinthe swarmitretrievesarandomlyselectedlistofupto50otherhostnamesforpeersintheswarm.Thehostnames forthesepeersareenteredintoa peerlist andtheclientinitiatesaconnectionviaTCPtoacongurable number max connect ofpeersinitslocalpeerlist.Theformatofthepeerlistisimplementationspecicbut atminimumassociatesagivenpeer'srelevantinformationwithauniqueidentier.Ifapeerinthepeerlist cannotbeconnectedtoitisejectedfromthelist.Ifthesizeofthepeerlistfallsbelowacongurablevariable additionalpeersarerequestedfromthetracker.Ofnoteisthatconnectionsinitiatedfromotherpeersmight alsoresultinadditionstothepeerlist. Theotherpeersconnectedtoanygivenpeerareknownasthatpeer'slocalswarm.Peersperiodically exchangeinformationonwhatpiecestheyhavewiththeirlocalswarm.Thisinformationexchangeallows eachpeertorequestthepiecesitismissingfromlocalswarmmembersthathavethem. ToensurepiecepropagationandmaximizedownloadthroughputBitTorrentpeersemployachokingalgorithmwhereuploadbandwidthisreciprocatedwithdownloadbandwidth.Thistit-for-tatmechanismprovides uploadbandwidthtopeersinthelocalswarminproportiontothedownloadbandwidththeyareproviding forthepeer.Peersinthelocalswarmareperiodicallyorderedbytheirdownloadbandwidthcontributionand alimitednumberareprovidedreciprocaluploadbandwidthunchokedandtherestareprovidednoupload bandwidthchoked.Additionally,forbootstrappinganddiscoverypurposesachokedpeerisoptimistically unchoked,disregardingtheorderingbydownloadbandwidthcontribution. Peerscommunicateviaasetofmessages.ThestandardBitTorrentprotocol[16]deneseightmessages: CHOKE,UNCHOKE,INTERESTED,NOT INTERESTED,HAVE,BITFIELD,REQUEST,PIECE,and CANCEL.Themessagescanbebrokenupintothreelogicalgroupings:contenttransfer,discovery,and resourcemanagement.Table2showsthesemessagesandtheirassociatedpayloads. ThecontenttransfergroupingofmessagesincludestheREQUEST,PIECEandCANCELmessages. WhenapeerwishestoreceiveapiecefromanotherpeeritsendsaREQUESTmessagewiththepayload indicativeofthepieceitisrequesting.ThepeeronthereceivingendoftheREQUESTmessageresponds 12

PAGE 22

Table2.BitTorrentprotocolmessages Message Payload REQUEST anindex,begin,andlengthofthepiecebeingrequested PIECE anindex,begin,andthepiecebeingsent CANCEL anindex,begin,andlengthofthepiecebeingcancelled INTERESTED nopayload NOT INTERESTED nopayload HAVE indexofpiecesenderjustcompleted BITFIELD biteldwith1ifpieceisavailable,0otherwise CHOKE nopayload UNCHOKE nopayload withaPIECEmessagewiththepayloadindicativeofthepieceitissending.CANCELmessagesareused duringtheendgamemodethatoccurstowardstheendofadownload.Theendgamemodeinvolvesapeer oodingallconnectedpeerswithrequestsfortheremainingpieces.Oncethepeerreceivesthenalpieces itCANCELsanyoutstandingrequests.ThediscoverygroupingofmessagesincludestheINTERESTED, NOT INTERESTED,HAVE,andBITFIELDmessages.ApeersendsanINTERESTEDmessagetopeers toindicatethatithasaninterestinthepiecestherecipientoftheINTERESTEDmessagehasavailable. Conversely,aNOT INTERESTEDmessageissentiftherecipienthasnopieceswhichthesenderdoesnot. TheHAVEmessageissenttoallpeersinalocalswarmuponthecompleteddownloadandsuccessfulhash checkofapieceandisthemethodthatalreadyconnectedpeerslearnaboutnewlyavailablepiecesintheir localswarm.TheBITFIELDmessageistherstmessageexchangedbetweenpeersaspartofaprotocollevel handshake.Itspayloadisabiteldindicatingwhichpiecesthesenderhasavailable,withavailableindexes setto1andothersetto0.Finally,theresourcemanagementgroupingofmessagescontainstheCHOKEand UNCHOKEmessages.ApeersendsanotherpeeraCHOKEmessageindicatingthatREQUESTmessages willnolongerbehonoredandanUNCHOKEmessagetoindicatethattheywillbehonored. Intermsofwastedenergytheimportantitemsofnotearethemaintenanceofthepeerlist,andtherelated needforotherpeerstobeabletoinitiateconnections.Whileaninabilitytoinitiateaconnectiontoapeer resultsinitsejectionfromthepeerlist,theterminationofanexistingconnectionalsoresultsinejection.In eithercase,anoncommunicatingpeerismarkedasdeadandisejectedfromthepeerlist.Asasleeping peerisunabletorespondtoinitiatedTCPrequests,andapeergoingtosleepseverstheconnectionstoits localswarm,anejectionfromthepeerlistnecessarilyfollows.Thisforcespowermanagementtobedisabled foraBitTorrentclienttocontinuecontributingpiecesafterbecomingaseedevenwhenlightlyutilizedi.e., ithasveryfewuploadrequests. 13

PAGE 23

2.3Thens-2BitTorrentSimulator Thens-2networksimulatorisaC++baseddiscreteeventsimulationenvironmentusedfornetworkresearch[34].Applications,devices,communicationprotocols,andnetworktopologiescanallbemodeledin ns-2.Duetoitsmodularnatureitisrelativelyeasytoaddnewcomponentstons-2. ThepotentialenergysavingsofaGreenBitTorrentclientwereevaluatedusingthens-2simulator[34]. TheBitTorrentpacket-levelsimulationmodeldevelopedbyEgeretal.[19]wasusedasastartingpoint.The modelbyEgeretal.includestheunderlyingTCPmodelthatispartofns-2.TheBitTorrentmodelismodular allowingforreplacementofpeerandpieceselectionalgorithms.Thismodelwasmodiedtoimplementthe greenBitTorrenteventsdescribedinChapter3. Asthemodelcreatedin[19]wasinitiallydevelopedtoanalyzepacket-levelvsow-levelBitTorrentsimulationsitdoesnotfullyimplementtheBitTorrentprotocol.Thesimulationmodeldoesnotuseatorrentle andinsteadsimulatesthisaspectofBitTorrentviathesimplestorageoftheamountofdatatobetransferred andthesizeofpieces.Piecesarenothashedandcheckedforintegrityuponreceptionandthusanydata receivedbyasimulatedclientistreatedaslegitimate.Thetrackerprotocolisnotimplementedandinstead asimpletracker-likeobjectisdirectlyaccessedbysimulatedpeersi.e.,peersdonotcommunicatewiththe trackeroverthenetwork.Onlythebasicchokingalgorithmfrom[17]isimplementedandthusperformance relatedadditionssuchasendgamemodearenotpresent. Thens-2BitTorrentsimulationmodelisoverallreasonablysimpleindesign.Apeerisrepresented bythe BitTorrentApp class. BitTorrentApp implementsallthefunctionalityofaBitTorrentclientincluding establishingconnectionsbetweenpeers,sendingandreceivingmessages,sendingandreceivingdata,running thechokingalgorithm,andpieceselection. BitTorrentApp objectsareconnectedtoeachotherviathebuiltin TCPconnectionmodelofns-2.Anadditionalapplicationprotocolconnection, BitTorrentConnection wraps theactualsimulatedTCPconnection.OutboundmessagesarestoredinaFIFObufferwhichisthencleared bythedestinationpeeruponreception.Theapplicationlevelmessagesthemselvesarerepresentedbythe BitTorrentData classandallthemessagetypesandassociatedpayloadslistedinTable2areavailable.The trackerisrepresentedbythe BitTorrentTracker classandactsasacombinedmetadatastoresimilartothe functionalityofthetorrentleinarealclientandBitTorrenttracker.Again,thetrackerprotocolisnot implementedandthuspeersdirectlyaccessthetrackerobjecttoretrievepeerlistsaswellasthemetadatathat wouldnormallybepresentinatorrentle. 14

PAGE 24

Figure5. Torrent classdiagram 2.4TheBitTornadoBitTorrentClient TheBitTornadoT-0.3.17BitTorrentclientwaschosentobasetherealGreenBitTorrentclientoffof[12]. BitTornadoisbasedofftheoriginalBitTorrentclient,withasimilarinterfaceandafewadditionalfeatures, inparticularabandwidthlimiter.BitTornadoiswritteninPythonandthusmulti-platform. DuetothemodularnatureofBitTornadothereareseveralcomponentsthatwhilenotdirectlymodied byaGreenBitTorrentimplementationarestillaffected.Additionally,duetothesomewhatloosenature oftheBitTorrentprotocolspecicationitisworthwhileexaminingsomeofthebehaviorthespecication leavesuptoclientimplementation.AsBitTornadowasforkedfromtheoriginalBitTorrentclientcodethere weresomeinitialchangestoorganizationmade.Whilethemajorityofthecodebasewasquitemodularand wellorganizedthehighlevelcoderesponsiblefortheclient'sinteractionwithatorrentwasnot.Tothisenda Torrent classwithcommonfunctionalitywasabstractedaway.The Torrent classisresponsibleforreadingthe metainfofroma.torrentle,initializingdatablocks,initializingtheobjectsnecessaryfordownloadingand uploadingdata,andisageneralpointofinteractionwiththeclient.Aclassdiagramofimportantattributes andmethodsofthisclasscanbeseeninFigure5. Whilenotexhaustive,theimportantattributesofthe Torrent classseeninFigure5are: downloader uploader encoder connector 15

PAGE 25

Figure6. Downloader classdiagram The downloader attributeisanobjectthatcoordinatesdatadownloads.The uploader attributeisanobject thatcoordinatesdatauploads.The encoder attributeisanobjectthatcoordinatesconnectionsbetweenpeers. The connector isanobjectthatimplementsprotocollevelcommunicationbetweenpeers. Therelevantmethodsare: init connector init encoder start torrenting shutdown get stats init connector initializestheconnectorobjectthis Torrent willbeusing. init encoder initializesthe encoderobjectthis Torrent willbeusing. start torrenting beginstheprocessofparticipatinginaswarm. shutdown disconnectsfromtheswarmandshutsthe Torrent down. get stats retrievesimportantstatistics aboutthe Torrent The Downloader classisresponsibleforcoordinatingdatadownloads.Theprimarytasksfordownloading dataaretherequestofpiecesfromotherpeersandhandlingofprotocolmessagesthataffectdatadownload. AclassdiagramofimportantattributesandmethodsofthisclasscanbeseeninFigure6. Whilethe Downloader objectscoordinatesdownloads,aseparate SingleDownload objectforeachconnectedpeerwhichperformsthenecessarytasks.Aclassdiagramofimportantattributesandmethodsofthis classcanbeseeninFigure7. 16

PAGE 26

Figure7. SingleDownload classdiagram The SingleDownload classcontainsthemethods: got choke got unchoke is choked request more got piece got have got have biteld got choke isaneventhandlerthatrespondstoaconnectedpeerchokingthis Torrent .AstheBitTorrent protocolspeciesthatachokedpeerwillnothaveitspiecerequestshonored,the got choke handlerclears anyqueuedrequestsfordatafromthepeerthatsentthechokemessageandnotiesothercomponentsofany requeststhatwerecleared.Similarly, got unchoke respondstoaconnectedpeerunchokingthis Torrent and beginstheprocessofrequestingmoredata. is choked simplyreturnswhetherornotthispeeriscurrently chokedbytheconnectedpeer. request more isthemethodthatqueuesrequestsfordata.First,anassertionismadethatthis Torrent isnotchokedbythepeerfromwhichdataistoberequested.Next,assumingthattherequestqueuehas 17

PAGE 27

notbeenexceededa backlog whichstartsat2andiscontinuallyadjustedbasedonrateandacongurable maximumforoptimalperformancenewrequestsarechosenfortherequestqueue.Thesenewrequestsare chosenvia PiecePicker object.The PiecePicker choosesanappropriatepiecetorequestfromtheconnected peerbyrstchoosingtherarestpiecerst.Thatis,thepiecerequestedwillbetheonethattheleastnumber ofpeersinthelocalswarmhaveandthatthepeerthepieceisbeingrequestedfromhas.Ifasuitablepiece isfoundtherequestedpieceisaddedtotherequestqueueofthispeerandaREQUESTmessageissentto theconnectedpeer.Ifnosuitablepiecesarefound,theconnectedpeerwillbesentaNOT INTERESTED message. The got piece methodisaneventhandlerredwhenthispeerreceivesapiecefromtheconnectedpeer. First,therequestedpieceisremovedfromtherequestqueue.Next,theratemeasuretotheconnectedpeer isupdatedforuseinthechokingalgorithm.Oncethisiscompleted,thepieceisvalidatedbycomparingthe checksumofthereceiveddataagainstthechecksumlistedinthemetainfole.Ifthechecksumfails,the pieceisreturnedtotherequestqueue.Finally,acheckonwhetherornottheentirelehasbeendownloaded occurs.Iftheleiscompletethe Torrent entersseedmode,ifitisnot,acallto request more ismade. The got have methodisaneventhandlerredwhenthispeerreceivesaHAVEmessagefromthe connectedpeer.The PiecePicker isupdatedtomakenoteofthenewpieceavailablefromtheconnectedpeer. got have biteld handlesthebiteldthatisreceivedduringaprotocolhandshake.Itoperatesinasimilar fashionasthe got have handlerbutworksonmultiplepiecesatatime. Asthe Downloader isresponsibleforcoordinatingdatadownloads,the Uploader isresponsibleforcoordinatingdatauploads.Asdatauploadsaremoreindependentthandownloadsthereisnoneedformanaging Uploader sbetweenconnectedpeers,sounlikethe Downloader eachconnectedpeerhasasingle Uploader associatedwithit.AclassdiagramofimportantattributesandmethodsofthisclasscanbeseeninFigure8. Relevantmethodswithinthe Uploader classare: got not interested got interested is interested got request got cancel choke 18

PAGE 28

Figure8. Uploader classdiagram choke sent unchoke is choked WhenthispeerreceivesaNOT INTERESTEDmessagefromtheconnectedpeer,the got not interested eventhandlerisred.Theconnectedpeerismarkedasnotinterested,anyoutstandingdatatouploadtothe connectedpeeriscleared,andthechokingalgorithmisre-run.UponreceivinganINTERESTEDmessage, theconnectedpeerismarkedasinterestedandthechokingalgorithmisre-runviathe got interested event handler. is interested isusedtoquerywhetherornottheconnectedpeerisinterestedinanypiecesthispeer hascompleted. The got request eventhandlerisredwhenthispeerreceivesaREQUESTmessagefromaconnected peer.IfthepeerthatsenttheREQUESTmessageischokedthennoactionoccurs.Iftherequestingpeeris notchokedtherequestedpieceisaddedtoanoutgoingrequestbuffertobeuploaded.IfaCANCELmessage isreceived,the got cancel eventhandlerremovesthespeciedpiecefromtheoutgoingrequestbuffer. Ifthechokingalgorithmchoosestheconnectedpeerassociatedwithaparticular Uploader the choke methodiscalled.ItmarkstheconnectedpeeraschokedandsendstheCHOKEprotocolmessage.Once theCHOKEmessagehasbeensenttothechokedpeer choke sent clearstheoutgoingrequestbuffer.If, ontheotherhand,thechokingalgorithmchoosestheconnectedpeertobeunchokedthe unchoke method iscalled.Iftheconnectedpeeriscurrentlyunchokednoactionoccurs.Iftheconnectedpeeriscurrently choked,however,itismarkedasunchokedandsentanUNCHOKEprotocolmessage. is choked isusedto querywhetherornottheconnectedpeerhasbeenchokedbythispeer. 19

PAGE 29

Figure9. Encoder classdiagram Figure10. Connecter classdiagram Encoder objectsmanageconnectionsbetweenpeers.Theconnectionsmanagedbythe Encoder areaBitTorrentprotocolabstractionwrappingaTCP/IPsocket.Aclassdiagramofimportantattributesandmethods ofthisclasscanbeseeninFigure9. Relevantmethodsinthe Encoder classare: send keepalives -SendsBitTorrentkeepalivemessagestoallconnectedpeerspertheBitTorrent protocolspecication. start connection -CreatesaBitTorrentconnectiontoapeer The Connecter [sic]classimplementsBitTorrentprotocollevellogic.Aclassdiagramofimportant attributesandmethodsofthisclasscanbeseeninFigure10. The Connecter classhasthefollowingmethods: connection made connection lost got message got piece The connection made and connection lost methodsarecalledwhenaconnectiontoanotherpeeris madeorlost,respectively.Whenaconnectionismadeitisassociatedwithanew Uploader object.Additionallyitisassociatedwithanew SingleDownload objectviathe Downloader objectassociatedwiththis 20

PAGE 30

Torrent .Finally,thechokerisnotiedoftheconnectionsothenewlyconnectedpeercanbeincludedinthe chokingalgorithm. got message handlesreceptionoftheBitTorrentprotocolmessageslistedinTable2.The got piece methodsendsHAVEmessagestoallconnectedpeersonsuccessfuldownloadofapiece.Whilethe SingleDownload classdescribedpreviouslyalsoperformsactionsonpiececompletion,HAVEmessagesmustbe broadcasttoallconnectedpeersand SingleDownload objectsonlyhaveaccesstoaconnectiontoasingle peer. 2.5RelatedWork NetworkconnectivityproxyingNCPhavebeenproposedasameansoflettingedgedevicessleepand maintainnetworkconnectivity[18],[22]andarealreadyavailabletothepublic[8].Thesenetworkproxies maintainafullnetworkpresentforthehostwhileitsleeps.In[27],[25],and[26]apowermanagement proxyforGnutellaisexplored.BysupportingasubsetoftheGnutellaprotocolmessagestheproxyallows ahostpeertosleepwhilenotactivebutrespondtocrucialmessagesandwakeupwhennecessary.The Gnutellaproxywasevaluatedbymeasuringledownloadtimeandqueryforwardingrates.Filedownload timewasshowntoincreasefrom1secondwithapeerthatwasawake100%ofthetimeto9secondswhenthe proxywasused,howeverasignicantamountofthisincreasewasduetothetransitionfromsleeptowake inWindowsXP.Theresultsindicatethat25%ofP2Phostsmovingtotheproxywouldresultinsavingsof $38millionperyearintheUS.Whilethesesavingsarebasedoffofthe60millionPCsinUShomes,Green BitTorrenttargetsthemuchlargermarketofdigitalcontentdeliverytohomeswithdigitalcableservice. NanoDataCenters[40]havebeenproposedasamethodofreducingtheenergyconsumptionofdatacenters.ThesenanodatacentersareinrealityP2PapplicationserversrunningontopofexistingISPcontrolled gatewaysinconsumershomes.UsingtracesfromNetix,Youtube,andIPTVasimulationmodelisbuilt whichdemonstrates20%to30%savingsinenergyusagewhencomparedtoatraditionaldatacentermodel. TheoverallenergyefciencyofBitTorrentcomparedtotraditionalclientserverdistributionmodelswas exploredin[33].Goingundertheassumptionthatpeersinvolvedincontentdistributionwillbeonanyways, theauthorsconcludethatP2Pcontentdistributionismoreenergyefcientthandatacenters.Withrespectto BitTorrentspecically,severalproxyingsolutionshavebeenproposed[1][5].Theworkinthisthesisdiffers dramaticallyfromthisapproach.TheSomniloquyprojectfromMicrosoft[1]developedalowpowerproxyingdevicethathandlesasubsetofapplicationrequirementswhilethemaincomputersleeps.ABitTorrent clientforSomniloquywascreatedasaproofofconcept.ImportanttonoteisthatthisBitTorrentclientcould 21

PAGE 31

onlydownloadandnotupload,thusmakingitoflimiteduse.Thelowpowerproxyin[1]specicallyhandles onlydownloadrequestswhichinturndegradesthestrengthoftheswarmbyconsumingresourceswithout contributing.Similarly,theproposedproxyingmethodin[5]designatesaspecicmachineinaLANasa proxywhichdownloadsonthebehalfofotherpeerswhichcanthenbepowereddown.TheproxywasevaluatedviaatestbedofseveralPCsconnectedtotheInternetovera100Mbit/sconnectiondownloadingles thatrangedinsizefrom3.95GBto4.71GB.InthestandardBitTorrentexperimentsallofthePCsoperated asnormalwhileintheproxyexperimentsonePCservedasaproxyfortheothers.TheBitTorrentproxy hastwomajoradvantages:areductioninenergyconsumedandpossibleimprovementtooveralldownload times.Energyconsumptionisreducedbecauseonlytheproxyneedstoremainpoweredonatalltimesand resultsindicatesavingsofupto95%.Overalldownloadtimesarereducedduetoareductionintheoverall numberofpeersinaswarm.Astheproxyhandlesdownloadsforeachofthepeersbehindittheamountof datatransferredviatheBitTorrentswarmisdecreased,whichincreasestheper-peerresourcesavailable,in turndecreasingdownloadtimesbyapproximately22%.Thisproxyingmethodislimitedbygeographicand networktopologyhowever.Clearlythepeer-proxyrelationisdependentonthepeersandproxybeingonthe sameLAN.Further,iftheproxyisadedicateddevice,i.e.,notusedandthusfullypoweredonatalltimes foradditionalservices,theenergysavingsscalewiththenumberofpeersitproxiesfor.GreenBitTorrentis uniqueinthatitisindependentofthegeographictopologyofpeersinadditiontomaintainingtheviabilityof theswarminwhichpeersparticipate. 2.6ChapterSummary Thischapterdescribedmethodsofcontentdistributionnecessaryforunderstandingtheremainderofthis thesis.Client-servercontentdistributionwasdescribedwithanemphasisontheenergyconsumptionofdata centers.Additionally,peer-to-peercontentdistributionwasexaminedalongwithpotentialenergysavingsit mightprovide. TheBitTorrentprotocolwasintroducedanddescribed.AlongwiththeBitTorrentprotocoldiscussion thens-2networksimulatorwasdescribed,withinwhichthenewGreenBitTorrentwasimplemented.The BitTornadoBitTorrentclientwasalsointroducedanddescribed.AstheBitTornadoclientisacomplex pieceofsoftware,classdiagramsandexplanationsofrelevantmethodsandinterworkingofthecomponents necessarytounderstandthemodicationswereprovided. 22

PAGE 32

Chapter3: GreenBitTorrentProtocolExtension 3.1WhatisaGreenBitTorrent? TheprimaryconcernofaGreenBitTorrentismaintainingthefewestpowered-onpeersatanygiventime bysleepingwhenresourcesareunneeded.Relatedisthetransitiontoasleepstatenotdisruptingthepeerlist ofitslocalswarm,andtheabilitytobeawokenwhenitsresourcesbecomeneededagain.Anawakepeer shouldalwayshaveasufcientnumberofotherpeersthatareawaketodownloadfrom,thusanawakepeer mustbeabletowakeupothersleepingpeers. Toachievetheabove,newpeerstates,timers,andeventsaredened.StandardBitTorrentdoesnot specicallydenepeerstates,howeverpeerscanbelogicallyconsideredtobeinoneoftwostates: not connected or connected .ThethreenewpeerstatesthatGreenBitTorrentdenes,are unknown connected and sleeping andaredescribedindetailinthenextsection.Inadditiontothenewpeerstateseventsdetecting thedisconnectionofapeer,ndingnewpeers,goingtosleep,andwakingupwillbediscussed.Finally,the effectsthatGreenBitTorrentclientshaveonaswarmofpeersthatincludestandardBitTorrentclientswillbe discussed. 3.2NewPeerStates Whenapeerrstreceivesalistofotherpeersfromthetrackernostatementastothestateofthesepeers canbemade.Apeermightbesleepingoritmightbeawake.Thus,upongainingnewknowledgeofthe existenceofapeerthepeerismarkedasbeinginthe unknown state.Thatis,neithersleepingnorawake. Onceapeerbeginscommunicatingwithanotherpeertheotherpeerismarkedas connected .TheconnectedstateimpliesthatapeerhasanactiveTCPconnectionwiththepeerthathasmarkeditconnectedand lepiecescanbeuploadedanddownloadedontheconnection.Notethattheabilitytouploadanddownload isdeterminedbytheBitTorrentprotocolandnotnecessarilydataavailabilityortheexistenceofaconnection betweenpeers.NotransferswilltakeplaceunlesstheconnectionbetweenthetwopeersisUNCHOKEDand INTERESTED. 23

PAGE 33

Figure11.Descriptionofchangedpeerdisconnectdetectionevent Figure12.BitTornadopeerdisconnectevent[12] Finally,apeerismarkedas sleeping ifithasdisconnectedwiththispeer,andthushasclosedtheTCP connectiontoit.ForfurtherdatatransferbetweenthetwopeersanewTCPconnectionmustbeestablished. 3.3NewPeerEvents ThedetectionofdisconnectedpeersalreadyexistsinstandardBitTorrent.StandardBitTorrentclients ejectpeersfromthepeerlistthathavedisconnectedandtheknowledgeofthepeer'sexistenceislost.This canbeseeninFigure12line3,acodesnippetfromtheBitTornadoBitTorrentclient.Incontrast,adisconnectedpeerisnotremovedfromaGreenBitTorrentclientspeerlistbutrathermarkedassleeping,asseenin Figure11. GreenBitTorrentpeersmustbeabletodiscoverandconnecttonewpeersasthemakeupoftheirlocal swarmchanges.Forexample,ifallthemembersofapeer'slocalswarmdisconnectthepeermusthavethe abilitytondandinitiatenewconnections.StandardBitTorrentpeersaccomplishthisbyrequestinganew setofpeersfromthetrackeratregularintervalsandinitiatingconnectionswithneworalreadyknownbutnot connectedpeersasnecessary.AGreenBitTorrentpeermustoperatesomewhatdifferentlyonthenewpeers receivedfromthetracker. Figure13showsthebehaviorofaGreenBitTorrentpeerwhennewconnectionsareneeded.Afterreceivinganewsetofpeersfromthetrackerthestateforeachpeerinthislistissetto unknown line4.Ifthe numberofcurrentlyopenconnectionsislessthan max connect apeerisrandomlyselectedfromthepeerlist. Beforeconnectingtoapeerthepeeristestedforwakeup. 24

PAGE 34

Figure13.Descriptionofchangedpeerdiscoveryevent Figure14.Descriptionofnewpeerinactivityandsleepevent Thespecicconditiontestedis: p.state==unknown ifthispeerisaseed,and p.state==unknownORp.state==sleeping ifthispeerisaleech. Iftheconditionismet,awakeupmessageissentandanattemptatestablishingaTCPconnectionoccurs. ThiswakeupmessagecouldbeastandardMagicPacket[4]oranotherpackettype.IftheTCPconnection fails,thepeerisconsidereddeadforexample,ithasbeenphysicallyremovedfromthenetworkand removedfromthepeerlistcompletely. Figure14showshowaGreenBitTorrentpeertransitionstosleep.WheninactivityisdetectedaNOT INTERESTEDmessageissenttoallconnectedpeersfollowedbyaCHOKEmessagelines2and3.These twomessagesensurethattheswarmisinaconsistentstatewhenapeergoestosleep.Oncethesemessages havebeensentthepeerclosesallopenconnectionsandgoestosleep. 25

PAGE 35

Figure15.Descriptionofnewpeerwakeupevent Figure15showswhatoccurswhenasleepingpeerreceivesawakeupmessage.OncetheinboundTCP connectionisestablishedline2thenowawakepeersendsaBITFIELDmessagedescribedinsection2.2 andTable2tothepeerthatsentthewakeupmessage.Thesendingofthebiteldmessageenablesthepeer thatsentthewakeupmessagetodeterminewhetherornotitisINTERESTEDinthepiecesthenowawake peerhasavailable. 3.4BackwardsCompatibility WhileitisexpectedthatGreenBitTorrentclientswillbeusedprimarilyinswarmscomposedexclusively ofotherGreenBitTorrentclientstheyarebackwardscompatiblewithstandardBitTorrentclients.However, withoutadditionalmeasures,GreenBitTorrentclientswilldegradetheperformanceofstandardBitTorrent clients.AsastandardBitTorrentclientwillejectanypeerthatgoestosleepfromitspeerlist,sleepingGreen BitTorrentpeerswillremainasleepandunusableunlesswokenupbyotherGreenBitTorrentpeers.Oneway ofmitigatingthisissueinvolvesGreenBitTorrentclientsdetectingthepresenceofstandardBitTorrentclients inaswarmandrevertingtostandardbehaviori.e.,notgoingtosleep.Themethodsforclienttypedetection standardorgreen,signaling,andanynegotiationbetweenclientsarebeyondthescopeofthisthesis. 3.5ChapterSummary InthischapteradescriptionofaGreenBitTorrentispresented.Thenewpeerstatesrequiredfora GreenBitTorrentweredescribed.Thethreenewpeerstates unknown sleeping connected allowlong livedknowledgeofsleepingpeerstoberetained.TheneweventsinaGreenBitTorrentclientwerealso described.Themaintenanceofpeerknowledgeafterapeergoestosleepwasdemonstrated.Themechanism bywhichaGreenBitTorrentpeergoestosleepwasexplained,specicallythemessagesthataresentby apeertransitioningtosleeptoensuretheswarmremainsinaconsistentstate.Whatoccurswhenapeer wakesupwasalsodescribed.FinallyissuesofcompatibilitybetweenGreenBitTorrentclientsandstandard BitTorrentclientswereexplored. 26

PAGE 36

Chapter4: ImplementationofGreenBitTorrent TheGreenBitTorrentclientwasimplementedwithinthens-2networksimulatoraswellasamodication totheBitTornadoBitTorrentclient.Thens-2implementationallowsforexperimentsinvolvingalargenumber ofpeersthatwouldotherwisenotbeaccessible.TheBitTornadoimplementationallowstestingoftheGreen BitTorrentwithrealpeersactivelytransferringdata.Thischapterexplainsthechangesandadditionstons-2 andBitTornadowhileimplementingtheGreenBitTorrentclient. 4.1Changestons-2BitTorrentSimulation AstheBitTorrentmodelbyEgeretal.wasusedasastartingpoint,thecodethattheGreenBitTorrent wouldnecessarilychangewasrstisolated.Duetothenatureofthemodel,theonlyclassthatrequired modicationwas BitTorrentApp 4.1.1PeerStates ThepeerstatesnotedinSection3.2werehandledbyincludinganewpossiblevalueforentriesina givenpeer'speerlist.Whiletheoriginalmodelhasthreepossiblevalues,-1fornotconnected,0forahalf completedconnectioni.e.,onepeeraskingforaconnectionbutnotyetrespondedtobytheotherpeer,and 1forfullyconnected,anadditionalvalue2indicatingagivenpeerissleepingwasadded.Theoriginalvalues of-1and1mapdirectlytotheunknownandconnectedpeerstates.Inthesimulationenvironmenttheentries inanindividualpeer'speerlistareshared.I.e.,thereisonlyeveroneinstanceofanentryforagivenpeer andthisinstanceexistsinmultiplelists. 4.1.2PeerEvents TheeventdescribedinFigure11wasimplementedbyoverridingthebase BitTorrentApp 's close connection method.Intheoriginalmodel, close connection ejectedthepeertheclosedtheconnectionfrom thepeerlistwhiletheoverriddenmethodmarksitassleepingaconnectedvalueof2. 27

PAGE 37

ThepeerdiscoveryeventdescribedinFigure13wasimplementedbyoverridingthe check connections method.Theoriginal check connections attemptstoconnecttoanynon-connectedpeersconnectedvalue1aslongasthetotalnumberofpeersinthelocalswarmislessthan max connect .Thenew check connections in GreenBitTorrentApp differsintwodistinctways.First,itsendsawakeupmessagetoallpeersitattempts toconnecttoasthereisnowaytodistinguishwhetherornotapeerinthe unknown stateissleeping.Second, ifapeer'sstateisknowntobe sleeping thenitwillnotbesentawakeupmessageorconnectedtoifthispeer isaseedaspertheconditionspeciedinFigure13. TheeventdescribedinFigure14isimplementedviatwonewmethodsin GreenBitTorrentApp called try sleep and go to sleep try sleep iscalledbyatimerwhichresevery n secondswith n being congurable. try sleep rstassertsthatthepeertryingtosleepisaseed,ifitisnotnoactionoccurs.If itisaseed,however,theactivityofthepeerischecked.Thisentailscheckingtheactiverequestsofeach connectedpeer.Ifnopeerhasanactiverequestfordata,thentheseedisdeterminedtobeinactiveanda callto go to sleep ismade. go to sleep againassertsthatthepeertryingtosleepisaseed.Ifthepeer tryingtosleepisaseed,theneachpeeritisconnectedtopeerstate connected orconnectedvalue=1issent aNOT INTERESTEDmessage,choked,andhasitsTCP/IPconnectiontothepeergoingtosleepclosed. Additionally,thepeerthatwenttosleepremainsunavailableforwakeupforacongurabletime,simulating thetimenecessaryforacomputertotransitiontoasleepingstate. TheeventdescribedinFigure15isimplementedviatwonewmethodsin GreenBitTorrentApp called wake up and done waking up .Asnewnewconnectionsarealwaysinitiatedwithawakeupcalldescribed intheimplementationofFigure13 wake up rstassertsthatthepeerisasleep.Ifthepeerisnotsleeping, noadditionalactionistakenandtheconnectionproceedsasnormal.Ifitis,thenatimerisstartedtomodel theamountoftimeacomputerwouldrequiretotransitionfromsleeptoawake.Whenthistimerres, done waking up iscalled. done waking up rstbeginslisteningonthesimulatedTCPconnectiontothe peerthatwokeitup.Oncetheconnectionisestablishedthesharedpeerlistentryrepresentingthenowawake peerhasitsconnectedvaluesetto1,effectivelysettingthepeersstatetoconnectedasperSection3.2.Next, thenewlyawakepeersendsitsbiteldtothepeerthatwokeitupandrunsthechokingalgorithm. 28

PAGE 38

Figure16.ClasshierarchydiagramforGreenBitTorrentimplementationinBitTornado 4.2ChangestoBitTornado TheBitTornadocodebaseismoredecoupledandmodularthanthens-2modelbyEgeretal.andthus changesinmultiplelocationswerenecessary.Severalclasseswereidentiedformodication: Torrent -Tobeextendedviaaderivedclass GreenTorrent Encoder -Tobeextendedviaaderivedclass GreenEncoder Connecter -Tobeextendedviaaderivedclass GreenConnector Figure16isaclasshierarchydiagramillustratingtherelationshipbetweenparentandchildclassesand overriddenmethods. 4.2.1PeerStates ThepeerstatesidentiedinSection3.2werenotdirectlytranslatedtotheGreenBitTorrentclient.The connected statecanbedirectlyinferredbytheexistenceofaconnectiontoanotherpeer.The unknown state canbeinferredbytheabsenceofaconnectiontoapeeraswellasthepeernotexistingina sleeping peers list.Finally,the sleeping stateisinferredbyapeer'smembershipina sleeping peers list. 29

PAGE 39

Figure17. GreenConnector#connection lost method Figure18. GreenEncoder#start connection method 4.2.2PeerEvents TheeventdescribedinFigure11wasimplementedin GreenConnector#connection lost .Unlikethe simulation,thestateofpeersinthepeerlistarenotshared,andsoaslightlydifferenttechniquewasused.As seeninFigure17, GreenConnector#connection lost addsthedisconnectedpeertothe sleeping peers list andthendefersto Connecter#connection lost seeninFigure12. TheeventdescribedinFigure13isimplementedviamethodsinthe GreenEncoder and GreenConnector classes.The Encoder classisresponsibleformanagingconnectionstopeers,and GreenEncoder#start connection implementslineslines9through11inFigure13asseeninFigure18.Again,asstateisnotshared betweenpeersinarealswarm, GreenConnector#connection made handlesthesettingofthepeerstatesin Section3.2asseeninFigure19byimplementingthefunctionalityinline13ofFigure13. TheeventdescribedinFigure14isimplementedin GreenTorrent#try to sleep and GreenTorrent#go to sleep seeninFigure20. GreenTorrent#try to sleep implementstheinactivitytimeronline1ofFigure14while GreenTorrent#go to sleep implementslines2through6ofFigure14. Line2ofFigure20rstassertsthatthispeerisaseed.Ifnot,checkforinactivityisrescheduledtooccur inanother15seconds.Ifthispeerisaseed,lines5through8checkforactivitybylookingforactiverequests byanyconnectedpeersorinterestbyanyconnectedpeers.Ifanactiverequestsorinterestedpeerexists,the inactivitycheckisrescheduledtooccurinanother15seconds.Finally,ifthispeerisaseedandisinactive, line9makesacallto GreenTorrent#go to sleep online9. 30

PAGE 40

Figure19. GreenConnector#connection made method Figure20. GreenTorrent#try to sleep and GreenTorrent#go to sleep methods Figure21. GreenTorrent#wake up method GreenTorrent#go to sleep rstassertsthatthispeerisaseed.Assumingthispeerisaseed,lines14 through17ofFigure20implementlines2through5ofFigure14andthepeertransitionstoasleepstate. TheeventdescribedinFigure15isimplementedinthe GreenTorrent#wake up methodseeninFigure21. 4.3ChapterSummary ThischapterdescribedtheimplementationoftheGreenBitTorrentclientwithinboththens-2network simulatorandtheBitTornadoBitTorrentclient.Thepointsofapplicationcontrolthatmustbemodiedto 31

PAGE 41

allowthedecouplingofTCP/IPconnectionstatefromapplicationstateasdescribedinSection3.1were isolated.Theimplementationofthechangesandhowtheyrelatetothepeerstatesandeventsdescribedin Sections3.2and3.3werealsodescribed.Finally,aclasshierarchytoillustratetherelationshipbetweenthe standardBitTornadoclientandtheGreenBitTorrentmodicationswasprovided. 32

PAGE 42

Chapter5: EvaluationofGreenBitTorrent InordertotesttheefcacyofGreenBitTorrentswarmsundervariousconditionsmustbeevaluated. Recognizingthescenariosunderwhichenergysavingsarepossibleandhowmuchsavingsareachievable istheprimaryconcernoftheevaluationofGreenBitTorrent.TothisendatypicallargeGreenBitTorrent swarminthesimulatorwasevaluatedandcomparedtheresultstoastandardBitTorrentswarmunderthesame conditions.AsmallerswarmofclientsusingtherealGreenBitTorrentclientwasthentestedandcompared totheresultsofastandardBitTorrentswarm.Finally,thesimulationwasvalidatedbyrunningexperiments withthesameswarmmakeupunderwhichtherealclientswereevaluatedandcomparedtheresults. 5.1SimulationExperiments Theworkinthissectionoriginallyappearedin[14].Insection5.2.2.1newresultsfromtherealclientas wellasavalidationofthesimulationexperimentsareprovided.ABitTorrentsystemcanbeviewedashaving controlandresponsevariablestobemanipulatedandmeasured,respectively. Thecontrolvariablesforthesystemcongurationwere: Numberofswarmsapeerparticipatesin Numberofpeerstomaintaininaswarm Numberofconnectedpeersmax connect Numberofseedpeersatthestartoftheswarm Numberofleechpeers Filesize Uploadanddownloadbandwidthforpeers RTTbetweenpeers 33

PAGE 43

ThecontrolvariablesforaGreenBitTorrentpeerwere: Transitiontimetowake-upandgotosleep Connectiontimerpresetvalue Inactivitytimerpresetvalue Thecontrolvariablesforsystemworkloadwere: Interarrivaltimedistributionforpeersenteringaswarm Distributionparametersincludingmeaninterarrivaltime T arrival Theresponsevariablesforapeerwere: Sleeptime Awaketime Filedownloadtime 5.1.1DescriptionofExperiment Anexperimenttomeasureledownload,sleep,andawaketimesasafunctionoftheinterarrivaltimeof peersintoaswarmwasdesigned.Thesystemmodeledasingleswarmof50peersatypicallargeswarm withoneadditionalinitialseedpeerthisinitialseedpeerwassettoneversleepinanyofthecasesandthe restoftheenteringpeersinitiallycontainingnopieces.Amax connectvalueof5thetypicalvaluefora BitTorrentclientwasused.Alesizeof1GBcorrespondingtoasmallvideolewasused.Filepieces were256KB.Anuploaddatarateof2Mb/sanddownloaddatarateof10Mb/sperpeercorresponding toVerizonresidentialFIOS2008baserates[41]wasused.TheRTTbetweenpeerswas10msmodelinga swarmcontainedwithinthedomainofasingleISP.Theexperimentswereconductedonthehighperformance computingresourcesoftheUniversityofSouthFlorida'sResearchComputing. ParametersspecictoGreenBitTorrentweresetasfollows.Thewake-upandgotosleeptransitiontimes were300mseach.Thisisareasonabletimeforanoperatingsystemtosaveitsstateandforaprocessorto recoverthisstateandresumeexecution.TheLinux-basedOLPCmachinerequiresonlytensofmilliseconds towake-up[42].Theconnectiontimerwassetto300smin.Thisisthedefaultconnectiontimervalue usedinBitTorrentclientimplementationsforcheckingwiththetrackerfornewpeers.Theinactivitytimer wassetto15s.Thisvaluewasselectedasreasonabletopreventoscillationbetweenawakeandsleep. 34

PAGE 44

PeersarrivedintoaswarmasaPoissonprocessthatis,interarrivaltimesareexponentiallydistributed. Thismodelsindependenthumanbehaviorwell.Themeaninterarrivaltimeswerevariedfromveryshortto modelaashcrowdtoverylongtomodelpeersarrivingintoaswarmwhereallotherpeershadalready completedtheirdownloadsthatis,alloldpeerswereseeds.Themeaninterarrivaltimesusedwere, T arrival =0,0.5,1,2,4,8,16,and32minutes.Thetimetodownloada1GBleat10Mb/sisabout 14.3min,thusthe16minand32minmeaninterarrivaltimeswillhavemost,ifnotall,peersarrivingintoa swarmwhereallotherpeershavealreadycompletedtheirdownload.Twosystemsorcasesweremodeled -acontrolnetworkconsistingofstandardBitTorrentwherenopeerscouldsleepandagreenBitTorrent network.Foreachinterarrivaltime30replicationswererun,eachreplicationwithadifferentinitialrandom numberseed.Theaverageofthereplicationswascomputedandplotted. 5.1.2ResultsfromExperiment ThreegraphsforstandardBitTorrentFigures22,23,and24andthreeforGreenBitTorrentFigures25, 26,and27showtheresultsfromtheexperiment.Thedownloadtimesforthe1st,25th,and50thpeerto entertheswarmasafunctionofinterarrivaltimeareshowninFigures22and25.Awakeandsleeptime forallpeerswithameaninterarrivaltimeof16minareseeninFigures23and26.Figures24and27show thesleepandawaketimeforpeer25overallinterarrivaltimeswiththegrayshowingthesleeptime.The differenceindownloadtimesbetweenthestandardandGreenBitTorrentsimulationsforpeers1,25,and50 areshowninTable3. FromFigures22and25itcanbeseenthat: Themeandownloadtimeforclient#1ishighandfairlyconstantindependentoftheclientinterarrival timeandcase. Themeandownloadtimeforclients#25and#50decreasesastheinterarrivaltimeincreasesforthe standardBitTorrentandGreenBitTorrent. GreenBitTorrenthaslargerledownloadtimesthanstandardBitTorrent.Table3showsthepercentage increaseindownloadtimeforgreenBitTorrentcomparedtostandardBitTorrent. 35

PAGE 45

Figure22.DownloadtimeforstandardBitTorrentsimulation Figure23.SleeptimeforstandardBitTorrentsimulation FromFigures23and26itcanbeseenthat: ThereisnosleeptimeforstandardBitTorrent,butthereisconsiderablesleeptimeforGreenBitTorrent. ForstandardBitTorrentthesumoftheawaketimesfortheentireswarmis324.6hours,forgreen BitTorrentitis72.1hours.8hoursisnowspentinsleep.Thisrepresentsanenergysavingsof 77.8%measuredoverallpeers. FromFigures24and27itcanbeseenthat: ThereisnosleeptimeforstandardBitTorrent,butthereisconsiderablesleeptimeforGreenBitTorrent. ForstandardBitTorrentthesumoftheawaketimesforclient#25forallinterarrivaltimesis29.6hours, forGreenBitTorrentitis10.2hours.9hoursisnowspentinsleep.Thisrepresentsanenergy savingsof65.5%measuredoverallinterarrivaltimes. 36

PAGE 46

Figure24.Sleeptimeforpeer25standardBitTorrentsimulation Figure25.DownloadtimeforGreenBitTorrentsimulation Figure26.SleeptimeforGreenBitTorrentsimulation 37

PAGE 47

Figure27.Sleeptimeforpeer25GreenBitTorrentsimulation Table3.IncreaseindownloadtimeforGreenBitTorrentversusstandardBitTorrentsimulation Meanclientinterarrivaltime Clientnumber 0min 0.5min 1min 2min 4min 8min 16min 32min Client#1 4.8% 1.5% 1.8% 1.9% 1.9% 1.9% 2.1% 1.6% Client#25 6.7% 3.7% -0.7% 5.2% 11.0% 44.8% 30.9% 18.1% Client#50 7.0% 4.6% 6.0% 15.5% 32.8% 18.7% 9.4% 8.2% Averageforall 4.9% 3.4% 3.5% 5.2% 13.7% 23.0% 22.0% 18.3% 5.1.3DiscussionofResults Twokeyquestionsemergefromtheobservedresults,theyare: 1.Whydoesclient#1alwayshavealargedownloadtimethatisroughlythesameforGreenandstandard BitTorrent 2.WhatexplainstheslightlylargerdownloadtimeforGreenBitTorrentascomparedtostandardBitTorrent? Fortherstquestion,client#1alwaysarrivesintoaswarmwithonlyoneinitialseedpresent.Later clientsarriveintoaswarmwithmanypeerspresentofwhichmanyarealsoseedsbyvirtueofalreadyhaving completedtheirdownload.Whentheclientinterarrivaltimeissmall,otherpeerswillarriveandbepresent duringthedownloadperiodforclient#1.Thus,client#1candownloadfrommultiplepeersinthecaseof smallinterarrivaltimes,butnotsowheninterarrivaltimesarelarge.Aslightreductionindownloadtimecan beseenforthesmallinterarrivaltimesbut,atthesetimestherewillalsobecompetitionfromotherpeers preventingclient#1fromgettingafulldownloadratefromtheotherpeers. 38

PAGE 48

Forthesecondquestion,thelargerdownloadtimesforGreenBitTorrentcanbeexplainedasseedsgoing tosleepputtingGreenBitTorrentatadisadvantagewithregardstodownloadtimecomparedtostandard BitTorrent.AstherearefewerawakepeersintheGreenBitTorrentswarm,therearealsofewerpeersthat mightinitiateanewinboundconnection.Whilethenumberofoutboundconnectionsislimited,inbound connectionsandthusthetotalnumberofconnectionsareeffectivelynotlimited.Thisreducestheoverall possiblebandwidthavailabletoagivenpeer,howeveritisextremelydependentonthemake-upoftheswarm atanygiventime.Thetimetowake-upsleepingseedsalsofactorsintotheincreaseddownloadtimefor GreenBitTorrent. 5.2RealClientExperiments Inordertovalidatethesimulationsexperimentsusingtherealclientwererun.Therealclientexperiments utilizedaswarmof10peers,withoneadditionalpeeractingastheinitialseed.Theclientswereeachhosted onseparatecomputers.EachcomputerwasconguredwithanIntel R Xeon R X3220quad-coreCPUrunning at2.40Ghz,4GBofram,andanIntel R PRO/1000networkadapter.Aphotographofthecomputerscan beseeninFigure28.Whilethesepeerswereconnectedtoeachotherovera1000Mbitswitchtheywere bandwidthlimitedto10Mbits/seconddownloadand2Mbits/seconduploadviathebuiltinbandwidthlimiter oftheBitTornadoclientanddistributeda100MBle. InadditiontoimplementingGreenBitTorrent,anRPCserverthatallowstheexperimentstobecontrolled wasalsocreated.TheRPCserverusesthestandardPythonxmlrpclib,alibrarythatimplementstheXMLRPCremoteprocedurecallmechanism,andexposesasetofcommandsthatcanbeissuedtoclients: create torrent start torrenting stop torrenting get stats get metainfo go to sleep wake up 39

PAGE 49

Figure28.Computershostingrealclientexperiments create torrent createsinitializestheclientbycreatinga Torrent objectofthespeciedtypes.ForexperimentationpurposesthecreationofTorrentandGreenTorrenttorrentsisallowedwithTorrentbeing astandardBitTorrentandGreenTorrentbeingaGreenBitTorrent.Creatingatorrentinvolvesreadingthe torrentleandinitializingdatablocksonthemachinetheclientisrunning. Afterissuinga create torrent command,acallto start torrenting ismade. start torrenting causes theclienttoconnecttothetrackerandbecomeamemberoftheswarm.Withnoparameters start torrenting willimmediatelyconnecttothetrackerandjointheswarm.Thereisanoptionalparameterthatcausesadelay ofusersuppliedsecondsbeforecontactingthetrackerandjoiningtheswarm.Toshutdownaclientacallto stop torrenting ismade. stop torrenting runsthroughthenormalclientshutdownprocedureandreturns statisticsfortheclient'ssession. Thestatisticsfortheclientssessionareexposedviaacallto get stats .Thespecicstatisticsreturned aregovernedbytheunderlying Torrent object.Forstandard Torrent objectsthestatisticsreturnedare: seed -whetherornotthis Torrent isaseed upTotal -thetotalamountofdatauploadedbythis Torrent downloadTime -thetimeinsecondsthis Torrent hasspenddownloadingdata totalTime -thetotaltimeinsecondsthis Torrent hasbeenamemberoftheswarm 40

PAGE 50

percentDone -thepercentageofthetotallethis Torrent hasdownloaded Inadditiontotheabove, GreenTorrent objectsalsoreturnthefollowing: sleepTime -thetimeinsecondsthis GreenTorrent hasspentsleeping awakeTime -thetimeinsecondsthis GreenTorrent hasspentawake Relatedto get stats get metainfo returnsthehumanreadableportionofthemetainfotorrentlethat aclientisworkingon. Finally, go to sleep forcesa GreenTorrent clienttogotosleepand wake up wakesa GreenTorrent clientup. 5.2.1DescriptionofExperiment Asinthesimulationexperiments,wake-upandsleeptransitionsweresetto300msandaninactivity timeof15striggeredatransitionfromawaketosleep.Againledownload,sleep,andawaketimesasa functionofinterarrivaltimeweremeasured.Allothervalueswereleftatthedefaults.Anidealtransfertime ifthedownloadbandwidthofapeeriscompletelysaturatedfortheseparametersis80seconds,andthus interarrivaltimestobearangeoneithersideofthisvaluewerechosen.Theinterarrivaltimeschosenwere T arrival =0,40,120,150,and400seconds. 5.2.2ResultsfromExperiment ThreegraphsforstandardBitTorrentFigures29,30,and31andthreeforGreenBitTorrentFigures32, 33,and34showtheresultsfromtheexperiment.Thedownloadtimesforthe1st,5th,and10thpeertoenter theswarmasafunctionofinterarrivaltimeareshowninFigures22and32.Awakeandsleeptimeforall peerswithameaninterarrivaltimeof16minareseeninFigures30and33.Figures31and34showthesleep andawaketimeforpeer55overallinterarrivaltimeswiththegrayshowingthesleeptime.Thedifferencein downloadtimesbetweenthestandardandGreenBitTorrentsimulationsforpeers1,5,and10areshownin Table4. 41

PAGE 51

Figure29.DownloadtimeforstandardBitTorrent FromFigures29and32itcanbeseenthat: Themeandownloadtimeforclient#1ishighandfairlyconstantindependentoftheclientinterarrival timeandcase. Themeandownloadtimeforclients#5and#10decreasesastheinterarrivaltimeincreasesforthe standardBitTorrentandGreenBitTorrent. GreenBitTorrenthaslargerledownloadtimesthanstandardBitTorrent.Table4showsthepercentage increaseindownloadtimeforGreenBitTorrentversusstandardBitTorrent. FromFigures30and33itcanbeseenthat: ThereisnosleeptimeforstandardBitTorrent,butthereisconsiderablesleeptimeforGreenBitTorrent. ForstandardBitTorrentthesumoftheawaketimesfortheentireswarmis5.71hours,forgreen BitTorrentitis1.31hours.85hoursisnowspentinsleep.Thisrepresentsanenergysavingsof 74.6%measuredoverallpeers. FromFigures31and34itcanbeseenthat: ThereisnosleeptimeforstandardBitTorrent,butthereisconsiderablesleeptimeforGreenBitTorrent. ForstandardBitTorrentthesumoftheawaketimesforclient#5forallinterarrivaltimesis1.30hours, forGreenBitTorrentitis0.61hours.63hoursisnowspentinsleep.Thisrepresentsanenergy savingsof50.8%measuredoverallinterarrivaltimes. 42

PAGE 52

Figure30.SleeptimeforstandardBitTorrent Figure31.Sleeptimeforpeer5standardBitTorrent Figure32.DownloadtimeforGreenBitTorrent 43

PAGE 53

Figure33.SleeptimeforGreenBitTorrent Figure34.Sleeptimeforpeer5GreenBitTorrent Table4.IncreaseindownloadtimeforGreenBitTorrentcomparedtostandardBitTorrent Meanclientinterarrivaltime Clientnumber 0sec 40sec 120sec 150sec 400sec Client#1 1.4% -0.4% -1.3% -0.8% 0.5% Client#5 1.6% -1.7% -22.1% 0.4% 24.4% Client#10 -0.5% 4.6% 13.7% -8.7% 3.8% Averageforall 1.2% 0.6% -7.1% -1.8% 1.3% 44

PAGE 54

Figure35.DownloadtimeforstandardBitTorrentsimulationvalidation Figure36.SleeptimeforstandardBitTorrentsimulationvalidation 5.2.2.1SimulationValidation Tovalidatethesimulation,simulatedexperimentswererunwiththesameparametersastherealexperiments.Again,threegraphsforstandardBitTorrentFigures35,36,and37andthreeforGreenBitTorrent Figures38,39,and40showtheresultsfromtheexperiment.Thedownloadtimesforthe1st,5th,and10th peertoentertheswarmasafunctionofinterarrivaltimeareshowninFigures22and38.Awakeandsleep timeforallpeerswithameaninterarrivaltimeof16minareseeninFigures36and39.Figures37and40 showthesleepandawaketimeforpeer5overallinterarrivaltimeswiththegrayshowingthesleeptime. 45

PAGE 55

Figure37.Sleeptimeforpeer5standardBitTorrentsimulationvalidation Figure38.DownloadtimeforGreenBitTorrentsimulationvalidation Figure39.SleeptimeforGreenBitTorrentsimulationvalidation 46

PAGE 56

Figure40.Sleeptimeforpeer5GreenBitTorrentsimulationvalidation Table5.Downloadtimeofrealclientversussimulationclient Meanclientinterarrivaltime Clientnumber 0sec 40sec 120sec 150sec 400sec Real/SimulationStandardClient -1.9% -11.2% -18.4% -16.8% -14.1% Real/SimulationGreenClient -5.7% -13.3% -30.7% -26.0% -30.8% 5.2.3DiscussionofResults TheresultsshowthatarealGreenBitTorrentclientiscapableofsignicantenergysavings.Ofquestion iswhetherornottheresultsofthesmallertestbedwillscaleup.Thisquestionisansweredbythevalidation resultsinSection5.2.2.1. Whilethenumbersarenotidenticalbetweenthesimulationandrealexperimentsthisistobeexpected. Therearenumerousvariablesthatcomeintoplayinrealworldexperiments,including,butnotlimitedtothe loadonthemachines,theloadonthenetworkingdevicesconnectingthemachines,andsubtledifferences betweenimplementations.Anyofthesecancauseaswarmthatmightsstartidenticallyinboththesimulation andrealexperimentstoevolveinquiteadifferentfashion.Inparticular,thebandwidthlimiterinthereal clientisnotperfect.Itusesarollingaverageanddelayssendingandrequestingpiecesasopposedtoactually limitingtherateatwhichdataissent.Additionally,thesimulationwasnotedtobehaveinunexpectedways whenpeersweregivenlargeramountsofbandwidth,indicativeofasystematicerror.Thedifferencein downloadtimesbetweenrealandsimulationclientscanbeseeninTable5.Ofnoteisthattherealclient outperformedthesimulationineachcase.Whatisimportant,however,isawideviewoftheresults.The shapeofthegraphsinFigures29through40areallsimilarandthuswhiletheabsolutenumbers 47

PAGE 57

ThesavingsseeninFigures37and40is45.2%,whichisveryclosetothe50.8%savingsseeninFigures31and34.Finally,the70.1%savingsseenforallpeersinthe400secondinterarrivaltimeseenin Figures36and39areagainwellwithin10%ofthe74.6%savingsseeninFigures31and34. 5.3ChapterSummary Thischapterexplainedtheexperimentalsetupdescribingbothsimulationandrealexperiments.Results fortwosetsofexperimentswerediscussed: 1.Asimulationexperimentofaswarmof50peersplus1seedtransferringa1GBle. 2.Arealclientexperimentofaswarmof10peersplus1seedtransferringa100MBle. Theresultsoftheexperimentsindicatedsignicantsavingsupto77.8%inenergywithminimaldownload penaltyaworstcaseof23.0%increaseindownloadtimesonaverage. 48

PAGE 58

Chapter6: SummaryandFutureWork IthasbeenshownthatrelativelysimplechangestoBitTorrentcanachieveamoreenergyefcientoperation-aGreenBitTorrent.Thesechangesallowpeerstosleepwithoutbeingdroppedfrompeerlists. Effectively,TCPconnectionstatehasbeendecoupledfrompeerstate. 6.1GreenBitTorrentEnergySavings GreenBitTorrentwasshowntoconsumelessthan25%oftheenergyasstandardBitTorrentwhereall clientsarefullypowered-on24/7withonlymodestpenaltyinincreaseddownloadtime.Forsmallinterarrival times,ledownloadtimeisincreasedbylessthan10%asseeninTable4.Formediumandlargeinterarrival times,downloadtimeforanindividualpeerisincreasedbyuptoabout25%,buttypicallybymuchlessas seeninTable4.Ofnotehoweveristhatthedifferenceindownloadtimeforallpeerswasbetween-7.0% and1.3%foreachinterarrivaltime.TheoverallenergysavingsachievablewithGreenBitTorrentifclients sleep75%ofthetimecouldbeover$1.6billionperyearintheUSaloneif100millionlesharingunits, eachconsuminga25Wonaverageandassumingaresidentialelectricityrateof$0.10perkWhisassumed. Thislevelofsavingsappearstobefeasiblebasedonthemethodsdevelopedandevaluatedinthispaper. 6.2DirectionsforFutureResearch Whileconsiderableenergysavingshavebeenshown,theimplementationiscurrentlydumb.Peersare onlyawareofthestatesofotherpeersasdescribedinSection3.2.Thisignoresanentiretaxonomyrelated toenergyefciency.Forexample,theenergycostsinvariouslocalesarenotequal,noraretheyproduced inthesamemanner[37].AsmarterGreenBitTorrentclientcouldfavorwakinguppeersthatareusing inexpensiveenergyviachangestothepeerdiscoveryalgorithmdescribedinFigure13.Similiarlyasmarter GreenBitTorrentclientcouldfavorpeersusingexpensiveenergyviachangestothechokingalgorithm allowingthemtonishdownloadsfasterandthusspendlesstimeawake.Figure13couldbealteredtowake peersupbasedonenergycostsbothmonetaryandenvironmental.Thechokingalgorithmcouldbemodied 49

PAGE 59

togiveahigherorderingandthusmorebandwidthandquickerdownloadtimestopeersusingexpensive energysources,thusincludingenergyintheresourceexchangemechanismthatmakesBitTorrentunique. Modicationstothetrackercouldfurtherthegoalofenergysavings.Thetrackerisaprimetargetfor examiningenergyefciencyaspeerslearnoftheexistenceofotherpeersthroughqueriestoit.Thetracker couldeasilybemodiedtoinuencethelocalswarmofanypeerbasedonenergycosts.Forexample,peers utilizingexpensiveenergysourcescouldbefunneledintoconnectingtopeersusingcheapenergysources tominimizeoverallenergyconsumption. Thesefuturedirectionscanprovideabasisforresearchintofuturepeer-to-peercontentdistributionsystems,inparticulartheconceptofenergyasanincentiveforresourcesharingresultinginhighlyscalableand energyefcientcontentdistribution. 50

PAGE 60

References [1]Y.Agarwal,S.Hodges,J.Scott,R.Chandra,P.Bahl,andR.Gupta,AugmentingNetworkInterfaces toReducePCEnergyUsage,tobesubmitted,2008.URL: http://research.microsoft.com/ users/ranveer/docs/somniloquy.pdf [2]Akamai:TheLeaderinWebApplicationAccelerationandPerformanceManagement,StreamingMedia ServicesandContentDelivery,Akamai,2009URL: http://www.akamai.com [3]Almeidaetal.MeasuringthebehaviorofaWorldWideWebserver,TechnicalReport1996-025,Boston University,1996. [4]MagicPacketTechnology,AMD,1998.URL: http://www.amd.com/us-en/assets/ content_type/white_papers_and_tech_docs/20213.pdf [5]G.Anastasi,I.Giannetti,andA.Passarella,ABitTorrentproxyforGreenInternetlesharing:Design andexperimentalevaluation, ComputerCommunications ,Vol.33,No.7,pp.794-802,May2009. [6]iTunesStoreTopMusicRetailerintheUS,Apple,2008.URL: http://www.apple.com/pr/ library/2008/04/03itunes.html [7]Award-WinningMGMFilmsNowontheiTunesStore,Apple,2008.URL: http://www.apple. com/pr/library/2007/04/11itunes.html [8]MacOSXv10.6:AboutWakeonDemand,Apple,2010.URL: http://support.apple.com/ kb/HT3774 [9]L.Barroso,U.H olzle,Thecaseforenergy-proportionalcomputing, Computer ,pp.33-37,2007. [10]S.Bausch,L.Han,U.S.BROADBANDCOMPOSITIONREACHES72PERCENTATHOME,A 15POINTYEAR-OVER-YEARINCREASE,ACCORDINGTONIELSEN//NETRATINGS http: //www.nielsen-online.com/pr/pr_060621.pdf [11]C.Belady,IntheDataCenter,PowerandCoolingCostsMoreThanTheITEquipmentitSupports, ElectronicsCooling ,Vol.13,No.1,2007. [12]BitTornado,URL: http://www.bittornado.com [13]BitTorrent,Inc.2008.URL: http://www.bittorrent.com/ [14]J.Blackburn,K.Christensen,ASimulationStudyofaNewGreenBitTorrent, Proceedingsofthe FirstInternationalWorkshoponGreenCommunicationsinconjunctionwiththeIEEEInternational ConferenceonCommunications, June2009. [15]DataCenterVirtualizationandOrchestration:BusinessandFinancialJustication,CiscoWhitePaper http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6505/ps8463/ prod_white_paper0900aecd8068edfc.pdf [16]B.Cohen,TheBitTorrentProtocolSpecication,Standard,January10,2008.URL: http:// bittorrent.org/beps/bep_0003.html 51

PAGE 61

[17]B.Cohen,IncentivesBuildRobustnessinBitTorrent, WorkshoponEconomicsofPeer-to-PeerSystems, 2003 [18]TC32-TG21-ProxyingSupportforSleepModes,EcmaInternational,2008.URL: http://www. ecma-international.org/memento/TC32-TG21.htm [19]K.Eger,T.Hofeld,A.Binzenh ofer,andG.Kunzmann,EfcientSimulationofLarge-ScaleP2P Networks:Packet-levelvs.Flow-levelSimulations, ProceedingsoftheSecondWorkshoponUseof P2P,GRIDandAgentsfortheDevelopmentofContentNetworks ,pp.9-16,2007. [20]GartnerEstimatesICTIndustryAccountsfor2PercentofGlobalCO2Emissions,GartnerGroup PressRelease,2007.URL: http://www.gartner.com/it/page.jsp?id=503867 [21]S.D.Gribble,E.A.Brewer,Systemdesignissuesforinternetmiddlewareservices:Deductionsfroma largeclienttrace, Proceedingsofthe1997USENIXSymposiumonInternetTechnologiesandSystems 1997. [22]C.Gunaratne,K.Christensen,andB.Nordman,ManagingEnergyConsumptionCostsinDesktopPCs andLANSwitcheswithProxying,SplitTCPConnections,andScalingofLinkSpeed, International JournalofNetworkManagement, Vol.15,No.5,pp.297-310,September/October2005. [23]N.Horowitz,NRDCStudyofSetTopBoxandGameConsolePowerUse, http://www. energystar.gov/ia/partners/prod_development/revisions/downloads/ settop_boxes/NRDC_SetTopBox_Data_IEA.pdf ,May2007. [24]IncreasingDataCenterDensityWhileDrivingDownPowerandCoolingCosts,IntelWhitePaper, 2006.URL: ftp://download.intel.com/design/servers/technologies/thermal. pdf [25]M.Jimeno,K.Christensen,andB.Nordman,ANetworkConnectionProxytoEnableHoststoSleep andSaveEnergy, ProceedingsoftheIEEEInternationalPerformanceComputingandCommunications Conference, pp.101-110,December2008 [26]M.Jimeno,K.Christensen,andA.Roginsky,APowerManagementProxywithaNewBest-of-N BloomFilterDesigntoReduceFalsePositives, ProceedingsoftheInternationalPerformanceComputingandCommunicationsConference, pp.125-133,April2007. [27]M.Jimeno,K.Christensen,APrototypePowerManagementProxyforGnutellaPeer-to-PeerFile Sharing, ProceedingsoftheIEEEConferenceonLocalComputerNetworks pp.210-212,October2007. [28]Johnsonetal.Themeasuredperformanceofcontentdistributionnetworks, ComputerCommunications ,Vol.24,pp.202-206,2001. [29]J.Koomey,EstimatingTotalPowerConsumptionbyServersintheU.S.andtheWorld, Analytics Press ,February2007. [30]Krishnamurthyetal.Ontheuseandperformanceofcontentdistributionnetworks, Proceedingsofthe 1stACMSIGCOMMWorkshoponInternetMeasurement ,pp.169-182,2001. [31]N.Laoutaris,P.Rodriguez,L.Massoulie,ECHOS:edgecapacityhostingoverlaysofnanodatacenters, ACMSIGCOMMComputerCommunicationReview, Vol.38,No.1,pp.51-54,Jan.2008. [32]J.Loper,S.Parr,Energyefciencyindatacenters:Anewpolicyfrontier,AlliancetoSaveEnergy TechnicalReport,2007.URL: http://ase.org/content/article/detail/4071 [33]S.Nedevschi,S.Ratnasamy,andJ.Padhye,HotDataCentersvs.CoolPeers, WorkshoponPower AwareComputingandSystemsHOTPOWER ,2008. 52

PAGE 62

[34]TheNetworkSimulator-ns-2,2008.URL: http://www.isi.edu/nsnam/ns/ [35]P2PResearchInstitute,2008.URL: http://p2presearch.com/ [36]V.N.Padmanabhan,L.Qiu,Thecontentandaccessdynamicsofabusywebsite:Findingsandimplications, ProceedingsofACMSIGCOMM2000 ,pp.111-123,2000. [37]Qureshietal.,Cuttingtheelectricbillforinternet-scalesystems, ACMSIGCOMMComputerCommunicationReview, Vol.39,No.4,pp.123-134,2009 [38]P.Rodriguez,S-M.Tan,andC.Gkantsidis,OntheFeasibilityofCommercial,LegalP2PContent Distribution, ACMSIGCOMMComputerCommunicationReview, Vol.36,No.1,pp.75-78,January 2006. [39]ReporttoCongressonServerandDataCenterEnergyEfciency,PublicLaw109-431,U.S.EnvironmentalProtectionAgencyENERGYSTARProgram,August2,2007. [40]V.Valancius,N.Laoutaris,L.Massoulie,C.Diot,P.Rodriguez,GreeningtheInternetwithNanoData Centers, ProceedingsofACMCoNEXT ,2009. [41]VerizonFIOSInternetPackagesandPrices,2008.URL: http://www22.verizon.com/ content/consumerfios/packages+and+prices/packages+and+prices.htm [42]W.Vota,SpeedyOLPCSuspend/Resume,OneLaptopPerChildNews,October5,2006. URL: http://www.olpcnews.com/software/operating_system/speedy_olpc_ suspend.html [43]VUDU,2008.URL: http://www.vudu.com/ [44]Youtube,YouTubeFactSheet,2009.URL: http://www.youtube.com/t/fact_sheet 53


xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 22 Ka 4500
controlfield tag 007 cr-bnu---uuuuu
008 s2010 flu s 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0003475
035
(OCoLC)
040
FHM
c FHM
049
FHMM
090
XX9999 (Online)
1 100
Blackburn, Jeremy.
0 245
Design and evaluation of a green bittorrent for energy-efficient content distribution
h [electronic resource] /
by Jeremy Blackburn.
260
[Tampa, Fla] :
b University of South Florida,
2010.
500
Title from PDF of title page.
Document formatted into pages; contains X pages.
502
Thesis (M.S.C.S.)--University of South Florida, 2010.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
538
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
3 520
ABSTRACT: IT equipment has been estimated to be responsible for 2% of global CO2 emissions and data centers are responsible for 1.2% of U.S. energy consumption. With the large quantity of high quality digital content available on the Internet the energy demands and environmental impact of the data centers must be addressed. The use of peer-to-peer technologies, such as BitTorrent, to distribute legal content to consumers is actively being explored as a means of reducing both file download times and the energy consumption of data centers. This approach pushes the energy use out of the data centers and into the homes of content consumers (who are also then content distributors). The current BitTorrent protocol requires that clients must be fully powered-on to be participating members in a swarm. In this thesis, an extension to the BitTorrent protocol that utilizes long-lived knowledge of sleeping peers to enable clients to sleep when not actively distributing content yet remain responsive swarm members is developed. New peer states and events required for the protocol extension, the implementation the new protocol in a simulation environment, and the implementation of the protocol extension in a real client are described. Experiments on a simulated swarm of 51 peers transferring a 1 GB and a real swarm of 11 peers transfer- ring a 100 MB file were run. To validate the simulation a simulated swarm of 11 peers transferring a 100 MB file is compared to the real swarm of 11 peers. The results of standard BitTorrent are compared to the new Green BitTorrent by examining download times, sleep time, and awake time. The results of the experiment show significant energy savings are possible with only a small penalty in download time. Energy savings of up to 75% are shown with download time increases as little as 10%. These energy savings could equate to over $1 billion dollars per year in the US alone if Green BitTorrent is used instead of standard BitTorrent for future rollouts of legal distribution systems.
590
Advisor: Ken Christensen, Ph.D.
653
P2P
Peer-to-peer
Data center
Set-top-box
Power management
690
Dissertations, Academic
z USF
x Computer Science and Engineering
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.3475