Implicit Stuff

• 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?
• Explicit
  • 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.
• requirements
  • local agent reacts to observations
  • is any local process thinking about global state?
• what causes explicit systems to break?
  • scale
  • false assumptions

Design issues: Implicit vs. explicit control methods, data semantics, etc.

• Ex: mem mgt in Inktomi. Central manager that knows the directory? Distribute responsibility to local VM system on each node?
• 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 should. Ex: 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 go.")
• 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 analysis?
• 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 abstractions "properly"?