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