wlanslovenija/nodewatcher-paper

Paper presenting nodewatcher, a modular open networks growing platform.

nodewatcher: A substrate for growing your own community network

nodewatcher is one of the projects of wlan slovenija open wireless network. Its main goal is the development of an open source network planning, deployment, monitoring and maintanance platform with emphasis on community.

This repository contains a paper presenting the project. The paper was published in journal Computer Networks, in the special issue on community networks, DOI 10.1016/j.comnet.2015.09.021.

Available at:

• http://www.sciencedirect.com/science/article/pii/S1389128615003400
• http://arxiv.org/abs/1601.02372

Abstract:

Community networks differ from regular networks by their organic growth patterns — there is no central planning body that would decide how the network is built. Instead, the network grows in a bottom-up fashion as more people express interest in participating in the community and connect with their neighbors. People who participate in community networks are usually volunteers with limited free time. Due to these factors, making the management of community networks simpler and easier for all participants is the key component in boosting their growth. Specifics of individual networks often force communities to develop their own sets of tools and best practices which are hard to share and do not interoperate well with others. We propose a new general community network management platform nodewatcher that is built around the core principle of modularity and extensibility, making it suitable for reuse by different community networks. Devices are configured using a platform-independent configuration which nodewatcher can transform into deployable firmware images, eliminating any manual device configuration, reducing errors, and enabling participation of novice maintainers. An embedded monitoring system enables live overview and validation of the whole community network. We show how the system successfully operates in an actual community wireless network, wlan slovenija.

You can cite it as:

@article{Kos2015279,
  title = "nodewatcher: A substrate for growing your own community network",
  journal = "Computer Networks",
  volume = "93, Part 2",
  pages = "279--296",
  year = "2015",
  issn = "1389-1286",
  doi = "http://dx.doi.org/10.1016/j.comnet.2015.09.021",
  author = "Jernej Kos and Mitar Milutinović and Luka Čehovin",
  keywords = "Community networks",
  keywords = "Management",
  keywords = "Provisioning",
  keywords = "Monitoring",
  keywords = "Wireless",
  keywords = "Mesh"
}

nodewatcher-paper's Issues

Last revisions comments

Deadline: August 15, 2015

• I suggest to review once again the whole section 3, with the point of identify concisely both the problems faced, and the proposed solution.
• A clear example may be sec. 3.2: it is very clear that platform independence is fundamental issue to face, but at the same time lots of details (such the procedure to repair and fix a node, or the level of detail in which the reason why a community network present different platforms) could be removed, or rewritten more concisely.
• I have serious concerns about the scalability of their proposals in what I would call "big CNs" (i.e. thousands or tens of thousands), mainly because, IMHO, they underestimate the social consequences in terms of diversity of this change of scale (hardware, opinions, ways of doing things, etc.). This is not to be amended, because it is in the core of the article, and because it is the authors' position.
  • I only suggest to review the text to mitigate some statements and introduce a point of doubt.
  • Alternative, in the case that they do not agree with my point, could they answer the following question "Ok, I like your proposal very much, what should I do to implement it in AWMN or guifi.net?"
• p4, table 1, "DEV" as it appears in the caption does not appear in the table itself (Project (Developers)). Please also consider to move the columns descriptions of the caption to table footnotes.
• Related work, regarding routing and security:
  • Babel: https://tools.ietf.org/html/draft-chroboczek-babel-security-considerations-00
  • Babel: https://tools.ietf.org/html/rfc7298
  • OLSRv2: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/?include_text=1
  • BMX6: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583481
• Related work, regarding network topology and performance:
  • http://www.sciencedirect.com/science/article/pii/S1570870514001474
  • http://www.sciencedirect.com/science/article/pii/S002200001300127X
  • http://dl.acm.org/citation.cfm?id=2507960
  • http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6934252
• Related work, regarding HW platforms, usage, and flexibility:
  • http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6379143
  • http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6673333
• Add open source monitoring system to table 1: http://dl.acm.org/citation.cfm?id=2507960
• Section 2.2
  • To allow quick finding in your Table 1, Include the acronyms at least for the commented columns in your text. Like: "...We show whether the project is being actively developed (A) and which year (Y) it first... In case of network monitoring (NM)... For topology visualization (TP)..."
  • I wonder what's the difference between Features API and Extensibility API ?
  • Some of the main features and characteristics expected from nodewatcher are NOT covered by Table 1: (i) Performance testing/monitoring (via time series), (ii) diagnostic (eg detect disappearing links), (iii) validation, (iv) central versus decentral architecture. Could these be included ?
  • Page 4, second paragraph: Include "(AWMN)" as acronym in the text when mentioning the Athens Wireless Metropolitan Network" for the first time to allow quick finding in Table 1
  • Section 2.2 conclusion: You should not summarize findings that have not been discussed before: eg: "(c) There is limited support for interactive display of time-series monitoring data".
• Section 3.3.2
  • Please Harmonize terminology used in Figure 6 and the text (would be good to find the left-sided also in the Figures or use the right-sided in the text): "Runtime Platform" vs "Transform Modules", "(Hardware) Device descriptor" vs "device DB", "Configuration transformation pipeline" vs "???"
  • The whole docker-container discussion is IMO only about enhancing the scalability of expensive firmware-building tasks. Actually a separate directory and thread would be enough for this process. Any discussion on linux namespaces and kernel-reusage seems absolutely not relevant for the main scope of this work. Neither that SSH connections must be established before they can be used. Actually, I am still not convienced why heavy reflashing with complete firmwares is better than a lightweight update of openWrt uci configs (with RouterOS a lightweight config update is the only possible way anyway). That such expendable expensive building tasks can now be outsourced into a cloud doesn't make the approach more attractive to me.
  • Please clarify absolutely misleading last paragraph of 3.3.1 "But without an easy way of "running" the firmware...Thereby, containers provide an easy way for existing communities to evaluate and follow the firmware development progress". This sounds like docker-containers can be used in a sandbox-style to execute the firmware developments of others (NOT just compile them but actively play with their new
    topology-visualisation tool in a virtualised mesh environment). Is guess that's not the case. Instead, to evaluate and follow the firmware development progress of others, Code-management systems like those
    provided by track or github.com with forums, activity, contributions, ... features are typically the tool of choice.
• Section 4.5
  • Given the effort made to scale up with firmware building using a docker cloud, it is a bit bold to consider a "Single installation" as a valid and reasonable option to make nodewatcher federated !!! Please consider scalability of a federated nodewatcher installation managing several 10k nodes and related implications just from polling/pushing tasks and other ... Not to mention the political concerns.

Address reviewer's comments

Reviewer 1

Overall the "work" is valuable and it is extremely relevant with the call for paper. However the "paper" is a little bit boring. The authors have difficulty in simply explaining at higher level the system architecture and get the discussion in too much details, in order to motivate any choice. It would be better to introduce an overview section with highlights all the user/administrator steps from the user decision to participate to the community network up to the time when her node is operational. By sequentially of describing each piece of the (good) system, the reader have a complete view only at the end. And this discourage the reading. In would be better to provide a bird-eye-view at the start of the paper.

• Add a high-level overview section containing a story of how a user deploys nodes in a community network.
• Add a schematic overview that goes together with the story.

Reviewer 2

Please discuss:

1. how nodewatcher with hardware diversity and novelty. Which are the constrains (e.g. OpenWRT like firmwares required? Implications of requirement of having to install a daemon in each node). Recommendations for new adopters and specially for (massive) migrations.

• Highlight the case for platform extensibility and show an example of how we can support other platforms like Mikrotik.
• Highlight the fact that there is no inherent requirement to install a daemon in each node as for example SNMP may be used instead through a module.
• Discuss importing from other systems.

Please clarify (and discuss the consequences if appropriated):

1. if all nodes need to see each other. I.e. how isolated clouds are handled, does each need a nodewatcher? if so, what if two nodes merge. Federation. if it splits?

• Highlight that there is no need for the nodes to see each other. It is just that either nodewatcher needs to be able to reach the nodes (in case polling is used) or the nodes need to be able to reach nodewatcher (in case push is used).

2. if how to develop "monitor pipelines" presented Fig.6 is well documented, e.g. to develop one for BGP

• Describe how we can currently support multiple protocols. We support both OLSR and Babel with ease, show that additional protocols are easily added.

Reviewer 3

Particularly in the former aspect, the review given by the paper could be significantly enhanced. The paper covers in too great detail technical engineering decisions to achieve the somehow common objectives of modularity and extensibility, which are of course noble goals. But it reads a lot like a white paper or technical report that praises a bit too much its own achievements without providing sufficient quantitative or qualitative comparison or overview of existing solutions, weaknesses, unaddressed aspects or yet achieved disseminations and impacts.

A table summarizing characteristics of existing management solutions would be desirable, (e.g. showing features, addressed issues, concerns, openness, usage, age, developer community size, ...).

• Prepare a table that compares all the different existing management solutions (through time, features, programming language, license, ...).

For example the guifi.net management system is able to generate firmware configurations (building of the entire firmware is due to the closed-source policy of Mikrotik, a different issue than for openWRT based systems) from a web-user interface for many different devices. But the paper claims this as a somehow unique feature of the nodewatcher platform.

• Highlight why having a complete firmware in addition to just configuration is beneficial (testing the configuration together with the exact software versions and only upgrading everything at once, ensuring that it works correctly).

Another interesting comparison would be on the implications of different designs approaches. One examples is the issue of centrality, single-point of failure, and security which seems pretty neglected in the whole discussion but, to the best of my knowledge, plays a very important role in community networks.

• Highlight that network operation does not depend on there being a working nodewatcher instance. Even if one fails, the network will still work.
• Mention security aspects, we are in the process of adding node authentication as part of the contract with OTI.

Another critical implication seems that the proposed system mandates exclusive configuration rights as any manual parameter change by a node-admin would violate the foreseen approach. This could also be considered a real burden when trying for example to test different parameters (eg when looking for link channels with least interference and highest TP in a given environment).

• Highlight that nodewatcher will only display warnings, it will not rollback any custom configuration. If the node admin knows what he is doing, he may simply mark the warnings as resolved. And then when the admin finds the best settings, he may just save them into nodewatcher in order to persist them across upgrades.
• In the future, nodewatcher may also help with link planning by having wireless survey information available from nearby nodes and can therefore estimate spectrum usage.

It remains unclear to what extend the proposed system can indeed achieve its promises. An overview of successful adoptions by other communities or completely different (unforeseen by the original developers) scenarios would be interesting.

The authors could describe in more detail since how long and with which acceptance and experience the new system (nodewatcher v3) has been used in their own community.

• Explain (or highlight as I think that we already say so) that we have been using the system in parallel since January 2015. I think we also currently list experience with adoption from the Croatian network.