We present delay-friendly guidelines for TCP-based VoIP and live video streaming ap- plications. We categorize them into TCP and OS-level guidelines, and application-level guidelines. In the following, we first provide a comprehensive set of guidelines for setting TCP and OS parameters. While several settings such as disabling Nagle’s algorithm and using large receive buffers are common practices in delay-sensitive applications, the impact of others, specifically, window validation, byte counting and limited transmit is less obvious. We then provide guidelines for setting application-level parameters.
7.6.1 TCP and OS-level guidelines
• Nagle’s algorithm should be disabled as it introduces transmission delays at the TCP sender.
• CBR-TCP applications should set a large receive buffer and operate with non-blocking sockets so that the transmission of TCP is not limited by its flow control mechanism.
• To increase the loss efficiency of TCP, SACK should be enabled [Chen et al., 2006] and limited transmit be used. The latter is primarily applicable for a TCP connection with small windows.
• Congestion window validation during application-limited periods [Handley et al., 2000], and byte-counting should be disabled. These settings are disabled by default on Linux and Windows XP systems.
• The initial window size should be set to four segments as it can remove delays up to three RTTs and a timeout during the initial slow-start period [Allman et al., 2002]. Some operating systems (e.g., Linux) inherit the ssthresh value from the last con- nection for the current connection. This may cause the current connection to enter congestion avoidance earlier even if it does not suffer from any loss, thereby incurring additional start-up delay during initial slow-start. Therefore, we suggest that ssthresh inheritance be disabled.
As a general rule, the above TCP-level configurations should be set on a per-connection basis if the underlying operating system supports it. Note that these guidelines do not require any change in the TCP stack.
7.6.2 Application-Level guidelines
• Playout buffer setting. As discussed in Section 7.4.4, a CBR-TCP application with small packets can statically set the playout delay to the loss recovery latency L + RT T + 3/f. This setting masks out TCP delay variations for a wide range of environments, in particular, for a large portion of the VoIP working region.
• Video flows. The delay performance of video flows can be improved by parallelizing the flow over multiple connections. If supported by the underlying operating sys- tem, an application should preferentially send packets over the connection that has the smallest send buffer size and is not in a timeout state (In Linux, an application can check the send buffer size by invoking ioctl(,SIOCOUTQ,) system call). Split- ting MSS-sized packets by half reduces delay for video flows if a single connection is preferred.
• Idle periods. VoIP over TCP may have somewhat different properties than CBR over TCP. In particular, VoIP with silence suppression has idle periods, requiring TCP to ramp back up to the old sending rate after idle periods. We therefore suggest that an application should continue sending minimal traffic during idle periods (e.g., 3 packets per round-trip time, as suggested by [Mondal and Kuzmanovic, 2007]) to avoid having very small congestion windows. The size of the packets sent during silence periods can
be as low as one-byte if the TCP implementation uses ACK-counting. This is because an ACK-counting TCP increases the congestion window size based on the number of packets sent rather than the number of bytes sent.
• MSS to packet size ratio. We recommend that the ratio of MSS to packet size should be an integer. This setting insures that the packet assembly capability of TCP will give the lowest possible sending rate in packets per second when the TCP sender is backlogged. The lower sending rate results in lower delays compared to a flow with an equivalent load in kb/s and a non integer MSS to packet size ratio.
• Proactive packet drop. By examining the size of the TCP send buffer, an appli- cation can potentially infer the delays a new packet will experience. Thus, it may choose to drop packets at the sender, if the buffer size crosses a certain inferred delay threshold.
• In-order delivery mechanism. As described in Section 7.4.2, the delays of TCP flows with small packets tend to be dominated by the in-order delivery mechanism of TCP. That is, packets are held in the receive buffer while waiting for a lost packet(s) to arrive. A potential modification to the TCP operating system API can allow the application to peek into its receive buffer and extract out-of-order packets. A similar approach has been proposed by [McCreary et al., 2005]. Although this modification requires changing the receive API to receive our-of-order packets, it does not change the network semantics of TCP.
7.7
Related Work
Goel et al. [Goel et al., 2002] present an empirical study of kernel-level TCP enhancements to reduce the delays induced by congestion control for streaming flows. The performance of TCP for real-time flows has also been considered by [Mukherjee and Brecht, 2000; McCreary et al., 2005]. However, unlike our study, these papers propose a modification to the TCP stack, do not provide insights on the delay working region for VoIP flows, and provide no guidelines for the playout buffer setting.
7.8
Conclusion
We presented a study of delay incurred by the real-time traffic such as voice and live video streaming when carried over TCP. We characterized the working region of TCP and studied the impact of packet size on the delay performance of TCP. We presented guidelines for setting the playout buffer of real-time traffic when carried over TCP and techniques for improving the delay performance of this traffic. These techniques can be useful to the designers of real-time applications.
Chapter 8
Energy Efficiency of VoIP Systems
8.1
Introduction
We aim to understand and analyze the energy efficiency of Voice-over-IP (VoIP) systems. The core function of a VoIP system is to provide mechanisms for storing and locating the network addresses of user agents and for establishing voice and video media sessions, often in the presence of restrictive network address translators (NATs) and firewalls. These systems also provide additional functionality such as voicemail, contact lists (address books), conferencing, and calling circuit-switched (PSTN) and mobile phones. From the perspective of energy efficiency, a VoIP system can broadly be classified according to two criteria: whether it is a primary-line phone service replacing PSTN and whether it uses a client-server (c/s) or a peer-to-peer (p2p) architecture. Vonage [Vonage, 2010] and Google Talk [Google, 2010] are examples of c/s architectures, while Skype [Skype, 2010a] is an example of a p2p architecture. Of these, only Vonage is a primary-line phone service replacing PSTN.
We begin the chapter by describing the common configurations of deployed c/s and p2p VoIP systems (Section 8.2). We then devise a simple model for analyzing the energy efficiency of these common configurations (Section 8.3). This model enables a systematic comparison of c/s and p2p configurations of VoIP systems. We then present measurements for the c/s and p2p VoIP components of these systems (Section 8.4) which we apply to the model developed for identifying the sources of energy wastage in these systems and the incurred economic costs (Section 8.5). Based on our analysis, we provide recommendations
to improve the energy efficiency of VoIP systems (Section 8.6). Finally, we present the related work (Section 8.7).