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 FutureFuture designs (last lecture)Evolving the Internet to incorporate these designsLiving in the brave new world3We Aren’t in Kansas Anymore...Internet was designed in cohesive environment-Everyone had the same goals, worked togetherThe Internet is now fully commercialThere 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 endeavorNow, each user is engaged in their own task-Often completely unaware of other users-Care only about own performanceWhy should we assume users will cooperate?-Why wouldn’t they act selfishly?5Congestion ControlEach user’s performance is a function of bandwidth and delay/dropsUsers adjust their sending rate to maximize their performanceWhat is the resulting equilibrium?-FIFO routers: terrible!-FQ routers: very good! (detailed game theory analysis)6ExampleUi = ri/diPoisson: di=1/(1-rtot)Social Optimal: rtot= 1/2, Utot = 1/4Nash Equilibrium w/FIFO: rtot= n/(n+1), Utot = (n+1)-2Nash Equilibrium with FQ: social optimal7Designing for SelfishnessAssume every user (provider) cares only about their own performance (profit)Give each user a set of actionsDesign a “mechanism” that maps action vectors into a system-wide outcomeChoose a mechanism so that user selfishness leads to socially desirable outcome-Nash equilibrium, strategy-proof, etc.8Interdomain RoutingAssume ISPs incur costs for carrying packetsWant to decrease total costs by carrying packets over lowest cost pathsHow to get ISPs to declare costs without lying?General approach: VCG mechanism-generalization of 2nd price auctionOnly slightly more complicated than BGP9Incentives in PracticeSee UW paper on practical uses of incentives10Tussle PaperConflicting interests are inevitable, and ever-changingAccept the presence of tussles, and design accordingly11Designing for TussleDesign for choice, not for outcome-separate mechanism from policyModularize design along tussle boundaries12InterfacesMake value visible: allow parties with compatible interests to reach equilibriumMake costs visible: allow parties to make informed choicesProvide tools to isolate and resolve faults/failures13CompetitionKey to innovation is competitionOnly the fear of competition will lead ISPs to adopt new designs, offer new servicesCompetition 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 serviceWhat do you think?14Another ViewpointBasic Internet service not a viable businessCompetition will only lead to everyone going brokeNeed to create public Internet service providers-Back to the future.....15Yet Another ViewpointNew services (QoS, Multicast) weren’t adopted because inter-provider agreements are too primitiveThey 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 AssumptionThe 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) FableResearchers invent new architecturesArchitectures are validated on a testbedIETF, 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 changesResearch-oriented testbeds:-Can test radical architectures-Lack of real traffic results in poor validationBoth 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 quoISPs are unlikely candidates for architectural changeArchitecture isn’t just static, its decaying-Ad hoc workarounds muddy the architectural waters22We Are at an ImpasseWe can’t test new architectures-Despite sizable investments in testbedsWe can’t deploy new architectures-And things are getting worse, not betterYet there are pressing requirements for which the current architecture is not well suited23The Community’s ResponseFocus 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 engineeringHave 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 researchersMust have a plausible deployment story-Not probable, just
View Full Document