Unformatted text preview:

CS 268: Lecture 24 Designing for the FutureIssues for the FutureWe Aren’t in Kansas Anymore...User Cooperation?Congestion ControlExampleDesigning for SelfishnessInterdomain RoutingIncentives in PracticeTussle PaperDesigning for TussleInterfacesCompetitionAnother ViewpointYet Another ViewpointDiscussionStill Another ViewpointThe Paper’s Fundamental AssumptionOur Founding (Funding) FableDo Traditional Testbeds Really Test?What about Deployment?We Are at an ImpasseThe Community’s ResponseOvercoming the Impasse?Testing: Virtual TestbedYou’ve Heard This All Before….Deployment: Standard Overlay StoryPondering SuccessThe Purist ScenarioThe Pluralist ScenarioPurists vs PluralistsThree Discussion QuestionsThe Ultimate Pluralist: Active NetworkingAn Active Node Toolkit: ANTSActive NodesWhere Is the Code?Code DistributionApplicationsPractical IssuesPhilosophical IssuesActive Networking and the E2E Principle?Clark, Saltzer, and ReedSlide 43Slide 44Will ISPs Adopt?TaxonomySlide 471Scott Shenker and Ion StoicaComputer Science DivisionDepartment of Electrical Engineering and Computer SciencesUniversity of California, BerkeleyBerkeley, CA 94720-1776CS 268: Lecture 24Designing for the Future2Issues for the FutureFuture designs (last lecture)Evolving the Internet to incorporate these designsLiving in the brave new world3We Aren’t in Kansas Anymore...Internet was designed in cohesive environment-Everyone had the same goals, worked togetherThe Internet is now fully commercialThere are many competing interests-Users no longer share same goals-Providers now compete with each other4User Cooperation?Originally users were all part of a joint endeavorNow, each user is engaged in their own task-Often completely unaware of other users-Care only about own performanceWhy should we assume users will cooperate?-Why wouldn’t they act selfishly?5Congestion ControlEach user’s performance is a function of bandwidth and delay/dropsUsers adjust their sending rate to maximize their performanceWhat is the resulting equilibrium?-FIFO routers: terrible!-FQ routers: very good! (detailed game theory analysis)6ExampleUi = ri/diPoisson: di=1/(1-rtot)Social Optimal: rtot= 1/2, Utot = 1/4Nash Equilibrium w/FIFO: rtot= n/(n+1), Utot = (n+1)-2Nash Equilibrium with FQ: social optimal7Designing for SelfishnessAssume every user (provider) cares only about their own performance (profit)Give each user a set of actionsDesign a “mechanism” that maps action vectors into a system-wide outcomeChoose a mechanism so that user selfishness leads to socially desirable outcome-Nash equilibrium, strategy-proof, etc.8Interdomain RoutingAssume ISPs incur costs for carrying packetsWant to decrease total costs by carrying packets over lowest cost pathsHow to get ISPs to declare costs without lying?General approach: VCG mechanism-generalization of 2nd price auctionOnly slightly more complicated than BGP9Incentives in PracticeSee UW paper on practical uses of incentives10Tussle PaperConflicting interests are inevitable, and ever-changingAccept the presence of tussles, and design accordingly11Designing for TussleDesign for choice, not for outcome-separate mechanism from policyModularize design along tussle boundaries12InterfacesMake value visible: allow parties with compatible interests to reach equilibriumMake costs visible: allow parties to make informed choicesProvide tools to isolate and resolve faults/failures13CompetitionKey to innovation is competitionOnly the fear of competition will lead ISPs to adopt new designs, offer new servicesCompetition will only arise when users have “choice”-choice in local ISP-choice in downstream ISPs•e.g., route control to guide packets to ISPs with better serviceWhat do you think?14Another ViewpointBasic Internet service not a viable businessCompetition will only lead to everyone going brokeNeed to create public Internet service providers-Back to the future.....15Yet Another ViewpointNew services (QoS, Multicast) weren’t adopted because inter-provider agreements are too primitiveThey don’t make value visible, so that ISPs can’t charge for giving better service-they can do so for users, but not between themselves!Can’t give users choice without passing on costs appropriately16Discussion17Still Another Viewpoint“Overcoming the Internet Impasse through Virtualization”-hotnets this year18The Paper’s Fundamental AssumptionThe Internet’s current evolutionary path will not adequately meet our future needs-Security-Reliability-New application and user requirements-…..We will need a significant architectural change-Perhaps not now, but eventually19Our Founding (Funding) FableResearchers invent new architecturesArchitectures are validated on a testbedIETF, ISPs, and router vendors collaborate to deploy new design20Do Traditional Testbeds Really Test?Production-oriented testbeds:-Real traffic provides good validation-But can test only very incremental changesResearch-oriented testbeds:-Can test radical architectures-Lack of real traffic results in poor validationBoth are expensive (dedicated bandwidth)21What about Deployment?Architectural change requires ISP consensus-Hard to agree-No competitive advantage from architectural innovation-All have huge sunk investment in the status quoISPs are unlikely candidates for architectural changeArchitecture isn’t just static, its decaying-Ad hoc workarounds muddy the architectural waters22We Are at an ImpasseWe can’t test new architectures-Despite sizable investments in testbedsWe can’t deploy new architectures-And things are getting worse, not betterYet there are pressing requirements for which the current architecture is not well suited23The Community’s ResponseFocus on areas where we can have impact:-Empirical studies-Incremental changes (subject to current constraints)Small stream of architectural proposals-Paper designs without hope of deployment-More science fiction than engineeringHave largely abandoned hope of effecting fundamental architectural change-Living with, rather than overcoming, the impasse24Overcoming the Impasse?Must be able to test new architectures:-Wide range of architectures-Real traffic from willing individuals-Low overhead for individual researchersMust have a plausible deployment story-Not probable, just


View Full Document

Berkeley COMPSCI 268 - Designing for the Future

Documents in this Course
Lecture 8

Lecture 8

33 pages

L-17 P2P

L-17 P2P

50 pages

Multicast

Multicast

54 pages

Load more
Download Designing for the Future
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Designing for the Future and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Designing for the Future 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?