[Bloat] Fwd: sweeping up the bloat

[Bloat] Fwd: sweeping up the bloat

[Sebastian Moeller]

Dear list,

it seems my reply-all skill got a bit rusty, so here I go again ;) (threading might be broken?)

On Jun 16, 2015, at 19:53 , Dave Taht <dave.taht@gmail.com> wrote:

> [...]
> 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 thought a voip app will pace simply by virtue of having to collect 10-20ms seconds worth of audio before packing this up and send it off. I have not looked at packet captures but my H0 is that there should be one UDP packet every 20ms, which I would call natural or data-driven pacing. I would not be too amazed if in reality instead of 1 packet per 20ms the app would send N packets every N*20ms; sad, yes, but not amazed.


Best Regards
       Sebastian

Re: [Bloat] Fwd: sweeping up the bloat

[Dave Taht]

On Tue, Jun 16, 2015 at 11:10 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Dear list,
>
> it seems my reply-all skill got a bit rusty, so here I go again ;) (threading might be broken?)
>
> On Jun 16, 2015, at 19:53 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> [...]
>> 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 thought a voip app will pace simply by virtue of having to collect 10-20ms seconds worth of audio before packing this up and send it off. I have not looked at packet captures but my H0 is that there should be one UDP packet every 20ms, which I would call natural or data-driven pacing. I would not be too amazed if in reality instead of 1 packet per 20ms the app would send N packets every N*20ms; sad, yes, but not amazed.

Kind of massively off the general topic of finding more low hanging fruit:

Well, our recommendation 3 years ago to the freeswitch folk was more
minimal buffering in the qdisc and fq_codel.[1] As we are well aware
this is stochastic fq, not full blown fq, and sch_fq was largely
targeted at tcp apps and has (had) some worrisome behaviors with udp
traffic and synfloods.

Many voip providers carry 1000s or 10s of thousands of simultaneous
conversations. Arguably a sch_fq like qdisc that just dropped all but
the newest packet in a flow might be of use.

Voip is also carried over tcp in some cases.

voip servers DO use tcp for things like backups and C&C. Voip service
providers also commonly used tcp-vegas, last I looked. CDG is looking
quite promising. How should they do tcp whilst serving voip?

webrtc is getting *widely* deployed and video frames, spread across
packets, have different characteristics than voip does, which we have
never fully explored in test (works DARN well in actual use, but could
it be better? I liked the old NADA ecn proposal for i-frames in
particular). Although it can be a server based application (what
should a server look like) it is also (hopefully) a p2p app. Are the
browsers pacing? Last I recall webrtc was sending a 16k or more burst.
Should a host enforce pacing in the lower levels of the stack? How
well does videoconferencing aggregate over wifi in each direction?

Apps like freeswitch/asterisk and conference servers and so on are all
moving fast to HD, extremely high rate/resolution (by previous
standards) videoconferencing, which has issues with ramping up with
tcp_friendly behavior. Some conferencing apps are completely ignoring
tcp_friendly behavior...

(I note the cluecon folk wanted a bufferbloat talk in august and I
keep hoping someone will go do that.)

[1] can't find the webpage on this

>
> Best Regards
>        Sebastian
>
> _______________________________________________
> Bloat mailing list
> Bloat@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