Hannes Tschofenig

Personal blog about various IETF and Internet related activities



Wikipedia describes bufferbloat as

a phenomenon in a packet-switched computer network whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. The phenomenon was detailed at least as far back as 1985, but gained more widespread attention starting in 2009.”

When the IAB and the IRTF organized the congestion control workshop for real-time interactive media in July 2012, Vancouver/Canada participants were investigating questions concerning congestion control algorithms of  real-time interactive services on the Internet. The ongoing standardization work on RTCWeb and its expected widespread deployment gave this topic an interesting spin. RTCWeb is an attempt to extend the capabilities of the Web platform, particularly using JavaScript APIs, to allow Web browsers to natively support browser-to-provider communication as well as other real-time communication features, i.e., functionality that was previously only possible with proprietary plug-ins (or with alternative communication architectures, like SIP or XMPP/Jingle).

As documented in the workshop report two solution directions were investigated, namely:

  1. Define a congestion control mechanism that prevents problems with self-inflicting traffic. Following the workshop a new working group was created in the IETF, called “RTP Media Congestion Avoidance Techniques (rmcat)”.
  2. Change network infrastructure equipment to prevent excessive buffering.

This write-up focuses on the he write-up mostly focused on #2. A certain amount of buffering is helpful to improve the efficiency of data transmissions to smoothen bursts in data transmissions. However, not dropping packets early enough in the event of congestion leads to increasing delays for interactive real-time communication since widely deployed congestion control algorithms rely on packet loss as a signal for congestion. Not dropping packets (or not in a timely fashion) prevents applications from reacting properly to overload. Real-time communication not only includes voice communication but also gaming, video conferencing, and Web browsing.

Since the congestion control workshop took place a number of activities had happened and there is an enormous amount of interest in detecting bufferbloat related problems as well as developing and deploying active queue management (AQM) techniques. In this short write-up I will provide some pointers to ongoing activities.

In the second part of 2012 the following events are worth pointing out:

  • Linux 3.6 received some updates to reduce the buffer sizes in the networking stack, including the TCP small queues and Byte queue limits.
  • As many researchers and engineers are trying to reproduce the tests various scripts have been made available to simulate the real-time response under load. One such script worth pointing out is the netperf-wrapper.
  • Van Jacobson and Kathleen M. Nichols continued their work on the Controlled Delay (CoDel) Active Queue Management algorithm (slides from IETF#84, a recording, and a presentation to the BITAG are available).
  • In addition to the CoDel AQM algorithm Cisco released their own AQM algorithm: it is called PIE.
  • Various papers are available that provide different data points, including measurements of cellular providers. For example, Keith Weinstein submitted a position paper to the IAB/IRTF congestion control workshop and published a paper about their Alfalfa video conference system, which contains further information about the data collection in cellular networks. Even the raw data is available.
  • A new European research project, called RITE – [Reducing Internet Transport Latency], started last autumn to investigate network buffering issues.
  • Finally, it is worth pointing out that the stochastic fair queuing mechanism has gotten a lot of attention. Stochastic fair queuing puts flows into independent queues and therefore allows some degree of flow segregation without introducing the penalty of QoS signaling.

With the IETF#86 meeting in Orlando/Florida a number of sessions covered bufferbloat:

In a nutshell, there is a lot of activity around the bufferbloat topic and with the increased awareness I expect further academic publications and also work continuing at the IETF.

2 Responses to “Bufferbloat”

  1. Testing for Bufferbloat « Hannes Tschofenig Says:

    […] « Bufferbloat Apr 1 […]

  2. Dave Taht Says:

    the main focus of the bufferbloat.net effort for about a year has been on combinations of fq + codel.

    The bits and bytes demo used nfq_codel, and the AQM paper, showed sfq_codel, as the clear winners across the entire range of tests.

Leave a Reply