[Babel-users] [PATCH 2/3] Add ECN support to babel messages

[Dave Taht]

On Fri, Sep 28, 2018 at 2:56 AM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Juliusz Chroboczek <jch at irif.fr> writes:
>
> >>>> I think I agree with Juliusz here, I'd prefer Babel stay truthful and
> >>>> instead change how fq_codel reacts to it.
> >
> >>> Yeah, perhaps fq_codel is not tolerant enough of bursts of packets.
> >
> >> Heh, I'm not sure there's a proper response to a large burst of
> >> back-to-back packets that won't suck for all other traffic...
> >
> > I'm not a specialist, but my uneducated intuition would be that
> > fq_codel can be tuned less agressively than plain codel -- the FQ
> > element will prevent undue delay for unrelated flows.
>
> Yeah, it will hurt other flows less (or not at all), but that will
> impact the intra-flow latency of TCP flows that do build a queue. So
> it's a tradeoff...

While packet pacing is seemingly entering everything nowadays, you
still can't get in more than you can put out. The "fq" part of
fq_codel automagically paces things. A mix of unicast and multicast
will acquire more bandwidth, not just from having different flows in
an FQ'd world, but from being able to take advantage of the vastly
higher rates from unicast, as we all know....

Still, when you are out of bandwidth, my argument is to "send less
data", and that in the long run babel would need to automagically
adjust the route announcement intervals to fit into the bandwidth
available.

It may well be I've been coping with another problem entirely, see
previous mail. when it's your default route that is not being taken
up, it's quite noticible.



>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619