[olsr-dev] Fwd: Frottle and Meshes

[Tim Schmidt]

I've already sent this off to the Frottle folks, but I think it would
be somewhat easier to write as a plugin for olsr.  I wish I had the
time and expertise to code this up in C, but the best I'm likely able
to do is get a perl version out in 6 months.  Let me know if I'm
insane or if this has a chance of working.

--tim

---------- Forwarded message ----------
From: Tim Schmidt <(spam-protected)>
Date: Feb 27, 2006 12:54 AM
Subject: Frottle and Meshes
To: (spam-protected)


Please excuse the uninvited email...  I caught your address from the
Frottle page.  I've been working on a wireless mesh network in my area
and would like something like Frottle to help mitigate the hidden node
problem.  but Frottle doesn't really lend itself to a distributed
network of peers (most of which I'll have no admin access rights to).

So I've been thinking about this and was somewhat inspired by the
rendezvous problem (http://en.wikipedia.org/wiki/Rendezvous_problem).
I think I have a set of coherent actions each node could undertake
which would result in nearly-optimal behavior...  I was wondering if
you'd be so kind as to act as a sort of sanity check and/or interface
to folks that may be interested in implementing such a system?

I've been using OSLR here and so some of the thinking may be somewhat
specific to that implementation...

The basic steps are as follows:

1: generate a "permission packet" with your unique ID (MAC address or
a hash of something)
2: discover neighbors and shake hands (possibly use OSLR ETX Table)
3: pass your permission packet to a neighbor (with the highest ETX?)
4: accept incoming transmissions and wait for your permission packet to return
5: treat an incoming permission packet for a non-neighbor as a
one-time permission packet for yourself
6: timeout after X (milli)seconds of waiting for your permission
packet (assume the node with your packet died)
7: after recieving your permission packet, transmit and pass your
permission packet on the the next neighbor in your list

Nodes following these rules would tend to group together into
self-forming Frottle-like polling groups...  nodes who are members of
multiple groups would function as a regular member of one group at a
time and transmit to the other when it's group was busy with nodes it
can't hear.  There would be some risk of nodes stepping on each other
because of that last feature, but it's the only way I can see so far
of minimizing latency due to waiting for nested polling groups
resolving.

Let me know if this sounds somewhat sane and you or anyone you know
seems remotely interested.

Thanks ;)

--tim