Mesh Network Visualization Proposal: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (→‎Project: typos)
Line 12: Line 12:
== General ==
== General ==


Mesh network visualization is an effective tool for mesh network analysis & testing. This tool would make use of the KDE Marble widget to display data assumed to exist in some database backed form. Different 'map overlays' would directly effect what data is extracted from the database, loaded into memory and displayed through Marble.
Mesh network analysis could be assisted considerable by a dedicated visual research tool. This tool would use Marble to display data assumed to exist in some database backed form. Different 'mesh overlays' would utilizes different data subsets, loading them into memory and possible animating them.


The Marble widget was chosen since it scales well alongside mesh size (WAN / LAN size mesh networks ). Presented data would be throttled according to map zoom levels, grouping nodes as clusters when zooming out. Ability to un/hide data layers would also keep large scale scenarios clear / small scale scenarios detailed. Viewing Marble as a 'global' scale mapping tool is mis-accurate : being similar to Google Earth - it would be usable also at the village \ municipal scale provided adequate maps are supplied. This makes the tool correlate well with OLPC's needs. As well, Marble makes integrating interactive user capabilities easy such as making nodes selectable. GPS support in marble would ease using GPS oriented XO mesh data.
Marble was chosen since it scales well with mesh size (WAN / LAN size mesh networks ). Presented data 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. As well, Marble makes integrating interactive user capabilities easy.


Most overlays map nodes by their GPS position. Although the XO-1 currently doesn't support a GPS module one might expected it to be incorporated in the future. If no GPS data is available an approximated node position could be computed by some triangulation algorithm based on relative signal strength. Existing GPS support in marble should come in hand for this.
Following is a list of several visual techniques and mesh network metrics to which they apply. Several node types would be displayed such as clients, AP, Routers, Clusters (when zoomed out). All mappings place nodes on map by their geographical positing.

== 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
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 area covering.
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. )
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 mesh metrics include node signal strength, node load rate, average node throughput, node collision / retransmission rates, load vs. signal strength, load vs. collisions, dropped packet count etc.
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.
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. Overlay type & hiding of mapped elements will use existing Marble functionality.

One far reached application might be to used the tool in an 'online fashion' where selecting two nodes may initiate a ping command to measure network lag time between them.


Although this might be beyond the scope of GSoC, most interesting visualizations would emerge when animating the above overlays. Implementation would call for either pre-loading all relevant data into memory or intensive database communication (sacrificing performance). Animation 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. Also interesting to view is network load shifting during the day.


== Data Representation ==
Interactive user capabilities include node/edge displaying IP data, segment protocol histogram, Tx\Rx ratios, etc. upon being selected. User interface will allowing for easy selection of overlay type & hiding of mapped elements.


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.
* Note :
:Although the XO-1 currently doesn't support a GPS module one might expected it to be incorporated in future versions. As well an approximated node position could be computed by applying a triangulation algorithm on the given data set.


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 ==

Revision as of 08:34, 6 April 2008

Project

The suggested project will aim to provide visualization capabilities for mesh network analysis. The KDE Marble widget would support display mechanism, along with a database backed data source. Provided capabilities include :

  1. IP to Geographical position mapping using the Marble widget.
  2. Add map overlays utilizing several visual techniques such as edge coloration, opacity levels & node grouping.
  3. Add interactive capability by making mesh node/edges selectable.
  4. Add animated versions of the map overlays (Time permitting) 

Current inability to run Marble under XO (being a KDE widget) was taken into account - nevertheless since the suggested tool's main goal is mesh network analysis & research XO users will probable be providing simulation data rather than actually running the tool. This issue may become irrelevantly once widget support is added to XO.

General

Mesh network analysis could be assisted considerable by a dedicated visual research tool. This tool would use Marble to display data assumed to exist in some database backed form. Different 'mesh overlays' would utilizes different data subsets, loading them into memory and possible animating them.

Marble was chosen since it scales well with mesh size (WAN / LAN size mesh networks ). Presented data 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. As well, Marble makes integrating interactive user capabilities easy.

Most overlays map nodes by their GPS position. Although the XO-1 currently doesn't support a GPS module one might expected it to be incorporated in the future. If no GPS data is available an approximated node position could be computed by some triangulation algorithm based on relative signal strength. Existing GPS support in marble should come in hand for this.

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. Overlay type & hiding of mapped elements will use existing Marble functionality.

One far reached application might be to used the tool in an 'online fashion' where selecting two nodes may initiate a ping command to measure network lag time between them.


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

  1. A working Marble widget capable to produce all non-animated data mappings.
  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 ) 

All these should provide the OLPC with an highly effective mesh network test & analysis tool. The open source community would benefit as well since added Marble features may be useful for other applications. This might be far-reached but enabling mesh network analysis at a country scale, say Peru, is not unconceivable either.


Any mentor comment through the actual application (submitted on 2008/03/30 11:42:44 PDT) is welcome.