Bufferbloat and Freeswitch Conference Call SUMMARY 1PM EST March 9

Freeswitch is one of the top two open source VOIP telephony applications, widely deployed throughout the world as a conference bridge, PBX, and IVR host.

The conference call was an attempt to have a meeting of the minds between the bufferbloat project’s work ongoing and the voice applications deployed in the field. The call was recorded. If you would like to participate post-hoc the mp3 is available at:

http://wiki.freeswitch.org/files/conf_call_2011-03-09.mp3

If anyone pulls a meaningful detail out of the recording (I know I missed a few things) please update this wiki page.

Attendees

Bufferbloat-ers: Jim Gettys, Dave Täht, Dave Hart
Freeswitch-ers: Michael Collins, Anthony Minessale (principal freeswitch developers) and 28-33 other participants listening in.

This conference call usually runs 30 minutes. It ran for 2 hours as we discussed all aspects of VOIP as it relates to bufferbloat. (And still barely scratched the surface)

Discussion

Beforehand, in addition to tweeting the time and sip/skype/gtalk methods of connecting to the conference call, I (Dave Täht) posted How I came to fear the bloat and join the project on one of my blogs - (basically this pieces remixes several JG’s blog posts from Nov-Jan 10)

Since JG was in poor voice I tried out my “Kleinrock has no buffers for TCP/IP, and buffers = distance and we’re going over the moon” rant (needs polish!), which JG then filled in with some more background from his Dark Buffers on the Internet presentation.

It’s pretty obvious that we need to have an elevator pitch about what bufferbloat.net is about. I ended up talking way too much about bug [#33].

The comcast paper that established [32 as an upper bound for unmanaged buffering on some home gateways]() in many circumstances was discussed. Both JG and I stressed it was the formula, not the number, that was important.

We talked about the Mesh Potato , the IP04 , and David Rowe’s excellent blog on low power/cost applications

The new ultra-low delay CELT codec was raved about… As codecs go, it really rocks.

I had a chance to talk a little bit about my (now on-hold) Wisp6 project, including showing off the sites and beam widths on the Bandwidth for Barrios Google Earth Map (zoom in below San Juan Del Sur, Nicaragua), the view - the (lack of) legal and regulatory environment, the partner I worked with, and of course, the surfing

We talked a bit about the cellular service lacking Pityhaya festival could perhaps leverage the ongoing open source BTS/GSM project , and also talked about how we can get the larger BTS/GSM companies to pay attention to bufferbloat.

Somewhere in there we talked about all the features folded into the new kernel tree, debloat-testing at present.

There was a really good question asked about how “eBDP” vs RED in a different light were supposed to interact. We talked about how RED was inadaquate and a bit about other AQMs like SFB could work in the presence of VOIP.

It turned out that since freeswitch VOIP servers use RTP for voice and TCP for command and control functions, that several members of freeswitch were already using TCP Vegas because it was latency sensitive.

The Freeswitch Ethernet tuning page had recommendations that were grossly incorrect for nearly any circumstance, which we corrected during the call.

We discussed the old wondershaper, and the lack of a good universal shaper in general and the lack of one that handles dual-stack IPv6/4 traffic in particular. Gained another volunteer to look into the shaping problem (Frank Carmickle )

On my ongoing quest to find a ipv6 enabled VOIP conference server on the East coast, we gained two potential volunteers as well as a potential site in Europe.

And then the call turned to the effects of virtualization on timing constraints and buffering. It sounds as though - with a little work - several virtual server technologies on both Linux and Windows can be made to “do the right thing” when it comes to timing constraints. Many of the Freeswitch developers are running on very old kernels (2.6.28, 2.6.18) in virtual environments.

And then the conversation gradually petered out…