>> Shaz Qadeer: Okay. It's my pleasure to welcome Damien Zufferey to
MSR today and tomorrow. He's interviewing in the Rice group.
Damien did his graduate work in EPFL and at the Institute of Science
and Technology in Austria. Currently he's a postdoctoral researcher at
MIT.
His core area is essentially program verification, but he is remarkably
broad in his interests. He has represented EPFL in the ICPC
programming competition, and he also has written a paper in the Journal
of Theoretical Biology in addition to numerous papers in core
verification conferences.
And today he is going to tell us about the work he's pursuing in the
important area of asynchronous systems.
>> Damien Zufferey: Thank you for the introduction, and thank you for
coming here. So, yes, I will speak today about work I did in the
problem of verification of message-passing systems.
Okay. So as Shaz mentioned, I did, okay, my Ph.D. with Tom Henzinger,
and now I'm currently a postdoc at [inaudible] in Martin Rinard's group
at MIT.
And, yes, my research is not only focused on message-passing
concurrency that we'll see today, but I also did, for instance, on more
core verification like on [inaudible] how to automate separation logic,
so reasoning about data structures and memory safety using SMT.
So what Shaz mentioned I'll talk about was the question of when do
cooperative behaviors occur in systems where known cooperation
basically is the best for each individual. And also more to what the
system side, where we had a bit of work trying to apply obstruction
techniques to large-scale scaling.
So the motivation when I started my thesis, I was looking at
concurrency in the search-passing system was to look where things are
going. And first even on the side of [inaudible] ship, we are going to
toward these more and more parallelism within the SIM device than we
are also like datacenters where we have more and more reason with these
tens of thousands of machines running together.
Also I'm sure that everybody in this [inaudible] has some kind of
smartphone which itself first contain more -- many processing units,
different kinds, but it also mobile is always connected. And more,
well, wearables device means we are going to wear more computer on us,
also [inaudible] of things that we are going to connect pretty much
everything to the Internet.
And we are wondering, you know, what are the challenge to do
verification and reasoning in that context.
So the bird's eye view of verification that you start with some code,
some property, and you want to build a system that is able to either
tell you, okay, your program is safe and maybe give you a proof of
safety or that the program has a bug and give you a contract sample
that chose the bug in your program.
So the talk will be divided into three part. So the first part maybe I
guess many of you have already heard about it, which is the part of the
work I did when I was intern this year, so the work on language P about
asynchronous event systems, so that's like message-passing currency at
the device drivers.
Then the second part is mostly work I did during my thesis, projects
called -- it's called depth-bounded systems. But the real question is
what are the limit of automatic verification when you have systems or
you have dynamic process creations. And when you have -- for instance,
with this system on your evolving communication topologies.
And if time permits, speak about bit of future work.
the question of fault tolerance.
We are looking at
So the first two parts will be asynchronous systems, but at some point
there are many interesting problem that need some notion of time. So
kind of we cover some notion of time.
So the first part here is about this language to program device driver.
And here the reasons. So the language is message passing concurrency.
So first this already using this abstraction you get rid of a lot of
type of error like data races because you don't have shared memory in
the language.
But it's still challenging to program systems well because you can have
many events going [inaudible] with the environment [inaudible]
concurrently the same time, so you have many possible schedule in your
system and gets to be really hard to debug and test.
So here are the contribution is to unifying modeling and programming
within the SIM system so that we get not only compilations, so code
generation, but you also get verification. And the case they use a USB
driver that ships in Windows 8.
And this is a collaboration with people within MSR and also within the
production team in Microsoft Research in Microsoft.
So the motivation of having state machine as a model, that, for
instance, if I show you some code that represent what [inaudible]
doing, even if it's a short like 20-line snippet, it will take some
time to go through it.
Now if I show you these fours -- these four state machines, it's fairly
easy to figure out what's going on. Start initial state, or this then
the door is closed, then someone pressed the open button, so it's -the door is open. When it's open, it closes after some time unless
there is an object which [inaudible] which case must remain open.
And under the same things, that instead of translating this between and
implementing into C, we can turn it into P and exactly pretty much the
same machine, but now it's an executable program.
So we have the initial state and the four [inaudible] before. And here
the difference that we have a little trains of code corresponding for
each state. So now this is not only a model but this also actually a
program.
And in P, not only we have the program but we also have this
environment of the program. So, for instance, if you want the user to
interpret the system, to press the open door button, or if you want a
model of the physical door and the sensor of the doors.
And now that you have put everything into the same system, for
instance, you can run the model checker and testing.
Okay. So now that we have this multiple submission, so how do they
interact. So here we have the classical [inaudible] state machine
semantic. So each machine come with some mailbox, which is a five
[inaudible] buffer. Can receive messages, do some internal computation
and send messages to the mailbox.
So it's a very simple model. [inaudible] part of the success is that
the model is very simple and clean, so it's easy to apply verification
on this model.
So compared to the first picture that we had earlier, basically within
the language, the programming language or the modeling language, we are
bringing not only the code but also the property that you want to check
the assumptions on the environment. So everything being explicit in
the code, which gives you the [inaudible] to do verification and also
to compile, to have an executable model.
And here one of the key part I think in my opinion of the success of
this project is that the language is not really a general-purpose
language, real domain-specific language to describe the protocol so
that where did the name P come from.
So basically directly at the source level inside the driver, we have
separation between the control structure of the driver and the data
processing part, which mean that we can use appropriate technique for
each part.
So here we focus on the verification of the controls of the driver.
And now that we have isolated the control structures, we can use simple
technique, for instance, like an XP [inaudible]. And it can go
actually really far because now we -- the language already provide a
small [inaudible] model. And it just works. Here we have Randy and
Vivek which are in the production team that develop the language and
also implement the USB 8 driver into the language. And here in the
background we can see the -- it's fairly big state machines.
So but if you can imagine tens of thousands of line of code, might
actually be much more worse than this.
Some statistics.
So here --
>>: So one of the nice things with PS, it was able to separate
controls from data.
>> Damien Zufferey:
Yes.
>>: So in the context of USB, can you give an example of what is data
and what is control?
>> Damien Zufferey: Control, for instance, are very [inaudible] this
event. For instance, when you plug a device into a machine, it create
an event in the system and the system will react to this event. So
creating new device state machine. And but only if you want to let
data transfer, for instance, you don't need to look at the data, you
just [inaudible] message that might tells you what you are doing, for
instance, that you need to move some data from point A to point B. But
somehow the day are not really [inaudible] DSL. So each -- maybe each
state of the DSL [inaudible] entry function. So when you enter a state
in the state machine, you execute some part, a snippet of code, which
actually performs some action, you're at least calling some -- a
routine written in C that will do the data processing part. Yes.
>>: To follow up on that question, so you gave an example where the
data part is irrelevant but the other parts would be where you have
data exactly relevant to what you're saying.
>> Damien Zufferey: So here the -- in P you can also -- so this
external function that you [inaudible] written in C, you can also give
them a model of this function written in P. In the model checker we
use this model as part of the verification. So it's some kind of the
contract of the [inaudible] that you're calling. And you -- if there
is some [inaudible] like that in the contract of this method.
>>:
But in the USB example, is everything essentially control?
>> Damien Zufferey: Most of the property that we check are control
related. You want to check, for instance, that when you have this
event coming in the system, that the system does not fail because there
is no handler for a particular event. So you want to -- we'll allow
this type of exception.
You want, for instance, also to check that the system eventually handle
all the events so that you cannot ignore some event that will sit in
the mailbox of our process forever. So it's more like this kind of
control property that you need, for instance, for your system not to
crash and also to be [inaudible] that you all -- eventually handles all
the events. Does that make sense?
And so here some statistics, so [inaudible] USB drivers for state
machine which [inaudible] two different version of the USB protocol and
the device state machine.
And here actually the state machine are getting fairly broad, fairly
large. But even though of this size we can apply verification and find
a huge number of bugs. And the reason is that you started doing
verification because the code even runs. So this type of property
about the event, checking that the event are appropriately handled can
be done even on strings of the state machine. So you don't need the
full code to do verification. Yes?
>>:
What are bugs?
>> Damien Zufferey: So here that would be events which are, for
instance, not handled which basically -- which lead to runtime errors
like, okay, there is a message that you do not expect and might
potentially lead to a crush. So, for instance, you need to protect
yourself not only for device that follow the specification but also
maybe malicious device which are buggy so it sends you messages that
are not expected by the protocol. So that was the type of error that
you need to protect the system against.
>>:
Okay.
So this is checking [inaudible] by the USB team?
>> Damien Zufferey:
>>:
For the USB model.
>> Damien Zufferey:
>>:
Yes.
Yep.
Or is it in P, this --
>> Damien Zufferey: Oh, so the P code -- some of the compiler
generates something, code on one side [inaudible] checker. And other
side it generates some C code which runs as a driver. So from the same
model, you have both the verification and the code generation.
>>: This clarification may be going back to the same question of what
are bugs. What properties are you verifying here? There's
correctness, there is progress. I think you alluded to some of this
before.
>> Damien Zufferey:
>>:
You know, messages will be processed.
>> Damien Zufferey:
>>:
Yeah.
Yeah.
But you please talk about --
>> Damien Zufferey: So here -- so actually liveness is trying to
[inaudible] property. So for to prove that, for instance, eventually
[inaudible] message sort of this kind of [inaudible] property of our
infinite trace is trying to [inaudible] to a safety property. For
instance, you say there is this kind of big state, which is like domain
and loop that we'd receive in and then process them ->>:
Your computer --
>> Damien Zufferey: Yep. Then you just say, for instance, I cannot -when I reach -- again, for instance, I started handling one message,
and when I recheck in this big loop, I must have processed all these
other series of events. So somehow you turn this kind of [inaudible]
property is trying to knit into something which is a safety property.
Somehow it's easier to check. So here you basically enforce this
progress bar, it's somehow bounding the progress, that you must do this
progress within this fixed amount of time. So basically it makes
the -- it's stronger property but is easier to check. Any other
question? Okay.
And so what was takeaway message from me? That when you design a
programming language, there's basically subspace of tradeoffs, what you
want to put [inaudible]. Here, for instance, I took the one possible
set of tradeoffs by [inaudible]. But then, for instance, performance,
generality, and productivity. So, for instance, [inaudible]
performance will get, for instance, something like C. If you want like
productivity and generality, you might get something like scripting
languages.
But the thing which are actually missing [inaudible] P is that you want
to add more and more dimension. When you write some code, how easy is
it to check that the code that you write is correct.
And how here P is giving up a bit on generality because you want
language as this core protocol but making much easier to check that the
problem is correct because the language [inaudible] semantic, checking
the same program but in C [inaudible] semantic of C and we can just
make our life simpler by using another language.
>>: So is the goal of P that any one of that you create is smart
enough to [inaudible]?
>> Damien Zufferey: No. So I will get to it because I think -- so
[inaudible] is doing a really great job for this domain, but main the
trick comes on this slide. I think P is moving some other domain
and -- this is my opinion -- basically we need some other verification
that can [inaudible].
So maybe first about the P language itself, that the first version,
iteration of the language that was the one used for the USB up in
Windows 8 now a cleaner version basically again using some [inaudible]
Windows Phone but is still for device drivers. But what becomes really
interesting now is that there has been some discussion to move out of
this world of device driver and basically to move to the question of
distributed system and distributed protocols.
So there have been some description about adding features on P to
implement distributed system protocol and discussion, you know, not in
the device driver world anymore but more in the Internet and cloud
world.
And here, at least my opinion, the language, it's still a good fit, but
the verification technology that we use we should start to show some
limitation.
So, for instance, the language, this unbounded mailbox, it also have a
lot of process creation which has two feature basically that gives you
an infinite state system which is something that cannot really dealt
with by efficient model checker unless what you do is apply some
bounding strategies. Yes.
>>: On the slide with the table where you're showing how many states
have been explored, sorry, does that -- are you doing any state
abstraction there or system like constraint, or is that basically
saying you've explored the complete state machine that's listed in the
left column and that's how big it is?
>> Damien Zufferey: No, there is some bounding strategy which is used
to deal with the interleavings of the communication to try to steer the
search toward what bugs are likely to be.
>>:
Okay.
So this is a sampling model checker.
>> Damien Zufferey: Yeah. It's not complete.
systematic technical validation.
>>:
Okay.
We call it like
Just trying to understand which --
>> Damien Zufferey: And here is actually for the server, there is also
some layer of [inaudible] verification to try to check the [inaudible]
state machine separately.
>>: So you get better coverage of each machine, and when you compose
them, you get this ->> Damien Zufferey:
>>:
Okay.
Double guarantee.
Yeah.
Exactly.
Thanks.
>> Damien Zufferey: So maybe I can check a few word, that, you know, I
said that you can also [inaudible] model to the system, so actually
Randy, when he developed the drivers, admitted these [inaudible] rules
which all have the assumption on the environment. And there is
actually a few -- there tend to be very small rules that, for instance,
if I receive a request, I won't receive a new request until I granted
the first request. So but is there a lot of this -- there are very
small property, but there is like hundreds of them, which are checked,
which are used to check the model.
Okay. So here actually when we have this feature of process creation
and a feature that goes [inaudible] the question of evolving
communication topology, that if you were present, the communication of
the system is a graph, you can also add and remove edges in the graph
by sending, for instance, addresses of processes into the messages.
And actually those features in the literature, they're called -- known
as mobile processes. And that's the domain I've been investigating,
looking at what is possible to do in this setting during my Ph.D.
And one of the reason might be, for instance, if -- so what we're doing
now, for instance, for the verification, using bounding strategies. So
for instance you can bound the number of processes. But maybe in some
cases it's not realistic to have a bound. Or if the bound is too high,
maybe it's [inaudible] practice.
So we have been looking at unbounded systems. And, yeah, this question
of when you have process creation, this question of frequent
configuration of the [inaudible] because a new process coming to the
system start interacting with other component and then the address,
like the mailbox, the address of that process, might get sent further
down into the system and you create new communication link.
And also there might be some [inaudible] property. For instance, you
want to track information flow, the communication topology is really
something that you might want to know.
So here it's [inaudible] those infinite state system is really hard to
deal with. But we -- you know, it's not because it's hard it goes
away. So [inaudible] that is an important, interesting problem, and
we've made some good progress, but the talk maybe at some point, if it
gets too technical, just interrupt me, ask question, so that we can
make it clear as we go.
And, yeah, here is that even though it's hard, in the end we have some
very interesting results.
Okay. Small motivating example. It's a simplified version of
MapReduce. Why MapReduce? Because it's a fairly broadly used general
type of computation that run in the cloud. So if we cannot handle that
kind of example, we cannot really handle anything. And also it's small
enough so that you can fit into size.
So you start with some set of data that you want to process. You have
some master and some workers, and so you dispatch the data to the
workers to do the mapping. Some machine may crash, in which ways you
need to find some other machine that is able to [inaudible] and send
back the data to this other machine.
When the computation is done, you just get at the result, some kind of
key-value pairs and [inaudible], and then you do the reduce to keep
only the best result.
But to make it really interesting, we need to consider not only a few
number of jobs that you process in parallel but an unbounded number of
jobs. Also the [inaudible] datacenter there is no reason that we
should bound this to a small number of worker. So it might be actually
simpler to consider an unbounded number of workers. And same for the
crashes.
And here [inaudible] basically the interesting part is that it can take
the system, compute all the reachable state of the system, and give you
this very compact representation. Here are four graphs that basically
subsume all the reachable set of the system and will give you all the
information about communication topology.
And also the interesting things that maybe I wish -- that was a kind of
a bit of a surprise, that we can go from an infinite state system to a
very small representation of all the reachable set of state. So then
we thought, okay, maybe we can go further. For instance, since this is
an [inaudible] variant you can apply again the [inaudible] system and
look what it does to this representation.
And here, for instance, we get -- if we just go very abstractly, we
have now this four state automata which actually simulate -- in term of
traces simulate the original system.
And we see how to go much further so that when you have a single
transition, you can also track how the graph is changed by the
transition. And then we can use that as a basis to build further
analysis.
>>:
What is the automata in this picture as many.
>> Damien Zufferey:
>>:
Will come in two slides.
Okay.
>> Damien Zufferey: So basically this is -- here the graph is really
like the state. So in the graph ->>:
Which column is the state on the automata?
>> Damien Zufferey: Yeah. Here basically we have -- so you can think
of here -- so these four graphs are like the [inaudible] for all the
reachable state of the system. And in this representation, you can
here the -- the third -- like the transition of the system that can
bring you from one state to the other. I mean from one set of state to
another set of state, which is more incomparable. So the more we tried
to learn together all the state that are somewhat similar in some
fashion, and some [inaudible] done by one of this graph.
And then actually we do it in a way so that basically you can summarize
many states into various small representation, and then you can track
how those set of state are changed by the transitions.
>>: So each problem is representing a set of states by means of a
graph?
>> Damien Zufferey:
Yes.
>>: And a transition is a transition of the system let's say is that
it from these states that transition is taken, then you will
[inaudible] this set of states.
>> Damien Zufferey:
>>:
Okay.
Exactly.
Yes.
>> Damien Zufferey: And we'll see how we can -- just what are those
graphs, how to we represent them, and what we can do with them.
So first [inaudible] system is that we have labelled graphs, so each
node of the system carries some sort of label which [inaudible] type of
the process, local information, like local variables, the program
counters, some information on multiple variables.
And then some other information which are more like relations, stored
models, part of the label of the node, but as edges in the graph. So,
for instance, if the master is a list of workers, you would just put
edges to the different worker machine.
And here we see the restriction that we need a finite state of label,
so each -- somewhat each individual process need to be finite state.
Okay. And now the transition basically works, the automaton come from
words of the code and how do we modify those graphs. So here I'd say
we have simple example where the master just spawn the one worker and
send a message, and the worker just receive that message and process
the message and send a reply.
So the way we model that is that first we have the master, which is,
for instance, line 4. So when we [inaudible] worker, it's a new node
in the graph. So basically somewhat new state machine in the graph.
And there is a relation between the two, which is this local variable
that contains the address, which is the edge in the graph.
Sending a message is actually somewhat similar as spanning some of your
processes, just I think some new node in the graph. Here the message
can carry the submission address and also the address of the sender.
And when you receive, for instance, you can extract the address of the
sender and store it into some local variable, which mean that when you
have this call to reply, now you know where to send the message back.
And so when we started the project, we did a lot of [inaudible] pi
calculus, and one of the insights of the pi calculus that you can see
in [inaudible] that there is no difference between processes and
messages. And also what is called -- what is known as mobility,
there's just this ability to addresses carried within message so that
we send message and receive message, you also modify the edges in the
graph.
So the -- yeah.
>>:
For instance, if I compare [inaudible] in P each --
I have a question about the previous slide.
>> Damien Zufferey:
Yes.
>>: So I understood how you add an edge in the graph.
edge get removed from the graph?
How does an
>> Damien Zufferey: For instance, if you -- for instance, you have
this -- well, this address here, this edge here represents the address
stored into worker. So if you put a new value into that local
variable, that will somehow change the edge. So the previous edge will
get removed. And also if you move out of the scope of the local
variable, the edge get removed.
>>: So what I don't understand is how does that graph represent a set
of states? To me it seems to represent exactly a single state.
>> Damien Zufferey: Because this graph is a single state. Will come
later to how you move from this single state to infinite set of states.
>>:
So the graph is [inaudible]?
>> Damien Zufferey: So this example, yes. We'll see now the
interesting question is how do we -- when do you have unbounded
[inaudible] you can add as many node as you want in the graph. So how
do we have a compact representation of these infinite graphs. So
that's what's coming.
>>:
[inaudible].
>> Damien Zufferey: Yeah. I mean, sure, you could repeat forever and
that will just create some new node in the graph so the graph
[inaudible]. But if you keep an explicit representation, it will
never -- it will blow up and it will go forever. So we need to do
something smarter. And it will come. Just bear with me.
So the first, for instance, we compare with P [inaudible] difference
that, okay, P are these unbounded mailbox. But it's not actually
[inaudible] sometime that's very dangerous things to do [inaudible] in
this ability. So that we verified two state machine in one FIFO we can
just build a Turing machine. So that's something we want to avoid.
So to make our life simpler, we just abstract the mailbox by forgetting
about the order of the messages. So we still have unbounded mailbox in
our model, but we just don't remember the order between the messages.
But now the interesting part come is that when we keep on adding
processes, we need some kind of [inaudible] processes and message are
the same. So if unbounded [inaudible] mailbox which is a chain of
messages are bad, unbounded chain of processes are also bad as well.
So we need [inaudible]. So we still want to have a restriction that
captures a large class of examples. So we started collecting some
examples. So we come from the -- it's a simple part of the
computation. So we were speaking a lot at that time with the people at
TPFL working the Scala laboratory, so we got the example from them.
And also in the literature. For instance, pi calculus. So the first
application to verification was actually the GSM handover protocol. So
we collected example, and then we ask what are those example in common.
And so here let's come this discussion, what's called depth
boundedness. Is that most of the system the communication topology is
some kind of similar to a tree. The restriction that we impose is that
in all the reachable set of state you need a bound on the longest
acyclic path in the graph. So you can still have cycle in the
communication, but they must be bounded cycles. But, for instance,
here you can have a process, and you can have an infinite number of
nodes [inaudible] infinite bounded number of workers for one master.
Donald Roland Meyer was already working before us on the problem, so
that's where the name come from, from one of his paper.
So here the intuition is some more processes, infinitely many processes
in parallel are kind of harmless and easy to deal with, but infinitely
many process like chain is something which is much harder. So we
want ->>: The graph for one strongly connected component, you would just
pick -- to apply that definition, you would pick some basic orientation
and that's the definition of the longest, basically that?
>> Damien Zufferey:
>>:
You get all the path in the graph.
Because presumably the worker communicates back.
>> Damien Zufferey:
>>:
Yeah.
Yeah.
So there will always be cycles --
>> Damien Zufferey: Okay. We -- we -- it's just as the paper. So,
yeah, you have cycles. Actually we look [inaudible] the acyclic graph.
So we just [inaudible] in the undirected graph. So we just
[inaudible]. So when you have like back-and-forth edges, it does not
change.
And now the intuition for the problem is simpler because when you have
this problem ->>:
So why is it simpler?
>> Damien Zufferey:
>>:
Yes.
What's the [inaudible]?
>> Damien Zufferey:
>>:
Is it simpler for depth bounded systems?
Okay.
That's -- no.
>> Damien Zufferey: So the intuition is -- so we are asynchronous
system. So the intuition that capturing the asynchronous system, for
instance, if you can add more limit to your system if you don't
schedule them because you are allowed to because it's that close, then
you get the small -- same thing at the smaller system.
For instance, if we have a transition, like the master sending a job to
the worker, now we just go back, but we make the system much larger.
Then the exact same transition can also be taken.
So what's the formalization? It's known as [inaudible] transition
systems. Which we did in one of the main -- as a workhorse, if you
want to prove [inaudible] result of an infinite system, so it mean that
you have an ordering between the state of your system.
So here, for instance, the ordering is adding more element into the
system, and it's ordering a simulation of relation. So for anything
that a small state can do, a larger state can also do.
And here the ordering is graph embedding. Also just if this graph is
smaller because it's a subgraph. And here you prove [inaudible] same
property. For instance, [inaudible] the order. So if you start doing
state specific [inaudible] and numerating state, what that mean
concretely is that at some point in time you will see state which are
comparable, so you cannot have like infinite state which are
incomparable in this ordering, and that's something that someone
[inaudible] much easier. And that's the basic of the algorithm that we
use.
So maybe there is the reason why [inaudible] is that all the transition
that I show you before can be captured at this [inaudible], this very
abstract model that, for instance, transition that where the master
send the task to the worker, it's like changing the edge in the graph,
you know, the worker is a reference to the job it must process.
And the way you apply that to end graph is that you look for matching
in the graph. And then you just replace the part of match. So
basically if you make this graph bigger, this matching will still
exist. So basically that's why the ordering is also this simulation
relation. Because adding more node in this graph [inaudible] original
matching.
>>: Is there some ring here to the left-hand side can't have a
negative -- I guess can't have a negative pattern?
>> Damien Zufferey: Maybe I can show you some example later if you
want, but [inaudible] to the system so that you can have not only
something that you look for as much but also something that prevents
the match. So like as you said, negative pattern. And there is some
order. It's called monotonic abstraction. So maybe I should just go
with the main part and then later we can just go into the system.
And here the [inaudible], okay, there is this framework of [inaudible]
systems, the algorithm for the systems. So [inaudible] just implement
and try. They're not that -- desirability is not efficiency. So even
though now we know that the problem is somewhat simpler, we still don't
have any kind of algorithm or analysis that we can apply to the system.
And so the original algorithm is basically a backwards search. So you
start from zero state and you go backward until you reach the initial
state. So if backwards does not work, we try to do it the other way.
So we start from initial state, do -- configure the successor, and
again and again, and at some point you have all the set of reachable
state.
And now checking error is just making sure that the error state is
disjoint from this set. But the problems that since we can add
processes, this set is not finite. So it's infinite.
So we need to do something a bit smarter. And here that's where this
monotonicity condition becomes interesting. Because when we, for
instance, explore the initial state, we know that basically all the
[inaudible] smaller than this state, cannot do anything more. So just
checking one state basically cover all the state which are smaller than
this one.
So then basic computing the post, even we compute the post on the
finite number of elements, we can cover a lot of state. And the goal
of the analysis here is just basically to cover all the state space by
just looking at finite number of elements. And here the challenges are
first how do we represent those element, because it can be an infinite
class, so we need something here to be able to represent this state.
And also about the algorithm and the method that we use.
So here [inaudible]. Now we have something that compare to the
standard algorithm that works much better in practice but a bit not as
good in theory, so we are to apply abstraction to make it work again.
And also checking error state, now we just [inaudible] ordering if you
find something that contains error [inaudible].
>>: But in this case when you apply the abstraction, supposing you
find that you're able to reach the error, is it possible that it's -the abstraction was too coarse?
>> Damien Zufferey: In this example, I mean, since the abstraction, we
designed it, yes, I can make example that will be too coarse. For all
the communication part in the example we look at we did not find any
such examples. Yes.
>>: How about -- I think I have a question [inaudible] I still don't
see how if your communication graph has bounded basically that then
your states -- they're simply state spaces [inaudible].
>> Damien Zufferey:
is ->>:
Well founded.
>> Damien Zufferey:
>>:
So basically it's how you prove that this ordering
Well founded.
Yeah.
>> Damien Zufferey:
So --
>>: But what is -- I mean so I just don't understand how even if you
have [inaudible] state space [inaudible].
>> Damien Zufferey: So if your cycles basically [inaudible] cycle
bounded in length. The fact that first there is no descending chains,
so there was from that part, is just because if you remove node in the
graph at some point you have DMT graph and you cannot go smaller than
that. And now to answer your question which is about why you don't
have like this infinitely many incomparable graphs, in the tree that's
extremely hard to prove. I mean, there is basically kind of just one
paper about proving that.
And we use some theorem like extension of [inaudible] tree theorem with
orderings. Or also there is very strongly with tree automaton, some
constriction of tree automaton that you need.
So basically you take your graph, you try to turn it into some kind of
tree where you basically closure of a tree, where you allow not only to
have edges from children -- parent to children but you can solve the
edges to ancestors. And then you can tree automatons more to recognize
the sets of state and identify this theorem with ordering and trees and
from this [inaudible].
But, I mean, it is true that is very -- let's say it's conflicted
proof.
>>: Just I guess the question to you is, yeah, the simulation
relationship also taken into account that this smaller -- this smaller
graph is simulating this bigger one. So what does that mean, that ->> Damien Zufferey:
So that you --
>>: -- that these three processes simulate -- or these two
processes --
>> Damien Zufferey:
transition --
So you -- but if you can prove for every
>>: The other way, the larger graph is relating this one.
on the right ->>:
Oh, right.
>>:
Yeah.
Yeah.
>> Damien Zufferey:
>>:
The thing
So --
Yes.
>> Damien Zufferey: So that's some -- basically when you look at here,
so the semantics applying a transition basically is looking for a
match, and unless we have this blocking pattern, which maybe we can get
later, if you don't have blocking pattern, then adding more nodes in
the graph does not remove the existing match. So that's the intuition
behind the monotonicity.
>>: But the elevator at the top of this cone is actually the smallest.
So in that sense you need to ->> Damien Zufferey:
>>:
The smallest graph, though.
>> Damien Zufferey:
>>:
No, it's the biggest one.
Not necessarily.
[inaudible].
Smaller graph than the other elements [inaudible].
>> Damien Zufferey: So here now each -- basically each graph represent
a sets of graph, that which will be welcome here, what's -- what is
this element at the top and what does it represent.
So here -- so we need this -- we have this significant set of graph, so
how do we represent. Let's look at the property of those graphs. And,
for instance, you know, it's a partial order, so you can add the limit.
Maybe at some point you get even incomparable graphs. But we look at
very specific set of graphs which are called directed sets.
So if you know that you have two elements which are incomparable, you
can get one which is bigger than the two. So just add more stuff until
you cover the two. And those sets are very well behaved. So we also
consider [inaudible] and we felt the [inaudible] people have called
that ideals.
So now we have some more intuition how to represent [inaudible] sets.
We just need to figure out what is the [inaudible] top. So basically
here that's what we call nested graphs. So the way you present
infinite set of graphs is that you just mark some nodes, maybe some
kind of generation of regular expression but [inaudible]. So you mark
some set of node, something that you can just go P many time.
And also we allow this to be nested. So here, for instance, this
represent [inaudible] server and some client. So you have unbounded
number of client, and each client can have an unbounded number of
requests pending. So that's how you can get both unbounded number of
processes and unbounded mailbox.
Okay. So here actually I don't know if people know between that stuff.
Basically this is really the key difference for this existing model of
Petri nets that you cannot do in Petri nets and you can do here.
Okay. So now we have everything we need, so we have this analysis. We
have the representation of this infinite set, and so we implemented and
then tried.
And that's, yeah, when [inaudible] interesting surprise that you go
from this infinite set of sate and actually you have this very, very
small representation of all the reachable set of state. So because of
this system and this monotonicity property, they have this somewhat
built in some kind of regularity that you can exploit. And this
irregularity actually really give you this small representation.
Okay. In practice it looks more like this.
same -- so I tell you ->>:
So if that's somewhat the
[inaudible] example.
>> Damien Zufferey: Actually, that's -- well, I tell you that now, for
instance, if we can track changes in the graph, for instance, when you
apply, so here what I show you basically looks the same graph but if we
just expend everything and we have all -- when we take a transition,
you just have the changes. So here is not something that you can
anymore read with a human, but still something that the computer can
deal with it. Yes.
>>: So this theorem that you said that if you have bounded [inaudible]
so that's the theorem that you proved, or is it [inaudible]?
>> Damien Zufferey: So what was known -- so we first -- when we
started working on that, we find this result. What we didn't know is
that Roland Meyer had the same result. But what we had that Roland
Meyer did not, add that this -- how to represent these infinite graphs.
So Roland Meyer just proved that the ordering of this property, but he
did not have the -- basically at that point he was interested only in
the theoretical result and did not try to apply it, so he did not add
this, how to represent those infinite graphs, which is basically the -now the element that you need if you want to apply analysis and go
beyond just this set of the results.
>>: [inaudible] theorem a general theorem on both [inaudible] and
because you built on top of well-founded orders ->> Damien Zufferey:
>>:
-- is the [inaudible] you had, but --
>> Damien Zufferey:
>>:
Yes.
Yeah.
So basically --
This proof is sort of -- I mean, your proof is for this system.
>> Damien Zufferey: Yes. Exactly. I mean, there is a lot of very
interesting literature, but you have to go like in ordering theory in
lab that you can just leverage and use. So somewhere there is a lot
of -- it's like saying that, you know, since there was a [inaudible]
interpretation, you can fit everything [inaudible] interpretation. So
here there is this [inaudible] framework, which is very powerful, but
if you want to use, there is still a lot of work to do. Especially if
you want to do have something that kind of -- some notion of
efficiency.
And here maybe just if we look inside, you see the same graphs, but now
transition basically are these mapping in blue that tells you how the
graph change over time.
So now so it's a good time to pause and consider. I say it might make
sense to look at unbounded systems because, for instance, even in the
case of the bound being too high, it not make you -- unbounded system
do not make your life simpler.
And here actually [inaudible] same things happen. So if I did a small
scaling test in that simple example, I just bounded the number of
inputs that the system processes. And then I show you here the time it
takes to compute the set of reachable states. And the number of
ideals, so the number of graphs that you need to represent the set of
reachable states.
And as you would expect when you're bounding your state's explosion,
and actually here since we're very generic class of system, this graph
is actually bad so it goes very well to some sites, like seven, then
you have just two more element and just blows up.
On the other hand, when you go to the limit, turn out to be a much
simpler problem actually in term of running time. And also what was
very interesting was that the part that was kind of new in the
[inaudible] the representation of doing things set of state is actually
smaller than a representation of finite set of state.
pretty cool result.
And that was
And then we use it to build on further analysis. So I'll tell you that
in this graph when you repeat it -- when you [inaudible] on this part
of the [inaudible] it just means that you have many elements. Now we
can do more. We can just associate a counter value that says not only
how -- exactly how not only many but that just count how many element
you get. And if you combine the two [inaudible] abstraction. So we
apply that to prove termination of systems.
Also interesting things, just do software engineering, for instance,
there is notion of state machine interfaces. So if there is -- for
instance, you have a lock object, there is a sequence of event of
method call which is legal, which is locking and unlocking and
alternating the two. And that's easily something that you can easily
capture your state machine.
And here if you apply analysis, we can basically get the generalization
of this concept. But when you have like multiple object together, for
instance, you have a collection and you have many territories pointing
to that collection, so if that collection -- when in territory decide
to remove an element of the collection, even though it's [inaudible]
territory to invalidate all the territories pointing to SIM collection.
So some model call changes [inaudible] that's something that we can
capture using this analysis. So we called that dynamic package
interfaces.
Yes. Oh. And, yeah, we have implemented all that, available the Web.
And we have [inaudible] using models different distributed system,
mostly coming from actors example.
>>:
Question, Damien, one previous slide.
>> Damien Zufferey:
Yes.
>>: Are you saying that your modeling the state machine interferes
using the same sort of pi calculus to bounded processes?
>> Damien Zufferey:
>>:
Do you think that that is a natural model for this kind of stuff?
>> Damien Zufferey:
>>:
Yes.
Pi calculus, no.
The graphs, yes.
Okay.
>> Damien Zufferey: So some here actually we don't really care that
much about the graph, rather about the language. Because, for
instance, if you have, yeah, exactly that [inaudible] element will be
one transition, and then this will say that you -- the order transition
of other territories iterating becomes invalid. So somehow you can
capture the language of this not only with a single object but the
language of the sets of objects using that representation.
>>: So the contribution of this paper that you have there, was that a
look at a piece of code and extract the model ->> Damien Zufferey:
>>:
So here --
[inaudible] automatically use it in this abstract language?
>> Damien Zufferey: Yeah. So exactly. So here the contribution is
not theoretical because it's just the same information we had before
[inaudible]. But actually it's more like on the implementation side.
Actually here the [inaudible] support that, just take snapshot of the
heap. So run the code using basically just calling all the methods,
and each time take snapshot of the heap. And then just compare the
snapshot of the heap basically to build this graph [inaudible]. So
somehow it's a simpler way of being able to build the transition
systems not only by looking at [inaudible] in the code but looking at
execution of four pieces of code and just by looking at the start and
the end result. So basically then it's a way of making analysis. So
here this runs on real code, so the previous examples work on models.
Here the analysis runs on the [inaudible] code. So it's more like how
to implement and make this work.
Also one interesting -- so this graph model, mostly the motivation came
from [inaudible] of heap graph and that's pointer [inaudible], then
actually you can also look at shared memory. So for instance what I
told you this strict [inaudible] abstraction, we use it to prove
progress of, for instance, log algorithm, like Treiber's stack,
Michael/Scott queue. So those are -- so proving progress in this
algorithm tend to be very tricky because there is interferences
[inaudible] particularly one process can make some action that will
make an order process fail and retry.
But here we have an analysis since it track like all the interaction
between the object, it's still precise enough to prove termination
of -- I mean to prove progress for this example.
>>:
Those examples are not test founded, right?
>> Damien Zufferey: So here -- so what we do, because for this we
don't prove the functional correctness, that the queue is a queue. So
we just prove progress. So we forget about the ordering of the element
inside of queue or inside the stack. So that it preserve termination.
To prove progress actually is enough. And ->>:
[inaudible].
>> Damien Zufferey:
>>:
So maybe a bit of comparison.
I have a -- I have a somewhat philosophical question --
>> Damien Zufferey:
>>:
Yeah.
Yes.
-- about this part of a graph.
>> Damien Zufferey:
Yes.
>>: So the kind of techniques that you describe right now, they fall
into the class where you try to construct a representation of the set
of reachable states in some -- something, you know, that a computer
understand and a human being will just not be able to make any sense of
it, that's one class of techniques. The other class of techniques is
basically [inaudible] where you try to capture the set of reachable
states as a [inaudible] that a human being can understand and the -- I
mean, for this class of techniques, the problem that has always been is
that it works on models and you have to make a lot of simplified
[inaudible] and there's a story about how to convert the bad from the
models to the implementation that are running the hardware, it's very
[inaudible]. So do you have some thoughts based on your experience on
how to make this kind of tooling be part of real software engineering
given that there will always remain a gap between models and
implementations?
>> Damien Zufferey: Okay. So -- so here I think to apply it, I think
if you look at the approach in the dynamic packaging interface,
somewhat tried to mix come kind of runtime and static analysis
together. So you can do some running the system basically to get some
traces from which you extract some transition in abstract system and
then run the static analysis on both transition. So from over here you
might need to do work to prove that the transition you extract from the
execution actually enough to prove some -- to give you some guarantee.
But starting by looking at execution, difference, for instance, that
the [inaudible] like the termination analysis runs on models, the DPI
really runs on the code. So basically it's a mix of -- it's a dynamic
runtime analysis with the static analysis.
>>: In the case of the work that you did for the dynamic package
interfaces, were you able to -- I mean, if you're using dynamic
analysis, then you get [inaudible] only a few traces.
>> Damien Zufferey:
>>:
Yeah.
Can you actually conclude about all behaviors in that case?
>> Damien Zufferey: So in that case, no, we don't have a completeness
theorem. So what we try -- so in practice we had both the models so
that we [inaudible] were complete models, and then we had their
implementation running on the real code, and we just compared the
output. They tend to -- they match really well in practice. But so
more basically, yeah, you are limited by the number of traces you
explore. So in practice there is a threshold of a few thousand traces
that worked pretty well. But, no, at that point you -- when you start
mixing runtime and static and dynamic analysis, you don't have any kind
of completeness. But we have something that can be applied, so...
>>: Is your philosophical question about do you want to find the right
way to write invariance about system with dynamic processes, or is the
right thing to do to figure out how to abstract systems with dynamic?
Is that the philosophical?
>>: Yeah. I mean, the thing is that traditionally you can write
invariance on real implementation and you can try to push them through.
Typically. But you for some reason -- I don't know.
>> Damien Zufferey: So here basically -- yeah. I mean, there is the
opposite approach that people have taken, these maybe session types.
When you first watch what you expect the system to be doing, and then
you just make it into a simple -- a language which is simple enough
that you can check that the system is actually doing that. So
basically you write top-level protocol, and then the protocol using a
language that can be projected in components with a protocol, and then
you can select what people call BFRL types.
But we do the other approach that -- for instance, it's not clear that
what's the right language to write those invariants. So instead of
writing invariance, say can we just take the system and figure out what
the system is doing. So that's the way we do the [inaudible] approach.
Because yet [inaudible] yeah. That would be the first part.
Comparison is that if you have a good language to write the invariant
of the system, then you can use SMT solver, for instance, to push the
proof through. But since you pick concurrent [inaudible] that would be
like challenge VCC approach.
Then if you look -- yes?
>>: So Murphy would be under that second bullet?
01 star abstractions.
So Murphy has like
>> Damien Zufferey: Yeah. So here -- okay. This is not complete, so
I did not really include all the different abstraction that you can
build.
So more actually if you look at 01 star abstraction, so what happen.
So in my case the system that we have behave like a 01 to something,
and then we have some [inaudible] technique that go to infinity, so 0
something abstraction, so in many case actually we can subsume that
type of abstraction, 01 star abstraction. But we don't have like a
fixed [inaudible] but if it's the widening or the acceleration that
tells you when you go to infinity. And that depends on the runtime, I
mean, how the system -- how is the code.
So for some reason it's something more general and complete version of
the 01 star abstraction.
>>: That wasn't my question, but I thought that you made the point
that you could have nestings [inaudible].
>> Damien Zufferey: So the nesting is really something that you need.
So, for instance, we compare like two vector addition system with Petri
nets, which have been not quite successfully as concurrent program
because can't just have this -- place that number of token, just count
how many process you have.
If you want to have both an unbounded number of process and unbounded
neighbors, okay, we -- if you want, I can give you technical
[inaudible] basically it does not fit into a single Petri net.
Basically because you have counters for the number of process, and then
if you want to have had the mailbox, which is not bounded or processed,
each time increments the counter by one, you need to introduce a new
counter, which is how many messages are there for this process.
So here that's where you need the nesting, so that when you have the -somewhat this multiple dimension of unboundedness. It comes
particularly when you have this tree-like topology. That, for
instance, you have just one step, which is like the Petri net, you have
like many processes, but if you want to count -- if you want to go
further down some kind of hierarchy, you need something like the
bounded systems.
So I think that's one of the reason why there's many [inaudible] trying
to fit concurrent message-passing system into Petri net, but it's only
like fragments which are kind of quite not the same but very close
because fundamentally you have a problem, and here I think we address
the problem.
>>:
So does your system do -- would it subsume [inaudible] Dubois '94?
>> Damien Zufferey: So here this related to the question of
[inaudible]. In this system you have these universal transitions. I
mean, that's also something -- so we look at -- so this paper you
mention and also some other cache currency protocol. But some time you
have some kind of universal transitions. If nobody else has done
something, that can take it ->>:
[inaudible].
>> Damien Zufferey: Yeah. Here we're kind of blocking -- so we can -okay. Gets a bit complicated. The short answer is that we can have -basically we can add guards. So, for instance, if nobody else has sent
a request, you can do some things, which is really universal.
So we can have this notion of guarded. This becomes, again, an
abstraction. For instance, we apply that, for instance, to prove -- we
can prove something like [inaudible] protocol safety so that you really
have isolation. Now the graph that it generates tends to be not so
nice. So it works well for safety, but we have not tried to apply this
for analysis on that, because the abstraction [inaudible] to keep many
safety properties that might not be -- that may be too coarse to allow
this for the analysis, like termination in progress.
But, yeah, so that if you want maybe I can just
I think I have. So yeah. You have transitions
side and right-hand side [inaudible] we can add
some pattern that if you can find this pattern,
not be fired.
show -- jump to this.
on top of the left-hand
some guards, which is
the transition should
So the way of still preserving the monotonicity of the system is just
one phase basically which is called unfolding. So you map the
left-hand side here, would be here, and then you look at all the
possible mappings of the guards. So here mean that would be somewhat
that need here would be here.
So we just remove that node, and then at that point the guards don't
know much anymore and you apply your transition. And it's called
monotonic abstraction. And it gives you [inaudible] this global
transition over the whole system. But since it's global [inaudible]
system, it's not really monotonic again. And the result depend on the
examples.
>>
>>:
Okay.
[inaudible].
>> Damien Zufferey:
>>:
Yeah.
[inaudible].
>> Damien Zufferey: Yep. So basically the intuition is that
somewhat -- so if there was not this node, the transition could fire.
And since you may need to keep some monotonicity, so you need to make
your transitions still fire when know things. You just remove them.
>> Shaz Qadeer:
I think we should let Damien finish his talk.
>> Damien Zufferey: Okay. Okay. So just maybe quickly a bit of
future work. Exactly, I mean, this question, for instance, this
monotonicity of the system that we need for this analysis is actually a
restriction when you look at other kind of systems. So especially
[inaudible] I mean, if you think of application large scale system, you
will encounter failure of machines. So we [inaudible]. And if you
want still to be able to prove some property, the systems, many of them
needs times. So, for instance, that was captured by the FLP
impossibility result. So if you don't have time, you cannot solve
consensus.
So some of the [inaudible] is not really well suited to deal, for
instance, if we want to deal with this [inaudible] algorithm. But they
are still very interesting because when they are using critical places.
The fact that you're willing to afford the cost of replication and
redundancy mean that you really probably care that your system is
correct. So that's a good target for verification.
But the method that we have basically could prove 50 but cannot prove
any kind of [inaudible] single systems. And you might also want to
prove progress. And still very challenging. So not only as before we
had this kind of explosion of the schedule due to the concurrency, but
if we had fault, we have one more nondeterministic [inaudible] when due
process crashes, when [inaudible] develops.
Also we have this parametric number of systems.
as before but worse.
So basically the same
So here actually we think that we should do things differently. That's
if you in the time -- instead of trying to add time on top of
[inaudible] let's try to go the other way around and start a model
where you really have true notion of time, which is synchronous model,
prove something in this synchronous model, and then you need some tool
then do some [inaudible] proof to say that the result you proved in the
synchronous model still [inaudible] in the asynchronous system.
And the reason of having these different models, they are really much
easier to reason about. And they have encapture -- I mean, they are
different nice properties. Let people call communication closed so
that basically messages are sent and received within the same round.
So if you agree to accept the [inaudible], you can just remove the
mailbox and uphold the [inaudible] before because of the mailbox
[inaudible] buffer just disappear. And so you have something which is
really much easier to reason about.
Also, if you have this round model that everybody takes up at the same
time, you get rid of the interleaving problem. So here we have
something, a much nicer model.
And here it becomes much easier to add, for instance, crashes, other
type of fault, like [inaudible]. But since the -- now we have this
round -- this very strong notion of time, it's still much simpler to
reason about.
And the reason we started looking at this very strong model of
synchronous, that if you look at the literature of [inaudible]
algorithm, many algorithm actually written in that form. Even though
they run into the mass -- on top of asynchronous system, the way the
algorithm [inaudible] structures, they follow these kind of multiple
phases.
For instance, [inaudible] you might send process some messages, and
then depending on the amount of process you receive, you might do some
update.
And even think of [inaudible], which is asynchronous algorithm, it has
these different phases. First elects the leader, then it try to send a
value once you agree to every processes and get the result, and if you
get enough result [inaudible]. So [inaudible] run on asynchronous
system, it's structures and runs. So that we want to -- something we
want to apply to make our life easier, or the verification process, the
verification side, so we have started on the direction. And something
that we still need to work on is the refinement proof from the round
based model down to the asynchronous systems.
So there is actually reasons why people have been working on this
round-based model is that there are, for instance, what people called
predicates layer, which is a generic way of implementing the illusion
of runs on top of [inaudible] systems.
So we could maybe just implement that. But if you look at those paper,
there's some multitheoretical constructions and unlikely to work in
practice [inaudible] to get something which applicable, we need to
specialize the [inaudible] proof to the algorithms. And, yeah, there
is very -- a lot of interesting work in that direction in how to
automatically transform an algorithm expressed in these round systems
to have something that trends on an actual asynchronous system.
Okay. That's all for the future work. And I'm happy to take any more
question, make clear any point and [inaudible]. Thank you for
attention.
[applause].
>> Shaz Qadeer:
More questions?
>>: CSP a long time ago broke through, did a number of new things.
Are any of those theorems and these formalisms that were used
[inaudible] are they still relevant today or are they just so taken for
granted these days we don't think about it?
>> Damien Zufferey: Honestly, the bang and question mark notation from
just P state much better than the pica code notation. But I think on
the other end, if like in the term of insight of the modeling systems,
we read a bit about CSP, but I think pica calls and that kind of
formalism, which is somebody [inaudible] systems more relevant.
If you give me some more precise question about CSP, I can compare.
But roughly I think [inaudible] insight of decoupling processes and
accuracies and names is actually very -- I mean, that's really
something we use.
>>: So everything you described is really to verifying the programs
are correct.
>> Damien Zufferey:
Yeah.
>>: And that means you have kind of a pretty long period of time to
think about answering that question [inaudible] yes or no. But if you
were to take some parts of this analysis and make them dynamic, then
maybe -- we were talking about this earlier -- maybe find some way of
doing a partial [inaudible] partially computing the same analysis and
then making some adjustments to the protocol that's executing,
especially if it's delivering messages or something.
>> Damien Zufferey:
So what -- yeah.
>>: Do you think that this would be something you could do?
there -- do you have any intuition?
Is
>> Damien Zufferey: I mean, there is this idea of [inaudible] when you
start -- you mix -- so you destroy the current set of your system or
some partial set and then use that as initial state of the static
analysis. And basically you reduce more like breadth for search so
that you explore all the possibility. But not very deep in time, just
for like the near feature. Because basically you try to avoid the
exponential blowup of data dependent [inaudible] explosion by just
looking at the near future.
And if you don't find anything but within the -- this near future, you
say, okay, just let it run. If you find something bad, you just steer
the execution of your program to automatic execution that does not
contain this error and then you basically restart by [inaudible] the
static analysis using the current time of the systems. You just -- you
continually run the static analysis part. But just exploring
short-term future, and if you find bug in short-term future, maybe it's
not [inaudible] and you can just -- but so I know it has been applied
in this [inaudible] because, for instance, my -- I have delay between
sending and receiving messages. And if you are like really [inaudible]
20, hundred milliseconds delay following a near future exploration that
might be already enough.
>>: So you had five seconds for getting the Internet state version of
this?
>> Damien Zufferey:
>>:
No, I think it was even simpler.
It was --
It was some number of seconds.
>> Damien Zufferey:
Yeah, it was very short.
>>: One second, okay. It was five [inaudible] and one second. So I
guess if you -- so you'd be under a second, let's do this kind of
analysis is what you expect if you did a bounded version?
>> Damien Zufferey: I mean, it really -- but if you do the bounded
version mean that there are very few transition to look at.
>>: I think it'd be really neat to put this in like a VM or something
[inaudible].
>> Damien Zufferey: Yeah. [inaudible] I cannot answer without trying.
I mean, I said the bounded -- bounding the horizon is definitely a very
interesting -- because especially for [inaudible] you have some small
gap of time between when you send a message and when you have to take
some action to do replying. That's already maybe ->>: Am I understanding that you want to build this bounded horizon
thing from the current state of the [inaudible]?
>> Damien Zufferey:
Yes.
Yeah.
>>: But, I mean, in a distributed system, knowing the current state,
the state is distributed, right?
>> Damien Zufferey:
>>:
Yeah.
Capturing that is very hard.
>> Damien Zufferey: So that's -- here you restrict your set of
property that you want to really [inaudible] as local to do one
process.
>>:
I see.
>> Damien Zufferey: I think there have been some work in that
direction by [inaudible].
>>: That's what [inaudible] static [inaudible] that's why you need
based on sums I'm sure on what the --
>> Damien Zufferey:
>>:
Yeah.
-- other machines might be at.
>> Damien Zufferey: So, for instance, if you know that [inaudible]
replicated and every machine run the same code, for instance, that's an
assumption that you can use so that you have some idea even of what the
other machine are doing because you know they run the same code as you.
>>:
I see.
>> Damien Zufferey: So that assumption that can [inaudible] even
though -- so you only see your goal state, but you have some idea of
what the other might be doing by the messages that you receive. But,
yeah, then you really need to restrain the set of property -- I mean,
visually you -- if you find some error which would affect [inaudible]
system. But since it's local, might be too late to send a message to
the components that you are going to crush.
>>: [inaudible] this round base view, did you come across this work by
[inaudible] on time triggered architectures? It kind of sounds -- so
this is basically build a communication layer that forces rounds and by
upfront scheduling when you can communicate. So you can't -- you no
longer just have this kind of arbitrary asynchrony. But you commit to
hardware that says this guy has this point in time [inaudible] in a
message and that's it.
>> Damien Zufferey:
>>:
So yeah.
[inaudible] this kind of rounds.
>> Damien Zufferey: I don't know exactly at the hardware level. I've
seen the version like [inaudible] called visual synchrony [inaudible]
this notion of round.
So I can't compare to visual synchrony and say [inaudible] we wanted to
leave something weaker because they really guarantee that not only this
notion of round, which is like total ordering on messages, but also you
have like every message get delivered. So I think we can find
something [inaudible] which might be weaker. So we can still get -you can still get progress, for instance, without I think all the
messages being delivered. And especially for network which is
congested, and then you've got messages, maybe you still -- if you have
an abstraction layer that forces all the message to be delivered, that
might slow you down quite a lot. So [inaudible] want something weaker
that -- I don't know exactly I can compare with the hardware, but at
least on the software side I think we need something weaker than
already what exist in term of view of rounds.
>> Shaz Qadeer:
[inaudible].
[applause].
>> Damien Zufferey:
Thank you.