[MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless structure

[Ben Anderson]

Firstoff, thanks for your comments...

> -->"Ben" == Ben Anderson <a_neb at optushome.com.au> writes:
>
>   >> From what I'm reading, the basic proposed structure for nodes is
>   >> you have one (or two) directional antennas, to connect you to the
>   >> rest of the network, and one omni so people can connect to you.
>
>   Ben> I disagree with this as a "structure" as it's backbone based,
>   Ben> and won't scale to more than a few of handfuls of nodes.
>
> a backbone-based architecture works just fine for the multiple
> millions of nodes on the wired internet, so i tend to treat claims of
> it lacking scalability with some caution.

Yes, and the internet also has **lots** of money spent on actually
developing faster, and faster switchs....  this is one of the reasons people
don't understand where the "13c/mb" goes -- this cutting edge tech for the
backbone isn't cheap.  If we want to scale it to "melbourne sized" with
thousands of nodes, 11mbit backbones are going to wind up leaving basically
nothing for anybody.  It's fine for handfuls of people, but get into the
hudreds through to thousands plus, and are people really going to be happy
with a 4kbit/sec WAN?
If we were to adopt a fully formal structure, and actually pay subscriptions
etc, we could roll out a high bandwidth backboned network...  I suspect this
will be fought against tooth and nail by a lot of people (again, there's
that "social scalability" factor).  And then the carrier licence becomes
part of the cost, then peering costs, etc etc -- we wind up where it'd
probably be cheaper to get on the (subsidised) optus network...


> personally, i think that a combination of an omni antenna for local
> (ie, few hundreds of metres) client access (and incoming links?), and
> a couple of directional antennae for meshing (outgoing?) sounds like a
> fine step in evolving the network.

I agree.  Fine step.  But that's all it is.  I have serious doubts you can
make this scale technically, financially, socially, etc.  I'm looking "long
term" -- ie what I ultimatly think it should look like to "just work" -- ie
ubiquitous public network.


> i guess it's possible that we'll reach a stage where the density of
> nodes means that directional antennae are no longer required, but i
> suspect this is several years off ...

Yes, potentially.  Though suppose that people could go and buy a black box
at kmart for 300 bucks, that gave them access to a public network, just plug
it in your ethernet card -- I suspect the network could go **BOOM**.  And it
could happen virtually overnight.  Again, this relies on the routing,
network structure, etc, to be defined well enough to be able to cope with
half a million users turning on a wifi card overnight -- the "omni antenna
for local... and a couple of directional antennae..." solution is unlikely
to be able to deal with scenario -- ever.


>   Ben> And to encourage this 'better connectedness' I've been
>   Ben> proposing (and hoping for comments) a "mojonation" like setup,
>   Ben> where the more traffic that gets transferred through your
>   Ben> system, the more "mojo" you have to spend on routing traffic
>   Ben> through other systems...
>
> hmmm.  i have a couple of immediate questions about the detail of how
> this could work:
>
> how does a router decide whether a packet should be forwarded (or
> dropped) and where it should be sent?

Packets should be queued always.  Packets with the most mojo being 'spent'
on this hop (for example, as one metric that could be used -- lots more
analysis and simulation would be very useful on different schemes for
load-ballencing) get ordered at the front of the queue.  Packets that drop
off the end of the queue get dropped.  And the addressing scheme, the only
realistic one that scales well that I've come up with is one based on
physical location (for example, gps co-ordinates could be used).  The packet
gets sent out the interface 'most in the direction of the destination
co-ordinates' -- and yes, this scheme still allows shortcuts across the netw
ork, simply by defining the gps co-ordinates of the destination...  for
connection based protocols (ie tcp) one could utilise state information in
the connection to optimise the route as more data goes through it to find
the shortest route.  ie going from a-b-c-d mightn't be the quickest, it
might go a-e-d as the quickest, but A's 'destination node' address for b is
closer physically to d than e is, so that would be an inefficiency --
there's no 'cost' metric built into the interfaces as I've defined them so
far, so this would be a useful thing to add -- though how to add it
network-wide without saturating the network with route-update broadcasts...

> what does "premium" service actually mean?  extra volume?  higher
> priority?  more direct (lower cost?) routes?

Whatever's the most valuable.  As it gets large, low latency, long distance
are going to be the most valuable (encouraging people to try and extract
more mojo from the network by building a shortcut across the network,
encouraging traffic across it, and therefore earning more 'mojo' to spend on
their own data...  This serves two purposes -- overloaded links are
expensive, limiting their use, keeping them useable, and encouraging more
network bandwidth to be built to help them extract more from the network
themselves.
Lower cost routes make sense to take all the time.  Higher priority --
someone spending mojo (ie they've actually contributed building network
infrastructure, and it is popular, and in use) should inherantly have more
"right" as such to access the network themselves, while a leaf-node leecher
should get only what's left over after the people who paid time and money to
set the infrastructure up have finished.  ie nobody gets cut off, the
latency of the link goes up as does packet loss (as routers run out of
memory to maintain a queue).
There's lots of simulation that could be done to develop better metrics to
more optimally encourage network growth and limit bandwidth overuse, I'm
sure...  this isn't finished, it's only just starting, remember :)

> are packets charged to their originating node or the previous
> forwarder?  how do you prevent spoofing of packet "owner"?  does this
> penalise "good" services like proxies?

I believe that every packet needs to be encrypted.  And using digital
signatures, it makes it very difficult to spoof packets.  And proxy's should
be rewarded with mojo, as it's a beneficial service to the infrastructure of
the network.  I'd like to keep away from calling it mojo if I could, as it's
sorta already taken.... Anyone got an idea for a name?


>   Ben> Also, to prevent lots of bandwidth being wasted doing network
>   Ben> discovery as in OSPF, or mobilemesh, I'm proposing a networking
>   Ben> scheme that relates to physical location....
>
> i'd be surprised if routing protocol overhead was a significant
> fraction of the network traffic?

Ok, for mobilemesh, if there's a routing update because a laptop has moved
between 'section a' and 'section b' that change gets propegated
broadcast-wise to the edge of the network that can actually address, and see
that laptop.  Ie if everyone on the network is to see everyone else, then
that routing update goes **everywhere**.  Imagine an australia-wide 10mbit
ethernet segment...  Have you ever watched a broadcast storm?  This will be
an order of magnitude worse.  The overheads are significant for 'discovered'
networks.


>   Ben> Encryption in this network would be a very high priority, to
>   Ben> prevent nodes from intercepting traffic, and modifying it
>   Ben> unknown.
>
> are you thinking about something other than IPSEC or ssh here?

I wanted it at the network layer, along with all these other goodies so that
tcp and udp application layers don't know the difference.


>   Ben> Ideally, I'd like to have a pll, a mixer, a big, high-bandwidth
>   Ben> DAC/ADC and a dsp/fpga combo to impliment a lot of different
>   Ben> modulation techniques (ie the closer you are, the more
>   Ben> wideband, spread spectrum high bandwidth protocol you use.
>
> sounds good!  let me know when i can get one for under A$500 ;-)

Theoretically (!) they're already available for somewhere around that
price...  No software mind you, just a pci board with lotsa nuts on it...
they've been made for years...  I'm trying to get demos/samples ATM for
another job.  I will let you know when I've got them in my hands, ready to
start developing on.  Do you have knowledge of verilog or vhdl?

>   Ben> Yes, I know I've written about this before, but last time I
>   Ben> mixed it up with the 'committee' stuff, and it seems the tech
>   Ben> detail got confused...
>
> not confused, just deleted ;-)

hehehe ;)  Looks like it got through this time :)

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