Back to index
Design of Distributed Systems Supporting Local Autonomy
David D. Clark, Liba Svobodova, MIT LCS
One-line summary:
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.
Overview/Main Points
- 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
then get
- autonomy,
- 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
node.
- Other copies can exist, but they are not the same as the
original object.
- 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
"local version".
- Justification:
- Most accesses are to your own data
- Most nonlocal accesses are read-only; conflict resolution
should be infrequent
Implications of this philosophy for various areas of DS performance:
- Efficiency: due to locality argument above, no problems. App
must know when it's operating on a copy since this allows
optimization.
- Reliability (in the data loss sense):
- Functions and data can be replicated on independent
hardware (availability)
- low-level error propagation restricted by physical
separation (hardware)
- 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
necessary.
- 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
etc.
3 requirements for a node's OS:
- 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)
Relevance
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.
Flaws
No implementation is described, even though the authors admit certain
subproblems presented are of daunting complexity.
Back to index