OCARINA("OptimizationstoCompelAdoptionofRINA")

MichaelWelzlRINAWorkshop– IndustryDay

i2CATBarcelona22.5.20181

Projectoverview• 5-yearprojectfundedbyNorwegianresearchcouncil,started1October2016;1postdoc+3Ph.D.students– Focusedonperformance.Assumptions:1. RINAneedsto showfantasticperformance,2. RINAcan showfantasticperformance!

• 3mainWPs:cong.control,routing,Internetdeployment– RINAforcesustothinkdifferentlyaboutnetworkalgorithmssuchasroutingandcongestioncontrol

– E.g.,Internet-like"end-to-end"congestioncontrolcouldbeimplementedinaRINAnetwork,butthatwouldbeaverystrangeconfiguration 2

IssuesofInternetCC.• Twomajormistakes:

1. Firstproducecongestion,thenreacttoit• Solution: createameaningful"load"signalthatdoesnotembedaveryspecificalgorithm(givesomefreedomtodesigners)

2.Cluelessaboutunderlyinginfrastructure,bydesign• Solution: useper-DIFloops,workwithback-pressure

• ECNisbroken– Costincurredinthenetworkisadditiveperhop(seeNUMtheory),butcan'tre-mark amarkedpacket

– Better"load"signalinDCTCP-styleusage:instantaneousqueuemarking,countmarks/RTT,orbeforeaqueueevengrows(virtualQ)

3

ProblemsofusingECNas“load”

• ModerncontrollerssuchasDCTCPconvergeathighmarkingprobabilities.

• Thetheory(e.g.NetworkUtilityMaximization(NUM))needsanadditivesignal;aproductvaluedeviatesmuchinhighmarkingprobabilities(>0.04)!

4

OurSolution• ExtendingtheTheory

– Withalotofmathandstabilityanalysisofcourse…• Results:(assumingalogarithmicutility)

Advantages:1. Newsignalisaprettygeneralsolution;justconveys"load",andcould

(relatively)easilybeextendedtomulti-bit2. Newsignalisprobablygoodinputtoload-basedroutingtoo3. REDasanalready-deployedsolutioncanbeused;onlysmallchangesat

sendersandreceivers5

x(1):avg.rateofafive-hopflowx(2):avg.rateofaone-hopflow

Simulationresults

deviation(previoustheory)

Numericalresults

ourmethod

Per-DIFloops:PRISTINEbackground

• AsequenceofDIFsdoingTCPCC.ismuchlikeasequenceofsplit-TCPPEPs→canbebeneficial[1]

• However,controlsusingrecursivequeuebasedfeedbackcanhavestabilityissues(+delayfrommultiplequeues)[2]

• Envisiontoaddressthiswithlogisticgrowthbasedcontrol[3]+new"fixed"ECN

6

1. PeymanTeymoori,MichaelWelzl,SteinGjessing,EduardGrasa,RobertoRiggio,KewinRausch,DomenicoSiracusa:"CongestionControlintheRecursiveInterNetworkingArchitecture(RINA)",IEEEICC2016,KualaLumpur,Malaysia,23-27May2016.

2. DavidHayes,PeymanTeymoori,MichaelWelzl:"FeedbackinRecursiveCongestionControl",13thEuropeanWorkshoponPerformanceEngineering(EPEW2016),Chios,Greece,5-7October2016.

3. PeymanTeymoori,DavidHayes,MichaelWelzl,SteinGjessing:"EvenLowerLatency,EvenBetterFairness:LogisticGrowthCongestionControlinDatacenters",IEEELCN2016,Dubai,UAE,7-10November2016.

WiFiuplink(e.g.videoconference)

• TCP's"sawtoothtest"doesnotmakemuchsensehere– 802.11MACis thishop'scongestioncontrol...butfocusedonsending1frame,nottellingusasendrate

• Couldusebufferdrainrate– perhapsBBRwouldworkwellhere?

• However:knowingbufferdrainraterequirestoalwayssend→workingonamodel-basedapproach 7

Deployment

• WecanconsiderRINA-under-IP,RINAoverlay,andRINA-IPgateways...

• Butwecanalsoconsider"switchingover"!– OnceahostdiscoversthatthewholepathtotheotherendisRINA-enabled,switch

– Today,often,pathsareshort(Google,FB,...arenotfarawayfromyou)

– TCP/IPareonlyrendez-vousprotocols– SomerecentIETFstandardscouldhelp

• AlittleironicJ 8

RelevantIETFworknotstrictlyOCARINA,butstill...

• TransportServices(TAPS)WG:makesappsprotocol-independent– Finished surveyingandcondensingservicesprovidedby:TCP,MPTCP,UDP,UDP-Lite,SCTP,LEDBAT

– NowworkingonAPI+implementationguidance,withAppleamongothers;implementations:Apple,NEAT(opensource)

• ProvisioningDomains(PvDs)(INTAREAWG):– RouterAdvertisement(RA)optionfromfirst-hoprouterconveysFQDNthathostcanusetoretrieveextrainfoaboutnetworkaccesscharacteristicsviaHTTPoverTLSquery

– Applicationsthenselect(vialocalIPaddress)whichPvDtouse,andcanlearnconfig.paramsfortransportlayerandabove 9

Conclusion

Thankyou!

13