On Tue, Jun 16, 2015 at 11:10 AM, Sebastian Moeller <[email protected]> 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 <[email protected]> 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 > [email protected] > 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
