Towards a User-Oriented Benchmark for Transport Protocols ...

pages

English

Documents

Écrit par
Ludovic Hablot

Publié par
Undu

Lire

Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres

pages

English

Ebook

Lire

Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres

Publié par

Undu

Nombre de lectures

Langue

English

Poids de l'ouvrage

3 Mo

Laboratoire de l’Informatique du Parallélisme
École Normale Supérieure de Lyon
oUnité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL n 5668
Towards a User-Oriented Benchmark for
Transport Protocols Comparison in very High
Speed Networks
Romaric Guillier ,
July 2007Ludovic Hablot ,
Pascale Vicat-Blanc Primet
oResearch Report N 2007-35
École Normale Supérieure de Lyon
46 Allée d’Italie, 69364 Lyon Cedex 07, France
Téléphone : +33(0)4.72.72.80.37
Télécopieur : +33(0)4.72.72.80.80
Adresse électronique : lip@ens-lyon.frTowards a User-Oriented Benchmark for Transport Protocols
Comparison in very High Speed Networks
Romaric Guillier , Ludovic Hablot , Pascale Vicat-Blanc Primet
July 2007
Abstract
Standard TCP faces some performance limitations in very high speed wide
area networks, mainly due to a long end-to-end feedback loop and a conser-
vative behaviour with respect to congestion. Many TCP variants have been
proposed to overcome these limitations. However, TCP is a complex protocol
with many user-conﬁgurable parameters and a range of different implementa-
tions. It is then important to deﬁne measurement methods so that the transport
services and protocols can evolve guided by scientiﬁc principles and compared
quantitatively. The goal of this report is to present some steps towards a user-
oriented benchmark, called ITB, for high speed transport protocols compari-
son. We ﬁrst present and analyse some results reported in the literature. From
this study we identify classes of ...

Voir

Publié par

Undu

Nombre de lectures

Langue

English

Poids de l'ouvrage

3 Mo

Laboratoiredel'InformatiqueduParallélismeÉcoleNormaleSupérieuredeLyonUnitéMixtedeRechercheCNRS-INRIA-ENSLYON-UCBLno5668TowardsaUser-OrientedBenchmarkforTransportProtocolsComparisoninveryHighSpeedNetworksRomaricGuillier,LudovicHablot,PascaleVicat-BlancPrimetJuly2007ResearchReportNo2007-35ÉcoleNormaleSupérieuredeLyon46Alléed'Italie,69364LyonCedex07,FranceTéléphone:+33(0)4.72.72.80.37Télécopieur:+33(0)4.72.72.80.80Adresseélectronique:lip@ens-lyon.fr

TowardsaUser-OrientedBenchmarkforTransportProtocolsComparisoninveryHighSpeedNetworksRomaricGuillier,LudovicHablot,PascaleVicat-BlancPrimetJuly2007AbstractStandardTCPfacessomeperformancelimitationsinveryhighspeedwideareanetworks,mainlyduetoalongend-to-endfeedbackloopandaconser-vativebehaviourwithrespecttocongestion.ManyTCPvariantshavebeenproposedtoovercometheselimitations.However,TCPisacomplexprotocolwithmanyuser-congurableparametersandarangeofdifferentimplementa-tions.Itisthenimportanttodenemeasurementmethodssothatthetransportservicesandprotocolscanevolveguidedbyscienticprinciplesandcomparedquantitatively.Thegoalofthisreportistopresentsomestepstowardsauser-orientedbenchmark,calledITB,forhighspeedtransportprotocolscompari-son.Werstpresentandanalysesomeresultsreportedintheliterature.Fromthisstudyweidentifyclassesofrepresentativeapplicationsandusefulmetrics.Wethenisolateinfrastructureparametersandtrafcfactorswhichinuecnetheprotocolbehaviour.Thisenableustodenescenariocapturingandsynthesis-ingcomprehensiveandusefulproperties.Wenallyillustratethisproposalbypreliminaryresultsobtainedonourexperimentalenvironment,Grid'5000,wehavebuiltandareusingforcontributinginthisbenchmarkdesign.Keywords:ProtocolBenchmark,TCP,Performanceevaluation,HighSpeedtransport,HighSpeednetworksRésumé

LaversionstandarddeTCPestconfrontéeàuncertainnombredelimita-tionsdeperformancedanslesréseauxàtréshautdébitquisontprincipale-mentcauséesparunebouclederétroactiondeboutenbouttroplongueetuncomportementtrèsprudentvis-à-visdelacongestion.UngrandnombredevariantesdeTCPontétéproposépourtenterdesurpasserceslimitations.Ce-pendantTCPestunprotocolecomplexecomportantbeaucoupdeparamêtresdénissablesparl'utilisateuretunéventaild'implémentationsdifférentes.Ilestalorsimportantdedénirdesméthodesdemesureanquelesservicesetlesprotocolesdetransportpuissentévoluerselondesprincipesscientiquesetêtrecomparésquantitativement.Lebutdecerapportestdeprésenterunedémarcheversladénitiond'unbancd'essaiorientéutilisateur,appeléITB,pourlacomparaisondeprotocolesdetransportsdanslesréseauxàhautdébit.Nouscommençonsparprésenteretanalyserquelquesrésultatsprésentdanslalittérature.Apartirdecetteétude,nousidentionsdesclassesreprésenta-tivesd'applicationsetdesmétriquesutiles.Nousisolonsensuitelesparamêtresinfrastructurelsetlesfacteursdetracquiontuneinuencesurlecomporte-mentdesprotocoles.Cecinouspermetdedénirdesscénariospermettantdecaptureretdesynthétiserdespropriétésutilesetcomplètes.Finalement,nousprésentonsdesexemplesderésultatsobtenusdansl'environmentexpérimentalGrid'5000illustrantnotredémarche.Mots-clés:Bancd'essaideprotocoles,TCP,évaluationdeperformances,transporthaut-débit,réseauxhaut-débit2

BenchmarkforTransportProtocols1Contents1Introduction22Relatedwork32.1Transportprotocolsforhighspeednetworks......................32.2Evaluationframeworks.................................42.2.1EvaluationsonRealExperimentalNetworks.................52.2.2EvaluationsonEmulatedNetworks......................52.2.3EvaluationswithNS2simulator........................73DenitionandgoalsofaTransportBenchmarksuite73.1Whatisabenchmark?..................................73.2ExampleoftheNPBanditsusage...........................73.3Guidelinesfortransportprotocolbenchmarking....................84ITB:InriaTransportBenchmarkproposal84.1Representativeapplicationsselection..........................84.2Metrics.........................................94.2.1Metricstypes..................................94.2.2Throughput...................................94.2.3Fairness.....................................104.2.4Efciency....................................104.3Systemparameters...................................104.3.1Topology....................................114.3.2Capacities....................................114.4Workloadparameters..................................114.5Benchmark.......................................124.5.1WMapplicationcharacteristics.........................124.5.2PPapplicationcharacteristics.........................124.5.3BUapplicationcharacteristics.........................134.5.4PAapplicationcharacteristics.........................134.6ITBclassesdenition..................................135Realexperiments155.1Topologyexample....................................155.2TUapplication.....................................165.3BUapplication.....................................165.4PAapplication......................................185.5ITBparameters.....................................185.5.1Problemsize:RTTparameter.........................185.5.2Workloadparameters..............................215.6Metricsconsiderationexample.............................236Conclusion237Acknowledgement24

2R.Guillier,L.Hablot,P.Primet1IntroductionToday,mostdatatransferapplicationsandabout90%oftheInternettrafcusetheTCPprotocol.TCPhasshownagreatscalabilityinnumberofusers,butnotinlinkcapacity.TheTCPperformancecanbeverylowandunstableindata-centerapplications,gridcomputingapplications,interactivecommunicationswithinhighspeedlongdistancenetworksinfrastructureslikebbertohome(FTTH)orlambdagridsenvironments.TheconservativebehaviourofTCPwithrespecttocongestioninIPnetworksisattheheartofthecurrentperformanceissuesfacedbythehigh-performancenetwork-ingcommunity.Severaltheoreticalandexperimentalanalysishaveshownthatthedynamicsofthetraditionalfeedbackbasedapproachistooslowinveryhighspeednetworksthatmaylosepackets.Consequentlynetworkresourceutilisationisnotoptimalandtheapplicationperformanceispoorandmaybedisappointing.Manyhigh-endcomputingapplicationswishtotransferlargevolumesofdataoverwideareanetworksandrequirehighdataratesinordertodoso.However,theseapplicationsarerarelyabletotakefulladvantageofthehigh-capacity(2.5Gbps,10Gbpsandupwards)networksinstalledtoday.DatafromInternet2showthat90%ofthebulkTCPows(denedastransfersofatleast10MBofdata)uselessthan5Mbps,andthat99%uselessthan20Mbpsoutofthepossible622Mbpsprovision.Therearemanyreasonsforsuchpoorperformance.Manyoftheproblemsaredirectlyrelatedtotheendsystem,totheprocessorandbusspeed,andtotheNICwithitsassociateddriver.TCPconguration(e.g.smallbufferspace)hasalsoasignicantimpact.Butwhentheseproblemsarexed,thecongestioncontrolalgorithmisoneofthekeycomponentwhichhastobemodiedtoalleviatetheperformanceprobleminhighspeedlongdistancenetworksenvironments.Congestioncontrolisthemostimportantandcomplexpartofatransportprotocolinpacketswitchsharednetwork.TCPprovidesafullydistributedcongestioncontrolprotocolwhichstatisticallyshareavailablebandwidthamongowsfairly.TCPwasdesignedrstandforemsottoberobustandwhencongestionisdetected,TCPsolvestheproblembutattheexpenseofperformance.Forexample,forastandardTCPconnectionwith1500-bytepacketsanda100msround-triptime,achievingasteady-statethroughputof10Gbpswouldrequireanaveragecongestionwindowof83,333segments,andapacketdroprateofatmostonecongestioneventevery5,000,000,000packets(orequivalently,atmostonecongestioneventevery12/3hours).Tosolvethisproblemseveralprotocolsenhancementshavebeenproposed[WHVBPa05,SL04,XHR04].Alltheseprotocolsarenotequivalentandnotsuitedforallenvironments.SomeoftheprotocolstargetinghighspeedInternet,attempttoimproveTCPresponsefunctionwhiletryingtoretainmaximumbackwardscompatibilitywithlegacyimplementations.Othersfocusondifferenttargetenvironments,forexamplededicatedopticalnetworks.TheyarelessconservativeandtheycanbeimplementedinuserspaceandoverUDP.Sinceacoupleofyears,theevaluationandcomparisonoftheseprotocolsreceiveanincreasingamountofinterest.However,TCPandotheralternativesarecomplexprotocolswithmanyuser-congurableparametersandarangeofdifferentimplementations.Severalaspectscanbestudiedandvarioustestingmethodsexist.Theresearchcommunity1recogniseitisimportanttodeploymeasure-mentmethodssothatthetransportservicesandprotocolscanevolveguidedbyscienticprinciples.Researchersanddevelopersneedagreed-uponmetrics-acommonlanguageforcommunicatingre-sults,sothatalternativeimplementationscanbecomparedquantitatively.Usersofthesevariantsneedperformanceparametersthatdescribeprotocolcapabilitiessothattheycandevelopandtunetheirapplications.Protocoldesignersneedexamplesofhowuserswillexercisetheirservicetoimprovethedesign.Thegoalofthisreportisthentocontributetothiseffortandpresentsomestepstowardsa1Seattleworkshop,February2007

BenchmarkforTransportProtocols3user-orientedbenchmarkdesignforhighspeedtransportprotocolscomparison.Therestofthereportisorganisedasfollows.RelatedworksandongoingeffortsarereviewedinSection2.Section3denesthenotionofbenchmarkandintroducesafewexamplesofsuchtools.Section4introducesthemetrics,parametersandmeasurementmethodsconstitutingourbench-markpropositionfortransportprotocols.Section5illustratesthisproposalwithpreliminaryresultsobtainedonourexperimentalenvironment,Grid'5000,wehavebuiltandareusingforcontributinginthisbenchmarkdesign.Finally,weconcludeinSection6andproposesomeperspectivesforprotocolandnetworkserviceenhancement.2RelatedworkHighSpeedtransportprotocoldesignandevaluationisahotresearchtopic[VBTK06].WerstoverviewandclassifyproposedalternativestoTCPandthensurveyseveraleffortstowardsasystem-aticevaluationoftheseproposals.2.1TransportprotocolsforhighspeednetworksTherecentalternativestoTCP,dedicatedtohighspeedInternet,aimatsolvingtheproblemofthepoorresponsefunctionofTCPinlargebandwidth-delayproductnetworksbymodifyingtheparameters,αfortheincreaseandβforthedecrease,oftheAdditiveIncreaseMultiplicativeDecrease(AIMD)algorithmthatisusedduringthecongestionavoidancephaseofTCP.ForexampleHighSpeedTCP[Flo03]andScalableTCP[Kel03]increasetheaggressivenessinhigh-performancecontextswhiletryingtostayfairtostandardTCPowsinlegacycontexts.Table2summarisestheAIMDvaluesthatareusedbydifferentTCPvariants.In[PFTK98],Padhyeetal.presentasimpleTCPmodeltoexpressthethroughputasafunctionoftheRTT,segmentsize,AIMDconstantsandlossprobability:qMSSq(1)RTT∗23p+RTO∗338pp(1+32p2)3SSMthatcanbereducedtorR=RTT2p(2)ifweassumethatthelossrateissmall(typicallythecaseintheopticalnetworksthatformsthebackboneofmostgrids/datacenters).ThesamekindofapproachhasbeenmadeforthenewTCPvariants[Xu07]andsimilarexpressionsexist.Table1providesanapproximatevalueofthecanddparametersconsideringthatalltheformulaareintheformcSSMR=RTTpd(3).H-TCPissupposed[SL04]tohavethesameresponsefunctionasHighSpeedTCP.CUBICisnotincludedintheTable1asitsresponsefunctiondoesn'ttintheformula.BychoiceoftheAIMDconstants,ithasthesameresponsefunctionasTCPRenoforasmallcongestionepoch/BDPvaluetoensureitsfairnesswithrespecttothisprotocol.TheseresponsefunctionsprovideaninsightoftherelativeperformanceofeachTCPvariantsforagivenBDPvalue,butthismodeldoesn'tcaptureanumberofcharacteristicsofrealnetworkslikereversetrafcormultiplexing.ManyoftheseTCP

4TCPvariantcdTCPReno1.220.5BIC15.50.5HighSpeedTCP0.120.835Scalable0.081.0R.Guillier,L.Hablot,P.PrimetTable1:TCPvariants'responsefunctionparametersTCPvariantαβTCPReno121BIC1orbin.search81CUBICcub(cwnd,history)51HighSpeedTCPinc(cwnd)decr(cwnd)HamiltonTCPf(lastloss)1−RRTTTTmmainxScalableTCP0.01∗cwnd81Table2:TCPvariants'AIMDconstantsvariantsareavailableinallrecentLinuxkernel:HighSpeedTCP[Flo03],ScalableTCP[Kel03],Hamilton-TCP[SL04],BIC[XHR04],CUBIC[RX05]andtheycanbeusedbyeveryone.TCPVegas[BOP94]andFAST-TCP[DXWH07]useothercongestioninformationavailable(round-triptimevariations,ExplicitCongestionNotication,etc)toregulatethroughputatthesenderendandthusnelycontrolbufferllinginrouters,managingIPcongestinooptimally.XCPgoesfurtherfromtoday'sstandards,proposinganewcooperativecongestioncontrolschemefeaturingaprecisecongestionwindowindicationgoingfromrouterstoendhosts.UDT,aUDP-basedDataTransferprotocol[GG07]addresstheproblemoftransferringlargevol-umetricdatasetsoverhighbandwidth-delayproductopticalnetworks.LikesomeTCPvariantssuchas[XHR04],UDTemploysanewwindow-basedcongestioncontrolalgorithmtargetingatuncon-trolledsharednetworks.2.2EvaluationframeworksSinceacoupleofyearsseveralteamsaimatdevelopingmethodologiesandtoolsprovidingcompre-hensivestandards-compliancetestingofTCPimplementations.Inthissection,wepresentinitiativesfocusingonTCPvariantevaluation.Varioustestingmethodsexisttoevaluatetransportprotocolper-formance:realInternet,realexperimentalnetworks,emulatednetworks,simulation.Eachonehasitspitfalls.Amixofseveralmethodsishighlyrequiredtoproduceconvincingresults[All99].Toourknowledge,therealInternet,throughthePlanetlabtestbedforexample,hasnotbeenemployedtoevaluateextensivelythenewTCPvariants.Severalmethodologiesandresultshavebeenproposedby[LLS06,Flo06,HLRX06]toidentifycharacteristicsanddescribewhichaspectofevaluationsce-nariodeterminethesecharacteristicsandhowtheycanaffecttheresultsoftheexperiments.Thenextsectionscomparerelatedworksaccordingtothetypeofmethodtheyhaveadopted.

BenchmarkforTransportProtocols52.2.1EvaluationsonRealExperimentalNetworksFewrealexperimentshavebeenran[CAK+05,LLS06]toanalysethebehaviourofarangeofnewprotocolsinhighspeedInternetcontext.Otherrecentworkfocusonsharedhighspeednetworksdedicatedtohighperformancedistributedapplications[GHK+07,GSP07,GHK+06].Therealex-perimentmethodgivesarealinsightoftheprotocolbehaviourinveryhighspeedenvironment(e.g.10Gbps),explorestheinteractionswiththehardwareinfrastructureandgenerallyhelpstodebugtheglobalhardwareandsoftwarecommunicationchain.Wan-In-LabWan-In-Lab[GSLL07]isatestbedoftheCaliforniaInstituteoftechnology.Itisbuiltarounda2400kmopticbbercableandarraysofopticalswitchestoconstructnetworkswithvariablelengthandRTT.Itisaccessibletousersthroughawebinterface.Thisinterfaceallowsuserstouploadexperimentalkernels,instrumentedwiththeWeb100tools,andtorunasetofpredenedtests.Theresultsofthesetestsarethenprocessedandplacedonthewebinbothgraphicalandnumericalform.ProtocolsaretestedforRTTfairness,convergencespeedbothwithandwithoutexistinglargeows,interactionwithshortows,andfairnessbetweenowstraversingdiffreentnumbersofhops.Theyareconsideringarangeofexperimentscombiningatopologyandsomenetworkingcondi-tionstostudyinterestingcases2.Themaininterestofthistestbedisthepossibilitytoperformrealexperimentsusingreallinks(1to10Gbpsspeed)andopticalswitchesandtohaveaccesstoahugerangeofRTTs(from0to180mswith2msincrements)byconguringtheopticalswitches.Grid5000Grid'5000project[BCC+06],isanexperimentalgridplatformgathering2500proces-sorsoverninegeographicallydistributedsitesinFrance.Thenetworkinfrastructureisanintercon-nectionofLANs(i.e.gridsites)andan10Gbpsopticalvirtualprivatenetwork(VPN).AsimpliedtopologyisshowninFigure1.TheparticularityofthistestbedistoprovideresearcherswithafullyrecongurabilityfeaturetodynamicallydeployanyOSimageorTCPstackonanyendhostofthetestbedandwithafullydedicatedopticalnetwork.ThistestbedhasbeenusedforexperimentingdifferentTCPstacksandseveraltypesofworkloadcorrespondingtorealisticgridcomputinganddata-centerapplications[GHK+07,GSP07].Internet-liketrafccanalsobeinjectedinthistestbed.2.2.2EvaluationsonEmulatedNetworksDeploymentofrealnetworksiscostlyandexperimentscanbetimeconsuming.Moreover,suchtestbedshardlyproviderangeoflatenciestofullyexploreprotocolbehaviour.Forthesereasons,severalteamsadoptemulationmethodbyusingsoftwareorhardwarenetworkemulators.HamiltonUniversityframeworkWiththeirlatestexperimentsonTCP[LLS06],DoughLeithetal.presentanexperimentaltest-bed,basedaroundtheDummynet[Riz97]networkemulator.ThegoalistostudytheperformanceofvariousTCPvariantsandtoproposeofaseriesofbenchmarktestseasilyreproducible.ThetopologyusedisaclassicaldumbbellwithaDummynetrouterinthemiddletoemulatelatencyandtosetqueuesizeandbottleneckspeedAsetofscripts3,alongwiththeresultsofalargequantityofexperimentswithgraphsaremadeavailable.Theyareconsideringawiderangeofparametersincluding:queuesize,bottlenecksize,2http://wil.cs.caltech.edu/mwiki/index.php?title=Experiments3workingwithTCP-Linux[WC06],aNS-2patchtouseGNU/LinuxTCPcongestioncontrolalgorithmmodulestoperformexperiments

610 GbE Links 1 GbE LinksLilleOrsayNancyRennesR.Guillier,L.Hablot,P.PrimetnoyLGrenobleBordeauxToulouseSophiaFigure1:Grid'5000backboneRTT(16,22,42,82,162ms),asymmetricRTT,TCPvariantsandnumberofwebsessions.Theavailabletestsweredonewithtwoowsandamaxbottlenecksizeof250Mbps.NorthCarolinaStateUniversityframeworkFortheexperiments[HLRX06]andvalidationoftheirTCPvariants4,InjongRheeetal.useatestbedalsobasedonDummynet.TwoDummynetroutersareused,onetomanagetheAQMandthebandwidthlimitation,thesecondtoadddelay,formingadumbbelltopology.Thechoiceofthistopologyismotivatedbythefactthatevenamorecomplicatedtopologylikeaparkinglotfailstocapturetherealismofproductionnetworks.Thebottleneckisxedto400MbpsandtheRTTvaluesusedare16,64,162and324ms.Twokindsofbackgroundtrafcmaybeinjected:short-livedandlonglived.Theshort-livedtrafcisgeneratedwithacustomversionoftheSURGE[BC98]webtrafcgeneratorfollowing5differentkindoftrafcdistribution.Thelong-livedtrafcisgeneratedusingiperf.Theamountofbackgroundtrafcissettobeabout70Mbps(lessthan20%ofthebottleneckcapacity).Thebasicscenarioconsistsinmonitoringtheinteractionsoftwoowswhentheyareinteractingwithvariouslevelsofbackgroundtrafc.AIST-INRIAframeworkTheAISTandINRIAteamsusehardwareemulatorscombinedwithnet-workvirtualisationsoftwareeWANtoevaluateprotocolsunderdifferentlatencyandtopologycon-ditions[PTK+06].AIST-GtrcNET-10isahardwareemulatorthatallowslatencyemulationupto858mswithoutlosses,ratelimitationandprecisebandwidthmeasurementsat10Gbpswirespeed.GtrcNET-10p3isafullyprogrammablenetworktestbed,whichisa10Gbpssuccessorofawell-establishednetworktestbed,GtrcNET-1.4BICandCUBICTCP

BenchmarkforTransportProtocols72.2.3EvaluationswithNS2simulatorTMRGNS-2frameworkIntheIRTFdraft[NS207],WeiandFloydproposeaframeworkofbenchmarkingTCPvariantsbasedontheNS2networkemulator.Itdenestopologies,trafcchargesandmetricsthatcouldbeusedtoevaluatetheperformanceofTCPstacks.Currently,threetopologiesareconsidered:dumbbell(onebottleneck),parking-lot(multiplebot-tleneck)withcrosstrafcandasimplenetworktopologywithtransitandsbtudomains.Fourkindoftrafcmodelsareproposed:FTPtrafc(long-livedows),Webtrfac(short-livedows),videostreamingtrafc(CBRtrafcoverUDP)andvoicetrafc(CBRorON/OFFows).MetricsdenedintheTRMG'smetricsdraft[Flo07]areconsidered:throughput,queueingdelay,jitter,lossrate,responsetime,fairness,convergenceandrobustness.Eachkindofmetricsisadaptedtothetraf-cmodelitiscurrentlytryingtomeasure.Astheyaredescribingaframework,theydon'tprovideexplicitscenariithatmightbeinterestingtorun.PolitecnicodiBaristudiesMascoloin[MV06]isusingNS-2simulationstoobservetheimpactofreversetrafconthenewTCPcongestioncontrolalgorithms.Thetestbedisbasedonadumbbelltopologywithatmost6differentsources/destinations.Thebottlenecksizeis250Mbpsandisalsosharedbytwonetworkstransmittingwebtrafc.Heismainlyfocusingontheproleoftheworkloadsthatareappliedtothesystem(on/offreversetrafc,reversetrafc+webtrafc,reversetrafc+webtrafc+differentRTTs).HeisusingthefollowingRTTsvalues:40,80and160ms.Themetricsusedtoanalysetheresultsaremainlylinkutilisation,goodput,congestionwindowsizeandtimeoutsevents.Thisshortoverviewshowsthatsoftwaretestbeds(simulatorsoremulators)enablecomplextopolo-gies,largenumberofowsexperimentsbutthebottleneckcapacityislimitedto400Mbpsandthelatenciesto400ms.Hardware-basedtestbedsgiveresearchersaccessto10Gbpsandupto800mslatenciesbutpresentsomelimitationintopologiescomplexity.3DenitionandgoalsofaTransportBenchmarksuite3.1Whatisabenchmark?Abenchmarkisaprogramorasetofprograms,whichcalculatetherelativeperformanceofamachineoranarchitecture(hardware),oranotherprogram(software).Eachbenchmarkmayeitherfocusonquantity(executionspeed,amountofdatacomputed,etc.)oronquality(robustness,security,etc.).Benchmarkcanbeexecutedattwodifferentlevels:•lowlevelormicrobenchmarks:Testingtheperformanceofoneparticularcomponentorfunc-.noit•applicationlevel:Aimingatrepresentingtypicalapplications/workloadsofaplatformthatneedsevaluation.AmongtheexistingHighPerformanceComputing(HPC)benchmarks,theNASParallelBenchmark(NPB)[FY02]iswellknown.Thissetofprogramsrepresentsthetypicalapplicationsclassesexecutedonclusters.3.2ExampleoftheNPBanditsusage(InBTH,PCCG,,thEeP,NFPTB,I[SF,YL0U2,]iMsGaacnodmSmPo)ntlhyatusgeidvebseancghomodarpk.anTelheofNthPeBdiisffaergernotupparoaflleeilgahtppplriocagtriaomnss

Voir