Future Internet Design A new NSF initiative

1. Future Internet DesignA new NSF initiative David D. Clark John Wroclawski, Mothy Roscoe, David Andersen, Craig Partridge Darleen Fisher, Guru Parulkar

2. NeTS • NeTS research program (NOSS; ProWin; NBD; FIND) FIND Future INternet Design (Research funds FY2006) • “Designing the Internet you want in 10 to 15 years”: trustable, manageable, evolvable, include emerging wireless/sensors/optical technologies & devices, support new applications, economically viable, etc. • Multiple-year “clean-slate” process: Research not constrained by the features of the current Internet • Network Architectural focus • FY2006 NeTS solicitation: • New approaches to network elements/functions (naming, addressing, forwarding, etc.) not full-blown architectures • But conscious that the elements are parts of a potential overall architecture • February deadline?? DO NOT DISTRIBUTE

3. FIND: A challenge question • 1) What are the requirements for the global network of 10 or 15 years from now, and what should that network look like? • To conceive the future, it helps to let go of the present: • 2) How would we re-conceive tomorrow’s global network today, if we could design it from scratch? • This is not change for the sake of change, but a chance to free our minds.

4. Isn’t today’s net good enough? • Security and robustness. • As available as the phone system • Been trying for 15 years--try differently? • Easier to manage. • Really hard intellectual problem • No framework in original design. • Recognize the importance of non-technical considerations • Consider the economic landscape. • Consider the social context.

5. What will be happening in 10 years • New network technology. • Wireless • Mobility • Dynamic capacity allocation • Dynamic impairments • Advanced optics • Dynamic capacity allocation (again!) • New computing paradigms • Embedded processor, sensors, everywhere • Whatever computing is, that is what the Internet should support. • The Internet grew up in a stable “PC” time.

6. The scope of the challenge • Is it “Internet classic”? A cloud of routers with general purpose computers at the edges? • No! The scope of the question is much bigger than that. • Ask: what will “the edge” look like. That is where the action is. • Sensors. Embedded computers. • Ask: what is it that users do? Try to conceptualize a network that supports that. • Information access and dissemination. • Location management and location-aware systems. • Identity management systems. • Conceptualize at a higher level (not higher layer).

7. What should we reconsider? • For the moment, everything. • Packets, datagrams, circuits--everything. • Our religious beliefs • End to end, transparency, our model for layering. • To conceive of a future, we have to let go of the present. • This does not mean that we cannot get there incrementally.

8. Defining success • We throw away the current Internet. • The most dramatic form of success. • We set a goal, and the we realize we can get there incrementally. • Impose a bias or direction on change. • Lots of fresh ideas leak into the present Internet.

9. If we don’t do this? • If we don’t step up to conceive of what networking will be in 10 years: • A narrowing of the utility of the Internet to specific purposes. E-commerce? • A pervasive loss of confidence in Internet. • Limit our ability to exploit new technology. • A loss of funding (inside NSF) to sectors that seem more relevant and vigorous. • A gentle glide into irrelevance for research.

10. Location services Identity management Identity without location Information arch The role of virtualization The role of overlays The role of packets Format: need we agree Managing aggregates Dynamic circuits Diagnosis and repair DHMP Firewalls: kill or love? Protecting the edge The future of E2E Secret life of apps. Diffusing traffic Complexity and limits Possible topics

11. Question 1: • Give us an example or two of exciting and novel ideas that we should consider for a Future Internet Architecture. • (I know, this is not a question. Answer it anyway…)

12. A Wild Idea: we ought to do someResearch on Architecture • Electricity: Today… • (…Architecture ???) Electricity: 1800… (…Architecture Today)

13. Applications Congestion control Routing Scheduling Channel Theoretically Derived Architectures • MANET resource allocation formulated as global optimization problem • Primal-dual decomposition generates a set of dual problems/algorithms/modules: • Local (except scheduling) • Tied together through congestion prices • System Architecture traceable to theoretically provable optimality.. Utility function U_s{x_s} (strictly concave function of the sending rates) Cross-layer interaction in form of “congestion prices” (cost per unit flow of sending data along a link to a destination) Optimal Cross-Layer Congestion Control, Routing, and Scheduling Design in Ad Hoc Wireless Networks. Lijun Chen, Steven H. Low, Mung Chiang†,John C. Doyle (Caltech and †Princeton)

14. Role Based Architecture† imagined flexible, customizable location and composition of architectural functions But just a data path mechanism. Where do semantics come from? One possible idea: Architecture Composition Languages Explicit description may give: Introspection Run-time Validation … (defmethod (flow :check-security-policy) ((port protocol) `(cond ((eq port 'smtp) (…)))) (defwrapper (flow :check-security-policy) ((port protocol) . wrapped-body) `(cond ((eq port 'smtp) (format t "~s no mail for you, monkey-boy~%" self)) (t ,@wrapped-body (format t "~s pass traffic for ~s onward~%" self port)))) Language-Defined Architecture †From Protocol Stack to Protocol Heap - Role Based Architecture. Robert Braden, Ted Faber, and Mark Handley. Proc. Hotnets-1, ACM SIGCOMM CCR, v33 #1, Jan 2003

15. Wild Ideas In Internet Architecture

16. Firewall Misconfiguration Promises, promises • What is the goal of routing? • To provide a path from A->D • How is it accomplished? • A--B + B--C + C--D • Add a sprinkle of transitivity • Voila: A->Z • But it doesn’t always work.

17. So what should routing do? • Provide two (three? four?) paths from A->D. • Maximally failure disjoint • And then? • Let end hosts/applications/networks choose between them • Or use them in parallel • Why? • [RON, SOSR, MONET, Akella et al., Detour] • Path choice helps in a big way. • But all had “warts”

18. Internet Wart Removal • Why do we have NATs and firewalls? • Address space (perceived?) shortage • Add more addresses. Easy. • Security (or perception thereof). • Theory: • For all networks, now and forever, • Exist people who wants/needs to control traffic flow • These people have money. • Router vendors like money. • If we do not provide the right mechanisms, they will create the wrong ones.

19. How do we remove the warts? • Provide fine-grained network access control • (see “off by default” - today.) • Goal: Access policy for host = • min(host policy + network policy) • Realization: Capability-based • Send a “may I speak to you?” packet • Network can interpose on these. Doesn’t need to interpose on normal traffic. (!) • Get back a response. Or not. Possibly delegate (DOA). • Eliminate need for innovation-crushing hacks.

20. Question 2: • How can we make the process of defining and testing a Future Internet Architecture a success?

21. FIND - Different Process • Explicit “goal” oriented -- Future Internet • Not usual for NSF • Longer timescale with sustained funding • Three phases -- iterative and overlapping • Exploration • Convergence • Experimentation at scale • “Competitive cooperation” model • Competition to bring out the best • Cooperation to build on each others work to deliver Future Internet • Competition -- we know it well • Cooperation -- we know it less well • Regular meetings -- three times a year • A community appointed group to help oversee, steer, and synthesize • Commitment to openness and transparency DO NOT DISTRIBUTE

22. FIND Informational MeetingDecember 5th, Washington Area