[Bloat] sweeping up the bloat

Dave Taht dave.taht at gmail.com
Tue Jun 16 13:53:12 EDT 2015


On Tue, Jun 16, 2015 at 10:33 AM, Steinar H. Gunderson
<sgunderson at bigfoot.com> wrote:
> On Tue, Jun 16, 2015 at 10:10:18AM -0700, Dave Taht wrote:
>> As one example: I don't have a firm guideline for how, why or when or
>> when to enable pacing
>
> My guideline is “always”.

As you are the original champion of the idea, sure! :) Certainly
seeing the original paper on pacing thoroughly refuted[1] and
observing the effects on tons of traffic now, I, too am mostly a fan
(aggregation bothers me but it's hard to measure, and fq_codel remains
the right thing for routers, bare metal servers hosting vms, and stuff
that gets hw flow control. IMHO. I would love to be able to turn on
the right things more automagically in all these cases)

But guidelines on how to configure it in applications are missing. As
are when where and how to implement it in DCs, handheld clients,
internal servers and hosts, home routers, slow networks, VMs, and bare
metal servers.

Quic does pacing, so far as I know, entirely in userspace, or does it
rely on sch_fq to do so? Should a VOIP app or server like freeswitch
use it?

I see in the kernel support for sk_pacing_rate, and max_pacing_rate
and it is unclear how/when those options can be of aid and set. I have
never seen the patches for vlc (not that I recall, anyway), and
certainly think that pacing and tcp_notsent_lowat would help things
like x11 tunneling. And I'd like to add correct support for it to
netperf and flent so as to better observe the effects on and off at
various rates, bandwidths, and link layer technologies.

So as you are the expert on this, can I request you write up where to
use it and how? Neednt be one big chunk...

[1] https://reproducingnetworkresearch.wordpress.com/2013/03/13/cs244-13-tcp-pacing-and-buffer-sizing/

>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast



More information about the Bloat mailing list