lecture05-principles-goals - Cornell University · lecture05-principles-goals.key Created Date:...
Transcript of lecture05-principles-goals - Cornell University · lecture05-principles-goals.key Created Date:...
ComputerNetworks:ArchitectureandProtocols
CS4450
Lecture5
-DesignGoals
RachitAgarwal
Announcements
• Coursewebpageisyourone-stopshop
• Officehourshavebeenannounced• Westartimmediately(startingtoday)
• Myofficehourstomorrowwillbecoveredbysomeone
• Thisweekisextremelybusyforme
• Sorryifmyresponsestoyouremailsorpiazzapostsaredelayed
• Iwillbebackinfullswingstartingnextweek
• ProblemSet1solutionswillbereleasedtoday
ContextforToday’sLecture
• Solvingproblemsrelatedtopropagationandtransmissiondelays
• Somein-classexercises
• Wewillsolvethemtogether
• WhywastheInternetdesignedthewayitwas?
• Howtobreaksystemintomodules
• Layering
• Wherearemodulesimplemented
• End-to-EndPrinciple
• Whereisstatestored?• Fate-Sharing
Recap:Threedesignprinciples
5
• Akindofmodularity
• Functionalityseparatedintolayers• Layerninterfaceswithonlylayern-1andlayern+1
• Hidescomplexityofsurroundinglayers
Recap:Layering
Builtontopof
reliabledelivery
Builtontopofbest-
effortforwarding
Builtontopof
best-effortrouting
Builtontopof
physicalbittransfer
AssumethecondiSon(IF)holds.Then,
• End-to-endimplementation
• Correct• Generalized,andsimplifieslowerlayers
• In-networkimplementation
• Insufficient• Mayhelp—orhurt—performance
Recap:End-to-endPrinciple(Interpretation)
• Whenstoringstateinadistributedsystem,colocateitwithentitiesthatrelyonthatstate
• Onlywayfailurecancauselossofthecriticalstateisiftheentitythatcaresaboutitalsofails…• …inwhichcaseitdoesn’tmatter
• Oftenarguesforkeepingstateatendhostsratherthaninsiderouters• E.g.,packetswitchingratherthancircuitswitching
Recap:Fate-Sharing
• Howtobreaksystemintomodules
• Dictatedbylayering
• Wheremodulesareimplemented
• DictatedbyEnd-to-EndPrinciple
• Wherestateisstored
• DictatedbyFateSharing
Recap:DecisionsandtheirPrinciples
Questions?
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,twohostsshouldbeableto
communicate(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
Themechanismthatallowshoststoattachtonetworksmustbemadeas
easyaspossible,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
• 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• Lotsofinterestingaspects• Lotsofgroupactivities• …
Nextlecture