[Cu-wireless] infrastructure and design [was: Are we making things too hard on ourselves]

[Paul Kennedy]

[
  I get the digest of the Cu-wireless list, so my remarks may be
  slightly out of date with any ongoing discussion.
]

Ben Freid <freid at uiuc.edu>remarked:
> I haven't made it to a cu-wireless meeting, but I have been actively 
> watching the mailing list.  Paul brings up some very important points of 
> creating a community wireless network.  Follow-ups to his message have 
> mostly been about routing protocols, but as Stephane points out,
>  > ...a discussion on how the "real thing" would work started a few times 
> but didn't conclude because ...
>  > ...different people have different ideas of what the objectives are....
> 

I would like to attend the meetings myself, but unfortunately,
I tend to use the weekend as a reservoir for the time needed
for my week.  Hence, I don't usually make it.  Details of what
is happening in the wireless project don't always make it to
the list, and as it is my only real window into the project, I
think that it would be good to get some of these opinions (that
people are preesenting at the meetings) onto the mailing list.

I have an idea of the design objectives (and I'll make a case
for it below).  But first, a followup to one of Ben's remarks
in response to my "network with cycles" example.

> I would suggest a more loosely connected wireless network
> be designed.  Nodes with broadband Internet access could
> host wireless access for the immediate surrounding area.
> If any member without broadband access wishes to host a node,
> a single point-to-point link with another connected node
> should be sufficient.

Ben's suggestion of a more loosely connected wireless network
is most likely how we will start--there will be points of
connectivity that offer very localized (100 ft) wireless access.

The real problem, as I see it, is that we _cannot_ expect to
have a single connection to the Internet.   I think that the
point of the entire network is to get connectivity to people
so that they can access the Internet at large.  While we will
most likely have local information and content going back and
forth (I can see a lot of internal traffic going to groogroo
for one or to the IMC servers), I think we need to _design_
the system with the understanding that we will (if not now,
but eventually) have more than one connection to the Internet.

If we suppose the opposite case, the we will end up with a
network that looks like a tree.  This has some serious downsides:

    1. Single point of failure for the entire network (at the
       root of the tree).

    2. Network congestion will increase as we add nodes.
       Since TCP favours connections with lower round-trip-times,
       nodes further down the tree will necessarily get worse
       performance because of the inherent latency built into
       the tree structure.

    3. The network _will_ have to be upgraded to do reasonable
       routing at some point when there is another broadband
       connection to the wireless network.  If this is not done,
       then in order to make the routing work, we will have
       to essentially partition the wireless network into two
       (disconnected) wireless networks.  My opinion is that
       this doesn't make sense.

Quite generally, the overall design of the network is fairly
clear in the absence of financial constraints: a point-to-point
network with a single point of connection to the Internet is a
design doomed to eventual failure--we need a design that allows
cycles in our network graph for any sort of scalability.

I believe that the network infrastructure (and eventual wireless
backbone) should be the main concern and _not_ the end-user
wanting to browse the web (but I'll address the end-user in
a moment) for the following reasons:

    1.  It doesn't do us much good to have wireless connectivity
        between nodes if we can't talk to the outside.

    2.  Wireless "apartment nets" or rough equivalents should not
        be the end goal.  A bunch of these such networks do
        not make a coherent network that is able to cope with
        route failures (as we will have happen).

    3.  The end user _will_ want to surf the web, and grafting an
        "apartment network" to a backbone should be fairly
        trivial if the rest of the infrastructure is done
        properly.  We want this to scale nicely and not
        painfully.

My example network (shown below) is what we might have an a
mature wireless backbone.  We could have network trees hanging
off these nodes on the core network.  In the eventuality of
better wireless networking becoming available, we could deploy
faster connections amongst the nodes on the core networks,
and redistribute the former core equipment out to the leaf
networks--we would continue to have an easy upgrade path.


                        B-----C-----D---[Internet]
                       /      |      \
                      /       |       \
     [Internet]---- A         E--------F
                      \       |       /
                       \      |      /
                        G-----H-----J---[Internet]


Ben further remarks: 
> 1)  Routing of a network with cycles takes a lot of time and effort to make 
> sure all packets get to any Internet portal.  With nodes/routers being 
> maintained by a number of different people, having one corrupted node could 
> harm the entire network.

Starting out, I think that the core nodes on the wireless
network are going to need to be run by people capable of
administering them.  We will probably have to have some sort
of agreed upon policy for node management.  The last thing that
we need are turf wars.


> 2)  Creating a wireless network, as in the diagram, would require a large 
> amount of hardware.  

Agreed, as well as the remark about cost.  

So, here is my vision for "Stage one" of the wireless network.
I think that what we need to do is start out with an upstream
provider point (I've heard people talk about the broadband access
at the IMC).  From there we should probably consider a linear
structure which will serve as the rudiments of our core network:

  Internet--[IMC]---[A]---[B]---[C]

Nodes A and B will require two wireless cards for each edge of
the network to which they are connected.  


"Stage one+" should be the addition of a wireless access point
at any of A, B, or C that would allow users in the vicinity of
nodes A, B, and C to connect to the internet though the wireless
backbone and the IMC.  Required for stage one is a map of nodes
that are reasonably within line of sight as well as within range.

"Stage two" might be seeing from where we could branch from
(or extending) the linear backbone.


So, that's my take.  Other ideas?

Paul


-- 
Paul A. Kennedy    "I don't use VI unless I need to resort to 'paper tape'"
pakenned at uiuc.edu                                    --Brynnen Owen 98/9/11