Back to index
Design of Distributed Systems Supporting Local Autonomy
David D. Clark, Liba Svobodova, MIT LCS
A particular philosophy of DS architecture based on autonomy, and
the functionality each node's OS must provide to be consistent with this
philosophy. Lots of vision, no implementation, sparse support.
Implications of this philosophy for various areas of DS performance:
- Justification for DS is not primarily economic: some tasks are
just naturally distributed
- In "real life" distributed tasks, each agent maintains a high
degree of autonomy. Use this as principle for building a DS; we
- some privacy (node controls its own data),
- availability (one node doesn't bring down whole system).
- 3 classes of components: nodes, servers (invisible to app
writers), comm substrate
- Each piece of info in the DS has 1 and only 1 home, on some
- Other copies can exist, but they are not the same as the
- Home node retains control over all copies, eg it may
encrypt them if it wants.
- Applications kow if they're touching the real object or a
- Most accesses are to your own data
- Most nonlocal accesses are read-only; conflict resolution
should be infrequent
3 requirements for a node's OS:
- Efficiency: due to locality argument above, no problems. App
must know when it's operating on a copy since this allows
- Reliability (in the data loss sense):
- Functions and data can be replicated on independent
- low-level error propagation restricted by physical
- If a node fails, info for which it was the home node
becomes temporarily unavailable.
- Comm substrate should be fault tolerant (multi-link).
ARPANET had just been deployed and showed this was possible.
- Transactional semantics/distributed atomic update: we know it's
important and complicated,
we have no story for it, it should only be used when absolutely
- Extensibility: they propose RPC service registration and note the
problems it brings (stale nameserver entries, etc.)
- Protection: assume untrusted network, use end-to-end encryption
- Expose whether data is original or copy (remote)
- Uniform set of comm. and authentication protocols
- Allow each node control how it stores data (don't make the OS
enforce a policy)
Underlying autonomy principles and "get OS out of the way" are
application-level-framing and end-to-end arguments. Clark went on to
write about these things later.
Main contribution here is to describe a particular philosophy of
distributed-system node design at a time when many others were pushing
for tightly-integrated "transparent" distributed systems.
No implementation is described, even though the authors admit certain
subproblems presented are of daunting complexity.
Back to index