Skip to content

Interlude: On assumptions

December 7, 2016

This post started out as an introduction to tomorrow’s paper choice, but when it grew too long, I decided to move it to a post all of its own…

Let’s talk about assumptions for a moment. Often implicit (if you’re really lucky, they might be made explicit and described in a ‘system model’ or similar), they have a very powerful effect which can last for years. Assumptions are especially powerful when they shape the design of lower layers in a software stack (or earlier process steps in a value chain) and then become forgotten over time. What we often forget to do is find those assumptions, and then question them. I like to think of two basic kinds of assumptions: pre-conditions and post-conditions.

Pre-conditions tell you when you can expect a certain result to hold (when a certain subsystem will behave as expected). For example, a fault-tolerant system that assumes a non-Byzantine fault model probably won’t provide all of the desired properties in the face of an active adversary. On the flip side, an impossibility result (e.g. FLP) may become possible again if you change some of the environmental assumptions:

… a slight variation of the model turns the problem from an impossible one, to one that is both possible and not particularly complex. https://brooker.co.za/blog/2014/01/12/ben-or.html

Post-condition assumptions are the things we are allowed to assume about the outputs of a process or layer. For example, in some networking models we may be allowed to assume that every message eventually gets delivered. Other models don’t afford this guarantee.

The reason I’ve framed it this way is that it makes it easier to see which questions to ask. In particular, if you’ve looked at module refinement you’ll know that we can make something more powerful by weakening preconditions and/or strengthening post-conditions.

Pre-condition questions:
– Does my usage of X fall within the pre-conditions? In other words, am I safe to assume any guarantees that X makes? [safety]
– What would happen if I could weaken the preconditions of X – would that open it up to usage in more places, and are any of those interesting? [opportunity]

Post-condition questions:
– Are my expectations of X valid given the post-condition guarantees it makes? (Am I relying on some property that X does not in fact guarantee). [safety]
– What would happen if I could strengthen the postconditions of X? Would that open it up to usage in more places, and are any of those interesting? Would it create an opportunity to simplify or streamline downstream components? [opportunity]

The safety questions are the ones we’re trained to ask (although we often forget). But it’s the opportunity questions that can unlock some really interesting lines of inquiry and discovery. If you can find an assumption that’s baked into an industry / value chain / software component, and that’s been there so long that people don’t even really see it, and that doesn’t necessarily have to hold any more… then chances are you’re onto something good!

This post started as an introduction to tomorrow’s paper, but when I realised it was getting too long I moved it into a post of its own. Suffice to say, coming up tomorrow is a fine example of strengthening post-conditions leading to a really interesting development…

9 Comments leave one →
  1. December 7, 2016 7:04 pm

    This sounds exciting! Can’t wait to see a real example of questioning an assumption we take for granted like that.

  2. Zteve permalink
    December 8, 2016 11:54 am

    Fascinating: did you think about the safety and opportunity questions the other way round? (This time read these from the point of view of X.)

    Pre-condition questions:

    Do I only use X in certain restricted situations? In other words: am I working too hard to prepare inputs to X that satisfy conditions that aren’t necessary? [over-cautious]

    What would happen if I could strengthen the preconditions of X – would that mean X could be made more efficient or simpler? [specialisation]

    Post-condition questions:

    Are my expectations of X only a small part of the post-condition guarantees it makes? (Am I relying only on some of the properties that X guarantees?) [over-cautious]

    What would happen if I could weaken the postconditions of X? Would that allow X to be more efficient or more simply implemented? [specialisation]

    Ironically, weakening the post-conditions of X might still allow it to be used more widely: because X does less, the less that it does might be more applicable to areas where the greater guarantees come with intolerable inefficiencies.

    I’m looking forward immensely to reading the next blog entry.

  3. Anonymous Distributed Systems PHD permalink
    December 8, 2016 9:42 pm

    It’s almost like they implemented part of RAFT in hardware using only UDP packets. The leader in RAFT serves the same purpose of sequencing. However the RAFT leader can also retransmit missed messages, and ensures that replicas receive a valid log. It seems that this retransmission work is pushed up into the library layer, so that the common case is fast.

Trackbacks

  1. Just say NO to Paxos overhead: replacing consensus with network ordering | the morning paper
  2. Four short links: 9 December 2016 | Vedalgo
  3. Four short links: 9 December 2016 | A bunch of data
  4. XFT: Practical fault-tolerance beyond crashes | the morning paper
  5. Interlude: On assumptions | CS TOPIC

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: