Mesh Network Visualization Proposal: Difference between revisions
No edit summary |
(updated removal of marble as the main display engine) |
||
Line 1: | Line 1: | ||
== Project Summery == |
== Project Summery == |
||
This project will aim to provide a visual research tool for mesh network analysis. |
This project will aim to provide a visual research tool for mesh network analysis. A mapping tool capable of vector graphic over-lays on top of satellite imagery would be used [GRASS is one such example]. The suggested tool would make use of a database backed data source. Provided capabilities include : |
||
1. Marble XO client mapping based on GPS data. |
1. Marble XO client mapping based on GPS data. |
||
2. Various map overlays utilizing several visual techniques. |
2. Various map overlays utilizing several visual techniques. |
||
3. Add interactive capability by making mesh node/edges selectable. |
3. Add interactive capability by making mesh node/edges selectable. |
||
4. Add animated versions of the map overlays (Time permitting) |
4. Add animated versions of the map overlays (Time permitting) |
||
⚫ | The suggested tool's main goal is to provide a mesh network analysis & research tool. XO users will probable be providing simulation data rather than actually running the tool. |
||
⚫ | |||
⚫ | The suggested tool's main goal is to provide a mesh network analysis & research tool. XO users will probable be providing simulation data rather than actually running the tool. Likely scenarios in which the tool would be used include wireless network installations at OLPC program sites, mesh testing & mesh research. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | Most overlays map nodes by their GPS position |
||
⚫ | |||
⚫ | |||
⚫ | |||
== Visualization == |
== Visualization == |
||
Line 23: | Line 36: | ||
Following is a list of several visual techniques and a partial mesh network metrics set to which they apply. Several map icons would be used for various network entities such as clients, AP, routers, clusters (when zoomed out). |
Following is a list of several visual techniques and a partial mesh network metrics set to which they apply. Several map icons would be used for various network entities such as clients, AP, routers, clusters (when zoomed out). |
||
1. Simple topology representation |
1. Simple topology representation |
||
interconnect nodes according to signal, actual data flow etc. Automatic node grouping would make this view scale easily to client, router or cluster levels. Illustrates mesh network cover. A 'village scale' representation may show active XO links and how they all connect to a school router. |
|||
2. Icon changing of nodes |
2. Icon changing of nodes |
||
Change node icons according to status (failed, busy, unreachable, router, XO laptop etc. ) |
|||
3. 'Heat' colorizing of inter-node edges |
3. 'Heat' colorizing of inter-node edges |
||
applicable to node signal strength, node load rate, average node throughput, node collision / retransmission rates, load vs. signal strength, load vs. collisions, dropped packet count etc. |
|||
Examples: |
Examples: |
||
- a 'hot' segment in the 'dropped packet' overlay would indicate a network segment being over loaded with data. |
- a 'hot' segment in the 'dropped packet' overlay would indicate a network segment being over loaded with data. |
||
- a 'cool' segment in the 'load vs. signal strength' would indicate under utilized network segments. |
- a 'cool' segment in the 'load vs. signal strength' would indicate under utilized network segments. |
||
This technique could make mesh bottle necks stand out & point out unreliable network segments. |
This technique could make mesh bottle necks stand out & point out unreliable network segments. |
||
4. Varied opacity edge coloration |
4. Varied opacity edge coloration |
||
applicable mesh metrics are collision / retransmission rates (higher opacity levels for more reliable segments), edge load rate. |
|||
Most interesting visualizations would emerge when animating the above overlays. Implementation would call for either pre-loading all relevant data or intensive database communication (sacrificing performance). This would help unveil network dynamics: Animating the load overlay would allow 'seeing' how routing algorithms respond to route around congested network segments (essentially entropy in action). Animated 'Load vs. Signal' overlay could show mesh reaction to segment / node (router) failure. Network load shifting during the day could be investigated to enhance usage during the night for certain tasks (automatic client software updating for example). |
Most interesting visualizations would emerge when animating the above overlays. Implementation would call for either pre-loading all relevant data or intensive database communication (sacrificing performance). This would help unveil network dynamics: Animating the load overlay would allow 'seeing' how routing algorithms respond to route around congested network segments (essentially entropy in action). Animated 'Load vs. Signal' overlay could show mesh reaction to segment / node (router) failure. Network load shifting during the day could be investigated to enhance usage during the night for certain tasks (automatic client software updating for example). |
||
⚫ | |||
The tool would expect experiment/simulation data to be present through some accessible database. According to available database schemes mapping overlays would become available. Example : the basic mesh topological map overlay, would require a list of XO clients, AP, routers etc. along side their GPS position and each XO's reachable neighbor. On the other hand, the packet collision overlay would require packet collision data for every mesh segment. The animated collision overlay would require the database to include time reference for every time snapshot. |
|||
⚫ | |||
One far reached application might be to used the tool in an 'real time fashion' where selecting two nodes may initiate a ping command to measure network lag time between them. |
|||
== Longterm Road Map == |
== Longterm Road Map == |
||
Line 59: | Line 96: | ||
The libpcap file format is the de-facto packet gathering format & should be thought as the default data input format. Unfortunately it currently lacks interface statistics data, vital for mesh analysis (hopefully provided in next generation libpcap file format). Since the tool will be database backed automatic database generation from a set XO libpcap files is a desirable feature though may exceed GSoC time scale. |
The libpcap file format is the de-facto packet gathering format & should be thought as the default data input format. Unfortunately it currently lacks interface statistics data, vital for mesh analysis (hopefully provided in next generation libpcap file format). Since the tool will be database backed automatic database generation from a set XO libpcap files is a desirable feature though may exceed GSoC time scale. |
||
⚫ | This still leaves some mesh metrics (router level statistics) that would have to be provided in some other form (preferable as an experiment database). Relevant mesh overlays will become available through database schema analysis. Example : a database linking nodes to their libpcap files with GPS data (expressed in the DB schema) would result in a GPS based overlay with an option to view each XO's libcap file in |
||
⚫ | This still leaves some mesh metrics (router level statistics) that would have to be provided in some other form (preferable as an experiment database). Relevant mesh overlays will become available through database schema analysis. Example : a database linking nodes to their libpcap files with GPS data (expressed in the DB schema) would result in a GPS based overlay with an option to view each XO's libcap file in wireshark. |
||
== Deliverables == |
== Deliverables == |
||
Since the potential of this tool is wide I will focus on the following features as a start : |
Since the potential of this tool is wide I will focus on the following features as a start : |
||
⚫ | |||
⚫ | |||
2. User interaction enabling node & edge selection. |
2. User interaction enabling node & edge selection. |
||
3. Ability to hide nodes / edges. |
3. Ability to hide nodes / edges. |
||
4. A layers menu for overlay selection & un/hiding of map elements. |
4. A layers menu for overlay selection & un/hiding of map elements. |
||
5. Auto node un/grouping upon zooming in/out ( optional ) |
5. Auto node un/grouping upon zooming in/out ( optional ) |
||
6. Animated overlays ( optional, depending on progress ) |
6. Animated overlays ( optional, depending on progress ) |
||
These should provide the OLPC with an highly effective mesh network analysis tool. |
These should provide the OLPC with an highly effective mesh network analysis tool. |
||
Any mentor comment through the actual application (submitted on 2008/03/30 11:42:44 PDT) is welcome. |
Any mentor comment through the actual application (submitted on 2008/03/30 11:42:44 PDT) is welcome. |
Revision as of 19:25, 14 April 2008
Project Summery
This project will aim to provide a visual research tool for mesh network analysis. A mapping tool capable of vector graphic over-lays on top of satellite imagery would be used [GRASS is one such example]. The suggested tool would make use of a database backed data source. Provided capabilities include :
1. Marble XO client mapping based on GPS data.
2. Various map overlays utilizing several visual techniques.
3. Add interactive capability by making mesh node/edges selectable.
4. Add animated versions of the map overlays (Time permitting)
The suggested tool's main goal is to provide a mesh network analysis & research tool. XO users will probable be providing simulation data rather than actually running the tool. Likely scenarios in which the tool would be used include wireless network installations at OLPC program sites, mesh testing & mesh research.
--- General ---
Mesh network analysis could be assisted considerable by a dedicated visual research tool. Different 'mesh data overlays' would be applied on top of satellite imagery, loading different database subsets into memory and possible animating them.
Presented data within the mapping tool would be throttled according to map zoom levels, grouping XO nodes as clusters when zooming out. Ability to un/hide data layers would also keep large scale scenarios clear. User interactive capabilities in the form of context menus will be provided.
Most overlays map nodes by their GPS position. If no GPS data is available an approximated node position could be computed by some algorithm based on relative signal strength. Background imagery could be disabled in this case.
Visualization
Following is a list of several visual techniques and a partial mesh network metrics set to which they apply. Several map icons would be used for various network entities such as clients, AP, routers, clusters (when zoomed out).
1. Simple topology representation
interconnect nodes according to signal, actual data flow etc. Automatic node grouping would make this view scale easily to client, router or cluster levels. Illustrates mesh network cover. A 'village scale' representation may show active XO links and how they all connect to a school router.
2. Icon changing of nodes
Change node icons according to status (failed, busy, unreachable, router, XO laptop etc. )
3. 'Heat' colorizing of inter-node edges
applicable to node signal strength, node load rate, average node throughput, node collision / retransmission rates, load vs. signal strength, load vs. collisions, dropped packet count etc.
Examples:
- a 'hot' segment in the 'dropped packet' overlay would indicate a network segment being over loaded with data.
- a 'cool' segment in the 'load vs. signal strength' would indicate under utilized network segments.
This technique could make mesh bottle necks stand out & point out unreliable network segments.
4. Varied opacity edge coloration
applicable mesh metrics are collision / retransmission rates (higher opacity levels for more reliable segments), edge load rate.
Most interesting visualizations would emerge when animating the above overlays. Implementation would call for either pre-loading all relevant data or intensive database communication (sacrificing performance). This would help unveil network dynamics: Animating the load overlay would allow 'seeing' how routing algorithms respond to route around congested network segments (essentially entropy in action). Animated 'Load vs. Signal' overlay could show mesh reaction to segment / node (router) failure. Network load shifting during the day could be investigated to enhance usage during the night for certain tasks (automatic client software updating for example).
Interactive user capabilities include node/edge displaying IP data, segment protocol histogram, Tx\Rx ratios, etc. upon being selected.
One far reached application might be to used the tool in an 'real time fashion' where selecting two nodes may initiate a ping command to measure network lag time between them.
Longterm Road Map
One far reached application might be to used the tool in a 'real time fashion'. Network statistical information would be gathered 'online' as experiments progress. Some possible applications of this would be :
- selection of two nodes may initiate a ping command to measure network lag time between them.
- Injection of simulated network node failures would ease the testing of the networks rerouting algorithms.
- File entropy simulations - measuring the speed in which the latest release of Ubuntu could reach opposite sides of the network using various P2P protocols.
Data Representation
The libpcap file format is the de-facto packet gathering format & should be thought as the default data input format. Unfortunately it currently lacks interface statistics data, vital for mesh analysis (hopefully provided in next generation libpcap file format). Since the tool will be database backed automatic database generation from a set XO libpcap files is a desirable feature though may exceed GSoC time scale.
This still leaves some mesh metrics (router level statistics) that would have to be provided in some other form (preferable as an experiment database). Relevant mesh overlays will become available through database schema analysis. Example : a database linking nodes to their libpcap files with GPS data (expressed in the DB schema) would result in a GPS based overlay with an option to view each XO's libcap file in wireshark.
Deliverables
Since the potential of this tool is wide I will focus on the following features as a start :
1. Support for all non-animated GPS based overlays backed by some DB.
2. User interaction enabling node & edge selection.
3. Ability to hide nodes / edges.
4. A layers menu for overlay selection & un/hiding of map elements.
5. Auto node un/grouping upon zooming in/out ( optional )
6. Animated overlays ( optional, depending on progress )
These should provide the OLPC with an highly effective mesh network analysis tool.
Any mentor comment through the actual application (submitted on 2008/03/30 11:42:44 PDT) is welcome.