US 7613105 B2
A network troubleshooting framework is described. In an implementation, a method includes forming a plurality of reports by a plurality of nodes in a network, wherein each of the reports is formed by a respective one of the nodes and includes trace data obtained from the respective node and another of the nodes. An inconsistency is detected in the trace data in one of the reports when compared with corresponding trace data in another of the reports. A set of the nodes is found that formed one or more of the reports having the inconsistency in the trace data.
1. A method comprising:
forming a plurality of reports by a plurality of nodes, each node comprising a processor, a memory, and a network connection device interconnecting the nodes in a network, wherein each report:
is formed by a respective node; and
includes trace data obtained from the respective node and at least one other node;
detecting by the processor an inconsistency in the trace data in a first report when compared with corresponding said trace data in a second report, wherein the detecting comprises:
constructing an inconsistency graph having vertices that reference one or more nodes;
adding an edge between at least two of the vertices if the referenced one or more nodes report inconsistent trace data; and
deriving a set of nodes that explain the inconsistent trace data that is reported as a set of vertices in the inconsistency graph having a fewest number of vertices that cover the inconsistency graph; and
finding a set of nodes that formed at least the first and second reports having the inconsistency in the trace data.
2. A method as described in
3. A method as described in
4. A method as described in
5. A method as described in
6. A method as described in
7. A method as described in
physical medium; and
8. A method as described in
9. A method as described in
10. A computer readable storage medium storing computer executable instructions that, when executed on a computer, configure the computer to perform the method as described in
11. A method comprising:
noting an inconsistency in at least one network setting included in one or more of a plurality of reports, the network setting including one or more computers, wherein:
each report is provided by a respective one of a plurality of nodes, each node comprising a processor, a memory, and a network connection device interconnecting the nodes in a network; and
each one of the plurality of nodes performs neighbor monitoring;
constructing an inconsistency graph for the noted inconsistency that references one or more nodes;
finding a set of nodes referenced in the inconsistency graph that explain the inconsistency, wherein the finding comprises the processor deriving the set of nodes that explain the inconsistency as a smallest set of vertices that cover the inconsistency graph, wherein each vertex corresponds to a respective node; and
supplying corresponding network settings from the reports after removing the reports from the nodes that are identified as supplying inconsistent information to a simulator to form a network simulation of the network.
12. A method as described in
13. A method as described in
14. A method as described in
15. A method as described in
network topology including routing;
physical medium; and
16. A method as described in
17. A computer readable storage medium storing computer executable instructions that, when executed on a computer, configure the computer to perform the method as described in
18. A system comprising a plurality of nodes, each node comprising a processor, a memory, and a network connection device, that are communicatively coupled, one to another, to form a network, wherein:
one or more of the plurality of nodes includes a data collection module, wherein the data collection module performs acts comprising:
collecting trace data from at least two of the plurality of nodes; and
forming a report that includes the collected trace data for communication over the network; and
at least one node includes a manager module that:
receives each report;
detects an inconsistency in the trace data in one report when compared with corresponding trace data in another report, wherein detecting the inconsistency comprises:
constructing an inconsistency graph that references one or more nodes; and
deriving a set of nodes that explain the inconsistency as a smallest set of vertices that cover the inconsistency graph, wherein each vertex corresponds to a respective node;
finds a set of nodes that formed each report having the inconsistent trace data; and
supplies the collected trace data after removing the data from the nodes that are identified as supplying inconsistent trace data to form a network simulation of the network.
19. A system as described in
20. A system as described in
21. A system as described in
22. A system as described in
23. A system as described in
24. A system as described in
25. A system as described in
network topology including routing;
physical medium; and
26. A system as described in
27. A node comprising:
a network connection device configured to communicatively couple the processor with a network; and
a memory configured to maintain a manager module that is executable on the processor, wherein the manager module performs acts comprising:
collecting a plurality of reports at the network connection device from the network, wherein each report:
is formed by a respective one of a plurality of nodes, each one of the plurality of nodes comprising a processor, a memory, and a network connection device interconnecting the nodes in the network; and
describes one or more network settings of the respective node and at least one other node;
removing an inconsistency in at least one network setting of one report when compared with a corresponding network setting in at least one other report, wherein the removing resolves the inconsistency in the at least one network setting, wherein the manager module is executable on the processor to remove the inconsistency by deriving a set of nodes that explain the inconsistency as a smallest set of vertices that cover an inconsistency graph, wherein each vertex corresponds to a respective node; and
supplying resolved network settings to a network simulation thereby providing a network simulation of the network.
28. A node as described in
29. A node as described in
30. A node as described in
31. A node as described in
network topology including routing;
physical medium; and
32. A node as described in
The present invention claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application Ser. No. 60/540,738, filed Jan. 30, 2004, which is titled “Fault Detection, Isolation, and Diagnosis in Multi-Hop Wireless Networks”.
The present invention generally relates to wired and wireless networks, and more particularly relates to a framework for removing data inconsistencies for a network simulation.
Network management, although a key ingredient in a successful deployment of a multi-hop wireless network, has received limited attention by both industry and research communities. Troubleshooting a network is an aspect of network management that is responsible for maintaining the “health” of the network and for ensuring its smooth and continued operation. Troubleshooting a network, whether wired or wireless, is complicated by interactions encountered among different network entities, among different faults, and so on.
Troubleshooting a multi-hop wireless network is further complicated by a variety of additional factors. For instance, typical multi-hop wireless networks are generally prone to link errors caused by signal propagation fluctuations. The signal propagation fluctuations may be caused by a variety of factors, such as fluctuating environmental conditions. These fluctuations result in a network topology that is dynamic and unpredictable. Node mobility further aggravates these factors, as nodes may be positioned in a variety of locations while connected to the network, thereby increasing the dynamic and unpredictable nature of the network. Additionally, the capacity of multi-hop wireless networks is generally limited due to scarcity of resources (e.g., bandwidth, battery power, and so on), which constrains the amount of management traffic overhead that the network can tolerate. Further, a wireless network may be vulnerable to link attacks from malicious parties. The attackers, for example, can inject false information to disrupt or interfere with the network management effort.
Traditional heuristic and theoretical techniques that were traditionally utilized to perform network troubleshooting typically do not capture the behavior of the network as implemented in a “real” environment. For example, network behavior may be governed by node interaction, one to another, as well as by external noise sources positioned in the vicinity of the nodes. Traditional heuristic or theoretical techniques do not adequately address interaction between the different components of the network with its surrounding environment and therefore do not capture the behavior of such a network.
Accordingly, there is a need for a framework for network troubleshooting that provides improved fault detection and diagnosis.
A network troubleshooting framework is described. The framework may employ a simulation of a real network to detect and diagnose faults in the operation of the real network. For example, a network simulation may be driven by data that describes the operation of the real network. In practice, raw data that is collected for use in driving the network simulation may contain errors for a variety of reasons, such as due to hardware, software, and/or network errors. To ensure that the data used to drive the network simulation is consistent, the raw data may be cleaned. For example, each node in a network may provide data for use in driving the network simulation. The data provided by a particular node may describe not only that particular node's operation, but also the operation of one or more neighboring nodes. Therefore, the data obtained from the nodes in the network may be redundant. The redundant data is then compared, one to another, to identify any inconsistencies, which may then be rectified in a variety of ways, such as through data averaging, removal of inconsistent data, and so on.
The network simulation may then estimate network performance based on this data. The estimated network performance is compared with observed network performance of the real network performance to detect if the real network is performing as expected. If not, a fault is detected in the operation of the real network. In other words, a difference between the estimated network performance as indicated by the network simulation and the observed network performance as indicated by the real network may be utilized to detect the occurrence of faults in the real network. The network simulation may then be utilized for fault diagnosis by selectively injecting one or more faults into the network simulation until network performance of the network simulation approximates the network performance of the real network.
Once the set of one or more faults that resulted in the approximated network performance are identified, one or more modifications may be identified and implemented to correct the faults. For example, the network simulation may then be utilized to perform what-if analysis such that modifications may be made to the simulated network to test whether the modification corrects the fault and/or otherwise improves network performance. Thus, the network simulation may provide quantitative feedback on the network performance impact of a variety of modifications that may be made to the network, such as modifications made to correct the faults and/or improve network performance.
The same numbers are used throughout the disclosure and figures to reference like components and features.
A network troubleshooting framework is described for use in wired and/or wireless networks to maintain efficient and reliable network operations. The framework described herein may employ an online trace-driven network simulation to detect faults and perform root cause analysis of the faults. The network simulation is “online” in that it may obtain network performance data from a “real” network.
The framework may be applied to diagnose a wide variety of performance problems (i.e., faults), such as faults caused by packet dropping, link congestion, medium access control (MAC) misbehavior, external noise, and so on. The framework may also be used to evaluate alternative network configurations to improve network performance. Although the following discussion describes the framework in an exemplary wireless network, the framework may also be employed in wired networks.
As previously described, network management has received limited attention by both industry and research communities. Implementation of network management may involve continual monitoring of the functioning of the network, collection of information about the nodes and links in the network, removal of inconsistencies and noise from the reported data, analysis of the data, and performance of appropriate actions to improve network reliability and performance.
Troubleshooting a network is an aspect of network management that is responsible for maintaining the “health” of the network and for ensuring its smooth and continued operation. Troubleshooting a network, whether wired or wireless, may be complicated by a variety of interactions, such as interactions encountered between different network entities, interactions between faults, and so on. Troubleshooting a multi-hop wireless network is further complicated by a variety of additional factors. For instance, typical multi-hop wireless networks are generally prone to link errors caused by signal propagation fluctuations, which result in a network topology that is dynamic and unpredictable. Additionally, the capacity of multi-hop wireless networks is generally limited due to scarcity of resources (e.g., bandwidth, battery power, and so on), which also constrains the amount of management traffic overhead that the network can tolerate.
A framework is described which addresses these complications. The framework may utilize an online trace-driven simulation to detect faults and perform root cause analysis. The simulation may be utilized to reproduce events that took place in the network which resulted in a fault, and therefore identify and rectify these faults.
The framework may utilize one or more of a variety of existing network simulators to simulate the network 100, such as QUALNET (QUALNET is a trademark of Scalable Network Technologies, Inc. of Los Angeles, Calif.), OPNET MODELER (OPNET MODELER is a trademark of OPNET Technologies, Inc. of Washington D.C.), and so on. The traces that are provided to the simulators are obtained from the network being diagnosed, i.e., a “real” network. Use of traces from the real network removes the dependency of the framework on generic theoretical models that may not capture the nuances of the hardware, software, and environment of the particular network in question, thereby improving the accuracy of the framework.
The framework may also employ a fault diagnosis scheme to perform root cause analysis. For instance, the scheme may utilize estimated network performance data emitted by the online trace-driven simulator as the baseline for expected performance of the real network. Deviation from the expected performance is then utilized to indicate a potential fault. Further, the scheme may selectively inject a set of candidate faults into a simulator to perform root-cause analysis by reducing fault diagnosis to a problem of searching a set of faults. A root cause may therefore be identified based on the faults that, when injected, cause the simulation to approximate the observed performance of the real network. Therefore, the framework may employ a search algorithm to detect and diagnose faults such as packet dropping, link congestion, external noise sources, MAC misbehavior, and so on. These faults may have relatively long lasting impact on performance, and are more difficult to detect than fail-stop errors, such as when a node turns itself off due to power or battery outage.
In this way, the framework may utilize a simulation as an analytical tool for troubleshooting and testing of alternative and potentially performance-enhancing configurations in a network. In the following sections, network traces are identified which, when provided to a simulator, provide a network simulation that gives an accurate depiction of actual network behavior. A technique is also described that reduces or eliminates erroneous data from the trace, further discussion of which may be found in relation to
The troubleshooting framework may be employed in a wide variety of network configurations. One such example is illustrated by the network 100 of
A mesh network, for instance, may be utilized as an enabling technology for neighbors to collaboratively form a self-managed community wireless mesh network. Each neighbor may provide one or more of the plurality of nodes 102(1)-102(N) of the network 100. With such a network, neighbors can, for example, share an Internet gateway 104 in a cost-effective way.
In an example of a mesh network as utilized in a neighborhood, routers which are utilized to communicatively couple the plurality of nodes 102(1)-102(N) reside inside a home and are plugged in electrical outlets. Therefore, each of the routers in this example has limited mobility. The relative stability of such a network, however, makes network troubleshooting even more important because faults might have lasting influence on network performance. It should be noted that the lack of router mobility in this example does not take away the dynamism in the network topology because wireless links can be accessible or inaccessible due to environmental changes. In another example, nodes of the mesh network may be mobile, such as through use of mobile computing devices having wireless communication capabilities, such as personal digital assistants (PDA), tablet personal computers (PCs), laptop computers, and so on.
Additionally, growth of a community mesh network is organic as users buy and install equipment to join the mesh network. Traditional mesh networks had a lack of a centralized entity responsible for network administration. However, the self-manageability and self-healing capabilities provided through the framework described herein may be provided such that each node 102(1)-102(N) implements troubleshooting capabilities. In the illustrated implementation, a single node is provided having management capabilities.
In the network 100 illustrated in
Memory (e.g., memory 108(n), 108(N)) includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM), random access memory (RAM), and so on. Memory may also include other removable/non-removable, volatile/nonvolatile computer storage media. Memory provides storage of computer-readable instructions, data structures, software components, and other data for nodes.
The network connection devices (e.g., network connection devices 110(n), 110(N)) may assume a variety of configurations for communicatively coupling the nodes to the network 100. When used in a local area network (LAN) environment, for instance, the node 102(n) is communicatively connected to the LAN through a network interface or adapter, which may be wired and/or wireless. When used in a wide area network (WAN) environment, the network connection device may be configured as a modem or other means for establishing communications, such as a wired connection over a digital subscriber line (DSL), a wireless connection provided with a satellite, and so on. Logical connections are depicted in
Nodes 102(n), 102(N) illustrate an exemplary management architecture composed of software modules. Generally, any of the functions described herein can be implemented using software, firmware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represents software, firmware, or a combination of software and firmware. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor, such as one or more central processing units (CPUs). The program code can be stored in one or more computer readable memory devices. The features of the framework described below are platform-independent, meaning that the troubleshooting techniques may be implemented on a variety of commercial computing platforms having a variety of processors.
An agent module 112(n) is provided for execution on each node 102(n) of the network 100. The agent module 112(n) is illustrated as being executed on the processor 106(n) and is storable in memory 108(n). The agent module 112(n) includes a data collection module 114(n) (hereinafter “collection module”) that, when executed, may gather data from various protocol layers and/or from the network connection device 110(n). In the illustrated network 100 of
The agent modules 112(n), 112(N), when executed on the respective processors 106(n), 106(N), collect and communicate data describing their (local) view of the network's behavior to the manager node 102(N). Examples of the data sent may include traffic statistics, received packet signal strength on various links, retransmission counts on each link, and so on.
The manager node 102(N) includes a manager module 116(N) that is storable in the memory 108(N) and executable on the processor 106(N) to process the data from the agents 112(n), 112(N) for troubleshooting the network 100. The manager module 116(N), for instance, includes a network simulator 118(N) (hereinafter, “simulator”) that is executable on the processor 106(N) and storable in the memory 108(N) to simulate the network 100.
Data received by the manager node 102(N) from the various agents 112(n), 112(N) may result in an inconsistent view of the network 100. Such inconsistencies can be the result of topological and environmental changes, measurement errors, misbehaving nodes, and so on. Therefore, the manager node 102(N) includes a data cleaning module 120(N) (hereinafter “cleaning module”) that is executable on the processor 106(N) to resolve such inconsistencies. Cleansed data output from cleaning module 120(N) is then provided for processing by a root cause analysis module 122(N) (hereinafter “analysis module”), further discussion of which may be found in relation to the following figure. Although the manager node 102(N) is illustrated as including the agent module 112(N) and the manager module 116(N), in another implementation the manager node 102(N) is a dedicated manager node in that it does not include the agent module 112(N). Also, as previously described, the functionality of the manager module 116(N) may be provided by more than one node in the network 100.
The analysis module 122(N) utilizes an online trace-driven simulation to determine root causes of discrepancies from expected network performance as indicated by the simulated network perform. In the following discussion, expected network performance and simulated network performance are utilized interchangeably to indicate network performance as provided by a network simulation. The analysis module 122(N) may utilize cleansed data 202 obtained from a trace utility, examples of such data are illustrated in
The analysis module 122(N) is illustrated as including a network simulation 210 that is provided through execution of the simulator 118(N). The network simulation 210 may be provided by execution of one or more software modules that provide simulations of characteristics of a network, examples of which are illustrated in
The analysis module 122(N) detects faults in the network 100 of
The analysis module 122(N), for example, may receive observed data 220 from one or more of the agent modules 112(n) of
After the root cause of the error has been identified through selection of one or more of the faults from the faults directory 218, the analysis module 122(N) may simulate one or more alternative actions for rectifying the fault. The alternative actions may be simulated under the current traffic pattern and network topology as provided by the traffic simulator 214 and topology change module 216, respectively. Based on the simulations, the analysis module 122(N) may suggest one or more appropriate actions to alleviate the faults and enhance overall performance of the network, an example of which is illustrated as link node fault 230 of
Use of the network simulation 210 for online diagnosis offers a variety of benefits over traditional heuristic or theoretical diagnostic techniques. For instance, the network simulation 210 can provide increased insight into the behavior of the network over traditional heuristic or theoretical techniques. An operational wireless network, for example, is a complex system having intricate pieces, such as traffic flows, networking protocols, signal processing algorithms, hardware, radio frequency (RF) propagation and so on. Additionally, interactions may occur between all of the pieces of the network. Interactions between faults may be effectively diagnosed and addressed through selection of one or more faults from the faults directory 218 that result in a network simulation 210 that corresponds to the actual behavior of the “real” network.
Further, network behavior may be governed by node interactions, one to another, as well as by external noise sources positioned in the vicinity of the nodes. Traditional heuristic or theoretical techniques do not capture the behavior of such networks and do not adequately address interactions between the different components of the network.
As an example, consider a seven-by-three grid topology network 300 shown in
Additionally, in this example, adjacent nodes can “hear” one another and the interference range is twice the communication range. Traffic between node A 312 and node O 314, for instance, interferes with the traffic between nodes C and Q 316, 318. Similarly, traffic between nodes G and U 320, 322 interferes with the traffic between nodes E and S 324, 326. However, traffic between G and U 320, 322 and traffic between nodes A and O 312, 314 do not interfere with traffic between nodes D and R 328, 330.
The following table describes an example of throughput of the flows 302-310 when each flow sends constant bit rate (CBR) traffic at a rate of eleven Mbps.
Traditionally, application of heuristic techniques may have lead to a conclusion that flow F3 306 receives an unduly larger share of the bandwidth. Through use of an online trace-driven simulation, however, the manager node 102(N) may conclude that this is normal behavior. For example, the network simulation may take link quality into account and therefore determine that flows F1 302 and F5 310 interfere with flows F2 304 and F4 308. Therefore, flow F3 306 is provided with additional bandwidth because of the lack of interference from flows F1 302 and F5 310, as opposed to flows F2 304 and F4 308. In this way, the simulation can determine that even though all the flows may have the same application-level sending rate, the observed throughput is expected. A simple heuristic, however, may come to an erroneous conclusion that nodes D and R 328, 330 are misbehaving.
The network simulation is utilized by the analysis module 122(N) to manage the network by knowing “what to expect” from the network given the current traffic flows and link qualities. In other words, the analysis module 122(N) can comment on what constitutes normal behavior based on estimations provided by the network simulation. In the previous example, even though F3 306 utilizes a greater share of the bandwidth of the network 300 than other flows in the network 300, this will not be flagged as a fault by the manager module because this behavior is expected. When the observed behavior deviates from the expected behavior, the manager module can invoke the fault search algorithms that utilize the faults directory 218 of
In addition, while it might be possible to apply traditional signature-based or rule-based fault diagnosis approach to a particular type of network and under a specific environment and configuration, simple signatures or rules are insufficient to capture the intrinsic complexity for fault diagnosis in general settings. In contrast, a simulator is highly customizable and may be applied, with appropriate parameter settings, to a large class of networks that are configured for use in different environments. Fault diagnosis built on top of such a simulator inherits this generality.
Yet another advantage of simulation-based approach is the ability to perform what-if analysis. That is, by modifying the settings or performing certain actions in the simulator, a simulator can predict performance for an imaginary scenario. Based on this data, a manager module can instruct the agent modules (e.g., agent module 112(n) of
Fault Detection and Diagnosis
A simulation-based diagnostic approach is described which provides for creation of an environment inside a simulator (e.g., network simulation 210) that approximates the functionality of a real network. The created environment (i.e., the network simulation) may then be utilized to determine expected behaviors of the real network as well as determine when discrepancies in the operation of the real network occur. To find a root cause of these discrepancies, the manager module is executed to search over a fault space to determine which fault or set of faults can reproduce network performance which approximates the network performance that is observed in the real network. The simulated network may reproduce a variety of network aspects, such as network topology, routing behavior, traffic patterns observed in the real network, and so on.
Using online trace-driven simulation as a building block, a diagnostic algorithm is described which is executable to find root-causes for faults. The diagnostic algorithm, for instance, may first estimate performance of the network under a given set of faults. Then, based on differences between the estimated and observed performance, the diagnostic algorithm searches a fault space to reproduce any observed discrepancies. In an implementation, the diagnostic algorithm can diagnose multiple faults of the same type (e.g., network topology), as well as diagnose the presence of multiple types of faults (e.g., noise and topology).
Faults may be diagnosed even when the trace data used to drive the simulation contains errors. For example, data provided by the agent module 112(n) of
Network Topology 402
Network topology 402 data describes the topology of the network, such as which nodes are currently members of the network and corresponding links between the nodes. Each node in the network, for instance, may be configured to report on the status (e.g., connected or disconnected) of neighboring nodes and nodes referenced in one or more routing tables of the node. In this way, node membership in the network may be communicated to the manager node 102(N) of
Traffic Statistics 404
Traffic statistics 404 data may be utilized to describe amounts of data that is communicated through the network and particular nodes that communicate that data. The traffic statistics 404 may be utilized as an input by the traffic simulator module 214 of
Physical Medium 406
Physical medium 406 data may describe effects on network performance of the physical medium that is utilized to implement the network. For example, in a wireless network each node may report its noise level and the signal strength of the wireless links from its neighboring nodes. In an implementation, variations in signal strength are periodically captured through time averaging, standard deviation, or other statistical aggregate.
Network Operation 408
Network operation 408 data describes network operation 408 of the real network. As previously described, observed network operation is compared with the estimated network operation output from the network simulation to detect network operation discrepancies. Network operation may include both link operation and end-to-end operation, both of which can be measured through a variety of metrics, such as packet loss rate, delay, and throughput. The following description focuses on link level operation.
Data collection may involve two steps: (1) collecting raw performance data at a local node and (2) distributing the collected data to collection points for analysis. A variety of tools may be utilized for local data collection, such as native routing protocols and packet sniffers.
In an implementation, even though distribution of data to the manager module introduces network overhead, the network overhead is low and has little impact on the data traffic in the network. Additionally, network overhead may be reduced by using compression, delta encoding, multicast, adaptive changes of a time scale and/or spatial scope of distribution, and so on. For example, a minimum set of data is collected and exchanged during normal operation of a network. Once a need arises for additional data (e.g., when the information being collected indicates a discrepancy), the manager module may request additional information and increase the frequency of data collection for the subset of the nodes that need increased monitoring.
Network characteristics that are modeled by the simulator may be classified in a variety of categories, such as traffic load, routing, wireless signal, faults, and so on. The following sections describe simulation examples of each of these exemplary categories as individual modules that are utilized to cause the simulator to simulate the corresponding network characteristics.
Traffic Load Simulator 410
A network simulation generated by a simulator may be configured such that it provides a traffic pattern that approximates the traffic pattern of the real network. An example of a traffic load simulation approach involves the simulation of end-to-end application demands. However, an N-node network can include potentially N2 demands. Moreover, end-to-end application demands may be difficult to obtain given the heterogeneity of application demands and the use of different transport protocols, such as a transmission control protocol (TCP), a user datagram protocol (UDP), a rapid transport protocol (RTP), and so on.
In an implementation, a traffic load simulator 410 module is a portion of the traffic simulator module 214 of
Matching the sending rate on a per-link basis in a simulator may be nontrivial when the sending rate on a link cannot be directly controlled, such as when only the application-level sending rate may be adjusted and the medium access control (MAC) protocol must be addressed. For example, when an application sending rate of a link is set at one Mbps, the actual sending rate (on the air) can be lower due to back-off at the MAC layer, or higher due to MAC level retransmission. The issue is further complicated by interference, which introduces interdependency between sending rates on different links.
An iterative search technique may be utilized to address these issues by determining the sending rate at each link. A variety of iterative search techniques may be utilized, such as (i) multiplicative increase and multiplicative decrease, and (ii) additive increase and additive decrease. As shown in the following procedure depicted using exemplary pseudo-code, each link individually tries to reduce the difference between the current sending rate in the simulator and the actual sending rate in the real network.
Route Simulator 412
Routing plays an important role in network performance, particularly in multi-hop wireless networks. One route simulation approach involves the simulation of a routing protocol used in the real network inside the simulator. In order to reproduce the same routing behavior as in a real network, detailed traces of packets are obtained to set up the routing.
The actual routes taken by packets may be utilized as an input to the route simulator 412 module. When routes do not frequently fluctuate, routing changes may be tracked instead of collecting routes on a packet-by-packet basis at the manager. For this purpose, the route simulator 412 module may be trace-driven. For example, the route simulation module may be implemented inside the simulator 118(N), such as a QUALNET simulator (QUALNET is a trademark of Scalable Network Technologies, Inc. of Los Angeles, Calif.). The route simulation 412 module accepts routing updates and corresponding timestamps as inputs, and then ensures that the packets in the network simulation follow the same route as in the real network.
Signal Strength Simulator 414
Signal strength has an impact on both wired and wireless network performance. Due to variations across different network connection devices (e.g., wireless cards) and environments, a general propagation model may be difficult to derive which captures all of these factors. To address this issue, the signal strength simulator 414 may be driven from real measurement of signal strength in the real network, such as obtained from the network connection devices themselves.
Fault Injection 416
The framework may include a fault injection 416 module that is executable to inject different types of faults into the simulator, such as packet dropping at hosts, external noise sources, MAC misbehavior, and so on. In this way, the analysis module may examine the impact of faults on the network. Packet dropping at hosts, for instance, occurs when a misbehaving node drops a portion of the traffic from one or more neighboring nodes, such as due to hardware/software errors, buffer overflow, malicious drops, and so forth. The ability to detect such end-host packet dropping is useful, since it allows the manager to differentiate losses caused by end hosts from losses caused by the network.
The framework, through execution of the fault injection 416 module, also supports the ability to inject external noise sources in the network. Thus, the framework may provide a simulation that replicates the effect of noise sources that lie outside the network (i.e., are not provided by a node) but nevertheless affect the network.
MAC misbehavior occurs when a faulty node does not follow the MAC etiquette and obtains an unfair share of the channel bandwidth. For example, in IEEE 802.11, a faulty node can choose a smaller contention window (CW) to aggressively send traffic.
Link congestion may also be simulated by the framework by supplying a high data transmit load on the simulated network. Unlike the other types of faults, link congestion is implicitly captured by the traffic statistics gathered from each node. Therefore, the trace-driven simulation can directly assess the impact of link congestion on the real network. Further discussion of fault diagnosis may be found in the following section.
Root causes for failures and performance problems may be diagnosed through execution of the analysis module 122(N) of
The search space for a fault may contain a multitude of searching dimensions due to the different combinations of faults which may be encountered. In an implementation, the analysis module 122(N) is optimized for efficient searching due to a realization that different types of faults often change a few particular network performance metrics. For example, packet dropping at hosts generally affects link loss rate, but does not affect other network performance metrics. Therefore, network performance metrics may be used to diagnosis network performance by noting differences between observed and estimated network performance indicated by the metrics.
In an implementation, it is not necessary to provide a predictive model for the purpose of fault diagnosis. Rather, it is sufficient to simulate what happened in the network after the fact. For instance, agent modules may periodically report information about link conditions and traffic patterns to the manager module. This information is processed and then fed into the simulator to create a network simulation that may then be utilized to determine a likely root cause of the fault.
As previously described, a trace-driven simulation, when fed with current network settings of a real network, may be utilized to establish estimated network performance of the network. Based on the difference between the estimated network performance and observed network performance, the type of faults may be determined using a decision tree, an example of which is depicted in
Due to a variety of factors, estimated network performance is unlikely to be identical with the observed network performance, even in the absence of faults. Therefore, discrepancies in network performance may be determined using a threshold. For example, a discrepancy may be determined based on whether a difference between estimated and observed (i.e., real) network performance values exceeds a corresponding threshold. The threshold may be computed in a variety of ways, such as by observing the historical difference between simulated and actual network performance.
A fault classification scheme, an example of which is depicted in
Reference will now be made again to
At block 504, the fault set (FS) and network settings (NS) are provided to a network simulation as an input. A variety of network settings may be supplied, such as signal strength, traffic statistics, routing tables, and so on.
At block 506, the expected performance (SimPerf) is predicted by executing the network simulation with the provided inputs. At decision block 506, a determination is made as to whether the difference (Diff) between the expected performance (SimPerf) and the real performance (RealPerf) is greater than a threshold. If the difference is greater than the threshold (block 506), the fault type (FT) is determined (block 510). Further discussion of determination of a fault type may be found in relation to
After the fault type is determined, the faults are located (block 512) by finding a set of nodes and links that have differences between the observed and expected network performance that exceeds a threshold for that particular fault type (block 514). The fault type determines what network performance metric is used to quantify the performance difference. For instance, packet dropping may be identified by finding links having a significant difference between expected and observed loss rates.
At block 516, the magnitude of the fault is determined. A function (denoted as “g( )”), for instance, may be utilized to map the impact of a fault into a corresponding magnitude. For example, in an end-host packet dropping scenario, the g( ) function is an identity function, since the difference in a link's loss rate can be directly mapped to a change in a packet dropping rate on a link (fault's magnitude). In an external noise fault scenario, the g( ) function is a propagation function of a noise signal. Blocks 510-516 may be repeated for each link or node. The fault with a corresponding magnitude may then be added to the fault set at 516.
The following depicts exemplary pseudo-code which may be executed to implement a procedure similar to the procedure 500 of
If the threshold of block 602 is not exceeded, then at decision block 606, a determination is made as to whether there is a discrepancy (i.e., a threshold noise differential ThreshNoiseDiff has been exceed) between the real noise (RealNoise) indicated on the real network and the expected noise (SimNoise) of the simulated network. If so, a noise fault is determined (block 608).
If the noise threshold has not been exceeded (block 606), then at decision block 610, a determination is made as to whether simulated packet loss (SimLoss), i.e. the expected packet loss, differs from the real pack loss (RealLoss) by more than a threshold loss difference (ThreshLossDiff). If so, a packet dropping fault has been encountered (block 612). Otherwise, the node is operating normally (block 614). It should be apparent that a wide variety of other fault types may also be determined in a similar manner.
During the initial diagnostic stage, a one-pass diagnosis algorithm is applied to derive an initial set of faults. During the second stage, the fault set is iteratively refined by (i) adjusting the magnitude of the faults that have been already inserted into the fault set, and (ii) adding a new fault to the set if necessary. The procedure 700 may be reiterated until the change in fault set is negligible, such as when the fault types and locations do not change, the magnitudes of the faults change by minimal amounts, and so on.
An iterative approach may also be used to search for the magnitudes of the faults. At a high level, this approach is similar to the link-based simulation, described in relation to
At block 702, for example, the expected network performance is estimated under the existing fault set for each iteration. For example, the expected network performance may be estimated through simulation of the network using network settings obtained from the real network. The network settings are provided through execution of agent modules on each node. The network settings provided by each node may describe local network performance of the node as well as network performance of neighboring nodes.
At block 704, the difference between estimated network performance (under the existing fault set) and real performance is computed. The difference, for instance, may be computed by a manager node through execution of a manager module. The manager module, when executed, compares the estimated (i.e., expected) network performance obtained from a simulated network with real (i.e., observed) network performance as indicated by additional network settings obtained from the plurality of agents.
The procedure 700 of
At block 712, the difference is translated into a change in the fault's magnitudes and the fault magnitudes are adjusted according to the computed change (block 714). For example, the function g( ) as previously described in relation to
At decision block 718, a determination is made as to whether the expected performance of the network using the current fault set is converging with real network performance. For example, the analysis module may store heuristic data which describes one or more previous iterations of fault sets and resultant performance values in the network simulation. The difference between the target values (i.e., real network performance values) and current values (i.e., simulated network performance values) is used as feedback by the analysis module to progressively “move” the network simulation to approximate the real network.
If the expected performance is not converging with real network performance (block 718), a new fault candidate is added to the fault set. In addition to searching for the correct magnitudes of the faults, for example, membership in the fault set may be iteratively refined by selecting new fault candidates that can best explain the difference between expected and real network performance (block 720). These new faults are added to the fault set (block 722). The fault set including the new fault candidate is then utilized as an input to a network simulation to estimate expected network performance under existing fault set (block 702). In an implementation, a fault is added during each iteration of the procedure 700 which can explain the largest discrepancy, thereby controlling false positives. The procedure 700 may then be repeated until the expected performance of the simulated network approximates the real performance of the real network. In this way, the simulated network may be moved through inclusion of faults such that it provides an accurate depiction of faults which cause the observed network performance in the real network.
The following illustrates exemplary pseudo code which may be executed to provide the procedure 700 of
In the previous sections, fault diagnosis was described in which trace data was utilized to drive an online simulation. In practice, raw trace data that is collected by agent modules, when executed on respective nodes, may contain errors for various reasons as mentioned earlier, such as due to hardware, software, and/or network errors. Therefore, the cleaning module 120(N) of
Due to neighbor monitoring, multiple reports from different sources (i.e., nodes) are likely to be submitted for each link. Node 102(3), for example, may obtain a report 802(2) from node 102(2) that describes network performance of node 102(2), as well as the network performance of nodes 102(1), 102(n). Parentheticals utilized in the reference numbers of the reports in
Node 102(3) includes network performance data from the report 802(2) (which is illustrated in phantom in
The redundant reports can be used by the manager node 102(N) to detect one or more inconsistencies in network performance. For example, reports 802(2), 802(3) may be compared to each other through execution of the cleaning module 120(N) by the manager node 102(N) to find inconsistencies in the network performance data described therein. The inconsistencies may be found in a variety of ways, an example of which is described in the following figure.
In the procedure 900 described in relation to
At decision block 902, a determination is made as to whether a number of packets received on a link, as reported by its destination, is significantly greater (as described by a threshold) than the number of packets sent on the same link, as reported by its source. That is, for the link 1 from node i to node j, and given a threshold t, the following determination is made:
At decision block 904, a determination is made as to whether a number of MAC-level acknowledgments transmitted on a link, as reported by its source, corresponds to a number of packets received on that link, as reported by its destination. In other words, for the link 1 from node i to node j, and given a threshold t, the following is determined:
At decision block 906, a determination is made as to whether a number of packets received on a link, as reported by a neighbor of its destination, is significantly greater than the number of packets sent on the same link, as reported by its source. That is, for link 1 from node i to node j, in which node j's neighbor is node k, and given a threshold t, the following is determined:
At decision block 908, a determination is made as to whether a number of packets sent on a link, as reported by a neighbor of its source, is significantly greater than a number of packets sent on the same link, as reported by its source. In other words, for the link 1 from node i to node j, i's neighbor k, and given a threshold t, the following is determined:
At decision block 912, a determination is made as to whether an inconsistent pair of nodes is already included in the inconsistency graph. If not, the nodes are added to an inconsistency graph (block 914). If the inconsistent pair of nodes are already in the inconsistency graph (block 912) or have been added to the inconsistency graph (block 914), an edge is added between the nodes in the inconsistency graph (block 916).
After each of the inconsistent pairs have been identified, then at block 918 a smallest set (i.e., least number) of nodes is found in the inconsistency graph that can explain the observed inconsistencies. For instance, an assumption may be made that most nodes in the network send reliable reports. Therefore, the smallest set of nodes that can explain the observed inconsistencies is found. This can be achieved, for instance, by finding the smallest set of vertices that covers the inconsistency graph, where the identified vertices represent the misbehaving nodes.
The smallest set of vertices may be found through utilization of a minimum vertex cover problem, which is known to be NP-hard. A greedy algorithm is applied which iteratively picks and removes the node and the incident edges from a current inconsistency graph until no edges are left.
A history of reports can be used to further improve the accuracy of inconsistency detection. For example, at block 920 a new report may be added to update the inconsistency graph without deleting previous information. Inconsistent pairs of nodes in the new report may then be processed using blocks 912-918 of the procedure 900. For instance, the same greedy algorithm of block 918 may be reapplied to identify misbehaving nodes.
Furthermore, vertices are depicted in the inconsistency graph 900B. As previously discussed, finding the smallest set of vertices facilitates finding the smallest set of nodes that can explain the observed inconsistencies. For example in the inconsistency graph 900B, vertices V1, V2, V3, V4, V5 and V6 are formed by edges E1, E2, E3, E4, E5, E6 and E7 and identify the inconsistent nodes.
In the previous sections, faults were selectively injected into a network simulation to identify which faults, if any, may have cause a difference between expected and observed network performance. The network simulation may also be utilized to perform “what-if” analysis to improve operation of the network. What-if analysis allows the manager module, when executed, to determine the effect of different possible network and node configurations on network performance. The result of the what-if analysis is a set of actions that allows the manager module to operate the network efficiently, such as by causing the agent module on selected nodes in the network to configure the respective node accordingly.
What-if analysis, for instance, may be carried out through the use of an online trace-driven simulation as previously described. Exemplary traces are identified in the following discussion which may that collected to drive the simulator (e.g., simulator 118(N) of
Traditional techniques that were employed for what-if analysis used simplified network models and derived the expected performance analytically. The online trace-driven simulation, however, has advantages over theoretical analysis in that the use of a simulator offers improved insight into the behavior of the network than is possible by a heuristic or theoretical technique by itself. For example, an operational wireless network is a complex system with many intricate pieces including traffic flows, networking protocols, signal processing algorithms, hardware, RF propagation, and most importantly the interaction between each of these pieces. Further, the network behavior may be governed by the interaction between nodes within range of one another and by noise sources in the vicinity. Neither heuristic nor theoretical techniques capture the behavior of such networks and the interactions between the different components.
At block 1002, one or more of a plurality of modifications are selected through execution of the manager module. Modifications may be selected in a variety of ways. For instance, modifications may be considered by the manager module as a fault that causes an increase instead of a decrease in network performance. Modifications in such an instance may be stored in the faults directory 218 of
At block 1006, expected performance of the network is predicted based on the inputs. For instance, the simulator may create a network simulation based on the network settings of the real network and the modification set. The network simulation, as previously described, may then be utilized to determine the consequences of the modifications to the real network.
The analysis module, when executed, derives one or more actions to be performed by agent modules of the network to implement the modification (block 1008). The analysis module, for instance, may include a directory of actions that are mapped to corresponding modifications. The analysis module may then obtain corresponding actions based on the modifications.
At block 1010, the analysis module forms a communication describing the one or more action for communication to the corresponding agent modules. The corresponding agent modules may then cause the respective nodes of the network to implement the actions described therein. Thus, the manager and agent modules may be utilized to perform what-if analysis based on an online trace-driven simulation in a manner similar to fault detection. What-if analysis may be utilized for correcting faults and improving network performance.
In another exemplary implementation, a simulation is used to determine a modification to be made to a network to improve network performance, such as by using an iterative approach to perform what-if analysis. This approach is similar to the simulation as described in relation to
At block 1106, for instance, network settings are collected that describes target end-to-end demands and the routing protocol that is in use. It should be noted that these network settings may be different from the traces used for troubleshooting, because the procedure 1100 examines how the network (e.g., link loads and routing) will react to the changes in network configuration.
At block 1108, the effect on the aggregate network throughput is examined based on removal, one at a time, of each flow from a network simulation. In an implementation, a damaging flow is identified as the one flow whose removal yield the most significant overall improvement to network performance. For example, a network 1200 is shown in
At block 1110 one or more actions are derived based on the modification which may be utilized to improve network performance. Exemplary actions may include rate-limiting, rerouting, and topology control of flow eight 1216. The network simulation enables the manager module to further evaluate the benefit of these actions accurately. For example, the following table shows an expected throughput for exemplary corrective actions.
An example of the described framework has been implemented on a WINDOWS XP platform (WINDOWS XP is a trademark of the Microsoft Corp., Redmond Wash.). Components of the exemplary implementation, design principles, and its features are described in this section.
The exemplary framework in this instance includes two separate components: agent modules and manager modules. As previously described in relation to
The exemplary framework employs simplicity and extensibility design principles. For example, the data gathered and propagated for monitoring and management may be cast into performance counters supported on WINDOWS (WINDOWS is a trademark of Microsoft Corp, Redmond Wash.). Performance counters may be provided as (name, value) pairs grouped by categories.
The described framework is also extensible. Adding to the data being monitored involves creation of a new category of performance counters and writing a module that updates the performance counter values as the information changes. Performance data related to transmission control protocol (TCP), user datagram protocol (UDP), internet protocol (IP), and workstation remote application programming interface (WRAPI) may be incorporated into the framework with little additional work.
Values in these performance counters may be read-only or writable. Writable counters, for instance, offer a way for an authorized manager node to change the values and influence the behavior of a node in order to fix problems or initiate experiments remotely, such as through communication of a manager module with an agent module being executed on difference respective nodes.
Each manager node may also be equipped with a graphical user interface (GUI) 1300, an example of which is illustrated in
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.