[Babel-users] RTT-aware branch of Babel

[Henning Rogge]

The main problem with RTT and buffers is that you will not get "really
bad RTTs" until the link is saturated.

Henning Rogge

On Fri, Jun 21, 2013 at 6:59 PM, Dave Taht <dave.taht at gmail.com> wrote:
> On Fri, Jun 21, 2013 at 6:52 AM, Baptiste Jonglez
> <baptiste.jonglez at ens-lyon.fr> wrote:
>> On Thu, Jun 20, 2013 at 03:23:28PM -0700, Dave Taht wrote:
>>> Is there a way to extract the RTT from the babel monitoring ability?
>>> or some other means (sounds like a wireshark decoder is in order)
>>
>> Sure, the averaged RTT is available both on the local interface and on
>> the dump generated by babeld (when a SIGUSR1 is received).
>>
>> If you want access to RTT samples, you can use the debug flag ("-d 2").
>> I suggest to grep for the string "RTT" in this case.
>
> I am delighted to finally have a means to measure RTT over multicast
> effectively. multicast behavior on wifi varies wildly by device, by
> driver, by queue type, with/without 802.11e, with powersave, etc
>
> I will try to get your code up in my lab over the next month or so.
>
>> There is indeed a tcpdump decoder for Babel (thanks to Pilot), but it
>> does not yet know about this extension.  I'll probably implement it at
>> some point.
>>
>>> one side effect of fq_codel I'm aware of is that the first packet in a
>>> stream will tend to be delivered faster than the second and
>>> succeeding, due to the "sparse stream" optimization.
>>
>> Does it apply to multicast packets?
>
> It applies to a 5 tuple of the source/dest ip and port and the
> protocol. So yes. Openwrt has a default quantum of 300 for fq_codel
> (the default in the linux mainline is the mtu), so your typical hello
> packet will often end up near the head of the queue, unless it is
> bunched up behind another babel packet. Except after a queue is built.
> And there are other variables as noted above.
>
> one possible optimization for babel in this case would be to send
> hellos on another tuple.
>
> Another more radical behavior for wifi (not really related to
> fq_codel) would be to use unicast more often, as packet aggregation on
> a conventional queue, as well as better rate training via minstrel, is
> desirable on links with low numbers of listeners, e.g. it is faster to
> send 8 unicast packets to 8 stations running at 54Mbit each than it is
> to send 1 multicast packet at 6mbit. At many traffic levels (by
> utilizing aggregation), a route update becomes essentially free, and
> if you are measuring RTT rather than "loss" as your metric, well...
>
>
>>
>>
>> _______________________________________________
>> Babel-users mailing list
>> Babel-users at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



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