servicepiggycase

ExplicitTransportErrorNotification(ETEN)forError-ProneWirelessandSatelliteNetworks–Summary_-ERajeshKrishnan,MarkAllman,CraigPartridge,andJamesP.
G.
SterbenzBBNTechnologiesWilliam.
IvancicGlennResearchCenterAbstract—ThispaperisasummaryoftheBBNTechnicalReportNo.
8333,"ExplicitTransportErrorNotificationforError-ProneWirelessandSatelliteNetworks.
"InthisstudywediscusstwotypesofExplicitTransportErrorNotification(ETEN)mechanisms:(i)per-packetmechanismsthatnotifyendpointsofeachdetectedcorruption;and(ii)cumulativemechanismsthatnotifyendpointsofaggregatecorruptionstatistics.
Wehaveimplementedtheproposedmechanismsinthens-2simulator.
WepresentsimulationresultsonperformancegainsachievableforTCPRenoandTCPSACK,usingETENmechanismsoverawiderangeofbiterrorratesandtrafficconditions.
WecompareTCPRenoandTCPSACKenhancedwithETENmechanismsagainstTCPWestwood,whichusesabandwidthestimationstrategyinplaceofthetraditionalAIMDcongestionavoidancealgorithm.
WediscusstwoissuesrelatedtothepracticaldeploymentofETENmechanisms:corruptiondetectionmechanisms(andtheirco-operationwithETEN-basedrecoveryinthetransportlayer)andsecurityaspects.
Weincluderecommendationsforfurtherwork.
IndexTerms—CongestionControl,ExplicitTransportErrorNotification,Internet,Protocols,Satellite,TCP/IPI.
BACKGROUNDNASAisworkingtoextendtheInternetintospaceinordertoimprovecommunications,enablenewsystemcapabilitiesandreduceoverallmissioncosts.
Assuch,NASAisinterestedinleveragingtechnologiesdevelopedbythecommercialcommunicationindustry.
Inparticular,NASAisinterestedinutilizingcommodityprotocols,theTCP/IPprotocolsuite,whereverpossible.
NASAcommissionedBBNTechnologiestoinvestigatethepotentialnetworkperformancebenefitsofETENandthepracticalissuesinvolvedinimplementinganddeployingETEN.
ThispaperisasummaryoftheBBNTechnicalReportNo.
8333,"ExplicitTransportErrorNotificationforError-ProneWirelessandSatelliteNetworks.
"II.
INTRODUCTIONOneobstacletogoodperformanceofinternetworkswithwirelessandsatellitecomponentsisnon-negligiblebit-errorrates(BER).
ThemostwidelyusedtransportprotocolintheTCP/IPsuite,thetransmissionControlProtocol(TCP)[1],guaranteesthatcorrupteddatawillberetransmittedbythedatasender,henceprovidingareliablebyte-streamtoapplications.
However,packetlossisalsousedbyTCPtodeterminethelevelofcongestioninthenetwork[2]–astraditionally,thebulkofpacketlossinnetworkscomesfromrouterqueueoverflow(i.
e.
congestion).
Therefore,toavoidcongestioncollapseTCPrespondstopacketlossbydecreasingthecongestionwindow[2][3],andthereforethesendingrate.
Thereductionofthecongestionwindowisnotneededtoprotectnetworkstabilityinthecasewhenlossesarecausedbycorruptionandthereforetheseneedlessreductionsinthesendingratehaveanegativeimpactonperformancewithlittleoverallbenefittothenetwork.
IftheTCPsendercandistinguishpacketslostduetocongestionfrompacketslostduetoerrors,betterperformancemaybeachieved.
TheperformancebenefitcanberealizedifTCPcanretransmitapacketlostduetocorruptionwithoutneedlesslyreducingthetransmissionrate,whilecontinuingtoprotectnetworkstabilitybydecreasingthesendingratewhenlossiscausedbynetworkcongestion.
TCPExplicitTransportErrorNotification(ETEN)istheconceptofnotifyingTCPthatpacketswerelostduetocorruption1.
ETENmechanismscanaidTCPindistinguishingpacketsthatarelostduetocongestionfromonesthatarelostduetocorruption.
Thepurposeofthisstudyistwo-fold:1.
ToestablishboundsontheperformanceimprovementsthatcanbeobtainedwiththeuseofidealETENmechanismsunderdifferentnetworkconditions–errorrates,capacities,delays,topologies,congestion–andtherebydeterminepromisingdirectionsforfutureresearch,ifany.
2.
ToconsiderissuesrelatedtopracticaldeploymentofETENmechanisms,toproposesuitablearchitecturesandmechanisms,toidentifysecurityvulnerabilities,andtoidentifyareasthatrequirefurtherstudybeforeanETENsystemisviable.
Throughsimulations,wehaveevaluatedpossibleenhancementstoTCPthatarebasedonETENnotificationsfromintermediateroutersand/orendsystems.
Emulationsinatestbedandlivetestingoverrealnetworkswereconsideredoutofscopeofthiseffort.
Thisstudyincludedthefollowingtasks:DetermineboundsonTCPgoodputimprovementspossiblefromETENwhenaTCPsenderispresentedwithidealinformationaboutthecauseofeachloss.
Evaluateviasimulations,actualperformanceachievableoverarangeofnetworktopologiesandtrafficconditionswithdifferentTCPvariantssuchasRenoandSACK.
DiscussandevaluatetheperformanceofspecificETENmechanismsthatfallinoneormoreofthefollowingbroadcategories:oForwardnotification–wherebyanynotificationaboutcorruptedpacketsissentinthedirectionofthedatapacketsandthenreturnedtothesenderinTCPacknowledgmentsegments.
oBackwardnotification–inwhichamessageissentfromthenode(end-hostorintermediaterouter)thatdetectsa1ETENissimlartoExplicitCongestionNotification(ECN).
InECN,TCPcanbeinformedoftheonsetofcongestionandadjustitstransmissionsaccordinglytherebyimprovingoverallperformance.
corruptedpackettothehostthatoriginatedthepacket.
Per-packetmechanismsthatattempttodeterminetherootcauseofeachlossexperienced.
AggregatenotificationschemeswheretheTCPsenderisprovidedwithaggregatestatisticsaboutthelosspatternsexperiencedinthenetworkpath.
DeterminehowTCPshouldbestreactuponreceivingETENnotification.
AssessthesecurityimplicationsofintroducingvariousETENmechanismsintotheInternetarchitecture.
Theseinclude:oPotentialvulnerabilitiesoftheproposedmechanismstodistributeddenial-of-serviceattacks.
oOperationoverencryptedtunnels,VPNs,andMPLSpaths,whereintermediatenodesmaynotbeabletodetermineactualsourceordestinationIPaddressesandports,makingETENnotificationeffectivelyimpossible.
oVulnerabilitiestomisbehavingreceiversthatattempttomaskcongestion-relatedlossesusingETENmechanismsinanattempttoobtainanunfairshareofnetworkresources.
III.
ERRORNOTIFICATIONANDRESPONSEMECHANISMSFortheETENmechanismsproposedinthisreportweassumeoneofthefollowingtwocasesholds:1.
ThesourceanddestinationIPaddresses,thesourceanddestinationTCPports,andtheTCPsequencenumbercanbecorrectlyobtainedfromthecorruptedpacket.
Inaddition,thepacketinquestionmustbepartofthesender'scurrentwindow;otherwise,theopportunitytomitigatetheperformanceproblemscausedbythecorruptedpacketislost.
Forthiscase,Oracle,BackwardandForwardETENwereconsideredwithOracleandBackwardETENsimulated.
2.
Thenodedetectingerrorscanonlycalculatecumulativeerrorratesforeachlink.
Inotherwords,theinformationintheheaderofacorruptedpacketisconsideredinaccurate.
BothForwardandBackwardCumulativeETENwereconsideredforthiscasewithonlyForwardCETEN(FCETEN)simulated.
IV.
ORACLEETENOracleETEN,illustratedinFigure1,isatheoreticalconstructthatassumessufficientknowledgeaboutthecorruptedpacket(senderanddestinationIPaddresses,senderanddestinationTCPportnumbers,andtheTCPsequencenumber)isavailabletotheintermediaterouterortheend-systemthatdetectscorruption.
Furthermore,thismechanismassumesthatthesourceoftheflowcanbeinstantaneouslynotifiedofthepacketcorruption.
OracleETENprovidesanupperboundontheperformanceimprovementachievablebyETENmechanismsthatnotifythesource.
WhiletheOracleETENmechanismisanimpossibilityintherealworld,itcanbeusedtodistinguishbetweencasesinwhichsomeETENmechanismwouldbeusefulandcaseswhennoETENschemewouldaidperformance.
Figure1-OracleETENV.
BACKWARDETENThebackwardETEN(BETEN)mechanism,illustratedinFigure2,isanalogoustobackwardexplicitcongestionnotificationschemes(e.
g.
,source-quench[4]).
Thismechanismassumesthattheintermediateroutercanextractorreconstruct(e.
g.
,usingFEC)sufficientknowledgeaboutthecorruptedpacketthatisrequiredtonotifythesender.
Figure2-BackwardETENVI.
FORWARDETENTheforwardETEN(FETEN)mechanismillustratedinFigure3isanalogoustoforwardexplicitcongestionnotificationschemes(e.
g.
,[6][7]).
Thismechanismalsoassumesthattheintermediateroutercanextract(orreconstructusingFEC)completeandcorrectknowledgeoftheIPaddresses,TCPports,andTCPsequencenumbercorrespondingtothecorruptedpacket.
Upondetectionofacorruptedpacket,theintermediateroutertransmitsaFETENmessagetothedestinationhost,whichthenconveystheinformationtothesenderonasubsequentacknowledgment.
Figure3-ForewardETENVII.
CUMULATIVEETENInpractice,wecannotalwaysaccuratelyretrievethesourceanddestinationIPaddress,sourceanddestinationTCPportnumbers,andTCPsequencenumberfromacorruptedpacketorlink-layerframe.
ForsuchcasesweconsiderETENmechanismsthatworkonthebasisofcumulativeerrorrates(forexample,errorratesthatareaveragedoveranintervaloftimeandacrossvariousflows),ratherthanattemptingtomakenotificationsonaper-packetbasis.
ThecumulativeETEN(CETEN)informationconveyedtotheend-hostscanbeinoneofseveraldifferentforms:Anabsolutebiterrorrate,byteerrorrate,orpacketerrorrateobservedwithinamovingwindowintime.
Theerrorratemaybequantizedintoasmallnumberofsteps(forexample,high,medium,andlow).
Abinaryfeedbackscheme[7](seealso[5][6])isaspecialcasethatprovidesindicationthatthebit/byte/packeterrorrateexceedssomethreshold.
Arelativeerrorratethatsimplyindicatesthatthequantizederrorratehasincreasedordecreasedfromthepreviousvalue.
Anestimateoftheprobabilitythatapacketsurvivescorruption.
CETENinformationcanbedeliveredtoasenderviaforwardorbackwardsignaling,analogoustoaFETEN-basedoraBETEN-basedstrategy.
Also,CETENcanbepiggybackedondataandacknowledgmentpackets,ratherthanusingadditionaldistinctmessages.
CETENinformationcanbecollectedonaper-hopbasisoraggregatedovertheend-to-endpath.
Duetothedifficultyincorrectlyassigningcorruptedpacketstotheircorrespondingflows,anyper-flowCETENinformationhastobeestimated,forexamplefromwhatisobservedacrossallflowsusingagivenlink.
CETENstrategiesthatrelypurelyonstatisticscollectedwithinthelifetimeofaparticularflowareoflimiteduseforshortflows.
Forexample,ashortflowmayhaveterminatedbeforeweobtainagoodestimateofthepacketcorruptionprobability.
VIII.
SENDERRESPONSETOETENThesender'sresponsetoanETENnotificationdependsonthetypeofthenotification.
IfthesenderreceivestimelyandreliableinformationaboutthecorruptedpacketthatidentifiestheTCPflowandthesequencenumberwithintheflow,thenthesendercanretransmitthecorruptedpacketwithoutadjustingthecongestionstate.
However,iftheinformationcontainedintheETENnotificationisonlypartiallyreliable,orifonlyacumulativeerrorrateisavailable,thenthesenderhastoapplyaheuristictodeterminewhatactionisappropriate.
Whenatransportendpointinfersapacketloss,itcannotexactlydeterminefromtheCETENinformationifthepacketlossoccurredduetocorruptionorcongestion.
Atbest,theCETENinformationprovidesarecentestimateofthefractionofthelossesthatareduetocorruption.
Thedecisiontobemadebythesenderincludeswhetheranoutstandingsegmentshouldberetransmittedandwhetherthecongestionstateshouldbealteredinresponse.
SincemostlinkleveltechnologiesrequirecorruptedpacketstobediscardedevenbeforeitreachestheIPlayer,per-packetETENmechanisms(attheIPandTCPlayers)cannotseethecorruptedpackets.
Althoughthesenderresponsetoper-packetETENismorestraightforwardthantheresponsetoCETEN,itmustbenotedthatthecorruptionlinklayercountersoferrorsarereadilyavailable;thesecounterscanbeusedtogenerateCETEN.
IX.
PERFORMANCEOFETENMECHANISMSInthissection,wedescriberesultsofsimulationsontheperformanceofOracleETEN,BETENandFCETEN.
Varioustypesoflinks(e.
g.
,terrestrialLAN,WAN,andsatellite),modeledbytheirrespectivelatencies,aresimulatedoverawiderangeofbiterrorrates.
ETENperformanceiscomparedagainstconventionalReno[2]andSACK[8]variantsofTCP.
EachsimulationconsistsofabulkTCPflow(FTPapplication)of120secondsdurationwithunlimiteddatatosend.
TheactualvaluesandvariablerangesusedinthestudyarelistedinTable1.
Allsimulationswereperformedusingthens-2simulator[9](version2.
1b7a)withextensions.
Table1-ParametersValuesOracleETENrepresentstheideal,yetimpossible,baselinethatprovidesanupperboundontheperformanceachievablebyanypracticalper-packetETENscheme.
OnedesigngoalisthattheadditionofanyETENscheme(toanygivenTCPcongestionavoidancestrategy)shouldnotmaketheperformanceworse;therefore,thecasewithnoETENisexpectedtoprovideausefullowerbound(and,thisisshowninoursimulationresults).
TheBETENstrategyrepresentsanimplementableper-packetETENstrategy(assumingthatwecanextractsufficientinformationfromcorruptedpackets).
Intheabsenceofcongestion,wecanexpectthatthegoodputwhenusingBETENwillliebetweenthegoodputsusingOracleETENandnoETEN.
TheCETENstrategyrepresentsanimplementablecumulativeETENstrategythatispotentiallymorerobustintermsofsecuritythanper-packetETENstrategies,buttheoreticallyprovideslessperformancegains.
InourstrategytheCETENflowsintheforwarddirectionandgetscopiedoverontotheacknowledgmentsgoingback.
Weconsidereightsetsofsimulations,asfollows:A.
Baseline–nocrosstrafficoverasingle-hoptopologyThissetofsimulationsisaimedatevaluatingthegainspossibleoverasingleuncongestedlinkusingOracleETENandBETENwithTCPRenoandTCPSACK.
B.
Multi-hoptopologywithnocross-trafficInthissetofsimulations,weusea3-hoplineartopologyofidenticallinks,whilevaryingtheotherparametersoutlinedabove.
Thesesimulationsservethepurposeofvalidatingourimplementationinamorecomplextopologywithmultiplelinksandrouters.
Theresultsareexpectedtomatchthoseofthefirstset.
C.
Multi-hoptopologywithcompetingUDPflows:Inthissetofsimulations,weusea3-hoplineartopologytoprovideinsightintotheperformanceofETENmechanismsinthefaceofcongestionfromconstant-bit-rateUDPtraffic.
Theintensityofcross-trafficisvariedacrosssimulationruns.
Thecompetingtrafficinthesesimulationsdoesnotuseacongestionavoidancestrategy.
D.
Multi-hoptopologywithcompetingTCPflows:ThissetofsimulationsofferscompetingTCPtraffic(insteadofUDPtraffic)andisotherwiseidenticaltothethirdset.
ThisprovidesinsightintotheperformanceofETENwhenthecompetingtrafficflowsalsouseacongestionavoidancestrategy.
E.
ComparisonofETENtoTCPWestwood:ThissetofsimulationsprovidesperformancecomparisonofourETENmechanismswithTCPWestwood[10]intheabsenceofcrosstraffic.
RecentlyproposedmodificationstoTCPcongestionavoidanceincludeusingbandwidthestimationtechniques.
TCPWestwood[10]isarepresentativecongestionavoidancestrategybasedonbandwidthestimation.
TCPWestwoodhasbeenshowntoperformwellunderhigherrorratesinsimulatedcomparisonstoTCPRenoandSACKTCP.
Here,wecompareviasimulationstheperformanceofETENwithRenoandSACKagainstTCPWestwood.
F.
ComparisonofETENtoTCPWestwoodwithUDPcross-traffic:ThissetofsimulationsprovidesperformancecomparisonofourETENmechanismswithTCPWestwood[10]inthepresenceofcrosstraffic.
G.
CumulativeETENperformancewithUDPcrosstraffic:Inthissetofsimulations,weusea3-hoplineartopologyofidenticallinks.
TheperformanceofCETENisevaluatedinthepresenceofUDPcrosstraffic.
H.
CumulativeETENperformancewithTCPcrosstrafficInthissetofsimulations,weusea3-hoplineartopologyofidenticallinks.
TheperformanceofCETENisevaluatedinthepresenceofTCPcrosstraffic.
X.
PERFORMANCEThefollowingarethreesampleresultsofthevariousteststhatwereperformedinthisstudy.
Foradetaileddescriptionofallthetestsandresults,refertothecompleteBBNreport.
A.
BaslineInthebaselinesetofsimulations,weinvestigateasingleTCPflowoverasinglelinkwithchannelerrorsthatresultinpacketcorruption.
Inthissetofsimulations,thereisnocross-trafficcompetingwiththeTCPflow.
ExaminingETENinisolationprovidesanempiricalupperboundonthegaininTCPgoodputthatisachievableusingETENmechanisms.
ThebaselineforthesimulationsistheperformanceofTCPRenoandSACKundervariouserrorrates.
Weconsidertwonear-idealconditionsfortheerrordetectionandnotification:1.
OracleETEN–completeknowledgeofthecorruptedpacketandinstantaneousnotificationtothesource.
2.
BETEN–completeknowledgeofthecorruptedpacketwithrealBETENmessagespropagatingbacktothesource.
TheresultsinFigure4showthegoodputusingRenowithOracleETENoveralong-thinnetwork(ataBERof10-5)isalmostseventimesthebaselinegoodputusingRenoalone.
ThegoodputusingBETENwithSACKismorethanthreetimestheSACKbaseline,andthegoodputusingBETENwithRenoisabouttwoandonehalftimestheRenobaseline.
ThefigurealsoillustratesthatwhentheerrorsarenotasprevalentonthelinktheETENmechanismshavearelativelysmallimpactbecauseerrorshaveonlyasmallimpactonstockTCP.
Fromthesimplesimulationspresentedinthissectionwecanderiveseveralconclusions:TheperformanceusingBETENwithSACKisclosetothatofOracleETENatlowerrorrates.
AstheBERincreases,thechancesoflosinganotificationalsoincreasesandweseethatgainsfromBETENbegintodiminish.
UsingBETENwithSACKoutperformsBETENwithReno;thismaybebecausetheabilityofSACKtocorrectmultiplelossescomplementsETEN.
Ingeneral,TCPSACKperformsbetterthanTCPRenoduetotheabilityofTCPSACKtomostlydecouplelossrecoveryfromcongestioncontrol.
Figure4-TCPwithETENoveranuncongestedlongthinnetwork(LTN)B.
TCPWestwoodversusSACKBETENForthesimulationresultsinfigure5,wecomparetheperformanceofTCPWestwoodwhenbothcongestionandcorruptionlossesarepresent.
Figure5showstheperformanceofTCPWestwoodandBETENovera3-hoplineartopologywith1.
5Mb/slinkseachwithaone-waydelayof320ms.
WeusecompetingUDPtrafficforthesesimulations.
Theplotshowsthatathigherrorratesandmoderatecongestion,BETEN'sabilitytodistinguishbetweencorruptionandcongestionlossesprovidesperformanceimprovementsovertheTCPWestwoodstrategythatreliesonintelligentbandwidthestimationalone.
TheWestwoodstrategy,however,showsanadvantageunderheavycongestion(_competingflows)withlowtomoderateerrorrates.
Figure5-TCPWestwoodversusSACKTCPwithETENoveralongthinnetwork(LTN)Figure6-CETENPerformancewithTCPRenoandTCPcrosstrafficC.
CumulativeETENversusTCPRENOThesimulationresultsinfigure6showCETENwithTCPcrosstraffic2.
Theresultsindicatethatunderallcongestionlevels,CETENoffersmoderategoodputgainsoverTCPReno,exceptathighBER(10-5).
TheCETENsimulationsweconductedaspartofthisinvestigationshowCETENtobeapromisingapproachinsomesituations.
Inothersituations,CETENoffersworseperformancethanTCPReno.
WefeelthatfurtherinvestigationintoadditionalCETENmechanismsiswarrantedbeforemakingconclusionsonthefeasibilityofCETENingeneral.
Forinstance,aninvestigation2ItisimportanttonotethatthecompetingtrafficinoursimulationdidnotuseanyETENmechanism.
Thus,thecompetingtrafficneedlesslyreducetheirtransmissionrateswhentheyexperiencecorruptionlosses.
Thisallowstheflowofinteresttousemoreofthebottleneckbandwidth.
intohowwelltheendsystemcanestimatethetotallossrateandusethatfordeterminingthefractionoflossescausedbycongestionmayshedadditionallightonCETEN(andmakeitmorefeasibletodeploy).
XI.
SECURITYCONSIDERATIONSETENtechniques(suchasBETEN,forexample)thatrequireout-of-bandmessagesarevulnerabletodistributeddenialofservice(DDOS)attacksbecausenetworksthatplantousethisformofETENwillhavetoallowsuchmessagestoenterorleavetheirnetworks.
ThismakesitpossibleforanadversarytolaunchaDOSattackbybombardingahost(oranetwork)withETENmessages.
Thiscanminimallyoverwhelmthevictimhost,butiflaunchedasadistributeddenialofserviceattackfromalargenumberofhosts(thathavebeencompromisedbyanInternetworm,forinstance),anattackcanoverwhelmthecapacityofentirenetworks[11].
ETENmechanismsmaybevulnerabletoanothermoresubtleandindirectattack.
Amaliciousadversarycansendfalsenotificationscorrespondingtopacketsthatareeithernotdroppedorweredroppedduetocongestion.
Thiscaninducethesenderintoretransmittingpacketsunnecessarilyorintobypassingcongestionavoidanceandcontinuetransmittingatahigherratethanappropriateforthegivennetworkconditions.
Thisattackinisolation(onasingleflow)cancauselimiteddamage.
However,ifacoordinatedattackwerelaunchedonmanyTCPflowsonaheavilyloadednetwork,theattackcanpotentiallydrivethenetworkintocongestioncollapse[12].
Theuseofencryptioncanpreventdeepheaderinspection.
Forexample,IPsec[13]hidesTCPportinformation;IPsectunnelsalsohidetheoriginalsourceaddress.
ThismakesitdifficultforintermediaterouterstodeterminethecorrectTCPendpointstowhichETENmessagesshouldbedelivered.
XII.
CONCLUSIONSOurconclusionsfromthisstudyare:Per-packetETENmechanismsoffersubstantialgainsinbulkTCPgoodputintheabsenceofcongestion;however,inthepresenceofcongestionTCPcongestionavoidancemechanismsdominateresultingininsignificantgainsfromETEN.
Theproposedper-packetmechanismsprovideusefulupperboundsonperformancethatcanbeusedtoevaluatefutureproposalsofper-packetandcumulativeETENtechniques.
Per-packetmechanismspresentsignificantchallengestopracticalimplementationbyprovidinganewopportunitytoexploitInternetsecurityvulnerabilitiesandbyrequiringintermediatenodestoreliablyextractinformationfromtheheadersofcorruptedpacketsCumulativeETENtechniquesaremoreattractivetoimplementation;however,theparticularmechanismweevaluateddidnotrealizethepotentialgainsofper-packettechniquesSecurityvulnerabilitiesincludenotonlydenial-of-serviceattacksbutalsomoresubtleattackswitheffectsrangingfromunfairbandwidthsharingtototalcongestioncollapseofthenetwork.
FutureworkinthisareashouldfocusonalternativecumulativeETENmechanisms,accuratelossinferenceatendpointstoavoidtrackingcongestionlossesateveryhop,interactionswithforwarderrorcorrection,andcross-layerco-operationforETEN.
XIII.
RECOMMENDATIONSFORFUTUREWORKTheresultsofthisinitialbroadstudyareintriguing;theyleadustorecommendfurtherworkfocusedonspecificaspectsofETEN.
Ontheonehand,ourworkdemonstratestremendouspotentialfromETENifreliableinformationextractionfromheaderswerepossibleandcongestioncansomehowbecontrolled.
Ontheotherhand,ituncoversanumberofpracticalchallengescoupledwithachievingonlylimitedsuccesswiththeparticularcumulativeETENschemeweimplemented.
TheprimarythrustthatwerecommendistoexplorecumulativeETENalternativesthatdonotrelyoncongestionfeedbackfromintermediaterouters(sincethiswouldimplicitlydemandglobaldeploymentandrendertheschemelesspractical).
WebelievethatthebiggestchallengetorealizingCETENschemesistheinabilityofaTCPendpointtoaccuratelyestimatethetotallossatafineresolution(ofafewpackets)andinatimelymanner(withinanRTTtoenablequickrecovery).
Researchisneededtodevelopthiscapability.
Giventhiscapability,werecommendthatourproposedcumulativeETENschemeshouldberefinedtomakeuseofitandthenre-evaluated.
TheinteractionsofECNwiththerefinedcumulativeETENschemealsoremaintobestudiedinthiscontext.
OurcurrenteffortfocusedonquantifyingthroughputimprovementsachievableusingETENandwasthereforelimitedtolong-livedTCPflows.
FurtherworkisneededtoisolatetheeffectsoflossduringtheslowstartphaseandquantifythebenefitsofETENforshort-livedflows.
Wealsorecommendthatthemechanismsbeevaluatedusingrealnetworktopologiesandtraffictracesincludingotherworkloads,forexample,HTTPtransactions.
Underhigherrorrates,TCPconnectionestablishmentcanbedelayedorcanfailcompletely.
WebelievethatincreasingtheconnectionestablishmentrateunderhigherrorratescouldbeakeybenefitofETEN.
Werecommendthatfutureworkaddressthisissue.
REFERENCES[1]J.
Postel(editor),"TransmissionControlProtocol,"RequestforComments:793,September1981.
[2]V.
Jacobson,"CongestionAvoidanceandControl,"ProceedingsofACMSIGCOMM'88,Stanford,CA,USA,August1988.
[3]M.
Allman,V.
Paxson,andW.
Stevens,"TCPCongestionControl,"RequestforComments:2581,April1999.
[4]ISI,"InternetControlMessageProtocol,"RequestforComments:792,September1981.
[5]K.
Ramakrishnan,andS.
Floyd,"AProposaltoaddExplicitCongestionNotification(ECN)toIP,"RequestforComments:2481,January1999.
[6]K.
Ramakrishnan,S.
Floyd,andD.
Black,"TheAdditionofExplicitCongestionNotification(ECN)toIP,"RequestforComments:3168,September2001.
[7]K.
K.
Ramakrishnan,andR.
Jain,"ABinaryFeedbackSchemeforCongestionAvoidance,"ACMTransactionsonComputerSystems,Volume8,Number2,May1990,pp.
158–181.
[8]M.
Mathis,J.
Mahdavi,S.
Floyd,andA.
Romanow,"TCPSelectiveAcknowledgmentOptions,"RequestforComments:2018,October1996.
[9]ns-2simulator,http://www.
isi.
edu/nsnam/ns/index.
html[10]S.
Mascolo,C.
Casetti,M.
Gerla,M.
Sanadidi,andR.
Wang,"TCPWestwood:End-to-endBandwidthEstimationforEfficientTransportoverWiredandWirelessNetworks,"ProceedingsofMOBICOM2001,Rome,Italy,July2001.
[11]S.
Gibson,"TheStrangeTaleoftheAttacksAgainstGRC.
COM,"http://grc.
com/dos/grcdos.
htm.
[12]S.
Floyd,andK.
Fall,"PromotingtheUseofEnd-to-EndCongestionControlintheInternet,"IEEE/ACMTransactionsonNetworking,August1999,pp.
458–472.
[13]S.
Kent,andR.
Atkinson,"SecurityArchitecturefortheInternetProtocol,"RequestforComments:2401,November1998.