Promptness

[Jonathan Shapiro]

   We've been using a way to characterize operational notions such as
   "promptness" and "fairness" that maks them much easier to think about. 
   Rather than trying to be precise about what is actually possible to
   guarantee, be precise about what the goal is, and then declare that systems
   are "expected" to achieve it.

For soft real-time systems, where one is prepared to recover from
occasional contract failure, this seems like a fine idea.  It's a more
Agoric approach, and therefore more realistic given limited resources.
In many ways, I'm quite happy to run the third movie back on my screen
in degraded mode, though there are some interesting challenges in
deciding what forms of degradation are acceptable and implementable.

We then can get into discussions of admission control and
decommitment.  The fourth movie back should probably just give up --
it isn't making useful progress in any case.  The fifth movie program
should probably come up and tell me that my machine isn't fast enough.

If we are talking about mission-critical hard RT systems, then
expectations seem inadequate.  The customer won't be comforted by
expectations when the Boeing goes down.  In this case, the contract is
either formally met or it isn't.

Are the two discussions (hard commit, expectation) orthogonal, or can
we come up with some clever way to make them part of a continuum?


Jonathan