Application Architecture Internet Architecture David D Clark MIT

Application Architecture Internet 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. n n 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 close Pre-process content n n n Specialized device Constrain actions Filter content Manage identity n n n Make comms asynchronous Move between end-nodes Outsource functions Cope with NAT, addressing Economics Centralize authentication Control release of attributes Preserve anonymity Replicate functions for robustness

What problems are we solving? Ease of use Ease of deployment Performance Economic (industry) structure Robustness Security Functionality

Security Re-factor security. n Freedom from attack: n Users, end-servers, third-party infrastructure Trusting users who want privacy n Untrusting users who want help n Third parties that want to intervene Delegation: who picks and who trusts the servers? n

Economics Should applications be designed taking into account the economic goals of the various stakeholders? n User choice of server and provider. Drives competition and controls prices n Prevent ISP capture n n Server-based services are basis for revenue generation. Akamai as source-driven example. n Email as receiver-based example. n

Ease of deployment The life cycle of an app, or how do apps grow up? n n n 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. n Not just the users of the application. Lots of parties have a stake in what the application does. n n n 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 n n User: delegation (ease of use), filtering (security), pre-formatting, control anonymity, replication and location, protection (applies to both ends) ISP: filtering (value strat, usage control, agent of state), revenue generation 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. n n 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. n n 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: n n A tool for sophisticated applications. A tussle tool with ISPs If the latter, who pays for them? n Cannot scale for free. (Can they? ) Prediction: they will be run by the ISPs. n n The major source of new ISP revenues. Usage based, content based, etc. Engineer them to shape this. Who routes? The alternative: Akamai (global providers).