Application ArchitectureInternet Architecture

David D. Clark

MIT CSAIL

September 2005

What is the problem?

Internet designers provided packet carriage and a DNS, and left the rest up to the application designer.

That limited function leaves a lot for the application designer to figure out.

To users, the Internet is the applications.

Poor application design can ruin the Internet.

Cartoon vs. reality

Cartoon: the application just runs in the end-nodes, so it can do anything it wants.

Reality: Applications today are sophisticated combinations of end-node function, servers, ISP mediation/interference, regulation/law and social conventions.

Designers solve a rich set of problems beyond the nominal goal of the application. Can we catalog these problems? Does the Internet provide the right support?

Where to start? Servers

Modern apps do not follow a simple end to end model.

(End to end at application level)

They are full of servers and services run by third parties.

Why?

Lots of reasons

Stage content closePre-process content

Specialized device Constrain actions Filter content

Manage identity Centralize authentication Control release of attributes Preserve anonymity

Replicate functions for robustness

Make comms asynchronousMove between end-nodesOutsource functionsCope with NAT, addressingEconomics

What problems are we solving?

Ease of use

Ease of deployment

Performance

Economic (industry) structure

Robustness

Security

Functionality

Security

Re-factor security. Freedom from attack:

Users, end-servers,third-party infrastructure Trusting users who want privacy Untrusting users who want help Third parties that want to intervene

Delegation: who picks and who trusts the servers?

Economics

Should applications be designed taking into account the economic goals of the various stakeholders? User choice of server and provider.

Drives competition and controls prices Prevent ISP capture

Server-based services are basis for revenue generation.

Akamai as source-driven example. Email as receiver-based example.

Ease of deployment

The life cycle of an app, or how do apps grow up? In the beginning, must be end to end. No

servers. If successful, lots of folks get interested, and

jump in. Leads to servers. In the middle? How about peer to peer?

The design of an app should take into account how it is to grow up.

Recognize the stakeholders

Applications are about humans and society. Not just the users of the application.

Lots of parties have a stake in what the application does. Users Governments ISPs (profit, employer, etc.) Rights-holders Large enterprise

Must do stake-holder or tussle analysis

Balance of power

Who can select the servers to be used?n User: delegation (ease of use), filtering

(security), pre-formatting, control anonymity, replication and location, protection (applies to both ends)

n ISP: filtering (value strat, usage control, agent of state), revenue generation

n Third party (state or “other”): filtering (law enforcement protection of rights-holders and censorship), monitoring (law enforcement, taxation)

Extra slides…

An Internet example: ports

Ports would be random, not well-known. Requires host-specific knowledge to filter. ISP filtering (value strat, traffic engineering) much

harder. Firewall filtering much harder. Port scans less useful.

Name server can be anywhere. Per-service name. Hard to launch location-based attack or scan on

name server. But: what names show in messages? What history?

Economics of overlay networks

Overlays are: A tool for sophisticated applications. A tussle tool with ISPs

If the latter, who pays for them? Cannot scale for free. (Can they?)

Prediction: they will be run by the ISPs. The major source of new ISP revenues. Usage based, content based, etc. Engineer them to shape this. Who routes? The alternative: Akamai (global providers).