Transcript FIND and Architecture

Future Internet Design
A new NSF initiative
David D. Clark
John Wroclawski, Mothy Roscoe,
David Andersen, Craig Partridge
Darleen Fisher, Guru Parulkar
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 fullblown architectures
•
But conscious that the elements are parts of a potential overall architecture
• February deadline??
DO NOT DISTRIBUTE
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 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.
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).
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 some
Research on Architecture
Electricity: 1800…
(…Architecture Today)


Electricity: Today…
(…Architecture ???)
Theoretically Derived Architectures

Utility function
U_s{x_s}
(strictly concave function
of the sending rates)
Applications

Congestion control
Cross-layer
interaction in
form of
“congestion prices”
(cost per unit flow of
sending data along
a link to a destination)
MANET resource allocation
formulated as global optimization
problem
Primal-dual decomposition
generates a set of dual
problems/algorithms/modules:

Routing

Scheduling

Channel
Local (except scheduling)
Tied together through congestion
prices
System Architecture traceable to
theoretically provable optimality..
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




(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


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
…
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
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Ideas
In Internet Architecture
Promises, promises
• What is the goal of routing?
– To provide a path from A->D
• How is it accomplished?
Firewall
– A--B + B--C + C--D
Misconfiguration
– Add a sprinkle of transitivity
– Voila: A->Z
• But it doesn’t always work.
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?
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
FIND Informational Meeting
December 5th, Washington Area