[MLB-WIRELESS] Applications on the melb-wireless network

[Toliman]

----- Original Message -----
From: "Ben Anderson" <a_neb at optushome.com.au>
To: "Will Lotto" <lotto at impulse.net.au>; <melbwireless at wireless.org.au>
Sent: Tuesday, March 19, 2002 12:49 AM
Subject: Re: [MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless
structure


> I disagree with this as a "structure" as it's backbone based, and won't
> scale to more than a few of handfuls of nodes.
> For it to have any chance of scaling larger (both technically and
socially)
> each node has to be capable of routing for another node... thereby
building
> a large mesh, where one only has to be able to see one other node to
> communicate, though the better connected, the more 'useful' that node is
for
> the rest of the network.

yes. nodes should be carefully decided upon, cause the worst thing will be
to flood a small area with nodes, while some areas are km's away from
coverage. a ~$2500 solar powered independent AP is not a easy thing to
finance or install without serious thought. given enough people can obtain
wireless hardware and antenna setups, we could string together a very tight
backbone around the CBD, and later provide network applications and services
for the 'core' backbone. but unless coverage can be spread out, the best
thing for everyone is to start the mesh off small, and use
ad-hoc/infrastructure that works until the network can route traffic in a
bigger way. lots of little steps.

of course, whatever pans out, it would be nice to see node-owners and
operators in the committee in some form, because they will be providing the
network for others. but it's not a given.

> Some people have brought up the fact that people on 'edges' will get
> discriminated against by getting poorer access because they're not
> transferring others data....

the fact is, theres two things that will determine access for the great
majority of wireless users. geography and residential location. affluent
areas will have better access, since people in those areas can afford
wireless hardware. for example, how many AP's are you willing to invest in
and set up to get access to an area where you don't live ?

>   One potential thing could be other services,
> hosting, data, etc, but since the network is primarily about transferring
> data, I suspect that it's going to have to be a consequence to get it to
> scale.  Unless someone else has an idea to bypass this limitation?  (I
> purposfully built in this 'leaf node discrimination' to prevent leaf nodes
> logging on and doing nothing but sucking down high bandwidth apps off the
> network (mp3, warez, movies, etc).

yes, the intranet mesh is a shared resource, if you want to suggest
applications for the network, the Wikiboard is the best place to do this.
That way people can dissect and critique individual parts of the idea. Yes
..  Setting up the "World Wide Warez" network or mojonation, freenet, a p2p
network is a grand application of the network :P

better applications would be setting up intranet apps for Chat, Instant
Messaging, gaming, organising events, streaming & multicasting data across
the network i.e. a 200kbit multicasting video stream, turn the mesh into a
streaming radio service.

one example i can think of that was popular during the sydney 2000 olympics
was an LCD viewscreen that was distributed to stores and hotels in the CBD
of sydney, which relayed events and medal tallies in live updates via a
broadcast network. Thats 1 possible application there.

> Also, to prevent lots of bandwidth being wasted doing network discovery as
> in OSPF, or mobilemesh, I'm proposing a networking scheme that relates to
> physical location....  This has privacy concerns, but so far I've not come
> up with any reasonable alternatives that don't have a central
administrative
> overhead that limits the scalability of the network.  So for example, to
get
> a packet to a device, you need to know it's gps co-ordinates.  I'm
proposing
> a network layer implimentation of this so tcp/udp apps can still be run
over
> the top of it.  Intelligent caching, even perhaps a 'dns' style node
> location system may be useful in producing a "nasty hack" version of what
> i'm talking about using current networking stacks...

my mind boggles as to how this would be implemented.
example.  Point A in broadmeadows would log on and just "assume" that the
route and all the nodes between essendon and mornington was clear and
active, based on an encrypted internal network transmission responding to
Point A that the route to mornington existed, just keep sending megs of
encrypted data down the line.. i did read the paragraph and i'm lost. please
explain how someone would send data to a person on the network from
broadmeadows to mornington using the 802.11b network.

there is a reason why OSPF, RIP, RSPF and mobile mesh have to 'discover' the
network, primarily because every link on every route is not 100% reliable.
nor are there multiple routes between nodes. the route traffic is not
excessive, nor is it unsafe to 'leak' routing info since it's a public
network.

GPS proves useful for once-off location, but since it has no bearing on
signal strength or capacity, i don't initially see how data obtained could
be used by any function of the 802.11b infrastructure, i also don't see an
application of knowing the precise global position of your node apart from
the egocentric. even if you were to have a mobile location such as a car,
the odds re that signal strength will be automatically detected by the
omnidirectional on the car, and will vary wildly.

> Encryption in this network would be a very high priority, to prevent nodes
> from intercepting traffic, and modifying it unknown.  For example, a
> commercial entity could setup a load of nodes, and use it to insert spam
> randomly into all our traffic....  With encryption, that dissappears.  And
> it also removes some of (but not all) the privacy concerns.  Encryption
> isn't really a "hard" problem based on the ready-made libraries that
> exist...  The routing protocol, and actually getting it working (and then
> getting it working on win* platforms...  (I don't even want to _think_
about
> a network layer win32 app, let alone build one))

a secure tunnel can be created for any applications you don't want anyone to
eavesdrop on, infact i would only chat or talk using something like
PGP-phone on the wireless network, since it would be kind of embarassing to
have someone running ethereal or snort picking up bits of a conversation
over an AP/bridge and piecing it together. The best practical security is
being open enough to let others see what you want them to see. and obscuring
the things you don't want them to see.

network abuse can be stopped without resorting to a tunnelled routing
network. all it requires is some arbiter of bandwidth on the network, maybe
a simplified, agreed upon QoS / traffic shaping protocol that runs on the
nodes to prevent thrashing of routed network traffic or abuse of the routed
network, but allows nodes to manage each area's data traffic. so someone in
the same suburb can get 500kb to another node user, but can't send more than
200kb/sec along the routed network unless it's not busy. or possibly even
less traffic is shared. that way it's a true shared resource, with some
applications receivieng more traffic than others. even at 1mbit, its still
faster than other communications mediums.

as before, this is an application discussion, not a network protocol one. if
a encrypted network could be more reliable than WEP, be more efficient in
implementation, be easily implemented with hardware AP's or prism2 // linux
boxes in weatherproof locations, and cheaper than an AP, cheap enough so
that people could sponsor nodes for areas they don't live in, then it would
be great. in fact, it would accelerate the growth of the mebourne mesh
immensely.


at least, thats my opinion.
Toliman.



--
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