[Olsr-dev] OLSR on OLPC?

[C. Scott Ananian]

[Replying to Henning's and Hannes' emails at once.]

On Wed, Jun 4, 2008 at 1:50 PM, Henning Rogge <(spam-protected)> wrote:
> On Wed, Jun 4, 2008 at 7:26 PM, C. Scott Ananian <(spam-protected)> wrote:
>>  b) actually deploying olsrd as a fall-back mechanism on the XO --
>> giving up the power benefits of running 802.11s autonomously in the
>> wireless chip in exchange for perhaps better behavior in some
>> scenarios,
> I'm not sure if the 802.11s will really save power. You will have to test it.

802.11s saves power because it is implemented in the firmware of our
wireless device.  Thus, we can turn off the CPU and still route
packets, which saves power.  Since olsrd would run on the main CPU, we
won't be able to route packets w/o keeping the CPU powered on.

>>  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?
> If all nodes can see each other, you have a "one-hop" network... so
> you will get only very few flooding of TCs.

We're very interested in testing this case (see response to Hannes below).

> Of course you have problems with collisions, but that's a problem with
> all WLAN nets in high density situations.

There are media access protocol tweaks that help 802.11 deal with
contention.  See reference below.

>>  e) do you separate data and control traffic?  If not, do you have
>> problems with interference causing routing instabilities under high
>> traffic conditions?
> We don't do this. Yes, this can be a problem...

The Nortel guys think that prioritizing control traffic is very
important (see below).  We'd be interested in doing more work here,
especially w/r/t monitoring the routing tables to see if instability
is a problem in practice.

>>  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?
> Do you have a link where I could look at the 802.11s standard ? Olsrd
> could easily be modified to work with MAC addresses instead of IPs I
> think. But I don't see a real advantage (except that routing in kernel
> space might be faster).

A good introduction to 802.11s routing is at:
  http://doi.acm.org/10.1145/1234161.1234166
which explicitly discusses the possibility of OLSR routing extensions.

These seem to have been dropped in favor of a more general extension
mechanism in the latest version of the 802.11s routing spec, which is
at:
  https://mentor.ieee.org/802.11/file/06/11-06-1778-01-000s-hwmp-specification.doc

[Moving on to Hannes' email]
On Wed, Jun 4, 2008 at 2:21 PM, Hannes Gredler <(spam-protected)> 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?
>
> most likely, since all the hello timers run at fixed intervals.
> most of our municipal networks have a sparse neighborhood,
> with typical a handful of nodes in the 1hop neighborhood.
>
> it should not be too difficult to progressively decrease the
> hello(and dead) timers if the neighborhood per interface
> grows beyond lets say 10 nodes.

I'd be very interested in working with y'all on this.  We're working
on a 100-laptop testbed we could probably use.

>>  e) do you separate data and control traffic?  If not, do you have
>> problems with interference causing routing instabilities under high
>> traffic conditions?
>
> yes we do. transit traffic is all handled within the kernel
> (except the BMF plugin which handles multicast in a seperate thread).

see above; I'd love to get quantitative data indicating whether this
is sufficient to prevent routing instabilities.

To quote a Nortel engineer:
  "When traffic affects routing you have a feed-back system which is
not good. This is something we work very hard to avoid with wireline
routing systems and its one of the reasons we almost never do
congestion based shortest path routing. I.e. it would oscilate like
crazy. [...] Its not hard to see that if traffic interferes with
routing that in turn affects traffic and hence routing etc... and you
get a horrible set of feedback oscillations in the network. I've seen
this many times in routing systems where the control packets are not
properly isolated from the data packets. The
symptoms are usually the same (a mess) and the cure is the same
(proper isolation/prioritization of control over data at every stage
of handling). Early OSPF networks used to have this problem (hellos
dropped due to congestion) and were quite spectacular and horrifying
to watch melt down. More than one very expensive outage (i.e. entire
countries) happened as a result."

>>  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?
>
> any wireless mesh protocol, without the ability to convey a loss or
> usable bandwidth metric is hopelessly broken.

I provided some links to the 802.11s specs above; do you feel the
metrics specified are useful?

>>  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?
>
> i'll defer that question to the berlin guys. they have real-world experience
> from running olsrd at conventions like the CCC.

The following academic paper cites several different approaches to
scaling the 802.11 media access protocol to handle lots of nodes:
  http://dx.doi.org/10.1109/TMC.2006.124

At the moment, "We are using regular 802.11 DCF as our Medium access
protocol. It is now augmented by a dynamic contention window,
currently under test. A dynamic CW  is not part of the standard, so
the vendors will implement them in many different ways."

It's my understanding that a number of different 802.11 chipset
vendors have implemented some form of extended media access protocol
for 802.11; I'm curious to know whether that's part of the secret
sauce folks like those in Berlin need to use in order to make 802.11
(mesh or not) work in large settings.
  --scott

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