Re: [Babel-users] switching cerowrt to quagga-babeld issues

[Dave Taht <dave.taht@gmail.com>]

On Mon, Jul 2, 2012 at 12:16 PM, L. Aaron Kaplan <aaron@lo-res.org> wrote:
>
> On Jul 2, 2012, at 5:36 PM, Dave Taht wrote:
>
>> How goeth ipv6?
>>
>>>
>>> The project may get more options, if we drive the prototype towards a finished deliverable.
>>
>> I am very enthusiastic about babel's new authenticated mesh routing!
>>
>> It is also my opinion that without a decent drop and packet mixing
>> strategy that mesh networks will perform badly under load. I'm hoping
>> that fq_codel does well, although it seems very likely that an
>> aggregation aware and fq_codel-like strategy needs to move into the
>> mac80211 layer, which is perhaps years worth of work.
> Or have better cross-layer communication - see below....
>>
>> What would a deliverable look like? What would interest people enough
>> to get some good data, papers written, progress made, more
>> users/developers and cash in the door?
>
>
> I would like to point you towards a nice feature that Henning is currently implementing: DLEP - a (mostly routing protocol independent) framework for communicating settings and metrics between a radio and a routing daemon.
> See https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
>
> Abstract
>
>
>    When routing devices rely on modems to effect communications over
>    wireless links, they need timely and accurate knowledge of the
>    characteristics of the link (speed, state, etc.) in order to make
>    forwarding decisions. In mobile or other environments where these
>    characteristics change frequently, manual configurations or the
>    inference of state through routing or transport protocols does not
>    allow the router to make the best decisions. A bidirectional, event-
>    driven communication channel between the router and the modem is
>    necessary.
>
>
>
> More info and code samples on the olsr.org git repo. I'd like to also encourage Babel coders to take a look at it and collectively improve this.

I just did. I like it.

I note that minstrel also supplies currently unreachable-via-api
information as to rates and retries that would be useful to be
exposed, but has a higher complexity than the above spec.
(note I only just read it, soo...). Andrew mcgregor has a
too-big-for-the-MPU paper on how minstrel works he's been distributing
privately.

Also I was fiddling with supplying GPS data and sensor data (over
babel, but it's not the best choice) both for more optimal wifi access
and for a prototype of an earthquake early warning system... and I'd
argue that GPS (and GPS time) data is generally useful and gps's are
now everywhere, a good way to distribute it could be added to the
above.

> It will be - as Dave already mentioned - anyway a hard problem to have this working for many radios in a standardized way, so it would really be helpful if different mesh developers for once could work *together* on some general feature which improves everybody's metrics.

YES! Please, can we mesh people find a way to work together for a change?

my own work on bufferbloat to a large extent is driven by a (5 years
worth of) quest to solve the "dense mesh" problem that OLPCs had. The
fq_codel work at least theoretically (but currently at the wrong
layer) is a means to improve that for all wired/wireless networks and
any given mesh protocol in particular would benefit. I have been
tracking batman-adv as well, but not olsr to any extent. Where does
"working code" lie?

I note that fq_codel throws an interesting congestion-related stat
away right now, which I'd like to find a way to include in a route
metric.

I also note that I am intensely dissatisfied with babel's current
metric, which is basically "ping" over multicast, but I'm happy as
babel's metric is pluggable and can be changed.

>
> Aaron.
>



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
with fq_codel!"