RequirementsDocument

Initial version 13 Aug 02 by ToddBoyle

Index (D R A F T!):

Introduction

Introduction

• Seattle Wireless Network is a specification for behaviors, which, if followed by Nodes, enables them to route TCP/IP traffic within the SWN domain, for example, across a metropolitan area.

Definitions:

• Seattle Wireless Network - a particular wireless network, meeting the requirements and definitions in this document. Community: a configuration of objects formed to meet an objective. The objective is expressed as a contract which specifies how the objective can be met. (ISO 10746) Member: (1) a person or organization who undertakes the costs and obligations to operate an SWN Node. Member: (2) a technical object which performs behaviors required by document, as elaborated by the SWN Specification. Community Network - similar to the Internet: a bunch of unrelated parties using protocols and cooperative behaviors to achieve a set of results. The community contract may be implied or explicit. Seattle Wireless Network is a "Community Wireless Network" but not the Internet.

Abstract Requirements

1. SURVIVAL - Any community must above all, survive by adding members faster than it loses members.

2. UTILITY - The SWN is a collaboration primarily to provide usefulness, i.e. to provide TCP/IP transport. (SWN also has social, educational, and research aspects.)

3. ATTRACTING MEMBERS - In a free society, members join in community contracts for reasons and motivations. A SWN node has nonzero costs. Members will not remain in SWN unless they perceive benefits in excess of those costs. The SWN must provide benefits to members. The benefit is TCP/IP transport (connectivity) to all of the other members of the SWN.
4. COMPETITION - TCP/IP transport is already available from many commercial providers, to every location in Seattle. Accordingly, it follows that SWN competes with alternative ISPs for members, attention, and resources, by comparative price and performance. SWN's problem domain is almost identical to the broader problem domain addressed by ISPs, and SWN can learn from them and applies many useful principles and solutions already developed by ISPs.
5. NETWORK EFFECT (Metcalf's law) - The value of a network is a geometric function of number of members. The value of SWN increases, and it becomes more competitive, by having larger numbers of members.
6. GROWTH - It is an intrinsic requirement of Seattle Wireless Network to grow very large, because otherwise, alternative networks have greater competitive value.
7. RIGOR of SPECIFICATION - The labor and attention of installation and maintenance are largest aggregate cost of SWN. Without precise specification and planning, these labor costs render SWN noncompetitive and nonviable.
8. ORGANIZATION and GOVERNANCE - these also impose great cost in time and attention on members, and must be highly efficient.

Requirements

Reference Implementation

• Seattle Wireless Network must be expressed in terms of one or more proven and tested reference implementations. A reference implementation is any reasonable combination of hardware and software that provides the AxNode, BxNode etc. defined in the Specification.

Reproduceable

• The SWN reference implementation must be reproduceable, a large number of Nodes. In other words, all devices used in a reference implementation must be available in large quantities and easy for new members to obtain.

Nontechnical users

• SWN must be installable and usable by people of ordinary skill levels. It must not require compiling kernels or knowing any programming language such as perl or C. It must be proven and tested sufficiently that it does not require technical skills or problem solving.

Ease of Installation

• SWN must achieve ease of installation in one of two ways: built into hardware, or , expressed into a complete installation package such as CDROM ISO, set of RPMs, TARs etc. which are capable of configuring every address, setting, security feature, etc. of a new node. Such configuration will minimize human entries.

Ease of Maintenance

• In principle, the SWN node must not require any maintenance. It must come up running after powering down, and must not require maintenance. The exception to this requirement is establishing relationships with adjacent nodes, at the time of installation.

Administrative Interface

• The SWN Node must have a user interface that provides in a single place or screen or script, wizard, etc. all of the configuration settings of the Node requiring manual configuration.

Scalability

• In principle, SWN network must not have built-in limitations on number of nodes. In fact because it is a closed network, it must be scalable to *at least* 100 nodes in order to reach viability. Your hotspots are of small size, and members will not support nodes unless there is mathematical likelihood of reaching significant destinations they desire.

Backbone

• Because nodes are controlled by other people they cannot be forced to stay online. And because this is unlicensed spectrum it cannot be forced to be reliable.

  A substantial portion of the SWN must consist of AxNode's and BxNode's, having multiple routes to other major nodes.

Reliability

• SWN must achieve something like 99% uptime in the long run, to ensure that members do not quit the network.

Speed

• SWN must provide at least 2Mbps at each link, and "broadband class" speeds at least 256Kbps from end to end, for most users, most of the time. (explanation: although most users on Internet are actually functioning below 56Kbps, SWN cannot become sufficiently valuable without broadband speeds, to cause a large enough adoption to become viable.)

Latency

• SWN must achieve low enough latency to support IP telephony and streaming multimedia, for multiple hops, much of the time. (explanation: SWN has consensus that merely transporting files such as by FTP, NNTP, SMTP, FidoNet, Gnutella etc. is not sufficiently valuable to cause a large enough adoption to become viable. See Utility and QoS outline

• Utility and QoS outline
  Application	Typ. BW (Mbps)	Acceptable Latency	Notes
  VoiceoverIP	0.01	250 ms	(suggest <100ms)
  Web surf	0.10	1 sec	-
  FTP transfer	1.0	5 sec	-
  LAN gaming	0.5	250 ms	(suggest <100ms)
  Email	0.01	5 sec	-
  videoconf	0.5	250 ms	(suggest <100ms)

Privacy

• Privacy of communications is a necessity for almost all users of Internet. Since there is no ubiquitous use of built-in privacy at the application level in today's email, browsers, etc., SWN must provide optional encryption (tunneling) at the infrastructure level (built into the nodes). The goal of this option is to maximize the success and efficiency of unskilled users bringing up an encrypted tunnel to another endpoint node of SWN. (THIS REQUIREMENT IS NOT ADOPTED AT THIS TIME BY MOST SWN DEVELOPERS.)

Uncoupled Hardware

• All nodes, including CxNode endpoints, should have separate devices for the host device and transport device(s). Transport devices include 802.11b access points, and other radios. The host device should have long service life, at least 5 years, in order to ensure continuity of the infrastructure and avoid having an "Installed base" where a large % of the network gets too entrenched on one particular transport or routing technology. Economic payoff of SeattleWireless depends on a long payback period than this years 802.11b, a, g, etc. We don't want to get immobilized, on 802.11b.

Local Wired Segment

• All nodes should include a separate, wired ethernet segment for local access to the SWN network, rather than providing access exclusively through the wireless interfaces. This reduces congestion on the wireless segment.

Security of Local Wired Segment

• The reference implementation of Bx, Cx, etc. nodes should prevent unauthorized wireless clients from accessing the host network.

Gateway

• All nodes MUST provide a gateway to the rest of the Seattle Wireless Network, upon request. All nodes SHOULD use Nocat for the gateway. Gateways SHOULD provide access to all visitors, at no cost.

Cutting off Connections

• A node MAY NOT break connections with or block packets from, a paid gateway without due cause. Due cause includes spamming, unauthorized intrusion into other systems, misconfigured router, or excessive resource consumption.

Charging for Network Resources

• A node MAY NOT impose charges for peering with other SWN nodes. A node MAY charge for Network Services, Application Services, or Internet Gateway Services. These are value add to the network and do not conflict with the spirit of free peering.