OT: community wireless (was virtual ifs / WDS)

On Fri, Apr 18, 2003 at 02:14:06PM -0400, Miles Nordin wrote:
>     cs> To help with mesh networking
> 
> huh?
> 
> First of all, it's kind of a sore point to me that you community
> wireless folk have been mindblowingly unable to come up with even the
> start of a mesh routing protocol.

  Miles, maybe you are entitled to be "sore" at community wireless.
  It does appear sometimes that it is only hype, doesn't it?  But let
  me tell you a different perspective.

  The idea of community wireless has captured a lot of people's
  imagination, and as usual there are many more people who are excited
  than who have the spare time or the skills to participate in "unwiring"
  their community. Many of those without skills or spare time use
  mailing lists as an outlet for their excitement. Their forecasts for
  community wireless are unreasonable, but they still set the standard
  for the builders to live up to because they are so out-spoken. A lot
  of people are dismissive of or "sore at" community wireless because
  it does not meet standards set by its armchair boosters.

  I think that groups such as Seattle Wireless, BARWN, and (dare I plug
  my own project) C-U Wireless are making pretty good progress for the
  numbers of volunteer hours spent and for the modest capabilities of
  802.11 radios.

  Regarding "mesh networking": it is not at all clear to me what qualifies
  a network as a "mesh," but sometimes people call "mesh routing" the
  routing you do in a radio network that is formed spontaneously (it is
  "ad hoc") and which supports mobility of clients or routers or both.
  Sometimes a network is called "mesh" if it is multihomed, or if it
  uses multiple paths to the same destination. If community wireless has
  been "mindblowingly unable" to come up with a mesh routing protocol,
  it is because mesh routing is a goal that is mindblowingly irrelevant,
  mindblowingly complicated, or mindblowingly indistinct.

  Also, why would "community wireless" bother to come up with a new mesh
  routing algorithm when we already have mindblowingly many to choose
  from? =) Depending what qualifications you choose for "mesh," there are
  several corporate and academic researchers producing algorithms which go
  by the names DSR, AODV, DSDV, TBRPF, MobileMesh, GPSR, ZRP, and so on?

  I question whether any of those protocols solve the problems community
  wireless networks deal with today. In fact, it is not clear that any
  of those protocols solve *any* network's real problems, and you can hear
  some noises to that affect in the IETF's working group on mobile and
  ad hoc networks.

  The network I am working on uses boring old OSPF in its
  point-to-multipoint mode, which helps us achieve some semblance of an
  "ad hoc" network (the only kind of network that I think can "scale"
  when you rely on volunteers for setup and administration).  I think
  that Seattle Wireless uses OSPF in a different configuration. IIRC,
  some of the folks with consume.net are using OSPF, also.

  Incidentally, the LocustWorld distro of Linux has adopted AODV, and
  the Kingsbridge network in UK uses it. I am curious at what size the
  performance of an ad hoc, rooftop-to-rooftop network built with AODV
  departs from the performance of an OSPF network of the same size, and
  also in which direction, so I have enlisted somebody to port HUT-AODV
  to NetBSD. Maybe by the time he finishes, we will have enough stations
  in Urbana to make a reasonable test.

> Second, how does *removing* support for sta *help* mesh routing?

  It doesn't. Sta is useful for WISPs, community wireless, and "the
  enterprise."

> Providing wds-only means if you want regular
> bridge-like functionality, both endpoints have to be APs.  This is an
> arbitrary and harmful constraint.

  Miles, it is not an arbitrary constraint that a STA cannot act
  as a bridge.  Moreover, sta(4) is not intended to address this
  concern. Consider the 802.11 spec and the design of present 802.11
  radios, and you will see why STAs will not bridge.

> 2. other things are settable per-station, such as transmit power and
>    IP address.  or are these things irrelevant in a community wireless
>    setting, too?  It seems to me that assigning stations individual IP
>    addresses, or moving them between two bridges, would blend very
>    nicely with your captive portal strategies.

  I think that transmit power control will be relevant when a block is
  packed with stations. Just how relevant, we will see.  Possibly 802.11
  MAC is no good for very dense community networks at any transmit power.

Dave

-- 
David Young             OJC Technologies
[email protected]      Urbana, IL * (217) 278-3933
--
*bsd wireless list, a bawug thing <http://www.bawug.org/>
[un]subscribe: http://lists.bawug.org/mailman/listinfo/bsd-wireless/