[MLB-WIRELESS] Meeting Structure? #%(^&!!

[Ben Anderson]

While I see merit in the short term benefits of creating such a structure to
create public infrastructure, the disadvantage is the high amounts of time
that people have to put in without compensation to make the system work in
any type of reliable way...  I think this leads to inherant scalability
problems as the system gets large...
One potential solution to the scalability problem is to use a system similar
to mojonation...  For example, as a wireless network grows in size, the
cross sectional bandwidth increases, but the end-end latency increases quite
swiftly.  So it would effectivly make sense to 'cost' more to transfer
low-latency traffic long distances (ie the more hops, the more expensive).
This means that people have incentive to _become_ more involved in the
network.  The geeks and leechers now instead of being able to sit off
passivly as leaf nodes doing nothing but snarf, have to actually do some
network engineering to get decent access (of course, if there's ever spare
bandwidth that's not "paid" for, it makes sense to fill this with
something -- and shared among leaf nodes I think is a nice altrustic use).
I don't think a monetary paid is a good thing in this system, as it will
hold the system back in scaling fast.  People can effectivly buy better
access to the wireless network simply by spending money on actually
improving the network, which should ensure the network scales.
An encryption layer is also important, as it means that commercial entities
can't then buy big pipes (causing them to be selected as 'defaults' based on
loading) and then do 'nasty stuff' like place ads in others traffic, or even
just take a copy.  Due to this, there's no reason to not want big companies
to partake in the network, as they effectivly improve the network for
everyone by buying an infrastructure to give them a certain level of
prioritisation on the network.
The more the network is overengineered (will wind up as a function of the
cost/bandwidth of the actual gear used) the more 'spare' will be left for th
e leaf nodes.

The biggest problem I've had with this type of network design is that
there's no real existing solution to deal with the problems we're trying to
deal with.  Mobilemesh is a reasonable idea, though it treats the _entire_
network as a broadcast zone, anything outside that broadcast zone, you can't
communicate with, as you don't know, and can't figure out a routing path to
the node (if I've understood the doc's correctly).  OSPF has problems in
that it's not designed for ad-hoc style networking, expecting some kind of
backbone type infrastructure.  This has the problem of not scaling (ie cross
sectional bandwidth isn't increased with adding nodes, as no load-sharing,
or alternate route discovery within a single AS occurs).  RSPF goes towards
solving this problem, though it's designed for slow networks and the network
discovery is still horizon based, though overall it looks like a much (much)
better option than OSPF.
A potentially better, though potentially more expensive for mobile units, is
the idea of routing based on physical location, either by way of carfully
allocating IP's, and rewriting a routing algorithm to select interfaces
based on that location.  With GPS's around the 200 buck mark (for screenless
models), this has potential.  Though that would only be necessary for
roaming units to be able to have packets routed to them from an originator
(if there's a connection that originated from the device, then the reverse
packet path can be infered from the outgoing packet path, assuming the links
are symmetrical).  This does add complexity, but shouldn't be prohibitive.
The GPS based units would need to have a home anyway, so another option is
to have the mobile device build it's routing map _as it roams_ -- though
this does not deal with a network that changes quickly and dynamically well
(ie it relies on more fixed than mobile nodes, which I think is bad, as it
then encourages 'service providing' homes, which then potentially removes
the control of the network out of the individuals comprising the network).
Building such a design I think probably makes sense to implement at a
network layer, though that pushs the project out of the realms of the
'average' user to help with the backend of making the system function, and
pushs it onto an individual, or a small group of individuals.  I have been
working on this myself for a while now, but I have very little spare time
thesedays.  (Some of the ideas I've been playing with are _very_ cool, but
sometimes a little far-fetched ;)

Anyone comfortable with network-layer protocol programming?  And on which
platforms?

I'm interested in comments, queries, etc.
Sorry if this has all been covered before (if it has, I think it needs
consolidation at least).

Cheers,
Ben.

> Whilst I don't post often, I think this topic is worth a bit of serious
> discussion. Not the meeting structure (never been to a meeting due to time
> constraints) but the comments about organisation. I have seen suggestions
> such as talk to Intel  / AMD about a donation to get XYZ going. I have
also
> seen comments about keeping the structure ad hoc. Both these comments have
> merit, however they are contradictory. This brings up the next point.
> Committee. The point of having a committee would be to provide a mechanism
> for descision making, a contact point, a group representitive, etc.
Although
> this does mean extra work, it is this type of organisation and sturcture
> which will provide the vehicle for growth, recognition, and eventually the
> possiblity of seeking donatations to the group from the likes of Intel.
>
> Money. It's something which is fundamental to the group. We now rely on
> donations to cover the cost of the hall, but who pays (and is out of
pocket)
> if the donations fall short of the hall costs, and if twice the costs are
> collected who pockets the extra? This again should be handled by a
structure
> headed by a committee of electees. When a club (or whatever)is formed and
> lead by a committee we have the possibility to open a bank account, and
> appoint a treasurer, keep a record of funds raised and spent for the good
of
> the group, etc. This removes the current liability of the individual who
> booked the hall for it's costs if nothing else. Another interesting point
is
> WHO is the group? Is there a membership list? If we wish to be recognised
by
> anyone for any purpose these characterisitcs of organisation are
> fundamental.
>
> I will admit to having a personal motive for making these points. I live
in
> Sunbury, which is largely in a valley, screened from Melbourne metro. In
> order to connect the 25 odd km to the metro area I see a need to have a
> stick on a pole, probably located in the Victoria University campus here
> which is located on the top of a local hill, great LOS to everywhere
around.
> This would effectively be a public node, and as such should be funded by
> those who benefit, IE the members of the group who live in the area. This
> will require the type of structure suggested above, so that VUT will
provide
> a roof, so that we can collect and manage funds toward the provision of a
> public point, etc.
>
> Over to you guys for a bit more thought & discussion.
>
> Bryce
>
> -----Original Message-----
> From: dwayne [mailto:dwayne at pobox.com]
> Sent: Friday, 15 March 2002 19:02
> To: melbourne wireless
> Subject: Re: [MLB-WIRELESS] Meeting Structure? #%(^&!!
>
>
> Tyson.Clugg at csiro.au wrote:
> >
> > Tee-hee-hee.... I got the response I was after.   So THAT's how this
group
> > started!  ;)
> yeah.
>
> Although there might have been other groups which merged with this in
which
> case *they* will have their own origin myths. Dunno.
>
> but that's how it looks to me.
>
> Dwayne
>
> --
> To unsubscribe, send mail to minordomo at wireless.org.au with a subject of
> 'unsubscribe melbwireless'
> Archive at:
> http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
> IRC at: au.austnet.org #melb-wireless
>
>
>
>
> --
> To unsubscribe, send mail to minordomo at wireless.org.au with a subject of
'unsubscribe melbwireless'
> Archive at:
http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
> IRC at: au.austnet.org #melb-wireless
>


--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless