[MLB-WIRELESS] meshing

[Tyson.Clugg at csiro.au]

I really do like the Seattle Wireless philosophy, the link posted by Drew is
particularly pertinent once again:
http://seattlewireless.net/index.cgi/PointToPoint

> > I have this impression, that somewhere in the back of our
> > collective, Melbwireless hivemind, we have these vague
> > thoughts that at some stage we are going to have a mesh
> > network.  By that I mean that nodes will be able to pass
> > packets along from one to the other, hippity-hopping their
> > way from one side of Melbourne to the other.
> 
> I don't have time right now to write a full response to this, 
> but I doubt
> this is such a wonderful goal to aspire to.
> 
> If person B is smack bang between persons A and C, they're 
> going to do a lot
> of packet forwarding. If person M is between persons A-L on 
> one side and N-Z
> on the other, they are going to be doing an *extreme* amount of packet
> forwarding.
> 
> I think that this kind of approach will quickly swamp the 
> geographically
> centralised nodes and cause their maintainers to lose interest - hey,
> wouldn't you do the same if you couldn't get a single packet 
> of your own
> out? Sure, you can use traffic shaping and a whole bunch of 
> QoS rules, but
> at the end of the day if you're forwarding heaps of traffic 
> for others and
> not getting much out of it yourself, you'll start to lose enthusiasm.
> 
> Contrast this with a backbone-style setup. I'm sure there are a few
> (dedicated? altruistic? bloody minded?) folk around who are 
> happy to run a
> few point-to-point links as a backbone and then hang other 
> branch nodes off
> them. The routing issues will have to be sorted out a little more
> thoroughly, but it will give us more overall bandwidth to 
> play with if we
> use a backbone-style topology.
> 
> > I think this is something we need to discuss if it is to be
> > a long-range goal for the network.  Maybe we can make
> > provisions in advance for this capability at geographically
> > significant sites. This would prevent us from investing in
> > unsuitable hardware, and cursing that choice down the road.
> 
> IMHO we're going to end up with two main types of nodes: 1) 
> leaf nodes and
> 2) everything else.
> 
> Leaf nodes could probably (quite happily) use a normal AP 
> plugged straight
> into an Ethernet hub to connect to a branch node with an 
> omni. Leaf nodes
> wouldn't need any kind of routing hardware or software - just 
> run them as an
> Ethernet bridge and all should be well. This is the simplest 
> way we can get
> other people involved - they only have to buy a single piece 
> of hardware, it
> comes in a box and they can just plug it in and connect.
> 
> Other nodes are going to have to handle a few more routing 
> issues and the
> odds are that we'll have to run a decent OS such as Linux or *BSD (no
> religious flames please) on the routing nodes.
> 
> Out of time - have to go. If anyone else has thoughts on the 
> matter, please
> yell out.
> 
> Regards,
> Andrew
> 
> 
> --------------------------------------
> Andrew Harcourt
> Telstra Research Laboratories
> 
> +61392536210 (office)
> +61409723311 (mobile)
> andrew.harcourt at team.telstra.com
> --------------------------------------
> 
> 
> 
> 
> --
> To unsubscribe, send mail to 
> minordomo at melbwireless.dyndns.org with a subject of 
> 'unsubscribe melbwireless'  
> Archive at: 
> http://melbwireless.dyndns.org/cgi-bin/minorweb.pl?A=LIST&L=me
lbwireless
IRC at: au.austnet.org #melb-wireless

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