lecture05-principles-goals- Design Goals Spring 2018 Rachit Agarwal. ... Recap: four fundamental...
Transcript of lecture05-principles-goals- Design Goals Spring 2018 Rachit Agarwal. ... Recap: four fundamental...
ComputerNetworks:ArchitectureandProtocols
CS4450
Lecture5-ThreeArchitecturalPrinciples
-DesignGoals
Spring2018RachitAgarwal
Announcements
• Youhavebeenagreatclasssofar• Mostofyouarequietandpayingattention
• Youaregivinggreatanswers!• Evenmoreimportantly,youareaskinggreatquestions!
• Thankyou!
• Admin:
• Theofficehoursareposted,andareon!• Weareonschedule:
• ProblemSet1isposted!
• Solutionswillbereleasedin1week.
• Remember:in-classquizzescanhappenatanytime
MoreAnnouncements
• Threequestions:• Doanyofyouconsideryourselfh4x0r?• Doyoufeellikeyouhavetoomuchtimeinyourlife?
• Wouldyouliketogetexposedtonetworkingresearch?
• Ifyes,talktome—Iamwillingtotakeontwoundergradresearchers
ContextforToday’sLecture
• Sofar,wehavediscussedseveralhigh-levelconcepts• Networksharing• End-to-endworkingoftheInternet• Addressing,Routing,Switch/Routerfunctionality,etc.
• And,havediveddeepintoseveraltopics:• Circuitswitchingandpacketswitching(especiallythe“why”)• Delays(transmission,propagation,queueing)
• Youknowmoreaboutcomputernetworksthanyoumayrealize!
• Today:Laythefoundationforrestofthecourse
GoalsforToday’sLecture
• Threearchitecturalprinciples:• Layering• End-to-endprinciple• FateSharingprinciple
• Designgoalsforcomputernetworks:
• Eightofthem
• Wewillcomebacktotheseoverandoveragain
• Almosteverylectureinthesemester
• Beforewestart,letmeoutrightlyadmit….
• FirsttimeIlearntthese,Isaid—whatthe@#$%….
• …thereareeasierwaystotorturestudents!• Now,thesehavebecometheguidingprinciplesofmycareer!
Quickrecapfromlastlecture
• Locatingthedestination:Naming,addressing
• MappingofnamestoaddressesusingDomainNameSystem
• Findingapathtothedestination:Routing• Distributedalgorithmthatcomputesandstoresroutingtables
• Sendingdatatothedestination:Forwarding• Inputqueues,virtualoutputqueues,outputqueues• Enablers:Packetheader(address),androutingtable(outgoinglink)• Queueingdelay:dependenton“networkload”
• Reliability:Failurehandling• Notmuchdiscussion,butthequestion:hostsornetworks?
Recap:fourfundamentalproblems!
Recap:thefinalpieceinthestory—Hostnetworkstack
OfSocketsandPorts
• Whenaprocesswantsaccesstothenetwork,itopensasocket,whichisassociatedwithaport
• Socket:anOSmechanismthatconnectsprocessestothenetworkingstack
• Port:numberthatidentifiesthatparticularsocket
• TheportnumberisusedbytheOStodirectincomingpackets
• Applicationopensasocketthatallowsittoconnecttothenetworkstack
• MapsnameofthewebsitetoitsaddressusingDNS
• Thenetworkstackatthesourceembedstheaddressandportforboththesourceandthedestinationinpacketheader
• Eachrouterconstructsaroutingtableusingadistributedalgorithm
• Eachrouterusesdestinationaddressinthepacketheadertolookuptheoutgoinglinkintheroutingtable
• Andwhenthelinkisfree,forwardsthepacket
• Whenapacketarrivesthedestination:
• Thenetworkstackatthedestinationusestheporttoforwardthepackettotherightapplication
Recap:theend-to-endstory
Questions?
ThreeArchitecturalPrinciples
• Howtobreaksystemintomodules?
• Classicdecompositionintotasks
• Wherearemodulesimplemented?
• Hosts?• Routers?• Both?
• Whereisstatestored?
• Hosts?• Routers?• Both?
NetworkModularityDecisions
• Howtobreaksystemintomodules
• Layering
• Wherearemodulesimplemented
• End-to-EndPrinciple
• Whereisstatestored?• Fate-Sharing
Leadstothreedesignprinciples
Layering
• Bitsonwire
• Packetsonwire
• Deliverpacketstohostsacrosslocalnetwork
• Deliverpacketstohostacrossnetworks
• Deliverpacketsreliably,tocorrectprocess
• Dosomethingwiththedata
Breakdownend-to-endfunctionalityintotasks
• Bitsonwire
• Packetsonwire
• Deliverpacketstohostsacrosslocalnetwork
• Deliverpacketstohostacrossnetworks
• Deliverpacketsreliably,tocorrectprocess
• Dosomethingwiththedata
Breakdownend-to-endfunctionalityintotasks
• Bitsonwire(Physical)
• Packetsonwire
• Deliverpacketstohostsacrosslocalnetwork(Datalink)
• Deliverpacketstohostacrossnetworks(Network)
• Deliverpacketsreliably,tocorrectprocess(Transport)
• Dosomethingwiththedata(Application)
ResultingModules(Layers)
• Application:Providingnetworksupportforapps
• Transport(L4):(Reliable)end-to-enddelivery
• Network(L3):Routing
• Datalink(L2):Localdelivery(forwarding)
• Physical(L1):Bitsonwire
FiveLayers(Top-Down)
• Akindofmodularity
• Functionalityseparatedintolayers• Layerninterfaceswithonlylayern-1andlayern+1
• Hidescomplexityofsurroundinglayers
Layering
Builtontopofreliabledelivery
Builtontopofbest-effortforwarding
Builtontopofbest-effortrouting
Builtontopofphysicalbittransfer
Anend-to-endviewofthelayers
• Application:Providingnetworksupportforapps• Transport(L4):(Reliable)end-to-enddelivery• Network(L3):Routing• Datalink(L2):Localdelivery(forwarding)• Physical(L1):Bitsonwire
Whydoesthepacketgoallthewaytonetworklayerateachhop?
Questions?
• Howtobreaksystemintomodules?
• Layering
• Wherearemodulesimplemented?
• End-to-EndPrinciple
• Whereisstatestored?
• Fate-Sharing
ThreeInternetDesignPrinciples
• Layersaresimpleifonlyonasinglemachine
• Juststackofmodulesinteractingwiththoseabove/below
• Butweneedtoimplementlayersacrossmachines
• Hosts• Routers/switches
• Whatgetsimplementedwhere?Andwhy?
DistributingLayersacrossNetwork
• Bitsarriveonwire,mustmakeituptoapplication
• Therefore,alllayersmustexistathost!
WhatgetsimplementedonHost?
• Bitsarriveonwire• Physicallayernecessary
• Packetsmustbeforwardedtonextrouter/switch
• Datalinklayernecessary
• Routersparticipateinglobaldelivery• Networklayernecessary
• Routersdonotsupportreliabledelivery• Transportlayer(andabove)notsupported• Why?
WhatgetsimplementedonRouter?
• Lowerthreelayersimplementedeverywhere
• Toptwolayersonlyimplementedathosts
Visualizingwhatgetsimplementedwhere
Endhost
Router/switch
• Layeringdoesn'ttellyouwhatserviceseachlayershouldprovide
• Whatisaneffectivedivisionofresponsibilitybetweenvariouslayers?
Butwhyimplementedthisway?
Ifafuncdoncancompletelyandcorrectlybeimplementedonlywiththeknowledgeandhelpoftheapplicadonstandingattheendpointsofthecommunicadonsystem,
thenprovidingthatfuncdonasafeatureofthecommunicadonsystemitselfisnotpossible.
Somedmesprovidinganincompleteversionofthatfuncdonasafeatureofthecommunicadonsystemitselfmaybeusefulasaperformanceenhancement.
End-to-endPrinciple
End-to-endPrinciple:anexample
• Supposeeachlinklayertransmissionisreliable
• Doesthatensureend-to-end(application-to-application)reliability?
• Supposenetworklayerisreliable• Doesthatensureend-to-end(application-to-application)reliability?
Ifafuncdoncancompletelyandcorrectlybeimplementedonlywiththeknowledgeandhelpoftheapplicadonstandingattheendpointsofthecommunicadonsystem,
thenprovidingthatfuncdonasafeatureofthecommunicadonsystemitselfisnotpossible.
Somedmesprovidinganincompleteversionofthatfuncdonasafeatureofthecommunicadonsystemitselfmaybeusefulasaperformanceenhancement.
End-to-endPrinciple:letsreadagain
Assumethecondidon(IF)holds.Then,
• End-to-endimplementation• Correct• Generalized,andsimplifieslowerlayers
• In-networkimplementation• Insufficient• Mayhelp—orhurt—performance
End-to-endPrinciple(Interpretation)
Whatdoestheendmean?
End-to-endPrinciple(Interpretation)
• Everyoneknowswhatitis• So,youmust!
• Everyonebelievesit• So,youmust!
• Nobodyknowswhatitmeans
• Wearealldoomedanyways.
End-to-endPrinciple(Threethingstoknow)
Questions?
• Howtobreaksystemintomodules?
• Layering
• Wherearemodulesimplemented?
• End-to-EndPrinciple
• Whereisthestatestored?
• Fate-sharing
ThreeInternetDesignPrinciples
• Notethattheend-to-endprinciplereliedon“fate-sharing”• Invariantsonlybreakwhenendpointsthemselvesbreak
• Minimizethedependenceonothernetworkelements
• Thisshoulddictateplacementofstate
Fate-Sharing
• Whenstoringstateinadistributedsystem,colocateitwithentitiesthatrelyonthatstate
• Onlywayfailurecancauselossofthecriticalstateisiftheentitythatcaresaboutitalsofails…• …inwhichcaseitdoesn’tmatter
• Oftenarguesforkeepingnetworkstateatendhostsratherthaninsiderouters• E.g.,packetswitchingratherthancircuitswitching
GeneralPrinciple:Fate-Sharing
Questions?
• Howtobreaksystemintomodules
• Dictatedbylayering
• Wheremodulesareimplemented
• DictatedbyEnd-to-EndPrinciple
• Wherestateisstored
• DictatedbyFateSharing
DecisionsandtheirPrinciples
FromArchitecturetoDesign:
DesignGoals
• Wroteapaperin1988thattriedtocapturewhytheInternetturnedoutasitdid
• Itdescribedanorderedlistofprioritiesthatinformedthedecision
• Whatdoyouthinkthoseprioritieswere?
DavidClark
• Connectexistingnetworks
• Robustinfaceoffailures
• Supportmultipletypesofdeliveryservices
• Accommodateavarietyofnetworks
• Allowdistributedmanagement
• Easyhostattachment
• Costeffective
• Allowresourceaccountability
InternetDesignGoals(Clark’88)
Wantoneprotocolthatcouldbeusedtoconnectanypairof(existing)networks
• Differentnetworksmayhavedifferentneeds
• Forsome:reliabledeliverymoreimportant
• Forothers:performancemoreimportant
• Butthereisoneneedthateverynetworkhas:connectivity
• TheInternetProtocol(IP)isthatunifyingprotocol• All(existing)networksmustbeabletoimplementit
#1:ConnectExistingNetworks
Aslongasnetworkisnotpartitioned,twohostsshouldbeabletocommunicate(eventually)
• Musteventuallyrecoverfromfailures
• Verysuccessfulinthepast;unclearhowrelevantnow• Availabilityisbecomingincreasinglyimportantthanrecovery
#2:RobustinFaceofFailures
Differentdeliveryservices(applications)shouldbeabletoco-exist
• Alreadyimpliesanapplication-neutralframework
• Buildlowestcommondenominatorservice
• Again:connectivity• Applicationsthatneedreliabilitymayuseit
• Applicationsthatdonotneedreliabilitycanignoreit
• Thisisn’tasobviousasitseems…
• Whatwouldapplicationsin2050need?
#3:SupportMultipleTypesofDeliveryServices
Questions?
Mustbeabletosupportdifferentnetworkswithdifferenthardware
• Incrediblysuccessful!• Minimalrequirementsonnetworks
• Noneedforreliability,in-order,fixedsizepackets,etc.• Aresultofaimingforlowestcommondenominator
• Again:Focusonconnectivity• Letnetworksdospecificimplementationsforotherfunctionalities
• Automaticallyadapt:WiFi,LTE,3G,4G,5G….
#4:VarietyofNetworks
Noneedtohaveasingle“vantage”pointtomanagenetworks
• Bothacurseandablessing• Importantforeasydeployment
• Makesmanagementhardtoday
• Recenteffortshaveimprovedmanagementofindividualnetworks
• ButnoattempttomanagetheInternetasawhole…
• Whatmightmakethiscomplex?
#5:DecentralizedManagement
Themechanismthatallowshoststoattachtonetworksmustbemadeaseasyaspossible,butnoeasier
• Clarkobservesthatcostofhostattachmentmaybehigherbecausehostshadtobesmart
• Buttheadministrativecostofaddinghostsisverylow,whichisprobablymoreimportant
• Plug-and-playkindofbehavior…
• Andnowmosthostsaresmartforotherreasons• Sothecostisactuallyminimal…
#6:EasyHostAttachment
Makenetworksascheapaspossible,butnocheaper
• Cheaperthancircuitswitchingatlowend
• Moreexpensivethancircuitswitchingathighend
• Notabadcompromise:
• Cheapwhereitcounts(low-end)• Moreexpensiveforthosewhocanpay…
#7:CostEffective
Eachnetworkelementmustbemadeaccountableforitsresourceusage
• Failure!
#8:ResourceAccountability
“Werejectkings,presidentsandvoting.Webelieveinroughconsensusandrunningcode.”
--DavidClark
InternetMotto
• Buildsomethingthatworks
• Connectexistingnetworks
• Robustinfaceoffailures
• Supportmultipletypesofdeliveryservice
• Accommodateavarietyofnetworks
• Allowdistributedmanagement
• Easyhostattachment
• Costeffective
• Allowresourceaccountability
RealGoals
• Whatgoalsaremissingfromthislist?
• Suggestions?
• Whatwouldtheresultingdesignlooklike?
Questionstothinkabout
• Performance
• Security• Resiliencetoattacks(denial-of-service)• Endpointsecurity• Trackingdownmisbehavingusers
• Privacy
• Availability
• Resourcesharing(fairness,etc.)
• ISP-levelconcerns• Economicissuesofinterconnection
Someofthemissingissues
Questions?
• Beginningof“Designofcomputernetworks”
• StartwithLayer1andLayer2• Physicalbits(verylittle)• Localbest-effortforwarding• Lotofinterestingaspects• Lotofgroupactivities• …
Nextlecture