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

[David Arnold]

-->"Ben" == Ben Anderson <a_neb at optushome.com.au> writes:

  >> Don't we first we need to have an actual network to plan long
  >> term for? Planning 3 years down the track is a bit pointless with
  >> the rate technology is advancing, something better will probably
  >> be out by then that solves all our problems in a little box (like
  >> the proprietary nokia rooftop router but non-proprietary) you can
  >> make/buy for $100.

  Ben> As far as I am aware, nobody is building this.  I would like to
  Ben> be the one to do so.

which is great, but i think we should be careful to separate
discussions of the now and then, in the interests of minimising
confusion.

this mail now dives into the "then" discussion ;-)

  Ben> As far as I see it, we can either have a 'mojo' like system, or
  Ben> have a "test" that people have to take before they get to use
  Ben> the network to guarantee that the people are altruistic enough
  Ben> to donate to the system when they don't have to.

the good thing about computers is that the ongoing costs are
negligible (in most cases).  so, once you have decided to invest the
cash in a spare machine, some cards and some antennae, i can't see too
many people bothering to turn the thing off at the wall when they're
not personally using it ...

i'm yet to be convinced that we need a charging regime, although i
accept that as bandwidth becomes constrained there will be issues for
those sites that are geographically in the pinch point.

consider a layout like a 2D hourglass, with a couple of nodes in the
neck.  intuitively, they're going to bear the brunt of the routing
burden, and will be constantly congested.  if we were to use a
mojo-like scheme, the cost of forwarding by a given node should really
be dynamically adjusted to be proportional to the weighted average of
the queue length -- that is, a busy node will cost more.

consequently, the owner of the busy node will accumulate lots of mojo,
and will be able to afford to put his/her packets at the head of the
queue, thus ensuring reduced latency.

that bit is fairly simple -- doing it with standard IP, an additional
header option and a new queueing module for the kernel should be ok.


what happens to packets that are dropped?  could we use an existing
ICMP message to inform the sender that packets are being dropped
because they could not afford the route?  what does the sending host
do in this case?  or the intermediate forwarders?

in the example, where there is only one (expensive) route between two
clouds, it's really up to the sender to decide (at layer 7) that this
is important enough to spend more to make it happen.  this is going to
have ramifications for application design -- no current web browser
has a dialog that pops up saying "that site is hard to reach.  do you
want to spend more?"

in the case where there are alternative routes, things are more
complex.  if there's a short but congested route (which is
correspondingly expensive) and a long (many hops) but cheaper route,
how do nodes make a choice when forwarding?  they'd almost need to
have an estimated cost to destination for whatever routes are
available, and the choose a next hop based on the packet's ability to
pay.

estimating the cost of route will require some complexity.  using a
geographical metric (ie. 47 mojos / kilometer) doesn't recognise node
density.  it would almost need to have a coverage map with a cost
function, which gets us back to OSPF-style routing protocol
information sharing.

what did you have in mind Ben ?




d 

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