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

["L. Aaron Kaplan" <aaron@lo-res.org>]

[-- Attachment #1: Type: text/plain, Size: 4906 bytes --]


On Jul 2, 2012, at 6:44 PM, Dave Taht wrote:

> 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.
> 

Nice :)

> 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?

Absolutely!

> 
> 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

Oh!... I remember being at One Kendall Sq. and discussing this with Michailis LOL...
I know exactly what you mean :) 30 XOs in close proximity was a recipe for disaster :)

> 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?

olsr.org/git/

What you are looking for in particular is:
http://www.olsr.org/git/?p=framework.git;a=summary
and DLEP:
http://www.olsr.org/git/?p=dlep_app.git;a=summary

> 
> 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

;-) the dirty little secret is : all of the current mesh protos have unsatisfactory metrics :)

> babel's metric is pluggable and can be changed.

Same for OLSR. Good design choice.


Okay, Dave . I recommend that you get a grip on the DELP draft and get in touch with Henning.
I shifted more towards the "making things happen" side of mesh R&D than to the implementation side. So you need to talk with Henning in this respect. I would love to see a common framework - well tested and hardened by multiple developers which is usable for all of us.

Aaron.



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]