The Bounded Retransmission Protocol: A CSP B Case Study

1
The Bounded Retransmission Protocol A CSP
B Case Study

2
Aims of this Session

• To demonstrate the use of CSP B on a larger
  example
• To show how we construct specifications from
  informal descriptions
• To put the theory into practice by analysing a
  communications protocol
• In addition, we will see some new features
• Synchronisation on machine channels
• Further process augmentation
• Conjunction of specifications

3
Communications Protocols

• Communication protocols aim to overcome one or
  more deficiencies of the communications medium
• Analysing protocols is a popular pastime in the
  formal methods community
• The aims and the structure of protocols are
  (usually) easy to comprehend
• However, protocol flaws can be extremely subtle
  and the discovery of attacks make for interesting
  talks
• So why do we choose to investigate a
  well-analysed protocol that has been deemed to be
  correct?

4
Bounded Retransmission Protocol

• The BRP is unusual because it manipulates data in
  a non-trivial way
• It also has a non-trivial flow of control
• To date, all analyses of the BRP have been done
  using either state based methods or event based
  methods
• Our approach comprises a state and an event based
  method

5
Bounded Retransmission Protocol
SENDER
MEDIUM
RECEIVER

• SENDER accepts arbitrary length files from its
  environment
• File components are sent within structured
  PACKETS over a lossy MEDIUM
• RECEIVER passes the file components of each
  packet to its environment
• Both SENDER and RECEIVER also pass status
  information to the environment

6
Modelling the Protocol
req
conf
ind
ind_err
trans
rec
MEDIUM
SenderCtrl PROCESS
ReceiverCtrl PROCESS
recack
sendack
SENDER MACHINE
RECEIVER MACHINE

• SENDER MACHINE handles the file components and
  packet construction
• A variation on the alternating bit protocol is
  used to determine fresh packets
• RECEIVER MACHINE contains an operation to
  compare bits
• Retransmissions and bounded behaviour are
  controlled by timeouts

7
Modelling the Protocol (Cont.)
req
conf
ind
ind_err
trans
rec
MEDIUM
SenderCtrl PROCESS
ReceiverCtrl PROCESS
recack
sendack
dec
abort
dec
SENDER MACHINE
RECEIVER MACHINE

• Time cannot be modelled directly using this
  approach
• Synchronisation channels are used to model
  timeouts
• Retransmissions occur only when messages are
  lost by the MEDIUM
• Both the SENDER and the RECEIVER abort a
  transmission at the same time

8
Packet Structure

• A file is a sequence of file components
• Each component is sent on the medium in a packet
• Since packets can be lost, a bounded number of
  retransmissions is possible
• A variation of the alternating bit protocol is
  used to distinguish new packets from
  retransmissions. An alternating bit is included
  in each packet
• Flags to indicate the first and last packets of a
  file transfer are also included in each packet

9
CSP B Model of the BRP

10
The Senders Flow of Control

11
Preconditioned Operations of the Senders B
Machine

• Both get_packet and advance require the file
  stored in the Sender machine to be non-empty. The
  operation dec requires the number of
  retransmissions to be positive

12
The Flow of Control (Cont.)

• In contrast, the receivers controller consists
• of three sub-processes

13
The Flow of Control (Cont.)
14
The State and Operations of the Receivers B
Machine

• The receivers B machine consists of a single
  state variable called
• All receiver operations are robust
• The file components do not enter the receivers B
  machine

15
The State and Operations of the Receivers B
Machine (Cont.)

16
A Lossy Medium

• Packets and acknowledgements are lost when the
  medium chooses to dec
• The medium and the sender are required to
  synchronise on the machine channel dec

17
The Complete System

• Putting everything together, we get

18
Formal Analysis

19
Proof of Consistency

• Each process body is translated into an
  equivalent sequence of B operations
• A control loop invariant (CLI) is constructed so
  that
• The CLI is established after initialisation
• Each (translated) process body maintains the
  invariant

20
Proof of Consistency (Cont.)

• Since the receivers B machine has no
  preconditioned operations, consistency on the
  receiver side is trivial
• The senders controller is made up of two
  mutually recursive processes
• Therefore we have two control points the entry
  point of and the entry
  point of

21
Proof of Consistency (Cont.)

• We assign the control variable the value 0
  whenever control is at and
  assign 1 whenever control is at
• The initialisation of the senders B machine is
  completely non-deterministic. Therefore, we
  cannot say anything about the senders state when
  control enters the process
  initially
• All preconditioned operations reside in the
  process

22
Proof of Consistency (Cont.)

• We now translate the senders controller

23
Proof of Consistency (Cont.)

• From what we have seen, one candidate for the CLI
  is
• Then, whenever control enters
• the CLI is vacuously true, and whenever
  control enters we know that
  there is something to send
• This is strong enough to discharge the
  preconditions but its too weak as a CLI

24
Proof of Consistency (Cont.)

• After some simplification of the translation of
  we would be obliged to prove
• However, updates the state by
  assigning
  which, after expansion, gives

25
Proof of Consistency (Cont.)

• However, the execution of is
  conditional on the value of the last packet flag
  it is executed only when this value is false
• If the value of the last packet flag is false
  then we know there must be at least two file
  components left. With this in mind, our CLI
  becomes

26
Deadlock Freedom

• The controller language and non-blocking machines
  prevents deadlocks between controller/machine
  pairs
• There may be inconsistencies between the
  controllers that can result in deadlock
• We can rearrange our system as follows

27
Deadlock Freedom (Cont.)

• Using FDR, we can check whether
• is deadlock free
• Deadlock freedom helps to convince us that
  timeouts have been modelled correctly
• The sender cannot refuse to
• The sender and receiver allow aborted runs

28
Livelock Freedom of the BRP

• We would like to investigate the behaviour of our
  system at its external interface
• This can be achieved by hiding all internal
  activity. However, it is possible to introduce
  divergences in the form of infinite internal
  activity
• As we have already seen, livelock freedom can be
  checked in FDR once consistency has been proven

29
Livelock Freedom of the BRP (Cont.)

• Intuitively, the bounded nature of the protocol
  tells us that the formal model of the BRP should
  be livelock free
• However, if
• then FDR tells us that
• is not livelock free

30
Livelock Freedom of the BRP (Cont.)

• This analysis fails because the bounded behaviour
  is modelled in B
• We must lift this state information into the CSP
  definition as parameters
• The process is parameterised
  with the number of file components that remain to
  be sent and the number of retransmissions that
  are possible

31
Livelock Freedom of the BRP (Cont.)

• The initial call to is
  made with the length of the file and the maximum
  number of retransmissions
• We can then add assertions to the events of

32
Livelock Freedom of the BRP (Cont.)

• Diverging assertions are introduced first

33
Livelock Freedom of the BRP (Cont.)

• Once consistency of this definition has been
  proven, the diverging assertions are converted to
  blocking assertions
• FDR confirms that these augmented definitions
  ensure livelock freedom (note that the value of
  one of the parameters strictly decreases with
  each recursive call)
• Other theorems that we have seen enable us to
  remove the assertions and the parameters to get
  the original definitions

34
Composing Safety Specifications

• Behavioural properties of the system are defined
  as process-oriented specifications
• Once again, we have seen how a property of a CSP
  B specification can be checked using FDR by
  isolating the CSP controllers
• The bounded nature of the protocol means that
  there are no (liveness) guarantees for a
  successful file transfer
• We shall concentrate on the safety aspects of the
  protocol

35
Composing Safety Specifications (Cont.)

• Rather than trying to express all desirable
  patterns of behaviour in one specification, we
  define several specifications whose conjunction
  captures all such patterns
• Conjunction in the traces model means parallel
  composition

36
Example The Buffer Properties of the BRP

37
The Buffer Properties of the BRP

• This process-oriented specification is not
  satisfied by the controller processes
• As with livelock freedom, some important
  information is lost by isolating the CSP
• We must lift enough state to prevent FDR giving
  false negatives
• For this property, we need the file contents and
  the value of the toggle

38
The Augmented Sender Controller

39
The Augmented Sender Controller (Cont.)

40
The Augmented Sender Controller (Cont.)

41
Other Safety Properties of the BRP

• The previous analysis shows that our model of the
  BRP exhibits the buffer property
• Following the same pattern we have investigated
  other safety properties
• Correct labelling on the channel
• The relationship between and
• The relationship between and

42
The Safety Property of the BRP

• The parallel composition of all of these
  properties links all the external events to
  capture the desired behaviour of the whole
  interface
• Proving them individually helps to identify the
  state that needs to be lifted
• As a further result, we have shown that the first
  packet flag is redundant because we do not
  constrain its value anywhere

43
Summary

• Modelling a system involves separating
  state-based concerns from event-based (control)
  concerns
• Verification requires us to move from CSP into B
  (consistency) and from B into CSP (livelock,
  trace/failures refinement)
• Interesting relationships between the two worlds
  emerge from the verification process