[UFO Chicago] Building tops...

[Thomas Binney]

--Apple-Mail-2114016573-1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii

I've already mentioned the building I have access to (for the record and 
for the map, 5560 Northwest Hwy.) and my company uses ADSL running at 
roughly 768 depending on which way the wind blows... but being a 
business, obviously the business has to come first so i have to make 
sure plenty of my bandwidth is kept open.  But I assume it'd be no 
problem to limit what remote users have access to right?  So I would 
gladly set aside 128k during business hours (for us roughly 7am - 6pm) 
and then jump that up to 640k or so between 6pm and 7am.   And perhaps 
we could get other businesses to donate more bandwidth during none peak 
(for them) hours?  If any of this makes sense... I'm a little brain 
drained at the moment.

Peter, how about putting a jpeg (or equiv) map of the city with markers 
for building we know we can get and another color mark for buildings we 
may be able to get and another to mark areas we need to get to fill in 
the holes in the network?  I don't know how much space you have on your 
server for something like that... if it's too much I may be able to do 
something like that (with your help) on a machine at my work.

Ok... enough me babble... go now... ugh...

Tom

Quoting Nate, possibly out of context:

While I'm on the subject (sort of), I'd like to present what I am
currently thinking about architechture.  Personally, I like the Seattle
Wireless version of community networking more than the Consume.net
version.  It is a lot more clearly stated and planned, I think.

The Consume.net architecture is simply an agreggation of individual
"peering agreements" between nodes (people with antennas and gear and
roofs (rooves? whatever)).  There are no guidelines for creating
point-to-point links and no central authority to do important things like
allocate address space and make static routing decisions.

The Seattle Wireless project defines four basic classes of nodes.  A
client node is a machine that wants to connect to the network.  A "C" 
node
has a local cell which services client nodes and a directional pointed to
an "A" or "B" for upstream connectivity.  A "B" node has directionals
pointed to other nodes and can perform some intelligent routing.  An "A"
node is basically a "B" node with a land line to the Internet.

I'm not completely satisfied with the Seattle Wireless model, but I think
they've got a wonderful starting point.  Here's how I would suggest we
define the network structure:

1) "D" nodes have computers that want a connection (wireless or
otherwise, but for the most part wireless).
2) "C" nodes provide a local cell that services wireless "D" nodes.
3) "B" nodes have wireless point-to-point links to other nodes.
4) "A" nodes have connectivity to an outside network (wireless or
otherwise).

Of course, most nodes are combinations.  Here are some examples... When I
was at DePaul, I had an "A/D" node, just like most of you have now 
(think:
site with a computer connected to the Internet).  Last week I had a "D"
node (a site with computers wanting a connection).  With the Linksys swag
I picked up on Thursday, I currently operate a "C/D" node (a site with
computers wanting a connection and a cell for "D" nodes).  When I get
broadband, I will have an "A/C/D" node, and hence UFO's first operational
cell (I think the criterion for calling a cell operational is when
wireless "D" nodes can read Slashdot).  When I start aiming directionals
at other nodes, I will have an "A/B/C/D" node.

I think over the long term, the node types that need the most attention
are "A-" nodes and the "B/C" node.  "A" nodes are by definition going to
cost a non-trivial amount of money to operate.  The outside connections
should be at least 128K/128K, which means ISDN and faster, and that's 
just
not something we can have installed willy-nilly all over the city like
Ameritech does.

"B/C" nodes are where the interesting engineering will happen.  These
little monsters should be our bread and butter.  They should be cheap,
small, self-contained, and low-maintainance packages that we can install
on a rooftop and basically forget about.  I think that it's the "B/C"
nodes that will get us coverage.

Now, about those T1's... they're reliable, they come with flexible terms
of use, and they're plenty fast, but they ain't cheap.  And that is the
sticking point.  At this point, our best source of T1's is probably by
donation from existing T1 users.

My $0.02.  Please add yours.  (And I'll keep that T1 offer in the back of
my mind).

-Nate
UFO CEWST


--Apple-Mail-2114016573-1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=us-ascii

I've already mentioned the building I have access to (for the record
and for the map, 5560 Northwest Hwy.) and my company uses ADSL running
at roughly 768 depending on which way the wind blows... but being a
business, obviously the business has to come first so i have to make
sure plenty of my bandwidth is kept open.  But I assume it'd be no
problem to limit what remote users have access to right?  So I would
gladly set aside 128k during business hours (for us roughly 7am - 6pm)
and then jump that up to 640k or so between 6pm and 7am.   And perhaps
we could get other businesses to donate more bandwidth during none
peak (for them) hours?  If any of this makes sense... I'm a little
brain drained at the moment.


Peter, how about putting a jpeg (or equiv) map of the city with
markers for building we know we can get and another color mark for
buildings we may be able to get and another to mark areas we need to
get to fill in the holes in the network?  I don't know how much space
you have on your server for something like that... if it's too much I
may be able to do something like that (with your help) on a machine at
my work.


Ok... enough me babble... go now... ugh...


Tom


Quoting Nate, possibly out of context:


<color><param>0000,0000,DEDE</param>While I'm on the subject (sort
of), I'd like to present what I am

currently thinking about architechture.  Personally, I like the Seattle

Wireless version of community networking more than the Consume.net

version.  It is a lot more clearly stated and planned, I think.


The Consume.net architecture is simply an agreggation of individual

"peering agreements" between nodes (people with antennas and gear and

roofs (rooves? whatever)).  There are no guidelines for creating

point-to-point links and no central authority to do important things
like

allocate address space and make static routing decisions.


The Seattle Wireless project defines four basic classes of nodes.  A

client node is a machine that wants to connect to the network.  A "C"
node

has a local cell which services client nodes and a directional pointed
to

an "A" or "B" for upstream connectivity.  A "B" node has directionals

pointed to other nodes and can perform some intelligent routing.  An
"A"

node is basically a "B" node with a land line to the Internet.


I'm not completely satisfied with the Seattle Wireless model, but I
think

they've got a wonderful starting point.  Here's how I would suggest we

define the network structure:


1) "D" nodes have computers that want a connection (wireless or

otherwise, but for the most part wireless).

2) "C" nodes provide a local cell that services wireless "D" nodes.

3) "B" nodes have wireless point-to-point links to other nodes.

4) "A" nodes have connectivity to an outside network (wireless or

otherwise).


Of course, most nodes are combinations.  Here are some examples...
When I

was at DePaul, I had an "A/D" node, just like most of you have now
(think:

site with a computer connected to the Internet).  Last week I had a "D"

node (a site with computers wanting a connection).  With the Linksys
swag

I picked up on Thursday, I currently operate a "C/D" node (a site with

computers wanting a connection and a cell for "D" nodes).  When I get

broadband, I will have an "A/C/D" node, and hence UFO's first
operational

cell (I think the criterion for calling a cell operational is when

wireless "D" nodes can read Slashdot).  When I start aiming
directionals

at other nodes, I will have an "A/B/C/D" node.


I think over the long term, the node types that need the most attention

are "A-" nodes and the "B/C" node.  "A" nodes are by definition going
to

cost a non-trivial amount of money to operate.  The outside connections

should be at least 128K/128K, which means ISDN and faster, and that's
just

not something we can have installed willy-nilly all over the city like

Ameritech does.


"B/C" nodes are where the interesting engineering will happen.  These

little monsters should be our bread and butter.  They should be cheap,

small, self-contained, and low-maintainance packages that we can
install

on a rooftop and basically forget about.  I think that it's the "B/C"

nodes that will get us coverage.


Now, about those T1's... they're reliable, they come with flexible
terms

of use, and they're plenty fast, but they ain't cheap.  And that is the

sticking point.  At this point, our best source of T1's is probably by

donation from existing T1 users.


My $0.02.  Please add yours.  (And I'll keep that T1 offer in the back
of

my mind).


-Nate

UFO CEWST

</color>


--Apple-Mail-2114016573-1--