[Olsr-dev] OLSR on OLPC?

[C. Scott Ananian]

On Thu, Jun 5, 2008 at 10:42 AM, Aaron Kaplan <(spam-protected)> wrote:
> On Jun 4, 2008, at 7:26 PM, C. Scott Ananian wrote:
>>  d) discovering your experience with OLSR in dense networks: if I put
>> 100 machines in a single room running olsrd, does the network break
>> down due to discovery traffic?
>
> you will have a layer 1 problem anyway in one single room. The problem is
> the amount of interference.
> I am pretty sure that this does not change - unless you use more bandwidth.
> 2.4Ghz has just that many channels.

There are a number of possible solutions:
 a) use all 3 non-overlapping 802.11bg channels (and somehow bridge
between them)
 b) detect the dense scenario and dial down the tx power to reduce
interference (at the cost of introducing multi-hop paths)
 c) deploy some of the windowed media access protocols so ensure that
access to the airwaves remains "fair" even as available bandwidth
decreases
 d) fall back to fancy APs and centralized media access coordination.
This stuff is in the 802.11 standards, but is not widely implemented.


>>  e) do you separate data and control traffic?  If not, do you have
>> problems with interference causing routing instabilities under high
>> traffic conditions?
>>
> Yes! (hehe, Henning probably did not know that).
> In addition in the freifunk firmware olsr traffic is prioritized via tc.
> (sven-ola : correct me if I have old info here). As Nortel already pointed
> out: yes, something like that is very reasonable to have.

tc?  could you expand that acronym for me?

>>  f) your thoughts on the OLSR extensions to the 802.11s standard: are
>> they worth implementing, or did you need to tweak the standard OLSR
>> protocol to make it work in real life?
>
> yes, olsr from olsr.org had a few extensions implemented over the years:
> 1) ETX from MIT roofnet .
> 2) hazy sighted link state routing from BBN/CUWin.net (a.k.a. "fisheye"):
> this tells a node that it should not send topology control packets all the
> time to all other nodes but more often to the immediate vicinity (TTL=1),
> less often to the outer rings (TTL=2, 4) and very seldomly to everyone
> (TTL=max).

could you point me to more documentation on these?

>>  g) the media access protocol in standard 802.11 doesn't seem to scale
>> much past 30-or-so nodes wanting to talk at the same time.  Have you
>> run into this problem in dense deployments?
>
> correct. That is why we use also 802.11a in addition :))

Hmm.  I think our front-end and antennas are tuned for b/g, but the
chipset it technically capable of a.  And there are 12-24 extra
channels in a.  That may be worth looking into.  If we can get
(conservatively) 25 users per channel using the standard 802.11 media
access mechanisms, we could reasonably scale up to 700 users within
radio "sight" of each other.  That sounds very attractive for dense
schools.

> There is no other magic extension to the MAC afaik. Except some hacks to
> keep it from splitting into different BSSID cells .

Could you elaborate?

>>  h) there's some talk on the wiki about a new v2 rfc for olsr -- is
>> there some place I could look at the work in progress?  what
>> particular challenges does it aim to tackle?
>>
> currently AFAIK everybody seems to be pretty much in favor of going towards
> RFC v2.

I'm actually more interested in using your existing codebase, because
my goal is to experiment with a mesh networking codebase which is
*not* a research project (as 802.11s still is).

> Well, I believe that 802.11s is pretty neat already for a classroom. I don't
> believe we could have done much better than Michails. But I do believe that
> a two layered approach - olsr as a backbone mesh and 802.11s as a classroom
> mesh - can be pretty neat.
> Also - since olsrd is on layer 3 (and will get some infos from layer 2 in
> the long run), it is quite portable.

Well, actually, at the moment we're deploying access points and
standard 802.11g in classrooms, and only using 802.11s "outside",
which is the exact reverse of your suggestion.  What I'm hearing is
that 802.11s "will never work" in dense scenarios.

> Use more frequencies! That will solve most of your trouble.

That does seem like a very profitable direction to research.  I'll
play around some today and see if we can get our radios to talk
802.11a despite the detuned frontend and antenna.  In a dense
scenario, low output power for 802.11a is actually a *benefit*.
 --scott

-- 
                         ( http://cscott.net/ )