CSE 555 Protocol Engineering

1
CSE 555Protocol Engineering

• Dr. Mohammed H. Sqalli
• Computer Engineering Department
• King Fahd University of Petroleum Minerals
• Credits Dr. Abdul Waheed (KFUPM)
• Spring 2004 (Term 032)

2
Correctness Requirements
3
Topics (Ch. 6)

• Correctness criteria
• Reasoning about behavior
• Assertions and system invariants
• Deadlocks and bad cycles
• Temporal claims

4
Correctness Criteria

• What does it mean for a design to be correct
  (i.e., to validate a design)?
• A design can be proven correct wrt to specific
  correctness criteria
• Logical correctness is concerned primarily with
  possibilities, not with probabilities
• Some fairly general correctness criteria
• Absence of deadlocks
• Absence of livelocks
• No improper terminations
• Problem high complexity even with finite state
  models
• A design should be provably correct
• Proving even simple protocol properties, such as
  absence of deadlocks, is PSPACE hard

5
Dealing With Complexity

• Validation methods need to solve complexity
  problems
• Methods should allow correctness analysis of
  large models
• Methods should provide techniques for reducing
  complexity of models (Ch. 8 and 11)
• Ability to express large models despite
  complexity depends on a careful choice of
  correctness criteria
• PROMELAs choice of correctness criteria support
  several independent levels of complexity
• Simple and straight-forward requirements are
  checked independently of the others
• Example Absence of deadlocks
• Slightly more complicated requirements have
  higher computation cost
• Example Absence of livelocks
• More sophisticated requirements are the most
  expensive to check
• Techniques of reducing complexity are applicable
  here (Ch. 11)

6
Basic Types of Claims

• Two types of correctness requirements
• Safety set of properties the system may not
  violate, i.e., bad things that should be avoided
  (e.g., invalid end states)
• Liveness set of properties the system must
  satisfy, i.e., good things that capture the
  required functionality of a system (e.g.,
  non-progress cycles)
• Function of a verification system
• Need not, and cannot, determine what is good or
  bad
• It can only help the designer to determine what
  is possible and what is not
• For a verifier, there are two types of
  correctness claims
• Claims about reachable and unreachable states ?
  state properties (e.g., system invariant, process
  assertion)
• Claims about feasible and infeasible executions
  (i.e., sequence of states) ? path properties
  (finite or infinite (e.g., cyclic))

7
Reasoning About Behavior

• Correctness criteria can be formalized as claims
  about the behavior of a PROMELA validation model
• Two general types of claims about a given
  behavior
• Inevitable or
• Impossible
• Suffice to support only one type of claim
• Claim of one type implicitly defines a
  complementary and equivalent claim of the other
  type
• PROMELAs expression of correctness criteria
• Define behaviors that are claimed to be
  impossible

8
Reasoning About Behavior (Contd)

• How to state that a given behavior is inevitable
• All deviant behaviors are impossible
• How to express an assertion stating that a
  condition is invariantly true
• Correctness claim assertion is impossible to be
  violated

9
Definition of Terms

• A state of a validation model is completely
  defined by
• Specification of all values for local and global
  variables
• All control flow points of running processes
• Contents of all message channels
• An execution sequence
• A finite, ordered set of states
• The behavior of a validation model
• Defined completely by the set of all possible
  execution sequences
• Model can reach a given state by executing
  PROMELA statements
• Model can be placed in a given state by
• Assignment of the appropriate values to
  variables, control flow points, and channels

10
Valid Execution Sequence

• Any arbitrary set of states do not necessarily
  form a valid execution sequence
• A finite, ordered set of states is valid for a
  given PROMELA model M if it satisfies two
  criteria
• The first state (state 1) of the sequence is the
  initial system state of M
• All variables initialized to zero
• All message channels empty
• Only init process active and set in its initial
  state
• If M is placed in state i, there is at least one
  executable statement that can bring it to the
  state i1

11
Terminating and Cyclic Sequences

• Terminating
• No state occurs more than once in the sequence
• Model M contains no executable statements when
  placed in the last state of the sequence
• Cyclic
• All states except for the last one are distinct
• Last state of the sequence is equal to one of the
  earlier states
• Cyclic sequences define potentially infinite
  executions
• System behavior of a PROMELA model
• Defined by all terminating and cyclic sequences
  generated by executing this model
• Set of reachable states of a PROMELA model
• The union of all states included in the system
  behavior

12
State Properties

• Propositions
• Correctness claims for PROMELA models can be
  built up from simple propositions
• A proposition is a boolean condition on the state
  of the system
• A proposition can refer to all the elements of a
  system state
• Local and global variables
• Control-flow points of arbitrary executing
  processes
• Contents of message channels
• Propositions implicitly define labeling of states
• In any given state, a proposition is either true
  or false
• Correctness criteria can be expressed in terms of
  states in which a given proposition should hold
• Specified by assertion statements in PROMELA

13
Temporal Ordering of Propositions

• Correctness criteria can be expressed as a
  temporal ordering of propositions (if more than
  one proposition is used)
• Need to specify order in which propositions are
  required to hold
• Truth of one proposition follows (immediately or
  eventually) the truth of another
• Complementary way to express temporal ordering
• Define the order in which propositions should
  never hold
• Only this alternative is supported in PROMELA
• Through a language feature called temporal claim

14
Temporal Claims

• We need to specify ordering of propositions
• Semantics of proposition orderings is different
  from statement orderings in PROMELA
• A sequential ordering implies that second
  statement in a process is to be executed after
  the first one terminates
• However, in reality we cannot assume relative
  speed of entities
• All we can say is that second statement executes
  eventually after the first one
• Correctness claims have to be more specific
• In a temporal claim, a sequential ordering of two
  propositions defines an immediate consequence

15
Temporal Claims and Process Types

• Types of correctness requirements are different
  for terminating and cyclic sequences
• Terminating processes
• An important requirement for terminating
  sequences is absence of deadlocks
• Not all terminating sequences correspond to
  deadlocks
• Need to express which final state properties make
  a terminating sequence acceptable as
  non-deadlocking.
• Cyclic processes
• Temporal claims for cyclic sequences need to
  express general conditions, such as absence of
  livelocks and non-progress cycles

16
Assertions

• Correctness criteria can be expressed as boolean
  conditions
• This criteria must be satisfied whenever a
  process reaches a given state
• PROMELA uses assert statement for this purpose
• Syntax of assert statement
• assert (condition)
• The condition can be an arbitrary boolean
  expression
• This statement is always executable
• It can be placed anywhere in a PROMELA
  specification
• Effect of the assert statement
• If the condition is true, the statement has no
  effect
• If condition is false in at least one execution
  sequence, the validity of the statement is
  violated
• The PAN run-time flag A can be used to disable
  the reporting of assertion violations
• spin a file_name.pml will generate a pan.c
  file. This file is compiled cc o pan pan.c to
  get the executable used for verification

17
Assertions Example

• In this example, we cannot predict what will be
  the final value of state
• 0, 1, or 2
• We can try the following correctness criteria
• When process of type A completes, value of state
  must be 2
• When process of type B completes, value of state
  must be 0
• Expressed using assert
• Claims are of course false!

Example without assertions
C\Tools\spingtspin state.pml state in A
is 1 spin line 2 "state.pml", Error
assertion violated spin text of failed
assertion assert((state2)) processes 3
state 1 8 proc 2 (B) line 3
"state.pml" (state 3) 8 proc 1 (A) line
2 "state.pml" (state 4) 8 proc 0 (init)
line 4 "state.pml" (state 3) ltvalid end
stategt 3 processes created
Example with assertions
18
System Invariants

• System invariants are boolean conditions, such
  that
• If they are true in the initial system state,
  they remain true in all reachable system states
• This is independent of the execution sequence
  that leads to each specific state
• A more general application of assert is to
  formalize system invariants
• System invariants can be expressed in a monitor
  process
• Exampleproctype monitor() assert (invariant)
  
• This process, after it has been started with a
  run statement, continues to execute independently
  of the rest of the system
• The assert statement is executable once for every
  system state

19
System Invariants Dijkstras Semaphore

• define p 0
• define v 1
• chan sema0 of bit
• proctype dijkstra()
• do
• sema!p -gt sema?v
• od
• proctype user()
• sema?p
• / critical section /
• sema!v
• / non-critical section /
• init
• atomic
• run dijkstra()

• define p 0
• define v 1
• chan sema0 of bit
• byte count
• proctype dijkstra()
• do
• sema!p -gt sema?v
• od
• proctype user()
• sema?p
• count count 1
• skip / critical section /
• count count 1
• sema!v
• skip / non-critical section /

20
Deadlocks

• Two types of possible execution sequences in a
  finite state system
• Either terminate after a finite number of state
  transitions or
• Cycle back to a previously visited state
• There are two types of end states that should be
  distinguished
• Expected or proper end states
• Unexpected end states
• Error states due to incomplete or inconsistent
  protocol specifications
• Deadlock state is only one type of possible error
  states
• Example unspecified receptions
• Two criteria for the final state of a terminating
  execution sequence to be considered a proper
  end-state
• Every instantiated process has terminated
• All message channels are empty

21
Deadlocks End-State Labels

• All processes do not necessarily terminate
• Some processes may stay alive even after all
  others terminate
• Example server processes
• In PROMELA, process states can be identified in
  proctype definitions as proper end-states using
  end-state labels
• Exmaple dijkstras algorithm
• proctype dijkstra()end do sema!p -gt
  sema?v od
• Process will be considered in a proper end-state
  when it is in a state labeled end

22
End-State Labels (Contd)

• More than one proper end-sate within a single
  proctype are possible
• All label names must be unique
• An end-state label is any label with prefix end
• Examples enddne, end0, endme, end_of_part_1,
  end_war etc.
• Revised first criterion of proper end-state
• Every instantiated process has either terminated
  or reached a state marked as a proper end-state
• Any final state in a terminating execution
  sequence that does not satisfy above criteria is
  classified as an improper end-state
• An implicit correctness claim for a validation
  model is that the behaviors they define, do not
  include any improper end states
• The PAN run-time flag E can be used to suppress
  the reporting of invalid end states (i.e., pan
  E)
• The PAN run-time option q means that all message
  channels must be empty for a system state to be
  considered valid (in addition to reaching a valid
  end state).

23
Bad Cycles

• Correctness requirements (i.e., properties) of
  cyclic sequences can be expressed in PROMELA
• Non-progress cycles
• Livelocks
• Two properties are
• No infinite behaviors of only unmarked states
• System cannot infinitely cycle through unmarked
  states
• Marked states are called progress-states
• Execution sequences violating this correctness
  claim are called non-progress cycles
• No infinite behaviors that include marked states
• Execution sequences violating this claim are
  called livelocks

24
Non-Progress Cycles

• How to claim absence of non-progress cycles?
• Define the system states within PROMELA model
  that represent progress
• Defined through progress-state labels
• A progress-state label marks a state that must be
  executed for the protocol to make progress
• Examples
• Delivering data to a receiver
• Incrementing a sequence number
• Passing of a semaphore test will show
  progressproctype dijkstra()end do
  sema!p -gtprogress sema?v od
• The passing of the semaphore guard cannot be
  postponed infinitely long
• In all infinite executions, the semaphore process
  reach the progress label infinitely often
• An automated validator can confirm that this
  claim cannot be violated
• More than one progress-state labels are possible
  progress0, progressing, progression etc.
• Use cc DNP o pan pan.c to enable non-progress
  checking, and pan -l to search for non-progress
  cycles

25
Livelocks

• Formally expressed as something that cannot
  happen infinitely often
• Using acceptance-state labels
• An acceptance-state marks a state that may not be
  part of a sequence of states that can be repeated
  infinitely often.
• An acceptance-state label start with prefix
  accept
• Examples acceptance, accepting, etc.
• Example modified proctype dijkstra()proctype
  dijkstra()end do sema!p
  -gtaccept sema?v od
• Claim it is impossible to cycle through a series
  of p and v operations
• This claim is false

26
Temporal Claims

• So far, we have defined specifications of
  correctness criteria with
• Assertions
• Three special labels to mark end, progress, and
  acceptance states
• Temporal claims define temporal orderings of
  properties of states
• We can express claims, such asEvery state in
  which property P is true is followed by a state
  in which property Q is true
• This is expressed as P -gt Q
• In the above statement, followed by has two
  interpretations
• Immediately followed by or
• Eventually followed by
• PROMELA support the second interpretation with
  the first as a special case

27
Temporal Claims (Contd)

• Two problems in specifying temporal claims P -gt
  Q
• Temporal claims should express orderings of
  properties that are impossible, just like other
  correctness criteria
• Temporal claims are defined on complete execution
  sequences
• Even if a prefix of the sequence is irrelevant,
  it must be represented as a trivially true
  sequence of propositions
• Examplenever do skip break od -gt P -gt
  !Q
• Independent of initial sequence of events, it is
  impossible for a state in which property P is
  true to be followed by a state in which property
  Q is false
• Claim is matched if and when claim body
  terminates and corresponding correctness property
  is violated
• Thus, PROMELA notation for temporal claims
  isnever
• A never claim is normally used to specify either
  finite or infinite system behavior that should
  never occur

28
Example Temporal Claims

• We want to express the temporal property that
  condition1 can never remain true infinitely long
• We need a representation of all behaviors, such
  that
• condition1 may be false initially
• It becomes true eventually
• It remains true
• Expressed in PROMELA as follows
• never do skip
  condition1 -gt break odaccept do
  condition1 od
• If and when the acceptance cycle is detected,
  claim is matched and corresponding correctness
  property is violated (livelock)

29
Example Temporal Claims (Contd)

• Another claim (perhaps an erroneous version of
  previous) can be expressed as followsnever
  do skip condition1 -gt
  break odaccept condition1
• Claim has just two state transitions after
  condition1 becomes true
• This claim is completely matched if there is at
  least one execution sequence in which condition1
  holds in two subsequent states
• For the first version, it would be an error (a
  livelock) if the machine can stay in the accept
  state infinitely long.
• For the second version, it would be an error if
  the terminal state is reachable

30
Specifying Temporal Claims

• Body of a temporal claim is similar to a proctype
  body, except for one difference
• Every statement inside a temporal claim is
  interpreted as a condition
• These should be free of side-effects
• PROMELA statements with side-effects are
  assignments, assertions, sends, receives, and
  printf statements.
• A temporal claim is matched if
• An undesirable/illegal behavior can be realized
• Thus, correctness claim is violated
• Application of temporal claims
• Most useful ones combine temporal claims with
  acceptance labels
• Two ways to match a temporal claim depending on
  undesirable behavior
• Undesirable behavior can define
• A terminating sequence or
• A cyclic execution sequence (livelock)

31
Specifying Temporal Claims (Contd)

• For a terminating execution sequence, a temporal
  claim is matched only when it can terminate
  (reaches the closing curly brace)
• The claim can be violated if the closing curly
  brace of the PROMELA body of the claim is
  reachable.
• For a cyclic execution sequence, the claim is
  matched only when an explicit acceptance cycle
  exists.
• To check a cyclic temporal claim, acceptance
  labels should only occur within the claim and not
  elsewhere in the PROMELA code.
• A combination of never claim with accept labels
  can express the absence of non-progress cycles
• Thus, temporal claims are more general than
  progress-state labels
• However, cost (complexity) of validation with
  progress-state labels is smaller
• There are easier ways to express never claims
• Spins built-in translator from formulae in
  linear temporal logic (LTL) to never claims (less
  expressive than never claims)
• The timeline editor, a graphical tool, converts
  timeline descriptions into never claims (less
  expressive than LTL formula)

32
trace Assertion

• Expresses a correctness requirement on existing
  behavior in the remainder of the system
• Expresses properties of message channels
• Formalizes statements about valid and invalid
  sequence of operations that processes can perform
  on message channels
• All channel names referenced in a trace assertion
  must be global
• All message fields must be global or mtype
  constants.
• Example
• trace
• do
• q1!a q2?b
• od
• Send operations on channel q1 alternate with
  receive operations on channel q2
• All send operations on q1 are exclusively
  messages of type a
• All receive operations on q2 are exclusively
  messages of type b
• Must always be deterministic
• Cannot contain random receive, sorted send, or
  channel poll operations
• No data objects can be declared or referred to
  inside a trace assertion
• Dont care values for specific message fields can
  be specified with the predefined write-only
  variable _ (i.e., the underscore symbol)
• notrace assertion is also supported, but rarely
  used

33
Tracing Verification Errors

• When the verifier finds an error it writes a
  complete trace for the error execution into a
  file called file_name.pml.trail
• Using this file, we can reproduce the error trail
  with spins guided simulation option spin t p
  file_name.pml