Specification, Verification, Performance Estimation, and Implementation
As described above, the focus of this dissertation is on simplifying the protocol design problem, which has four key elements: specification, verification, performance estimation, and finally, implementation. Historically, these dimensions have largely been separated. To give the reader a view of what lies ahead, the approach taken here begins with the assumption that performance estimation and protocol verification are equally important problems that must be addressed at some point before implementation. Thus, what is needed is
• A language that is formal, yet has the capability to both abstract and to refine, as needed, throughout the design process. The language must provide a means of expressing performance constraints.
• A set of tools that facilitate design exploration and evaluating performance
• Clear understanding of the relationships of key parameters in the protocol design, and the relationships to the network layer and physical layer characteristics
• A means of separating simulation models while still capturing essential interdependencies – for example, simulating both the backbone network (packet-level abstraction) and the signal-space modulation details is prohibitively expensive and provides little intuition about the way the system should be designed. Instead, one would like to abstract where possible without losing essential performance information.
Thus, what is needed is a methodology that addresses the exploration phase, the
“standardization” phase1, and the implementation phase.
1.2.1 The specification problem
As a starting point, we take the well-known fact that protocols of any significance are notoriously difficult to design. First, there is the problem of saying what the protocol does and, without constraining the implementation, detailing the services that it provides. The services, legal sequences of message exchanges, and the behavior under all exceptional conditions must be defined in such a way that there can be no semantic ambiguity. This is the specification problem.
To have any hope of applying automated methods of formal verification to the problem, the protocol must itself be described in a language that has well-defined
semantics and an underlying mathematical model of the system being represented.
Chapter 3 explores the existing formal languages used to describe protocols and compares their models of computation, concurrency, communication, and other features that either aid or hinder the integration of performance metrics.
1.2.2 The verification problem
The verification problem deals with the issue of proving correctness properties about a system. These properties usually fall into two broad classes: safety, or
“invariance”, properties and liveness, or “eventually”, properties [OL82, Pnu85, Eme90]. Intuitively, a safety property asserts that “nothing bad happens,” while liveness properties state that “something good eventually happens.” Though it will be explored in detail in later sections, it is introduced here with the observation that formal verification is perhaps the most challenging and least-understood technologies available to system designers.
The challenge for a designer lies in the fact that formally proving anything about a system requires a precise mathematical model of the system. Further, for practical systems, proving the safety and liveness properties is computationally intractable without abstracting away all but the most relevant detail needed to prove that the properties hold, and in practice is more an art than a science. The art of abstrac-tion requires a deep understanding of the protocol as well as knowledge of how the representation of a system impacts the capability to prove properties about it.
Fortunately protocol systems can be modeled as finite automata, giving us a starting point for the mathematical model. But reducing the size of the model to a point where an automated formal verification system becomes useful requires a deep understanding of operation of the system and the subtle relationships between each subsystem. This step is still the limiting factor that impedes the application of formal verification.
1.2.3 “Correctness” and performance
Two other critical points about formal verification techniques are that 1) they are capable of working with the possible states that a system might be in rather than the probability of being in a given state, and 2) time is abstracted to the point that it is only possible to distinguish between orderings of events. Thus, proving correctness is limited to proving properties that are concerned with the ordering of two events, rather than the absolute interval that separates them. Thus it is possible to say that the event bfollows the event aor occurs simultaneously with event a. This is a critical point because the third dimension of interest, performance modeling, is particularly interested in the times and probabilities. The
“correctness” of a protocol, for many applications, cannot be expressed solely in terms of safety and liveness properties. Determining that a given protocol system meets a throughput requirement can be as important as answering the question of formal correctness.
For example, formal verification can determine that it is possible for a buffer to overflow, but provides no information about how likely that event is. In practice one would like to optimize for the common case – sizing buffers to handle typical occupancies without overflow – while being able to recover from the corner cases
(buffer overflow). As another example, throughput and delay estimates are typically based on statistical models of the communications channels, the number of users, and the traffic patterns for each user. The most natural simulation domain for modeling these phenomena is using discrete event simulation systems that provide essentially unrestricted input specifications (e.g., Ptolemy, VHDL, and Bones).
Discrete event systems are in general not finite-state [ELLS97] and hence are incompatible with formal verification. Thus, although answering the questions is a crucial part of showing that a protocol is “correct,” the design is approached from two fundamentally different paradigms. Both seek to answer the question that must precede implementation efforts – namely, “does the protocol provide, in a fundamental way, the desired behavior?”
1.2.4 Relating abstract models to implementa tion
Finally, the implementation domain of the protocol also has a significant ability to impede an integrated design approach, especially when the implementation contains a mix of hardware and software. The media access control layer, in particular, is closely tied to the underlying physical layer and control logic must respond to events at the microsecond level; for power efficiency, it is most efficient to implement this control logic in hardware. Product differentiation, firmware upgrades, and the flexibility of a software-based approach, on the other hand, pull towards implementing as much as possible in software. In practice, the final implementation is a mix of hardware and software.
The problem of designing these hybrid systems and obtaining meaningful performance estimates is an area of active research known as “co-design” (see
hardware and software naturally have two very different types of concurrency – interleaved and true parallel – and so design styles, representations, and simulation semantics are extremely domain-specific. We will explore these issues further in Chapter 3.
Summarizing, we are presented with conflicting objectives in our specification languages, in our ways of checking “correctness”, and it becomes difficult to relate these various conceptual models to the domain of our implementation. For a pure specification, such as a standards body might produce, all detail must be included in the model. For performance modeling, we would like the capability to model many users, to quantify throughput, delay, and buffer occupancy, etc. – we need to have a higher-level statistical model of the system with both time and probabilistic metrics. For verification, we would like to compact, abstract, and remove as much detail as possible without changing the protocol. It is not surprising that the languages used to describe a particular model are strongly influenced by whether the model is to be used for specification, for formal verification, for performance modeling, or for the actual implementation.
Before proceeding, it is beneficial to take a brief look at the history of protocol design, protocol specification, and the various technical tools that have been used to verify correctness and estimate performance.