the transport layer is dead – long live the transport...

TheTransportLayerisDead–LongLivetheTransportLayer!

MichaelWelzlUniversityofOslo/UniversityofRomeTorVergata

15.01.20181

MichaelWelzlUniversityofOslo/UniversityofRomeTorVergata

15.01.20182

Wakeupcall• Thetransportlayerisinterestingagain!

– Somehow,(mostlyUS?)industryisaware,butacademia+(European?)fundingbodiesdon'trecognize;onlyexception:MPTCP

• Longlistofnew,interestingstuff!– HTTP/2+QUIC;LEDBAT;WebRTC(withRMCAT congestioncontrols)– Focusonlowlatency:Bufferbloatcommunity=>AQMalgorithms:

(FQ-)CoDel,PIE andnowalsosomeWiFiwork;ECN:ABE,L4S

• Whyhastransport"gonecold"?– Noproblemtosolve,TCPworks? nottrue! TCP=latency,complexity,bad

fairness,badinteractionswithdelay-sensitiveornon-greedytraffic,...– ChangingTCPisfrustratinglyhard,elsenochancetochangeanything?

Notsotrueanymore!=>storyofthistalk! 3

Outline

1. The"transportlayerossification"problem

2. Thesolution1. IETFTransportServices(TAPS)WG2. NEATECproject(andsoftware!)

4

Terminology

5

Ossification Petrification

TheTransportLayerisDead....

(theproblem)

6

Thebeauty;-)ofOSI...

• AN-layerprovidesaservicetotheN+1-layer– what'sbelowtheserviceinterfaceishidden

•

• Protocolsinsidelayersareinterchangeable

• Transportlayer(andabove)shouldbeespecially easytochange!

node A node B

protocol Layer N+1

Layer N: services N1, N2

service interface

entitiy vertical comm.

horizontal comm.

N1

N2

N1

N2

7

Internettransportisossified

è Applicationsexpectprecisely thebehaviorofTCPandUDP

node A nodeB

e.g.HTTP Application Layer

TransportLayer

entityUDP

TCP

è Routersexpecttoseeprecisely TCPorUDP(sometimeswithevenmorelimitations)

8

Transportlayerdevelopment• Computer,30yearsago

• AprogramthatsendsdataovertheInternet,30yearsago

(usingBerkeleysockets)

9

Transportlayerdevelopment• Computer,today

• AprogramthatsendsdataovertheInternet,today

(usingBerkeleysockets)

10

Morethanjustsockets...

• Previousexample:Berkeleysockets– Today,applicationsusemanydifferentAPIsfromvariouslibraries/middlewares

• Buttheselibraries/middlewaresuse socketsè limitedbytheservicesofTCPandUDP1. Areliablebytestream2. Unreliablepacket(“datagram”)transmission

It’sawayofthinking aboutcommunication!11

...andit’sfromthe80s!

1) Reliablebytestream,TCP

2) Datagram,UDP

12

Whatabout...

• Priorities?– Amongyourownflows,andbetweenyoursandothers?

• Careful“donotdisturbanybody”background(“scavenger”)communication?

• Intelligentuseofmultiplenetworkinterfaces?

• Maybeusingdataevenwhenachecksumfails?– Codecscanhandlethat,butUDPwillthrowawayallyourdata

• Usingprotocolfeaturesthatyieldlowerlatency?– Maybetradelatencyagainstbandwidth?– Controlthesendbuffer?

13

Example:unordered message delivery

• Some applications can accept data chunks outof order,even when requiring reliability– TCPcauses Head-Of-Line(HOL)blocking delay

Chunk 2 Chunk 3 Chunk 4 Chunk 1TCP receiver buffer

App waits in vain!

• Some protocols can deliver data outof order (e.g.SCTP)• If suchaprotocol is notavailable:fine to use TCP!

• in-orderdelivery is correct!Justslower

...BUT:unless anapplication asks for it,we can NEVERgiveitdatainthe wrong order.è Thisservice needs to be inALLAPIs!(notjustsocketlevel)

14

...LongLiveTheTransportLayer!

(thesolution)

15

Solutionpart1:AStandard.

IETFTransportServices(TAPS)

16

TAPSBackground

Application

Protocol X

ISP A (supports

X only)

Application

Protocol X

ISP A (supports

X only)

TAPS system

Application

Protocol Y

ISP B (supports X and Y)

TAPS system

Application

Protocol X

ISP B (supports X and Y)

without TAPS with TAPS

• mid-2013,thetimehadcome:LEDBAT,RTMFP,MPTCP,SPDY,Minion• Canwegetsomeorderintothischaos?

• 1yearofcommunity-convincing;1barBoF;2BoFs=>TAPSchartered24.9.2014• Historyavailableat:https://sites.google.com/site/transportprotocolservices/17

HowTAPSwantstosolvetheproblem

• Unorderedreliablemessagedeliveryisonlyoneexample

• Whatistheminimumsetoftransportservices...– fromtheservicesthatIETFtransportprotocolsoffer...thatwe“must”makeavailableeverywhereforthemtobecomeusable?

• Onceweknowthat,wecanspecifyhowtoimplementaTAPSsystem

18

TAPScharter:plannedoutcomes

1. Listofservices providedbytoday’stransports

2. List:subsetofservices thatsystemssupportingTAPSwillprovide+guidanceonchoosingamongavailablemechanismsandprotocols

3. Experimentalspec:mechanismstoprovidetheservicesidentifiedinitem2(“Thisdocumentwillexplainhowtoselectandengageanappropriateprotocolandhowtodiscoverwhichprotocolsareavailablefortheselectedservicebetweenagivenpairofendpoints.Further,itwillprovideabasisforincrementaldeployment.”)

19

Bottom-upmethodtoderiveaminimumsetoftransportservices

• IETFTransportServices(TAPS)WorkingGroup1. Survey ofservicesprovidedbytransportprotocols– RFC

8095(54pages)2. In-depthanalysisof30+RFCs:TCP,MPTCP,UDP,UDP-

Lite,SCTP,LEDBAT (RFCs-to-be8303&8304~79pages)3. Derivationofaminimumset:from2),keeponlyservices

thatrequireapplication-specificknowledgeanddonotprohibitfallingbacktoTCP/UDP;resolvesomeresultingpeculiarities(1Internet-draft,53pages)

20

Fall-backsenableone-sideddeployment

SeveralProtocols

NewAPI

NewApp NewProtocolX

NewAPI

NewApp

TCP

NewAPI

NewApp

UDP

NewAPI

NewApp

TCP

Sockets

CurrentApp

UDP

Sockets

CurrentApp

21

Result(latestversion):high-levelview

1. Flowcreationandflowgrouping– Mostconfigurationfeaturesonlyconfigureagroup(e.g.,can’tconfiguretimeoutforanSCTPstreamonly)

– Shoulduseconfigurationearly,ideallybeforeconnecting

2. Send-before-connect– Couldalsobeimplementedasaparameterto“connect”– Specify“idempotentdata”forextra-fasttransmission(TFO)

3. Limitedconnect/listen/close/abortsemantics(supportUDP,ortransparentlyusestreams)– Connectmaynotinvokeaccept!– Nohalf-closedconnections 22

Note:assumeTCPfall-backonly(assumingUDPfall-backlimitsthislist)

Result(latestversion):high-levelview/2

• Beinformedaboutsenderbufferrunningdry– Latedecisionaboutchoiceofdatatosend

• Configure:per-flowpriorities,network-widepriorities(DSCP),timeout,authentication,checksums

• Somequeries,e.g.relatedtopacketsizes• Sendmessages,receivebytestream

– Messagesstayintact,butmaybereorderedordropped(configuredbysender)

– Receivermustbeaware(detectboundaries)23

Movingtoasystemspecification...

• TAPScharteritem3:currentlyvariousdocuments/proposals– post-sockets:TLSfeatures,connectionmigration,variousotherextras,relatedtoApple'ssoon-to-be-shippedcode

– guidelinesforTAPSsystems,securitysurvey– NEATprojectoutputs(happyeyeballs,API,..)– socketintents(mostlyfocusedoninterfacechoice)

24

Solutionpart2:Code.

Theproject(andsoftware)

25

WhatdoesNEAToffer?• Auser-spacelibrary forefficiente2enetworkInternetcomm.,designedtobeeasytouse– Thinkofitas"TAPSminimumset++"

• Easy,platform-independentaccesstothefeaturesofTCP,MPTCP,SCTP,UDP,UDP-LITEandmoreresearchythings viaacallback-basedAPI– Policysystemtocontroleverythingviajsonfiles

• One-sideddeploymentpossible,candofall-backstoTCPorUDP,cantalktonativepeers(e.g.TCP,SCTP,evenWebRTCbrowser!)

26

Internals:sequenceofeventsinNEAT

27

Happy

Eye-balls

28

Moredeploymentconsiderations• “Application”couldbealibraryormiddleware

– e.g.,pub-subdoesn’tneed100%reliability=>interestingresearchpossibilities("networkingmeetsdistributedsystems")

– wouldonlyexploitasubsetofTAPScapabilities,butre-compilinganappwiththenewmiddlewareversionwouldmaketheappuseTAPS

• RelatedNEATdevelopment:NEATsocketAPI– RunlegacyapplicationsoverNEATusing"withneat commandname params"– Benefitfrom:policysettings;transparentSCTP-stream-mapping

Non TAPS-enabled application

M's API

Legacy transport(TCP, UDP)

M's internals

Non TAPS-enabled application

M's API

Available transports (TCP, UDP, Minion,

SCTP...)

M + TAPS internalsMiddleware M Middleware M

29

Conclusion

• Wehave:– IETFTAPS– Apple– TheNEATproject,includingMozillaandthemainSCTPdevelopers

• ....allworkingtowardsareal transportlayer– Newflexibility,newresearchpossibilities

• PleasejointheNEATeffort– download,test,extendandplay!

30

node A node B

protocol Layer N+1

Layer N: services N1, N2

service interface

entitiy vertical comm.

horizontal comm.

N1

N2

N1

N2

Stuff!

• TAPS:– https://datatracker.ietf.org/wg/taps/

• NEAT:– http://www.neat-project.org– https://github.com/NEAT-project/neat– "NEAT:APlatform- andProtocol-IndependentInternetTransportAPI",

IEEECommunicationsMagazine55(6),2017.– "De-ossifyingtheInternetTransportLayer:ASurveyandFuture

Perspectives",IEEECommunicationsSurveys&Tutorials19(1),Firstquarter2017.

31

Questions,comments?

32

Backupslides

33

Sendingmessages,receivingabytestream

• Canwemakethiscombinationwork?– BecompatibletoTCPbutstillbenefitfrommessages?

• Alternativenotveryattractive:alwaystellinganapplication“sorry,youonlygetastreamhere”isnotmuchdifferentthansaying“sorry,useTCPinstead”– Let’sminimize#hoopsanappdeveloperhastojumpthrough

• Message-orientedTCPappsalreadyframetheirdata– Unnecessarytorepeatthisintransportlayer– Requirementtotellreceiverapp“hereisyourcompletemessage”createsa

majorlimitationandisoftenunnecessary

34

Application-Framed(AFra-)Bytestream

• NormalTCP-likebytestream API– Optional:someadditionalinformationprovidedbysenderapp

• Senderapp: handsoverastreamofbytes,informstransportaboutframeboundariesandrequirements(order,reliability,..)– Delimitedframesstayintact,inorder– Morerelaxedrulespossiblebetween frames– Delimitersassumedtobeknownbyapplication

• Receiverapp:receivesstreamofbytes– App-leveldelimitersturnitintomessages

• TCP=specialcase:nodelimitersused– Cantalkto“normal”TCPapplicationsonbothsides

35

Unorderedmessagedelivery:SCTP

36

API API

Msg 3

Msg 2

Msg 1

SenderappMsg 1

Msg 3

Msg 2

Receiverapp

• Informwhereframebegins• Configure:“unordered”

Block1Block3 Block2

App-definedheader.Couldalsobee.g.implicitknowledgeaboutsize

Justabytestream!

Appknowshowtoidentifymessages

Block1Block2 Block3

• Informwhereframeends

Unorderedmessagedelivery:TCP

37

API API

Msg 3

Msg 2

Msg 1

SenderappMsg 1

Msg 2

Msg 3

Receiverapp

• Informwhereframebegins• Configure:“unordered”

… TCPjustignoresthis!

Block1Block3 Block2

Justabytestream!

Appknowshowtoidentifymessages

Block1Block2 Block3

• Informwhereframeends

Unreliableunorderedmsg delivery:SCTP

38

API API

Msg 3

Msg 2

Msg 1

SenderappMsg 3

Msg 2

Receiverapp

• Informwhereframebegins• Configure:“unreliable,unordered”

Block1Block3 Block2

Justabytestream!

Appknowshowtoidentifymessages

Block2 Block3

• Informwhereframeends

Unreliableunorderedmsg delivery:TCP

39

API API

Msg 3

Msg 2

Msg 1

SenderappMsg 1

Msg 2

Receiverapp

• Informwhereframebegins• Configure:“unreliable,unordered”

… TCPjustignoresthis!

Block1Block3 Block2

Justabytestream!

Appknowshowtoidentifymessages

Block2 Block3

Block1

Msg 3

• Informwhereframeends

Unreliablemessagedelivery:SCTP,largemessages

40

API API

Msg 3

Msg 2

Msg 1

Senderapp Receiverapp

• Informwhereblockbegins• Configure:“Unreliable”

Block1Block3 Block2

Packets

• Informwhereframeends

Unreliablemessagedelivery:SCTP,largemessages

41

API API

SenderappMsg 2

Receiverapp

Justabytestream!

Appknowshowtoidentifymessages

Block1Block3 Block2

Packets

SCTP

Init:

exampledecisiontree

-Willyouneedsomeformofreliability?Yes: SCTPorTCP canbeused.- Isanyofthefollowingusefultotheapplication?*Choosingascheduler,choosingpriorities*Configurablemessagereliability*Unorderedmessagedelivery*RequestnottodelaymessageSACKsYes:SCTPispreferred.No:- Isanyofthefollowingusefultotheapplication?*Handoveramessagetoreliablytransfer(possiblymultipletimes)beforeconnectionestablishment*Suggesttimeouttothepeer*NotificationofExcessiveRetransmissions(earlywarningbelowabortionthreshold)*NotificationofICMPerrormessagearrivalYes:TCPispreferred.No:SCTPandTCPareequallypreferable.

No: allprotocolscanbeused.- Isanyofthefollowingusefultotheapplication?*Specifychecksumcoverageusedbythesender*Specifymin.checksumcoveragerequiredbyreceiverYes:UDP-Liteispreferred;No:UDPispreferred. 42

Avoids,e.g.:1)chooseUDP2)appasksforreliability

TCP UDP SCTP

APP Class 0 APP Class 1 APP Class 2 APP Class 3

TCP Minion Experimental Mechanisms

Traditional Socket NEAT Socket

Middleware

NEAT Framework

NEAT User API

NEAT APP Support API

NEAT Policy

ManagerUSER

KERNEL

Policy Information

Base

Characteristic Information

Base

Policy Interface

SCTP/UDP

APP Class 4

PCAP RAW IP Experimental Mechanisms

KPI

Selection Components

H and SComponents

NEAT APP Support Module

IP

DIAG & STATS

NEAT Kernel Module

Policy Interface

Transport Components

SCTP/UDP

SPUD/UDP…

Userspace TransportExp

Mech

NEATarchitecture

43