[MLB-WIRELESS] Re: Node x is over this way -was- Applications

[Ben Anderson]

----- Original Message -----
From: "Drew" <drew at wirelessanarchy.com>
To: "Ben Anderson" <a_neb at optushome.com.au>
Cc: "Clae" <clae13 at yahoo.com>; <melbwireless at wireless.org.au>;
<jon at webprophets.com.au>
Sent: Wednesday, March 20, 2002 7:16 AM
Subject: Re: [MLB-WIRELESS] Re: Node x is over this way -was- Applications


> >
> >
> >Correct.  Though long range links are generally expensive...  Perhaps
> >tunneling over the internet could be useful in removing the need for
> >network-wide broadcast discovery...  Hmm, that and mobile-mesh could work
> >quite well...  That'd save a lot of engineering...  But still, it doesn't
> >incorporate a decent encryption layer, or a 'mojo' layer either...
> >I think I'm going to have to sleep on this... I'm still thinking there's
> >some issues with this method I'm not considering yet...
> >
> There are *tons* of issues. The main problem with the mojo idea, is that
> it doesn't solve what it's trying to.

I'm not convinced.  Keep throwing the type of problems like below at me and
if I run out of ways of solving them, then I'll have to give up, won't I :)

> example - problem: bandwidth congestion
> how does mojo attempt to solve this? by creating a class system where
> those with more links get more mojo, while those on the outskirts, or
> those who cant afford to put 5 cards and 5 antenna on their roofs are
> penalized by the system. so how could those people gain more mojo? by
> sending more traffic. thus actually increasing the amount of traffic on
> the network, as these people try to earn "credits" so they can download.
> mojo is like a ratio FTP site, but part of the network, instead of just
> some horrible idea on a ftpd.

I agree, horrible idea on an ftpd.  And implemented 'nastily' it'd make the
network suck.  I'm proposing using the mojo only to give people the ability
to get low-latency access to the network.  Packets without mojo would
traverse the network as if the mojo didn't exist -- overloaded nodes would
still be overloaded, except now people could actually still get low-latency
access to it, in what I think is a fair manner (and in a manner that causes
the network to grow to encourage increasing this 'resource in demand')
There's a lot of economics theories that cover this concept quite well.
People wouldn't earn credits sending information onto the network.
Increasing congestion would never be a workable metric to a successful mojo
like system.  I don't think I've nailed down the concept of mojo enough for
you to determine that there's any case at all that increases congestion, let
alone a general statement that all mojo on the fringe of the network
increases congestion.  Can you clarify your assertion any?

> lets try this again without mojo
> problem: bandwidth congestion
> how do people solve this? those that have LOS, and can afford it, add
> more links out of their congested cloud, or across their congested
> cloud. say 2 people do this on each end of this cloud, now suddenly,
> traffic is reduced by 50% in the cloud, as there are now a route closer
> to 50% of the people than the other. this helps everyone, not just the
> person doing the longer link. enough people do this and the problem is
> gone. there is incentive here, and it will happen without mojo. those
> setting up the links have 0 hops to a shortcut, of course they'd want to
> set one up.

Your solution requires someone altruistic enough to actually set the link
up, and make it available.  What's more likely to happen in that scenario is
that the people with congested links stop giving it away because hundreds of
users are flaming them for providing a crap service.
Prime example, look at what happened with the mailing list.  Few flames
happened, the people being altruistic with their time WRT committee stuff
decided it wasn't worth their time, and packed up and left.  Very
dissapointing in my opinion.  I think I can come up with a lot more
real-world examples where relying on peoples altruism to scale stuff breaks.
Though hopefully what I've said already is enough to convince you.

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