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

Future Internet DesignA new NSF initiative

David D. Clark

John Wroclawski, Mothy Roscoe, David Andersen, Craig Partridge

Darleen Fisher, Guru Parulkar

DO NOT DISTRIBUTE

NeTSNeTS 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??

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.

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.

What will be happening in 10 yearsNew 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.

The scope of the challengeIs 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).

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.

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.

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.

Possible topics

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

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…)

A Wild Idea: we ought to do someResearch on Architecture

Electricity: Today…

(…Architecture ???)

Electricity: 1800…

(…Architecture Today)

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)

Applications

Congestion control

Routing

Scheduling

Channel

Cross-layer interaction in form of “congestion prices”(cost per unit flow ofsending data alonga 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)

Language-Defined Architecture

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))))

†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

Wild Ideas

In Internet Architecture

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

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.

Firewall

Misconfiguration

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”

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.

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.

Question 2:

How can we make the process of defining and testing a Future Internet Architecture a success?

DO NOT DISTRIBUTE

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

FIND Informational Meeting

December 5th, Washington Area