CUWiN Development Agenda
These are the research and development areas that we think are most interesting and rewarding. Let us know if you are currently working on any of these or if you interested in working on these items.
Setting Appropriate Carrier-Sense Thresholds: CUWiN supporters at MIT have stated that carrier-sense threshold is set substantially higher than the typical Rx signal strength on the MIT Roofnet. This may help explain bad performance and is an area that could be greatly improved upon.
Transmit Power Control & Attendant Carrier-Sense Adjustments: Operation at lower power to reduce self-interference and, by adding dynamic power control, would lower general congestion within the unlicensed bands to be more “neighborly.” This may be an area where adjuncts would be particularly useful (e.g., for Atheros hardware).
IPv4/IPv6 NAT Traversal: Most CUWiN Internet-connected wireless nodes are unreachable from other locations outside the network because they are behind NAT firewalls. Teredo allows Ipv6 packets to traverse NAT firewalls. CUWiN would program a Teredo pseudo-interface, teredo(4). This interface would support client/relay/server modes. CUWiN developers have identified stf(4), the 6to4 pseudo-interface, as a potential starting point.
Self-Interference Mitigation: Power control matters. Utilizing a proper metric (e.g., James Stevens' Least Interference Routing) does, with adaptations for 802.11, use routes that minimize the number of links that are interfered with by a packet stream. This may provide an additional avenue for increasing the scalability of wireless networks.
OPN/MS Research's MultiNet: Connective among community wireless network can be enhanced without using more radios if you can operate with one radio on more than one network. Sam Leffler's Multi-BSS support may provide a good starting-off point. The OPN project (see: http://dek.spc.org/opn/) came out of discussions among CUWiN developers and other wireless innovators during the 2004 Freifunk.net summit in Denmark and provides an innovative way to leverage already existent off-the-shelf WAPs to interconnect “smart” community wireless network.
Channel Agility: Coordinating channel changes on a wireless network, and/or operating on more than one channel as in MS MultiNet can substantially boost network throughput and user density. One of the major roadblocks has been identifying an efficient way for wireless nodes to decide upon and coordinate channel changes. What advantages exist if a receiver that is impaired by local interference tunes to an interference-free channel? What happens when this receiver's neighbors change to its channel before transmitting to it? Does the channel-switching overhead absorb the performance gain? While datasheets suggest that we can switch channels in 100us-200us, what happens in the real world?
Multicast: Community wireless meshes can boost efficiency of this broadcast medium by adding multicast routing. A successful networking solution will need to deal with the nuances of multicast forwarding on wireless (e.g., packet duplication) and may have to develop a new wireless metrics for multicast?
Ports: The Linux port will open up entire new realms where CUWiN's technology would be useful. As one of the main Open Source operating systems, with a growing number of users, Linux is a natural addition to the CUWiN family. Mac OSX, being BSD-based, may prove to be the least difficult OS addition. A full port would need to include the net80211 and BSD wireless drivers. But once this is done, it should become possible to run HSLSD and ETX as they would on NetBSD machines. Most importantly, a Mac OSX port would enable seamless connectivity with other CUWiN-enhanced devices – creating an all-in-one, OS neutral technology that interoperates with countless other devices.
“Debuggability”: CUWiN developers have identified the need to both add sparse kernel dumps and to reserve a partition to collect them on the wireless nodes. This can be done by collecting netbsd.gdb kernels for releases and putting them in a known location. For development/testing builds, collecting netbsd.gdb kernels somewhere would also enhance the stability of the software and reduce confusion. Ideally, all daemons and utilities would be built using -g -DDEBUG, and unstripped versions for releases (and optionally for development builds) would be collected a priori.
Improving the HSLS Bootstrap Condition: When a router (R) detects a new peer (P) whose originator address is not in R's routing table, then R should wait a set time (e.g., 10 seconds) and initiate bootstrap on the interface where it hears P. This should help to improve network stability and integration of new ad-hoc devices.
Multi-Threaded HSLSD: Running the Hello protocol, LSU generation/relaying, and the “decision” process in separate threads will improve hslsd. Currently, the HSLS daemon does not split these processes.
Quagga: CUWiN originally utilized Zebra, which has become a relatively defunct project. Switching and maintaining Quagga is relatively trivial – but systematic testing and documentation are still needed.
Graphical User Interface: End users need to be able to reconfigure individual interfaces for different roles (e.g., AP, mesh, subscriber). Firewall and bandwidth-shaping rules need to be added and GUIs created. A set log destination needs to be added along with the abilities to set subscriber's machine names and addresses, select preferential gateways, etc. CUWiN developers have already created a first-generation mock-up for this interface, available online here: http://www.cuwireless.net/nodeconfig.
Directional “Smart” Antennas: Several promising, cheap technologies for adding adaptive antennas to 802.11 are just around the corner (e.g., “Commodity-Class Phased Array Antennas, Motia Javelin, Atheros' latest products, Airgo “True MIMO”). Documentation is needed to add driver support for these products. Research is also needed to determine the optimal antenna configuration and where one can find a source for cheap, compact antenna arrays. Routing integration will also be needed, following from the UDAAN findings.
Drivers: ACX-100 (may not be suitable), ADMtek and ADM8211B/C, Ralink RT2500 (which already has an OpenBSD driver and just needs to be ported), Realtek RTL8185, etc. The main problem has been obtaining the documentation necessary to complete these drivers. Intel drivers iwi(4), ipw(4) are already in -current, but work is needed to ensure their compatibility.
QoS: Delay can be controlled, and service differentiation (e.g., voice, video, bulk data) can be achieved by computing and integrating delay/jitter metrics, computing SPF on different combinations of metrics, and using different routing tables for different types of traffic. It may be possible to control delay/jitter on the mesh with some driver modifications that make forwarding decisions concurrent with packet reception, but this is an area where more research is needed.
ETTADAPT: Expected Transmission Time (ETT)-based rate adaptation, with hooks for routing daemons (HSLSD) to read metrics out of the kernel would improve network efficiency. John Bicket has recently finished “SampleRate” (which currently only works with Atheros radios). Hooks for reading the ETT per client/peer out of the kernel would need to be added. And the problem of how to ETT up-to-date for idle clients/peers would need to be solved.
LIBETT: An HSLSD module that reads ETT metrics out of the kernel, matches them with IPv6/IPv4 peers using the NDP/ARP tables, and sets metrics in the link-state database would help with network scalability.
Quagga Improvements: CUWiN developers' experiences with Quagga have called into question its reliability. For example, the zserv socket sends no success/failure indications; zserv error-checking is virtually non-existent; and neither Zebra nor the protocol daemons are prepared to handle protocol-daemon crashes/restarts. CUWiN proposes to investigate and improve
potential stability problem-areas in Quagga.
Cross-Building: Through the efforts of countless volunteers, CUWiN has completed a first-generation cross-build to Linux. Debugging and syncing with continuing development is expected to still take ongoing staff time. The Linux Crossbuild creates a development environment that is native to Linux and is a major step towards opening up the project to a large group of new developers by enabling them to program in a native Linux environment. Development and maintenance of Linux, FreeBSD, OpenBSD, and Mac OSX cross-builds will allow many more Open Source developers to program in the environment of their choice.
Transparent TCP Proxy: Kentaro Kurahone has programmed/ported several TCP extensions to be implemented in NetBSD, including Eifel detection/response and SACK. These extensions may improve TCP throughput on CUWiN's multi-hop wireless network. Next steps include figuring out how to intercept TCP connections originating at or beyond the edges of the wireless network (for example, at a subscriber's PC, or on the Internet) and convert the end host's TCP stream into a stream with options such as SACK/Eifel enabled.
Gateway Discovery/Negotiation: Use HSLS Opaque LSAs to advertise gateway capabilities: IPv4 global addresses, IPv4 NAT, IPv6/6to4, VPN and negotiate these capabilities. One can then set up a tunnel to gateway to prevent “gateway flap.” If one can make the default route a cloning route it becomes possible to operate on more than one gateway and then do a gradual switchover to a new gateway. Likewise, this opens up the potential to use different gateways for different classes of service (e.g., voice, video, etc.). One of the major research questions is whether, for QoS, one should set up tunnels with different DIFFSERV labels and send packets down tunnels with like DIFFSERV only. These and other questions would be answered, and the capabilities developed during the course of this project.
Name Service: Full implementation of CUWiN's prototype ad hoc name service. More information is available online at: http://svn.cuwireless.net/svn/cuw/trunk/doc/local (c.f., name-service, name-service-tasks, and name-service-use-cases-arch).
Logging and Alerts: Functionality to create alerts for network operators about exceptional conditions needs to be added and logs of exceptional events and debug messages need to be stored to nodes and/or a central server. Log size control is a prerequisite and queuing of log messages during network outages needs to be added.
Reliability: A better measure for node “liveness” needs to be computed and node recovery strategies with different levels of severity should be integrated into network self-administration (e.g., ifconfig up/down interface, restart daemon, reset computer). Resource limits for different programs should be maintained and auto-recovery from “resource exhaustion” added.
Miniaturization: Paring down the CUWiN software so that it fits onto small Flash ROMs like cheap Wireless Access Points is a must for creating consumer-grade, off-the-shelf devices.
Multi-Radio Support: Numerous potential clients and communities have asked for multi-radio support to be added to the CUWiN software. In addition, multi-radio support will allow one radio to be used for local Wireless Access Point coverage while the other can handle backhaul. This will greatly improve the utility of the system while also providing a simple turnkey solution for creating ubiquitous wireless access within a geographic area.
Linux Port and Port to Consumer-Grade Device: Once version 1.0 of the CUWiN software is released, the next step is to port the working CUWiN software to Linux or a widely available consumer-grade device. This goes far beyond the crossbuild by allowing the software itself (as opposed to just the developers environment) to run on Linux machines or off-the-shelf wireless hardware such as the $60(US) Realtek AP, or the equivalent. A cheap, mass-produced router approach has huge appeal, particularly to international developers. As an alternative, manufacturing a purpose-built off-the-shelf device also interested many of CUWN’s international wireless contacts. One goal of this major upgrade is to port over the routing code and eventually turn desktop PCs and hand-held devices into mesh nodes.
Bandwidth Shaping: One of the primary concerns is to protect the precious (and expensive) Internet bandwidth on a shared VSAT (or other Internet connection), which is a primary communications conduit in many developing countries. One possibility is to bootstrap the captive portal software at the network edges. Packets sent to/from the Internet from/to a mesh user can be blocked or strictly rate-limited until the user enters a valid login and password into the portal. The portal “speaks” HTTP over SSL. Since it would be unwise to rely on UDP flows to reliably throttle back, even if they are limited, one solution would require putting UDP filtering/shaping on the mesh nodes.
Posted 8 September 2006
