OSI: Beyond the Scope

CUWiN Development Team
29 Jun 2004

This document contains development projects that are outside the scope of this OSI project. The estimates on this work are rough and many need further investigation before highly accurate estimates can be provided. In addition, while this OSI project focuses on solutions to known problems, many of the tasks below are to identify suspected problems facing wireless networks and then program the solutions -- which adds a sizable uncertainty factor to these estimates.

NOTE: This document was originally delivered at the time of the initial disbursement. Additions to this document that have arisen out of development to date can be found at the end of the document.

NOTE: All estimates are based upon a 30 person/hour workweek. Rates would be $50/hr or $1,500 person/week for programming; project coordination/management usually runs about 10-15% on top of this.

Multicast extension to HSLS. Enables the wireless network to be a much more efficient broadcast medium by adding multicast to HSLS.

ESTIMATE: 6 months research and programming.

Improve the routing metric for both unicast and multicast.

Take advantage of "advantaged" nodes for multicast. "Advantaged" nodes have several one-hop neighbors, so they are well-suited to disseminating multicast messages.

Address stability issues in ETX. We can anticipate that fewer multicast ETX probe packets will get through when the network is under load than when it is not, especially since the multicast packets are not protected like unicast packets are. (CWN has already noticed that OSPF Hellos will not get through when we do a big download on the network for this same reason.)

ESTIMATE: 2-3 weeks to stabilize ETX by augmenting the ETX probe packets by tapping neighbors' data packets.

Security. There are problems establishing trust of the routing and forwarding functions. The problems are not well-understood. The solutions we have researched thus far and/or have been implemented by other Wireless ISPs have been inadequate -- Peter Folk (volo.net) and Greg Troxel (ir.bbn.com) seem to agree.

ESTIMATE: 1 year+ -- more research needed to identify solution and provide an estimate.

TCP: an in-vivo study of TCP on our network would need to be conducted before any specific work could be confidently proposed; however, research anticipates that loss via a wireless network would wreak havoc on TCP sessions. Also, initial research anticipates that when two or more TCP streams use the same 802.11b link simultaneously, one will dominate the available link bandwidth (which, for example, is bad when one user is streaming an MP3 over the same link where somebody is trying to surf the Web).

Proposal is to study TCP performance on the Community Wireless Network (CWN), and then seek funding fix identified problems.

ESTIMATE: A 6-week study of TCP on the CWN would provide adequate base-line information for determining the causes of stall on TCP streams. 2 aditional weeks would be needed to find the right free tools for doing the study -- an initial search by CWN for tools in 2003 yielded disappointing results.

Advanced antenna systems. The CWN has to share the band with a LOT of users, and the CWN makes links over greater distances than 802.11b was designed to cope with. To mitigate interference and to improve link margins, higher gain is desirable. To get higher gain while retaining the ad hoc nature of the network, it may be necessary to use multiple antennas or smart/adaptive antenna systems. We do not know of places selling smart/adaptive antennas to the public (yet), but it is possible to buy three sector antennas ($50-$100/ea.) and a computer-controllable RF switch ($150) to test out the concept while awaiting for the commercialization of this technology. The proposal is to build 3-5 such routers to test their utility within a CWN environment and study the feasibility of decreasing the price for these form factors.

Contingent on Atheros' support, CUWiN can try to use a feature of their newest 802.11a/b/g chips: antenna diversity on greater than 2 antennas. We may need to modify "consumer" cards or else to source "special" cards.

NOTE: for the Department of Defense, BBN Technologies has already studied HSLS with directional antennas. They produced a technical report which is on their web site.

ESTIMATE: [more research needed to identify solution and provide an estimate]

Kernel improvements. CUWiN would like to take advantage of new 802.11 radios' features, but it takes time to write device drivers for them.

ESTIMATE: 5-12 months' intensive work (depending on whether the device is especially complicated or the documentation is especially crummy).

Somewhat more important is improving the existing 802.11 framework to do a first-class rate adaptation to cope with changing link quality, especially "smartening it up" so that congestion is not confused with link degradation, and fragmenting packets to deal with frequency-hopping and microwave-oven interference. (CUWiN has already done some work in the link-adaptation area. See `rssadapt' in NetBSD.)

ESTIMATE: 1 week library research to find out how to cope intelligently with both frequency-hopping/microwave-oven interference and congestion. 7-10 weeks to design and program a solution.

We can take better advantage of the radios that NetBSD already supports if more of their features are exposed by the API. For example, transmit power control and carrier-sense thresholds. There are useful wireless statistics that are missing a useful API, also.

ESTIMATE: 1-2 weeks to implement the transmit power API that CWN designed in 2003 for both ADMtek and Realtek radios. 1-2 weeks to design and implement (for both ADMtek and Prism) a carrier-sense threshold API.

Transmit power control. CUWiN can increase the capacity of rooftop networks (and also be better radio citizens!) by unifying transmit-power control with the routing and link-adaptation functions. In one way or another, transmit power control really touches on everything mentioned above, from multicast routing to security to TCP to antenna systems to kernel features.

CUWiN developers have written on the topic of "virtual wireless interfaces" for 802.11 on a few mailing lists, and think that is the way to unify power control and link-adaptation with the routing layer.

ESTIMATE: 2 months to finish the design and program the feature.

Additional documentation, testing, and debugging time for internationalization of CUWiN.

ESTIMATE: [more research needed to identify solution and provide an estimate]

Marketing/outreach. Dissemination of software and networking with CUWiN host sites.

ESTIMATE: [more research needed to identify solution and provide an estimate]

CRITICAL. Capital campaign funding for Independent Media Center to buy a permanent home for the project and a stable location for Community Webhosting servers, T1, and future hosting of the CUWiN project offices.

ESTIMATE: $100000+ (could be a match for funding raised by the IMC)

Integration of open network solutions (e.g., Freenet -- http://freenet.sourceforge.net/) to ensure information freedom on CUWiN.

ESTIMATE: depends on implementation.

Audio/video streaming equipment to test applications of the network:

ESTIMATE: $5000

Router equipment to handle the increased bandwidth:

ESTIMATE: $3000

One year of additional T1 service:

ESTIMATE: $8000

Building of "streaming appliances" that automatically integrate with our network; programmer time to develop application level for the network.

ESTIMATE: [more research needed to identify solution and provide an estimate]

Travel funding for conferences for main project staff. CUWiN has no funding to support dissemination of research, networking, etc. at conferences. Funding is needed for 4-6 people to attend 2-3 national conferences and 1-2 international conferences. CUWiN staff have already had to turn down multiple invitations to conferences because of lack of travel funding. Example conferences include:

HSLS: Unidirectional links. HSLS will not always be used with the ETX metric. Unidirectional links should be distinguished from bidirectional links, as suggested in [1], p. 24. This is about six hours' work that it is reasonable to postpone: we have rarely seen unidirectional links in practice, and ETX will assign such links very high costs, essentially eliminating them from routing considerations.

HSLS: Database bootstrapping. Both the limited dissemination of HSLS link-state updates (LSUs), and the sequence-number techniques for detecting/discarding out-of-date LSUs, conspire to make an HSLS network assimilate new or rebooted routers slowly. Our protocol document tentatively described a new message type, the Database Synchronization Payload, and a complicated protocol for a new router to find out from its 1-hop neighbors which link-state advertisements (LSAs) are missing from its database---or else which LSAs are present with "out-of-date" sequence numbers---and to request the up-to-date LSAs.

This tentative synchronization protocol was inspired by the Database Exchange protocol used by OSPF.

Following an internal technical discussion, the complicated synchronization protocol has been discarded in favor of an uncomplicated protocol which both dispenses with the new Database Synchronization payload type (it is only necessary to add one field to LSU packets) and works better in the HSLS limited-dissemination regime. It will take approximately 18 hours to finish programming and debugging database bootstrapping: the data structures that support this work (see the LSU lists indexed by hop-count in the HSLS Address-Family Records, and the Bootstrap Records) are already finished. The remaining programming and debugging time will be dedicated to adapting the LSU generation and processing for bootstrapping.

HSLS: Jitter. Development of schedule randomizer for packets do keep them from colliding during transfer.

HSLS: LSU Acknowledgements. Development of a module that sends positive acknowlegements of LSUs from one node to another, and resends LSUs that aren't acknowleged.

ETX: Further Features. Our initial design was ambitious and included features that are not needed at this time. Implementation of these is incomplete. Their lack of exercise in no way inhibits the core functionality. These two features are: 1) A "suspension" mechanism that allows a node to pre-declare downtime (and expected return time), thus expediting adjustment of these metrics; and 2) An extension mechanism, of which there is no immediate need, but may ease interoperable deployment of future development.

Embedding community wireless networking into inexpensive APs. It is possible to make open-source network appliances for community networking out of inexpensive ($60-$100) wireless access points based on chips by Atheros and Realtek. These APs integrate all the same features as our testbed nodes for a fraction of the cost. (There are trade-offs: the memory is very tight.) We estimate six to nine man-months' work to make our software work on a $60 access point.