[MLB-WIRELESS] Re: mojo -was- structure

[Ben Anderson]

> >   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.
>
> but if we are only building a network for people who are "altruistic
> enough"  how altruistic is that?

It's not, and that's the point.  I think it's implicity self-defeating.  It
won't scale relying on altruism.


> >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.
>
> queuing should be by type of traffic, not by the "worth" of the sender.

So if everyone starts making video phone calls at 200kbits/sec... the
latency goes up, the absolute maximum is 20 users (and more realistically
more like 12-15).  Even at more respectable voice bandwidths of 20kbits,
there's only a realistic 120-150 users before the whole network is shot.
And traffic type is easy to circumvent.  The low latency stuff is needed by
*lots* of services.  chatting, games, voice, video conferencing, etc, etc...
there's lots that need interactive performance.  The only way to be able to
get a reasonable interactive performance is to have a guaranteed QoS metric
(as in ATM style controls) or to ensure that you have enough bandwidth to
ensure the network never becomes overloaded.
As the network gets larger, latency in general will increase.  More nodes in
area, more hops, more collisions, etc.
And how then do you propose to stop the 20 interactive users
videoconferencing from using all the interactive, low latency bandwidth to
effectivly deny the network of any high bandwidth, high latency services?
And how are you going to guarantee that what says it's a game protocol, or
chat protocol is actually that, and not someone tunneling mp3's through it?
The DoS possiblities in traffic class queuing are just mind boggling.
If you have a solution for these issues within class based queuing, please
tell us -- I'd prefer it to be not based on a 'mojo' 'payment' style
structure too.  I just haven't found anything else yet that even gets close
to scaling.

> the above is actually a _dis_incentive for that person to invest in
> extra bandwidth in their region

Reasonable point.  But...

If there's a bottleneck, and the value of mojo in that region goes up,
people in that region will be inspired to capitolise on that by trying to
shift some of the bandwidth away from the overloaded section of the network.
Competition theory.

More mojo will be paid for low latency traffic, and so an overloaded node
should actually make less than a high bandwidth low latency node.
Similarly, a low latency, low bandwidth node is more valueable to some
traffic than a high bandwidth, high latency node.  And class based queuing
very rarely takes this into account multiple hops later.  the best metric is
made on a router-router basis, not a complete route-path basis.

There are a lot of bandwidth/latency/mojo-worth tradeoffs that could be
potentially made, and that's why I'm proposing simulation to try and
discover a tradeoff that is both fair, and scales well without limiting
"mojoless" access as much as possible.

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