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

[Ben Anderson]

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

Alternatly, one thing I've seen done before is a whole neighbourhood get
sold on the idea of high speed network access, and they ran fibre to **every
home** and installed gigabit hardware everywhere, and the whole cost of the
project was very comparable per house to broadband internet access for a
year (they co-operativly got bandwidth, which was included in that price).
Perhaps we should consider whether organising ourselves and spreading the
word, and getting whole neighbourhoods to run fibre around is a better, more
future-proof way of providing a UPN.


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

If there's "mojo" benefit in it, it's quite possible people will run around
installing nodes in 'troublespots' simply so they improve their own ability
to use the network, despite the 'node' not being near them, and not being
used directly by them...
People on broadband pay nearly a thousand dollars a year, sometimes probably
a lot more...  If we can scale the network, there's potentially a lot of
'money' available for scaling the network fast, in a big way.  I agree with
the "do what works now for fun" -- I'm trying to examine, plan for and start
developing solutions for what I hope will grow into a UPN.


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

I'm not sure you've understood what I'm saying.  I'm not suggesting any
application layer software, I'm trying to deal with low-level network layer
issues...


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

With a 'backbone' based network, you can forget pretty much all of those
except messaging, and chat, for a network of say 100nodes+
(think about 10mbit ethernet, where half the bandwidth is used already, and
it's half-duplex, with a chain of backbone nodes (still 10mbit, effectilvy
5) all trying to use the same, if not similar slabs of bandwidth in the
air...  It's going to fall over very quickly...  And with 100nodes, assuming
100% efficiency, in peak times, the network's back to under the speed of a
modem.  Now try and scale the network to a thousand nodes.

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

Sure, but that's small-fry stuff...  I'm trying to design a UPN here :)


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

The packet would be broadcast, a node closer than the source would
re-brodcast it.  The interface each node decides to send it out on depends
if the node has multiple interfaces of course...  Assuming for the moment
the network is purely a mesh, no shortcuts etc.  Because we know the
physical location where we're trying to move the packets, the nodes can
simply store & forward the packet closer and closer to it's actual
destination.  After the initial packet has 'worked' it's way through the
network, the routers have discovered a lot about the network through the
path where that packet travelled -- the packet will propegate, and any
'parallel channels' to that destination node will wind up discovered by
multiple received packets at the destination, which can then be sent back as
an ack, with then explicit routing details contained in the packet.
Connectionless services is more difficult, and it'd probably wind up looking
a lot like a 'network layer connection' and then a transport layer
connectionless protocol on the top.  Routers with more memory to store
topology obviously have more advantage, and in the 'ospf' or 'mobilemesh'
they need this memory anyway, so we're not spending anything we didn't have
to before anyway.
So to give you a general picture, the packet would be broadcast, and then
each cell in the rough direction of the destination cell would rebroadcast
the packet, and so on until it converges on the destination nodes GPS
co-ordinates.

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

Broadcasting the entire network topology to the entire network when there's
routing changes...  sheesh, the mind boggles.. We've only got 11meg...
It's not about the routing info that needs encrypting.... it's the payload.
It should be a default.


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

If you use GPS as the routing decision metric, mobile units would need to be
able to know where they are, and then also send info back to a known 'home
node' or a 'dns server' - just some repository where the actual current gps
co-ordinates of that device can be located.  This could be a good reason to
encrypt that particular data :)


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

Having it as default unencrypted is a problem in that there is a lot of data
that's being passed around between nodes, and we don't have 'carrier
licences' to protect us from the law... if someone sends kiddieporn through
your node, it's probable that you'll be considered personally responsible
for that data.  I'm not a lawyer, so I'm not 100%, but I'm pretty sure
that's how it works....  if everythings encrypted by default, when something
encrypted hits, with x and y's gps location, one can use that info to
extract a lot of information.  If however, the packet is encrypted by
default, and the network sends a lot of traffic for others around, it's
going to be very difficult to figure if x is talking to y, or if they are
just passing on someone elses data...  It's been tested somewhere, I forget
where...  but encrypted kiddie porn is not kiddieporn without the key to
unlock it.  So you can pass it around all you want until someone has a key
for it, and then it's illegal...  Again, I'm not 100%, and don't wan't to
test the theory, which is why I think we need a default encryption
library... Hell, it's only 11mbits, even 500Mbytes/sec isn't that hard to
encrypt in real-time thesedays...

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

I don't want tunnels.  I want the network layer to deal with all this.
Since the bandwidth is broadcast, you can't stop kiddies using a different
routing scheme and dropping the througput on 'our' public network
enormously.  And on what metric are you going to base this QoS -- how are
you going to decide who gets priority?
How are you proposing to manage said network -- it sounds like there's a lot
of manual configuration necessary for your solution (and I'm not confident
it will scale either).  I'm trying to keep everything automatic...

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

I never once talked about application layer...  Application layer routing?
Hell that sounds impossible (prove me wrong, show me it'll work... I'll buy
you a beer).

> at least, thats my opinion.
> Toliman.

Thanks for your opinion...  I'm not sure I've understood fully what you've
been talking about...   Respond to my responses, I'm just trying to figure
out which parts of this idea I have to do more design work on...  It seems
to work in my head, and on the simulations I've done...  it seems to all
work fine...  But I've probably left some things out of consideration, and
hopefully this peer-review will sort out if i'm just smoking good crack, or
actually on to something...

Ben.


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