[MLB-WIRELESS] GHO ----- UPDATE!

[Ryan Abbenhuys]

Dan, you're spot on the money.

Eventually to maintain any usefulness they need to be restricted to around
3 connections each and used to link the large clusters together via a
nominated node in each cluster.

Each nominated uplink node should not be propogating their entire route
table but rather aggregating their routes and propogating only a couple
that will cover everyone in their cluster.  ie, 10.10.128.0 with a mask of
255.255.254.0 (/23) which would cover 10.10.128.1 right through to
10.10.129.254

This is done to prevent unnecesary routing traffic.  A node in RGsouthern
doesn't really need to know about each individual nodes status in
RGInnerNorth, they only need to know how to get to the entire cluster of
InnerNorth.  If the particular node is down, their pings timeout after they
get as far as they can.

Sure it gives you a warm a fuzzy feeling to see a nice big route list but
technically you want the opposite of that. You want the smallest route list
you can get and this is what route aggregation is for.

The next thing to look at is those backbone uplink nodes should setup some
simply QoS.  QoS tags won't be that useful because not everyone is going to
be reading/supporting them so your best option is to queue packets based on
port numbers.  For example give high priorities to ports for gaming, chat,
telnet, etc that want low latency and give ports for http, ftp, etc a low
priority.

...however before a lot of this happens the IP allocation system needs a
complete overhaul or you're in for a painful surprise further down the
track.
This is something I unsuccessfully tried to campaign for. :-\


>> -----Original Message-----
>> From: owner-melbwireless at wireless.org.au [mailto:owner-
>> melbwireless at wireless.org.au] On Behalf Of Ryan Abbenhuys
>
>
>> Are you guys still not familiar with the term "backbone"?
>> 
>> After 4 or more people connect to any AP I guarantee you'll be better
off
>> using dialup modem links.
>
>Ryan, what would you suggest for GHO?  Are three 2.4GHz interfaces - each
on
>a different channel serving a different area - not an improvement over a
>single interface?  A 5.8GHz interface is also planned.  At the moment the
>idea is to allow people to connect from wherever they can to do signal
>strength and data rate testing.  We should also start experimenting with
>network Quality-of-Service (QoS) applications and be measuring their
>usefulness.
>
>FYI, as of this writing:
>
>GHO-North has two OSPF clients:
>10.10.129.3 Node GWS - nice webpage and propagating 13 /28 subnets!
>                     - also propagating 127.0.0.1.  Naughty!
>10.10.129.4 Node IKD - no webpage and is propagating 192.168.20.0/24
>                     - and 192.168.60.0/24 onto the network.  Naughty!
>                     - nice work on the long link though. :)
>
>GHO-South also has two OSPF clients:
>10.10.130.178 Node GES - propagating 4 /28 subnet, a /30 and a nice
>                         webpage
>10.10.130.180 Node FKR - propagating 3 /28 subnets. (no webpage on the
>                         router)
>
>GHO-Mobile has one OSPF client:
>10.10.131.70 - Node FUT - propagating 3 /28 subnets and a nice webpage
>
>Running ARP on the GHO router reveals no other clients connected at all.
>
>Of course, too many clients on any one AP will cause it to slow right down
>with hidden-node problems - negating GHO's usefulness.  So I believe the
>longer-term plan is to work out who are the best candidate nodes to retain
a
>permanent direct-link to GHO.  Once chosen, only they will be allowed
>access.  I would hope that the method used to choose these nodes is fair
and
>open, and provides the best technical outcome for the overall network.
>Perhaps some generally-agreed-upon official guidelines should be drawn up
so
>that everyone is clear on what is required to become a permanent client of
>Node GHO.  If we don't I can see GHO becoming a source of discontent and
>dissatisfaction once again.
>
>At this point I'd say that the most likely nodes to be allowed to retain a
>GHO connection are those who serve traffic to a cluster of Melbourne
>Wireless nodes.  GHO is too important to allow permanent leaf-node access,
>except maybe on the "GHO-Mobile" interface, or to providers of important
>content to the network.
>
>The point is important enough to be made again:
>For technical reasons, GHO cannot offer open-slather access if it is to be
>truly useful to the Melbourne Wireless network.  Just because you *can*
>connect to it doesn't necessarily mean you *should* connect to it.  If you
>can connect to a more local node, please do so.  If you can set up a
>multi-radio routing node in your area, even better!
>
>Cheers,
>
>Dan

To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message