- What are the design principles?
- centralized vs. distributed
- explicit vs. implicit
- application semantics - guaranteed performance
vs. probabilistic performance - notion vs. correctness?
- Implicit methods
- approximations of explicit method, used when explicit
method would be too complex
- penalties of mistaken implication - can affect
performance of system of a whole?
- using dataflow natural to system to infer control flow.
- layering? layer is implicit if using info from layer
above it in order to deduce information
- "Peek" - this is the essence...?
- selection abstraction breaking?
- if no system components communicate with each other in
order to infer/convey information, but merely local
information gleaned from applications
- e.g. implicit: TCP. If app never opens socket, you
never get into situation where TCP daemons are
exchanging state info. Only application derived events
can cause system state information to be inferred.
- local agent reacts to observations
- is any local process thinking about global state?
- what causes explicit systems to break?
Design issues: Implicit vs. explicit control methods, data
- Ex: mem mgt in Inktomi. Central manager that knows the
directory? Distribute responsibility to local VM system on each
- Ex: TranSend load balancing and remote execution.
- Ex: Cache coherence: the other extreme; apps don't "expect" failure
modes there, and everything is centralized.
- Hypothesis: When you can get by with implicit methods/hints, you
TCP congestion control. Explicit methods may be more efficient
but more restrictive, and are sometimes infeasible due to system
complexity or distributed authority. (Joe H.: "In fascist
countries, the trains
run on time." David C.: "But they never go where you want to
- Implicit methods can exhibit weirdness in corner cases.
Sometimes the decision is based on what the penalty is for making
a mistake using the implicit method.
Attempts to define terms
- System: collection of processes performing a function
- Application: things that runs on the system
(Joe H.: it's only a real system if it can support a variety of
heterogeneous applications, as opposed to a dedicated system such
as a DB or a robot)
- Explicit: entities in system actively exchange any information
beyond that conveyed by "normal" application data flow.
- "Peek": sometimes the lower layers use the upper layer semantics
as hints (SRM, ALF, ...) (Dave W: "selective abstraction
breaking", like looking at other people's traffic to do
congestion control. Also: OS following DB research in letting
apps manage their own resources; TCP congestion control based on
peeking since there was no abstraction in original TCP; etc)
Food for thought
- Are explicit systems more robust? DO they submit more readily to
- Do implicit systems necessarily scale better?
- How about adaptive systems? Is that axis orthogonal to implicit
vs. explicit, or to the scalability axis?
- Joe H.: Implicit system == some player can decide not to play,
but system still works.
- Where could we "cheat" (peek) to solve something that's not
working now? How far will it get us to redesign some