Mobility 1 : the Pi Calculus

1
Mobility 1 the Pi Calculus

• Cédric Fournet
• Microsoft ResearchCambridge

2
References

• Communicating and Mobile Systems The
  Pi-Calculus, Robin Milner, Cambridge University
  Press, 1999
• The Pi-Calculus a Theory of Mobile
  ProcessesDavide Sangiorgi and David Walker,
  Cambridge University Press, 2001
• See also http//research.microsoft.com/fournet/

3
Contents

• Mobile Names the Pi Calculus
• Mini CCS basics syntax, semantics,
• Some equivalences
• Name Mobility in the Pi Calculus
• Process Mobility
• Applications Alternatives
• Mobile Ambients Luca
• Security Protocols in the Applied Pi Calculus
  Martin
• Mobility and Security Cedric
• Spatial Logics Luca

4
Communicating Systems ?

• Two related questions
• What is a function?
• Sequential machines
• Models for computation lambda, PCF, abstract
  machines
• What is a process?
• Coffee Machines, Xboxes, distributed systems.
• Models for interaction CCS/CSP 80s, Pi 90s
• How to model concurrent behaviours?
• How to describe processes in a compositional
  manner?
• When are two processes equivalent?Divergence is
  not necessarily bad.
• Operational, rather than denotational.

5
Why Using a Calculus ?

• A calculus, rather than a purely descriptive
  model
• Calculate reason on processesin a systematic
  manner using equations.
• State and prove correctness properties.
• Reuse basic tools, such as observationalequivalen
  ces and proof techniques.
• Two different viewpoints
• Specification languageDescribe and validate
  concurrent protocols.
• Core programming languagePrinciples for
  language designSemantics for concurrent
  programsExecutable spec, with implementation
  constraints.

6
Asynchronous Programming

• Distributed programs
• Network of interconnected devices
• Hard to write asynchronous, uncertain, open
  environment
• Harder to understand relate to a specification
• Awkward to test debug
• Not much programming-language support
• Traditional (low-level, sequential) languages
• Various design patterns
• Libraries for concurrency, synchronisation,
  distribution, communications,
• Distributed programming biased in this
  settinge.g. RPC/RMI rather than asynchronous
  events
• What are good abstractions for asynchronous
  programming?

7
Mobile Programming

• The distributed configuration of the
  systemevolves as part of the computation.
• Example mobile agents
• More general, quite common, usually not explicit
• Mobility?
• Dynamically export references to local
  resources(name mobility)
• Dynamically retrieve, link, and execute some
  remote library (code mobility)
• Move active parts of the computation from one
  machine to another (object mobility, thread
  mobility, strong mobility,)
• What are good abstractions for mobile programming?

8
Mini CCS

• A Calculus of Communicating Systems Milner,80

9
Mini CCS
10
Examples

• Reductions
• Constants globally-defined, recursive
• Internal choice (encoding)

11
Contexts

• A context is a process with a placeholder.
• An evaluation context is a context with an
  active placeholder.

12
Reduction Semantics

• Communication Handshake
• Reduction is defined up to structural
  rearrangements(chemical-style semantics)

13
Structural equivalence

• Structural equivalence
• gathers all syntactic rearrangements of running
  processesthat preserve the scopes
• is complicated, but has no real computational
  contents
• can be oriented, to get partial normal forms

14
Contextual Equivalences

• How to calculate ?

15
Observational Equivalences

• We may want to check that our processes have
  some observable properties.
• So far, we described the calculuswe must be
  able to calculate too!
• Which equivalence? An embarrassing choice.
• Numerous notions of equivalence for process
  calculi.
• Trade-off between expressiveness and proof
  techniques.
• For a given equivalence, many different
  formulations.
• We motivate and compare three common
  equivalences(first for mini CCS)

16
Which equivalence?

• The ideal process equivalence
• When two processes are equivalent, they have the
  same properties. In every system, one can replace
  one with the other without affecting the system
  in any visible way (sound).
• Conversely, when two processes are not
  equivalent, there is a system where replacing one
  with the other makes some visible change
  (complete).
• There are simple, effective techniques for
  proving equivalences (simple)
• The equivalence has a rich set of identities, so
  that we can compute on processes (expressive)

17
May Testing

• May testing equivalence is the equivalence of
  processes that have the same safety properties
• observed in a finite number of interactions,
• according to the communication rule,
• without termination, timing, or liveness
  properties.
• We need to define a notion of test, or
  experiment.
• We reuse our calculus
• A test is just a process (actually, a context)
• By convention, the test succeeds when this
  testing process sends a message on a given
  channel.

18
What is observable?

• Our test harnesses range over all evaluation
  contexts in CCS.
• Basic observation predicates detect (any) output
  on a given name

19
May Testing Equivalence

• The definition of may testing naturally follows
• This definition is robust we can change the
  definitions of observations and contexts, and
  still obtain the same equivalences for CCS
  processes.

20
May Testing Equivalence

• Observing outputs as a whole (on any name)
• Observing inputs
• May-testing for both inputs and outputsyields
  the same equivalence.

21
May Testing Equivalence

• Some equations
• Structural equivalence (by definition)
• Internal communication is invisible
• Concurrent communication is invisible
• Divergence is invisible
• Practical proof techniques? Not quite
• May testing is not too fine good
  counter-examples
• May testing is sometimes too coarse.

22
Deadlocks?

• May testing is sometimes too coarse. Consider
  internal choices, defined as
• We always have
• i.e. may testing does not detect potential
  deadlocks.

23
Fair Testing

• We can use a more sophisticated testfair
  testing detects whether a process always retain
  the possibility of emitting on a

24
Fair Testing

• Ce

25
Fair Testing Equivalence

• We have

26
Fair Testing

• Useful equations
• Practical proof techniques? Not at all
• Some fairness (detects deadlocks, but no
  livelocks)

27
Fair Testing

• Useful equations
• Practical proof techniques? Not at all
• Some fairness (detects deadlocks, but no
  livelocks)
• Relation with may testing?
• We can use contexts
• such that

28
Getting Organized

• Some useful properties for expressiveness
  context closure and basic observables.

29
Equivalence Requirements

• For instance, is the largest relation
  that meets conditions (C), (X), and (?).
• This is a convenient way to organize equivalences
• Equivalences defined as largest relations that
  meet some (monotonic) properties have
  co-inductive proof techniques.

30
Towards Co-inductive Proofs

• To prove P ? Q for some given processes,
• Choose any relation R such that P R Q
• Prove that R meets all the requirements in
  thedefinition of equivalence ?
• This establishes R µ ?, hence P R Q
• This is a good starting point for proofs
• We can choose more convenient requirements that
  define the same equivalence relation
• We can add requirements that make R simpler

31
A key property for proofs

• The (weak) simulation property Park, Milner
• Simulation requires a direct lock-step
  correspondenceof reductions between related
  processes.(This is not obviously observable.)

32
Barbed Congruence

• Barbed Congruence ? is the largest symmetric
  relation that meets conditions (C), (?), and (S)
• Finer than may testing (by definition)and also
  finer than fair testing (proof)
• Much easier to establish
• For example,

33
Barbed Congruence (redefined)

• Barbed Congruence is also the largest symmetric
  relation that meets the three conditions

34
A hierarchy of equivalences

• It is often convenient to combine several
  equivalencesto study the properties of
  processes.
• Lemmas and proofs use finer equivalences.

35
Using labels instead of contexts

• Explicit actions,finer equivalences,simpler
  proofs.

36
Labelled Transition System
37
Labels vs Reductions

• Reduction semantics are easier to grasp
• Labelled semantics make interactionwith the
  environment more explicit
• Labelled semantics are technically
  simpler(structural/labelled case analysis vs
  induction on contexts)
• It is useful to have both semantics,especially
  when they coincide

38
Labelled Bisimilarity

• Labelled (weak) simulation property
• A relation R is a labelled bisimulationwhen R
  and R-1 meet (S) and (S?).
• Labelled bisimilarity is the largest labelled
  bisimulation

39
Labelled Bisimilarity (2)

• Labelled bisimilarity is a congruenceProof
  (sketch)
• For prefix (?.P, ?.Q) P ¼ Q ¼
• Similarly for parallel composition, for
  restriction
• Labelled bisimilarity Barbed congruenceProof
  (sketch)
• Hence, labelled bisimulation (and its variants)
  yields an effective proof technique for
  contextual equivalences

40
Mobility ?

• A Calculus of Mobile ProcessesMilner Parrow
  Walker,92

41
Value-Passing CCS

• Interaction on free channels, as before
• Convenient, but not essential could use more
  channels

42
The Pi Calculus

• Channel names can be communicated
• Communication becomes dynamic

43
Reduction Semantics (as before)

• Communication
• Structural equivalence

44
Name Mobility

• The dynamic creation of new links between
  active processes Milner
• At a suitable level of abstraction, the location
  of a process is determined by its links to other
  processes.

45
Contextual Equivalences

• Much the same as for CCS
• Barbs and contexts are easily adapted
• We obtain the same hierarchy of equivalences
• We have the same equations for CCS processesseen
  as Pi processes.
• We can now relate more interesting processes.

46
Labelled Semantics

• How to get rid of structural equivalence ?
• Labelled bisimilarity barbed congruence ?
• Output labels can now carry along extruded
  names

47
A Labelled Semantics
48
Labelled Bisimilarity

• Labelled (weak) simulation property
• A relation R is a labelled bisimulationwhen R
  and R-1 meet (S) and (S?).
• Labelled bisimilarity is the largest
  labelled bisimulation
• Congruence for evaluation contexts
• Finer than barbed congruence
• With convenient proof techniques

49
Encodings
50
Example Sending Tuples

• We can encode richer forms of communicationusing
  communication protocols on private channels.
• We could also exchange messages in both
  directions
• We need a private channel c for each
  tupleotherwise, parallel communications may get
  mixed.

51
Example Sending Tuples (2)

• Correctness?
• The first communication step in the translation
  corresponds to the source communication step
• Further steps are local and deterministic
• No full abstraction (for barbed congruence)the
  context can block some communications

52
Example Data

• Milners Booleans
• Integers are similarly encoded
• Two continuations, for zero and for succ.
• Are these good encodings?
• Operational correspondence
• No full abstractionthe context can observe too
  much (cf games semantics)we need restrictions
  (e.g. types) to fix this problem.

53
Process Mobility

• Do we need higher-order mobility?
• Technically tricky
• Scoping rules get complicated (sharing,
  substitutions)
• Labelled transitions become too precise
• Blue Calculus Boudol,

54
Encoding Process Mobility (1)

• Instead of passing a process,we pass a fresh
  name representing that process.
• Is it a good encoding ?

55
Encoding Process Mobility (2)

• Operational correspondence

56
Encoding Process Mobility (3)

• Operational correspondence
• Full abstraction (for barbed congruence) at
  least for processes that use higher-order
  internally.
• Informally, this encoding is not localpassing a
  pointer to a process instead of passing a copy
  of the process.

57
Encoding Functions

• How to encode the lambda calculus in Pi ?
• Choose an evaluation strategy
• Perform a CPS transform
• Encode abstractions using higher-order processes.
• Much like simpler datatypes
• We easily obtain operational correspondence
• We dont have full abstraction (at least without
  types)because the context can detect function
  calls.

58
Variations on Name Mobility
59
Which communication model?

• In CCS, In Pi channel-based handshakes.
• There are many interesting restrictions and
  alternatives
• Internal Mobility Pi-I Boreale Sangiorgi
• One can communicate only new names
• Input and output are symmetric again!
• We still essentially have the pi calculus
• Fusions Victor
• Names are globally fused when passed as
  parameters

60
Asynchrony

• Asynchronous Pi Calculus Boudol, Honda Tokoro
  
• When sending a message, there is no direct
  mechanism to detect that the message has been
  received.
• Asynchronous laws (insensitive to buffering).
• Contexts have less discriminative power.
• There are (global) encodings
• As a core programming language, much easier to
  implement!
• Asynchrony, equators, and this kind of stuff ??

61
Locality

• Even in the asynchronous Pi, communication
  occursin the ether. This is sometimes too
  abstract.
• How to rule out any hidden dynamic
  synchronization?
• The Join Calculus Fournet Gonthier
• When fresh names are introduced, a series of
  inputs for those names are statically defined,
  once for all.
• One can only send on a received channel.
• A-Pi Merro Sangiorgi
• Name mobility applies only to the output
  capability

62
Types

• Using types for names and processes, one can
  enforce various communication disciplines.
• Consistent arities for communication
• Polarity (input/output), Linearity
• Communication patterns processes as types
• Behavioural properties deadlock freedom
• Typed equivalence
• The observer must be a well-typed context
• This is often necessary to get full-abstraction
• Typed translations, for instance from lambda
  calculi to the pi calculus Honda et al.
• Types for security

63
Programming Languages

• Facile, CMLprogramming with CCS
  channelshigher-order communication in message
  contents.
• Occam (CSP)
• PICT (95) an asynchronous Pi calculus as a core
  language for concurrent programming.
• JCL, JoCaml the join calculus as a core
  language for distributed/mobile programming.
• Klaim, and coordination languagesa tuple space
  a large channel
• Databases and workflow languages

64
Conclusions

• Mobile names naturally represent dynamic
  capabilities,such as communication capabilities.
  
• Mobility for fresh names is very expressive.
• Dynamic configuration
• Local encodings
• Higher-order mobility can (sometimes) be reduced
  to channel mobility.
• Names dont have to be channels names!
• Cookies, Tokens, UIDs
• Dynamic memory new creates a fresh memory
  location
• Security cryptographic keys