The Transport Layer is Dead – Long Live the Transport Layer! Michael Welzl Net Group, University of Rome Tor Vergata 30. 09. 2017 1
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
TheTransportLayerisDead–LongLivetheTransportLayer!
MichaelWelzlNetGroup,UniversityofRomeTorVergata
30.09.20171
Outline
1. Theproblem
2. Thesolution1. IETFTransportServices(TAPS)WG2. NEATECproject(andsoftware!)
2
TheTransportLayerisDead....
(theproblem)
3
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
4
Internettransportisossified
è Applicationsexpectprecisely thebehaviorofTCPandUDP
node A nodeB
e.g.HTTP Application Layer
TransportLayer
entityUDP
TCP
è Routersexpecttoseeprecisely TCPorUDP(sometimeswithevenmorelimitations)
5
Transportlayerdevelopment• Computer,30yearsago
• AprogramthatsendsdataovertheInternet,30yearsago
(usingBerkeleysockets)
6
Transportlayerdevelopment• Computer,today
• AprogramthatsendsdataovertheInternet,today
(usingBerkeleysockets)
7
Morethanjustsockets...
• Previousexample:Berkeleysockets– Today,applicationsusemanydifferentAPIs
• Thesehigher-layersystemsuse socketsè canonlyoffertheservicesofTCPandUDP1. Areliablebytestream2. Unreliablepacket(“datagram”)transmission
It’sawayofthinking aboutcommunication!8
...andit’sfromthe80s!
1) Reliablebytestream,TCP
2) Datagram,UDP
9
Whatabout...
• Priorities?– Amongyourownflows,andbetweenyoursandothers?
• Careful“donotdisturbanybody”background(“scavenger”)communication?
• Intelligentuseofmultiplenetworkinterfaces?
• Maybeusingdataevenwhenachecksumfails?– Codecscanhandlethat,butUDPwillthrowawayallyourdata
• Usingprotocolfeaturesthatyieldlowerlatency?– Maybetradelatencyagainstbandwidth?– Controlthesendbuffer?
10
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)
11
Fromhttp://blog.sendmemobile.com/music-humor/ten-1990s-artists-who-need-a-comeback
IntServ?DiffServ?IntServ overDiffServ!
("Ucan'ttouchthis"ISPcorerouter)
Bytheway:the90swerenobetter!
12
Internet(end-to-end!)QoS
• Circulardependencythat’sverysimilartotheTransportLayerproblem[RFC2990]
• Internet(IPovereverything)+strict QoS guaranteeswasneveragoodfit– Alternativesexist,butperhapsnotassexyforISPs– e.g.AlternativeBestEffort(ABE)Service(PaulHurley,Jean-YvesLeBoudec,PatrickThiran)andsomepapersbySergeyGorinsky etal
– Coulddothat,orjust“tryQoS”butnotrelyonit– "TryQoS"isnowdonebyWebRTC:
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18 13
...LongLiveTheTransportLayer!
(thesolution)
14
Solutionpart1:AStandard.
IETFTransportServices(TAPS)
15
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/16
HowTAPSwantstosolvetheproblem
• Unorderedreliablemessagedeliveryisonlyoneexample
• Whatistheminimumsetoftransportservices...– fromtheservicesthatIETFtransportprotocolsoffer...thatwe“must”makeavailableeverywhereforthemtobecomeusable?
• Onceweknowthat,wecanspecifyhowtoimplementaTAPSsystem
17
TAPScharter:plannedoutcomes
1. Listofservices providedbytoday’stransports
2. List:subsetofservices thatsystemssupportingTAPSwillprovide+guidanceonchoosingamongavailablemechanismsandprotocols
3. Experimentalspec:mechanismstoprovidetheservicesidentifiedinitem2(“Thisdocumentwillexplainhowtoselectandengageanappropriateprotocolandhowtodiscoverwhichprotocolsareavailablefortheselectedservicebetweenagivenpairofendpoints.Further,itwillprovideabasisforincrementaldeployment.”)
18
Bottom-upmethodtoderiveaminimumsetoftransportservices
• IETFTransportServices(TAPS)WorkingGroup1. Survey ofservicesprovidedbytransportprotocols–
RFC8095(54pages)2. In-depthanalysisof30+RFCs:TCP,MPTCP,UDP,
UDP-Lite,SCTP,LEDBAT (2Internet-drafts,79pages)3. Derivationofaminimumset: from2),keeponly
servicesthatrequireapplication-specificknowledgeanddonotprohibitfallingbacktoTCP/UDP;resolvesomeresultingpeculiarities(1Internet-draft,53pages)
19
Fall-backsenableone-sideddeployment
SeveralProtocols
NewAPI
NewApp NewProtocolX
NewAPI
NewApp
TCP
NewAPI
NewApp
UDP
NewAPI
NewApp
TCP
Sockets
CurrentApp
UDP
Sockets
CurrentApp
20
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 21
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)22
Sendingmessages,receivingabytestream
• Canwemakethiscombinationwork?– BecompatibletoTCPbutstillbenefitfrommessages?
• Alternativenotveryattractive:alwaystellinganapplication“sorry,youonlygetastreamhere”isnotmuchdifferentthansaying“sorry,useTCPinstead”– Let’sminimize#hoopsanappdeveloperhastojumpthrough
• Message-orientedTCPappsalreadyframetheirdata– Unnecessarytorepeatthisintransportlayer– Requirementtotellreceiverapp“hereisyourcompletemessage”createsa
majorlimitationandisoftenunnecessary
23
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
24
Unorderedmessagedelivery:SCTP
25
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
26
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
27
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
28
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
29
API API
Msg 3
Msg 2
Msg 1
Senderapp Receiverapp
• Informwhereblockbegins• Configure:“Unreliable”
Block1Block3 Block2
Packets
• Informwhereframeends
Unreliablemessagedelivery:SCTP,largemessages
30
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. 31
Avoids,e.g.:1)chooseUDP2)appasksforreliability
Movingtoasystemspecification...
• TAPScharteritem3:currentlyvariousdocuments/proposals– post-sockets:fall-backtoTLS,systemonbothsides,extrafeatures(e.g.connectionmigration)
– guidelinesforTAPSsystems,securitysurvey– NEATprojectoutputs(happyeyeballs,API,..)– socketintents(mostlyfocusedoninterfacechoice)
32
Solutionpart2:Code.
Theproject(andsoftware)
33
WhatdoesNEAToffer?• Auser-spacelibrary forefficiente2enetworkInternetcomm.,designedtobeeasytouse
• OffersaccesstothefeaturesofTCP,MPTCP,SCTP,UDP,UDP-LITEandmoreresearchythings viaacallback-basedAPI
• Policysystemtocontroleverythingviajsonfiles• One-sideddeploymentpossible,candofall-backstoTCPorUDP,cantalktonativepeers(e.g.TCP,SCTP,evenWebRTCbrowser!)– Notpreciselytheminimumset,butmuchoverlap(e.g.:sendmessage,receivewithoutguaranteeofmessageboundariesforTCP;transparentuseofSCTPmulti-streaming),andmuchmore
34
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
35
Internals:sequenceofeventsinNEAT
36
Happy
Eye-balls
37
Moredeploymentconsiderations• “Application”couldbealibraryormiddleware
– e.g.,pub-subdoesn’tneed100%reliability– wouldonlyexploitasubsetofTAPScapabilities,butre-compilinganappwith
thenewmiddlewareversionwouldmaketheappuseTAPS
• 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
38
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:ASurveyandFuturePerspectives",
IEEECommunicationsSurveys&Tutorials19(1),Firstquarter2017.
39
Questions,comments?
40
Related Documents
