[Babel-users] RTT-aware branch of Babel

[Henning Rogge]

On Fri, Jun 21, 2013 at 8:20 PM, Dave Taht <dave.taht at gmail.com> wrote:
> I would like to get packet drop statistics at every level in the stack
> unified and presentable in a reasonable format. Toke has done some
> preliminary work in this area, but much more remains.
>
> https://lists.bufferbloat.net/pipermail/bloat-devel/2013-June/000436.html

Yes, that sounds nice...

> Felix has made minstrel stats more mildly accessible inside the kernel
> as well, but much work remains there too. The current sysfs method is
> cumbersome....

We talked about his plans to get the complete minstrel statistics out
of the kernel with netlink some months ago.

> I would say it should be measured. Extrapolating from 1980s ethernet
> behavior to today is quite a jump. I got a ton of captures from the
> gathering a few months ago that may be useful.
>
> One thing I should note for those using present barrier breaker is the
> default fq_codel quantum of 300 probably has bad scaling properties
> for a set of "many" wifi nodes, and that (until we have per station
> queuing and a few other mods in the (sadly unfunded) pipeline) a
> different filter should be used to sort on destination mac address
> rather than the five-tuple, with a larger quantum (4500?). The present
> setting works pretty well on small networks but...

Yes, nothing beats true measurements.

>> Its the bane of every routing metric in a mesh... how to get the
>> metric both stable enough to be useful and fast enough to be useful.
>
> I tend to view the problem underneath - getting good statistics - as
> crucial to getting to where a metric could work. Certainly minstrel -
> on a link that is active - provides a set of potentially very useful
> passive measurements (and was recently made the default rate control
> in linux) - passive measurements that can be made more active if
> needed.

One problem I see is how to combine measurements through existing
unicast traffic and measurements done via multicast for the links
without traffic.

> but certainly RTT and loss isn't bad, and is more generic and flexible
> than tying things to minstrel... A bad link today - on unicast - can
> exhibit seconds of latency when you factor in rates and retries. A
> problem is that multicast doesn't really behave like unicast does,
> anymore, in wifi, which is kind of something I hinted at earlier today
> in another message.

We are using to "linkspeed" and lossrate in OLSRv2 at the moment, but
of course linkspeed on wired links have to be set in the
configuration, which is less than optimal.

Henning

--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan