Page 1 |
Save page Remove page | Previous | 1 of 199 | Next |
|
small (250x250 max)
medium (500x500 max)
Large (1000x1000 max)
Extra Large
large ( > 500x500)
Full Resolution
|
This page
All
|
TOPOLOGY GENERATION FOR PROTOCOL TESTING:
METHODOLOGY AND CASE STUDIES
by
Ganesha Bhaskara
A Dissertation Presented to the
FACULTY OF THE USC GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(ELECTRICAL ENGINEERING)
May 2010
Copyright 2010 Ganesha Bhaskara
Object Description
| Title | Topology generation for protocol testing: methodology and case studies |
| Author | Bhaskara, Ganesha |
| Author email | ganesha@bhaskara.org; bhaskara@usc.edu |
| Degree | Doctor of Philosophy |
| Document type | Dissertation |
| Degree program | Electrical Engineering |
| School | Viterbi School of Engineering |
| Date defended/completed | 2009-11-19 |
| Date submitted | 2010 |
| Restricted until | Unrestricted |
| Date published | 2010-03-09 |
| Advisor (committee chair) | Gupta, Sandeep |
| Advisor (committee member) |
Silvester, John Govindan, Ramesh |
| Abstract | One of the key steps in the design or refinement of an application or network protocol is, testing of the protocol for correctness and performance. Simulation and state space exploration are the most popular ways of testing protocols. Simulation tools like NS, OPNET etc., allow the designer to test/evaluate a protocol's performance on fully specified instances of topologies. State space exploration tools like SPIN allow the designer to test the protocol state space on fully specified instances of topologies for the desired properties. Correctness or (target) behavior of protocols can be expressed using designer specified reachability properties and standard structural properties (invariants on states), whereas, performance of protocols is often expressed as aggregate over states of the protocol (average throughput, average packet loss, etc.). The scope of this study is limited to the correctness of control or house keeping functions of protocols.; Correctness and performance of many protocols and distributed applications in Internet Protocol (IP) based network depends on the network topology, i.e., on the end and intermediate nodes, their physical and logical (MAC, IP, transport etc.) inter-connectivity, as well as the relationship between the control fields of the different nodes. Theoretically, since topology controls packet delivery, it affects of state space of the system and hence must be considered as an input during testing. Though end to end topology abstractions are routinely used to evaluate and test protocols, it is not sufficient as specific topology configurations can drive the performance of the protocol to unacceptable levels or cause the protocol to misbehave. For example, certain topology configurations may cause the throughput of the protocol to decrease by orders of magnitude (microwave interference for 802.11 protocol) or the node requesting an IP address may not get an IP address (specific configurations of tunnels) or a node that is supposed to detect mobility may not detect mobility (in the presence of virtual machines). Not relying only on the high level abstraction of the end to end topology is especially important in today's world due to the large scale use of intermediate nodes that do not adhere to the end-to-end principles. When America On Line (AOL) introduced a load balancing transparent HTTP proxy for its users, a great majority of its subscribers were unable to use a the AOL chat client to communicate with others on the other side of the proxy. Detecting such topology induced errors in protocols after deployment can be a costly affair due to the large scale disruption and its associated support costs. In short topology can severely affect protocol performance and correctness and hence the topology space on which the protocol is expected to execute needs to be characterized.; To thoroughly test IP based protocols and applications, for each protocol behavior or protocol property, the testing procedure must iterate implicitly or explicitly over the set of all topology configurations (potentially large in case of IP) on which the protocol is expected to execute. Formally, for a given behavior B a testing procedure is given by; Loop 1: All valid topologies; --Loop 2: All inputs, initial states and sequences of injection; ----Loop 3: Check of behavior B occurs; Today, simulation and state space enumeration tools are used to test a protocol on a specific topology instance. In the above procedure, the loops within the outermost topology enumeration loop, those representing state space enumeration over a given topology instance has been extensively studied. Though this work has to deal with the complexity of state space enumeration indirectly, addressing the state space enumeration problem itself is not a part of this work. Any testing procedure, be it simulation or state space enumeration has to deal with the very large space of scenarios that can exist in the behavior space. Addressing the large scenario space is beyond the scope of this work.; In the above procedure, the outer most loop enumerating individual instances of topologies in the topology configuration space, will incur impractical runtime complexity due to combinatorial explosion in the number of topology instances when the number of components that make up the topology and/or their configurations are very large. Further, to ensure thorough testing, the set of topologies on which the protocol can misbehave must be used during testing. Thus, an approach that can differentiate between the set of topologies on which the behavior occurs, and, the set on which the behavior does not occur, can be very useful to reduce the complexity arising out of the necessity to consider all topology configurations to ensure thorough testing. Though several studies have attempted to study the influence of topology on protocol behavior, a methodology to systematize selection or generation of topologies that can used for effective protocol testing has received little attention. This has often resulted in errors in protocols triggered by specific topology configuration going unnoticed at design time only to show up after deployment. The focus of this work is to generate necessary topology conditions that any topology on which the target behavior occurs must satisfy. This can be used to systematize topology coverage while protocol testing, by eliminating the large class of topologies that do not satisfy the necessary conditions and focusing the simulation and state space enumeration efforts on the topology space on which the problematic behavior occurs.; To generate the necessary topology conditions, the procedure must implicitly or explicitly consider all topology configurations and for each topology, determine weather the target behavior occurs or not. A direct approach that uses reachability analysis on each topology configuration has very high complexity due to the potentially large state space for each instance of the topology configuration. There is a trade-off between the computational and space complexities and accuracy of practical search techniques. On one hand, the complexity of the problem can be reduced by restricting the properties of the systems where efficient decidability is guaranteed. On the other hand, trade-offs can be made between the quality of the solution (closeness to sufficient conditions and/or decidability) and complexity. Two of the most common techniques used in practical fault detection techniques are state space folding (abstraction) and sampling. State space folding obtained by abstracting details of the system introduces false positives for error detection, whereas, the sampling technique introduces false negatives for error detection; To generate necessary topology conditions that a topology must satisfy for the target behavior to occur, a methodology called "Compressed Representation of State Space for topology configuration generation" (COMPRESS) is developed. This is based on the novel combination of two basic ideas (a) represent complex topologies as a composition of simple end to end topology component abstractions derived from packet destination types (e.g., IP unicast, IP broadcast, etc) (b) use the information already embedded in the protocol FSMs (folded state space) to drive the composition of the end to end topology abstractions to obtain more complex, but relevant topologies. For a given behavior, COMPRESS, indirectly, i.e., without explicit topology enumeration, identifies necessary conditions satisfied by the set of all topologies on which that behavior may occur, without solving the reachability problem. To our knowledge, this is the first work that addresses the problem of generation of necessary topology conditions for a target behavior to occur.; The usefulness of the COMPRESS methodology is evaluated using case studies of several different class of protocols including client server protocol, resource discovery protocol, emergency location information server protocol and multicast based micro-mobility protocol. For each protocol, behaviors that include errors that either appear as 100% performance degradation or unexpected behavior to the end user are studied. The necessary topology conditions generated by COMPRESS were highly non-intuitive and revealed unexpected or severe errors triggered often by small topology configurations. It is also shown how necessary topology conditions generated by COMPRESS can, not only be used to effectively and efficiently characterize the problematic topology space causing that behavior by eliminating a very large set of uninteresting topologies (up to 99.4%), but also be a powerful tool to characterize the severity of the problematic behavior itself. Through these case studies, it is shown that the topology conditions generated are highly non-intuitive, close to sufficient conditions and practically useful, but also the practical runtime complexity is quite manageable.; The contributions of this work are multifaceted. The first contribution is articulating and characterizing the role of topology in systematic protocol testing. This also includes understanding the fundamental properties of the components that make up the solution space of the topology generation problem and properties of possible solution approaches. The second contribution is the COMPRESS methodology, especially the topology augmented TCG data structure, extensions to handle topology dynamics and theoretical framework characterizing the properties (including limitations) of the results generated by COMPRESS. The third contribution is the set case studies that not only illustrate the applicability and usefulness of the COMPRESS methodology, but also reveal unexpected behavior in existing and proposed protocols in the presence of specific topology configurations. |
| Keyword | network protocol; protocol; systematic testing; testing; topology generation: computer network protocol; protocol testing |
| Language | English |
| Part of collection | University of Southern California dissertations and theses |
| Publisher (of the original version) | University of Southern California |
| Place of publication (of the original version) | Los Angeles, California |
| Publisher (of the digital version) | University of Southern California. Libraries |
| Provenance | Electronically uploaded by the author |
| Type | texts |
| Legacy record ID | usctheses-m2868 |
| Contributing entity | University of Southern California |
| Rights | Bhaskara, Ganesha |
| Repository name | Libraries, University of Southern California |
| Repository address | Los Angeles, California |
| Repository email | http://www.usc.edu/isd/libraries/services/ask_a_librarian/email/ |
| Filename | etd-Bhaskara-3399 |
| Archival file | uscthesesreloadpub_Volume32/etd-Bhaskara-3399.pdf |
Description
| Title | Page 1 |
| Contributing entity | University of Southern California |
| Full text | TOPOLOGY GENERATION FOR PROTOCOL TESTING: METHODOLOGY AND CASE STUDIES by Ganesha Bhaskara A Dissertation Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (ELECTRICAL ENGINEERING) May 2010 Copyright 2010 Ganesha Bhaskara |
