An Introduction to the future
of the Internet (part 1)
David Clark
MIT CSAIL
July 2012
1
The Internet is a success

So why would we want to rethink its design?



It is not that some broad class of application is
unsupported.


Application designers have shown the broad utility of
the Internet (within some limits).
The issues are centered in the broader context
within which the Internet is positioned.

2
It’s not the data plane.
Packets have proven their generality, and we have
polished the data forwarding function for years.
Need to consider a broad range of requirements.
Issues to consider










3
Security
Availability and resilience
Economic viability
Better management
Meet society’s needs
Longevity
Support for tomorrow’s computing
Exploit tomorrow’s networking
Support tomorrow’s applications
Fit for purpose (it works…)
In the beginning




We really had no idea what we were
doing.
A lot we got right (perhaps surprising…)
A lot was almost an accident.
We did not understand:



4
How to write a standard
Dynamics of control
Correct system modularity
Now

We know a lot more


Requirements have gotten a lot more
complex



5
About requirements, design methods and
mechanisms.
Many more interests ask to be served.
Daunting complexity
Not just a technical problem
Warning

Computer scientists like to talk about
mechanism and performance.

(I am somewhat critical of this…)



6
Forwarding schemes: 54 and counting.
This set of talks is more about
requirements and design approaches.
I will discuss mechanism, but as
illustration.
Outline of these lectures

Look at some of these important objectives



Describe some emerging proposals and
approaches



Sometimes conflicting, sometimes clear.
(Sometimes my personal point of view.)
So wander between requirements and
mechanism.


7
What is wrong with the network of today?
Why is it worth considering alternative designs?
Mechanism is easier to think about.
Requirements are more fundamental.
Designing the future

Explicit projects in US and EU to think
about an Internet for the future.


Ask what our global network of 15 years from
now should be.
US: FIND (Future Internet Design) and FIA
(Future Internet Architecture)


EU: Framework projects

8
Nebula, MobilityFirst, Named Data Networking,
Expressive Internet Architecture (XIA), ChoiceNet
PSIRP, PURSUIT, 4WARD, Haggle, Trilogy…
Why take a longer view?

Two ways to pick research topics:

Look at the problems of today and try to fix
them.


Sometimes called “incremental”, which is NOT a
bad word or a bad way to proceed.
Describe a goal: where are we trying to get?
An objective imposes a bias on forward progress.
 Sometimes called “clean slate”, which is often misunderstood.


9
Not a rejection of the present, nor a demand for a fork-lift
replacement of the current network.
Issues to consider










10
Security
Availability and resilience
Economic viability
Better management
Meet society’s needs
Longevity
Support for tomorrow’s computing
Exploit tomorrow’s networking
Support tomorrow’s applications
Fit for purpose (it works…)
What was that list??


Those were not requirements.
They are a wish list.



It is a big jump from any of these items to
the design of mechanism.

11
Desiderata
An aide-memoire
And that is a big issue.
Design methodology

We must think about the process of moving from objectives to
specific requirements to mechanisms and architecture.

If the problem is too big to consider at once, must modularize the
design process.



12
Beware an over-dependence on layering.
That list of issues represents a broad set of criteria:
 Not just the “traditional”: performance/optimization, generality,
new technology
 Implies a multi-dimensional assessment of new ideas. Implies
tradeoff and balancing.
We understand a lot more now than we did in 1974.
 This current work should be based on methodical design,
analysis, theory.
Security

Use as a first example of a requirement.


Hard and important.
Why is the problem so hard?

We don’t agree on the definition of good security




We want different outcomes in different contexts.
We cannot correct the insecurity of end-nodes.
Old ideas: (good ideas, but not why we thought.)

Confidentiality, integrity, availability

How does this relate to firewalls, VPNs?

13
A balance among stake-holders.
After the fact--not a part of the network
A different modularity

Attacks on the network


Attacks on communication





14
A special case of availability.
Information assurance.


Infiltration (can lead to most anything)
So either prevent infiltration or limit its consequences.
Denial of service


Confidentiality and integrity addressed with encryption.
Availability?? The central objective of networks.
What else?
Attacks on the host


Routing, supply chain
Sign the information, not the connection.
National security
Who is responsible?

Attacks on the network.


Attacks on communication.



15
A contested space.
Information assurance


A contested space: end-node, network, application designer, user.
DDoS.


Confidentiality and integrity can be delegated to end-nodes. (contested)
Availability is a shared responsibility.
Attacks on hosts.


The network.
Unclear once you get deeply into it.
National security.
An ugly situation

Everybody says we need better security, but.



Security is an emergent property of a running
system


Depends on architecture, mechanism, allocation of
responsibility, operational issues.
Most of my security friends design mechanisms.

16
No agreement as to what that really means.
No agreement as to which actors play which role in
producing it.
Much easier—does not make your head hurt…
Doing better next time?

The hypothesis of the future Internet
research agenda is that we could do a
better job if we freed ourselves from the
constraints of the present.


17
Do we actually know enough to do that?
What do we actually know about the
fundamentals of network architecture, and its
relation to these broad set of requirements?