PSM-throttling: Minimizing Energy Consumption for Bulk Data Communications in WLANs Xiaodong Zhang Ohio State University in Collaborations with Enhua Tan, Ohio State Lei Guo, Yahoo! Songqing Chen, George Mason University Good morning, everyone, my name is Enhua Tan, from the Ohio State University. Today I am going to present a paper about power saving for bulk TCP transmissions such as streaming media in wireless environment. This is a joint work with Lei Guo at the Ohio State University, Songqing Chen at George Mason University, and my advisor Xiaodong Zhang at the Ohio State University. Lei Guo is currently working at Yahoo incorporation. ICNP’07, Beijing, China

What is Going on in Internet? Wireless accesses to Internet are very pervasive: Everywhere: campus, offices, home, public utilities … Most are supported by Wireless LANs Media content is heavily delivered in Internet: Streaming: Real or Window media (> 80% in TCP) HTTP-based streaming: YouTube, Google Video (TCP) TCP downloading: web sites (traditional or web 2.0) Mobile devices are increasingly diverse and portable: Laptop, PDA, iPhone, WiFi phone … Challenge: mobile devices can easily exhaust their batteries by viewing streaming media. First, I will introduce the background of this work. As we know, wireless accesses to the Internet are becoming more and more pervasive on campus, in offices, at home, and in public utilities such as fast food restaurants. Most of the mobile devices are using Wireless Local Area Networks to access the Internet. At the same time, media content has accounted for a high percentage of the Internet traffic volume: such as streaming media whose majority is delivered in TCP; http-based pseudo streaming including YouTube or google video; and traditional TCP-based media downloading web sites. YouTube is the most popular one. On the other hand, mobile devices are becoming increasingly diverse and portable, from laptop to PDA, and the recently released iPhone, etc. It is challenging for mobile devices to watch media online continuously since the capacity of their batteries is limited.

Limited Power in Mobile Devices Wireless Network Interface is a major power consuming source! WLAN Access Point (AP) YouTube Servers Internet WiFi Phone Windows/Real Media Server Laptop This figure shows a typical scenario for mobile devices accessing the Internet. The Internet media servers include YouTube, Windows/Real Media, and normal web servers. Usually, the mobile devices access the Internet with their wireless network interface (WNI) through the Access Point in a Wireless LAN by IEEE 802.11 protocols. However, the wireless interface consumes major power of the devices, for example, the WNI can consume more than half of the power in a PDA. So can we minimize power consumption of the wireless network interface while satisfying the QoS requirement of media transmissions? Web Server PDA Question: Can we minimize WNI (Wireless Network Interface) power consumption while satisfying the QoS requirement?

802.11 Power Saving Mode (PSM) and Its Variant Wakeup every 100ms via PS poll Limits: Buffered packets lead to delayed TCP acknowledgements Increase round trip time estimation at the sender side May degrade the TCP throughput PSM adaptive (PSM-A): Widely used in commercial products Only sleep when no packet receives for a while (e.g. 75ms) Offer less power saving, but retain TCP performance As a matter of fact, IEEE 802.11 protocol defines Power Saving Mode (PSM) in order to save power for wireless interface. PSM wakes up the wireless interface every 100ms, which is the beacon interval of the Access Point (AP), and will send PS Poll request to the AP to receive the packets buffered in last 100ms. However, for a TCP connection, PSM will delay the acknowledge of the received buffered packets, and increase the round trip time estimation at the sender side, which leads to degrading TCP performance. PSM adaptive (PSM-A) is a variant of PSM widely used by commercial products. PSM adaptive keeps the WNI awake if receiving any packet, and turns the WNI into sleep (PSM mode) when no packet receives for a certain amount of time (e.g. 75ms). PSM adaptive can offer better TCP performance, by sacrificing the power saving efficiency.

Ideal Power Saving Condition: Sleep Well and Work Energetically If the media traffic can form a predictable pattern: periodic bursts Client WNI can sleep/work periodically Transmitting: 1.346W, receiving: 0.9W, idle: 0.741W Sleep: 0.048W Receiving Packets Time In an ideal case, if the WNI can sleep well and work energetically, the power consumption will be minimized. Considering that, if the media traffic can form a predictable pattern, for example, periodic bursts, then the wireless client can accurately follow the traffic pattern to sleep and work periodically. In this way, the power consumption of the WNI is minimized while the TCP throughput will not be degraded. Sleeping

Forming Ideal Condition by Proxy Buffer and shape media traffic into periodical bursts A proxy between mobile devices and media servers Devices can predict packet arrival time, safely sleeping minimizing power consumption without performance loss Limits: modified client Proxy needs to handle diverse communication protocols Needs a dedicated and expensive infrastructure Reference: Chandra & Vahdat, USENIX’02 In literature, a paper published in Usenix 2002 proposed to use a proxy to buffer the media traffic packets, and shape the traffic between the proxy and the mobile devices into periodical bursts. The mobile devices can easily predict the packet arrival time and sleep safely, which leads to minimized power consumption and non-degraded performance. However, this scheme requires the applications on mobile devices to be modified for using the proxy; and requires the proxy to handle different media transmission protocols, and more importantly, needs a dedicated and expensive infrastructure support.

Problem Statement Can we minimize mobile devices power consumption while satisfying the QoS requirement, without using a dedicated proxy? The problem we have formulated in this research is, can we minimize the power consumption of the mobile devices and satisfying the QoS requirement of the media transmission, without using a dedicated proxy? Server Internet Wireless Device Proxy

Outline Problem Statement Motivation and Overview Design Internet Experiments on Bandwidth Throttling PSM-throttling Design Evaluation Summary Here is the outline of this talk. Next, I will present the motivation and overview of our design. Then, I will give the design and implementation of PSM-throttling scheme. Finally, I will talk about the evaluation and summarize this presentation.

Conventional TCP Throughput Control Works well for low volume of simultaneous requests Large volume of simultaneous requests make servers be the bottleneck TCP congestion control cannot well address server bottleneck problem Internet Server TCP Congestion Control Conventionally, for a Internet server, the end-to-end throughput of the TCP transmission will be solely determined by the TCP congestion control mechanism. This works well when the volume of requests are lower. However, for streaming media traffic, the server can be the bottleneck of the delivery, because of the large volume of the traffic and simultaneous requests. So if the server only engages TCP congestion control, the bottleneck problem cannot be well relieved. TCP Congestion Control Client Full-Speed Transmission

Bandwidth Throttling: Serve Large Volume of Requests Simultaneously Underutilized bandwidth Internet Client 2 Media Server Bandwidth Throttling: Server sends packets at a limited constant rate (lower than end-to-end bandwidth)  More Simultaneous requests will be served In practice, for a media server, in order to serve more clients at the same time, it will throttling the transmission throughput at the server side, by sending packets in a limited rate, instead of fully utilizing the end-to-end bandwidth, which is known as bandwidth throttling. With the increasingly abundant Internet bandwidth, the TCP throughput will no longer be determined by the TCP congestion control mechanism, but be constrained by the server side. As we observed, bandwidth throttling has become a common practice for delivering media content. Client 1

Bandwidth Throttled TCP Transmission Server Win = 256 K Client WNI Receiving This figure shows a bandwidth throttled TCP transmission. The server continuously sends out packets for the client to receiving, at a pace controlled by the server. The client needs to wake up and receiving the packets with no time to sleep. Window size defaults to 256K ACK every two data packets Transfer rate throttled by the server in a constant rate WNI is busy receiving, no time to sleep

PSM-throttling: A Client-hinted Mechanism to Create Bursts for Power Saving 20 K burst 20 K burst 20 K burst Server Win = 0 Win = 0 Average throughput = Normal Streaming/Transfer Rate Win = 20 K Win = 20 K Win = 20 K Client WNI recv sleep recv sleep Burst tput ≤ E2E bandwidth Motivated by this observation, we propose PSM-throttling to let the wireless client hint the throttling process in order to create periodical bursts for power saving. Here we shows the workflow of the process. Initially, the client sends an acknowledge packet to the server, specifying the receive window size in the TCP header, which we called unchoke ACK. The window size is designed to be the bytes need to transferred within a pre-defined flow burst period. Upon receiving the unchoke ACK, the server sends the number of bytes requested by the client to the network together in a burst. After the client receives the first packet, it sends a choking ACK with zero receive window size in the TCP header to stop the server sending more packets. The client can safely turn into sleep before the flow burst period ends. And so on, so forth. In this scheme, the burst throughput becomes constrained by the end-to-end bandwidth, while the average TCP throughput can still be the same as original throughput by managing the sleep time to be the flow burst period minus the receiving time. Our scheme does not need any extra infrastructure support like a proxy. And it is application independent and client-centric since only the WNI driver on the client needs to be added a new functionality. Flow burst period Flow burst period No proxy needed Application independent and client-centric: only add a new function in client WNI driver

Related Technical Issues How can a server recognize client hints? Utilizing TCP flow control mechanism: placing “hints” in receive window field in the TCP header No change to servers An ACK packet during sleep consumes trivial power For a given flow burst period (T), E2E bandwidth, and average throughput (r), (win size = T × r) burst and sleep times are determined to sufficiently sleep, T should be larger than 2 × RTT This slide further explains some related technical issues of our scheme. First, the server recognize the hints (or the choke and unchoke acknowledgement) from the client by utilizing the build-in TCP flow control mechanism since the hints are placed in the receive window field in the TCP header. The server does not need any change for our scheme. You may notice an ACK packet is required to send during the sleep time for unchoking the connection, in fact, it only needs the WNI to wake up and send out only one packet, and then sleep again, which consumes trivial power. And lastly, for a given flow burst period (T), end-to-end bandwidth, and average throttled throughput (r), the burst time and sleep time in a period are determined by these three parameters. In order to have sufficient sleep, T should be larger than 2 times round-trip time, since each ACK needs a round-trip time for effectiveness.

Bandwidth Throttling Detection in TCP-based Media Transmissions Major media servers, such as Windows/Real Media servers, and lighttpd server (used by YouTube), have build-in bandwidth throttling We confirm this by detecting server-side throttling: Choke the transmission for 200 ms at client side: Win = 0 Unchoke: Win = Original If resulting traffic bursts and the TCP throughput is remained the same  server is using bandwidth throttling We analyze the burst patterns and throughputs of Internet traffics to verify our detection methods As we know, major media servers, such as Windows, Real media servers, and lighttpd server, used by YouTube, have build-in bandwidth throttling mechanisms. Now we will show the Internet experiments we did in order to verify if bandwidth throttling is widely used at the media server side. We add a new function in the WNI driver to choke the TCP connection for 200ms by setting the receive windows size of the TCP acknowledge packet to 0. After 200ms, we will restore the receive window size and let the server send out all the buffered packets, and so on. If the server is using bandwidth throttling, we will observe traffic bursts with non-degraded TCP throughput. We analyzed the traffic pattern and throughput of our experiments in order to verify our detection methods. They will be shown in the following slides.

Real Media Server: A Sequence without Choke/Unchoke We first did the experiment on Real media server. This figure is the original TCP packet sequence without choke and unchoke detetection. The X-axis is the time elapsed, and the Y-axis the sequence number of each packet. This figure shows that the packets are delivered continuously. Packets are continuously Delivered: Tput = 350Kbps

Real Media Server: the Sequence with Periodical Choking By periodically choking the connection with choke ACKs, we observe clear traffic bursts and the average TCP throughput is still the same as before. This confirms that Real media server is using bandwidth throttling for content delivery. Bursty and keeps the TCP Throughput: Tput = 350Kbps

Windows Media Server: a Sequence without Choke/Unchoke For Windows media server, we have similar observations.

Windows Media Server: the Sequence with Periodical Choking Bursty and keeps the TCP throughput

Linux File Server: a Sequence without choke/unchoke We also test a Linux file server which doesn’t have bandwidth throttling engaged.

Linux File Server: the Sequence with Periodical Choking TCP throughput reduced!  No throttling at the server side Although the TCP sequence after periodical chocking looks bursty, the actual burst transfer rate is the same as the previous average transfer rate, which means the new average TCP throughput is reduced for the sleep time posed by chokings, and suggests that the server doesn’t engage bandwidth throttling.

PSM-throttling Design: Bandwidth Throttling Detection Measure the stable flow rate r for a specific duration T0 Creating bursts by choking the connection for half of the time Measure the flow burst rate r’ If r’ ≥ 2r, server is engaging bandwidth throttling, which can be used for power saving in PSM-throttling In designing PSM-throttling scheme, we first include the detection of bandwidth throttling as shown before. Initially, the flow rate is measured for a specific duration in order to get a stable value. Then the TCP connection is choking and unchoking for half of the time respectively in order to create bursts. The burst rate is measured and comparing with the previous measured flow rate, and if it is larger than 2 times the flow rate, which means the new average flow rate is not degraded, we will regard the connection as bandwidth throttled and use PSM-throttling for power saving purpose.

PSM-throttling Design: Further Increase Traffic Burst If the burst rate is not high enough (not fully utilizing the wireless channel): Client waits for about 20 ms so that there are enough packets buffered at the AP PS Poll to receive the buffered packets  More bursty! In the design of PSM-throttling, we also consider the case of further increasing the burst rate by utilizing the Access Point buffer. Since the end-to-end bandwidth may restrict the burst rate created by choking mechanism to be lower than the effective bandwidth in a wireless LAN, we consider to let the AP buffer the burst for a small interval (such as 20 ms), so that the wireless client can retrieve the packets with PS poll forming a higher rate burst. The small delay for the buffered packets is negligible to impact the TCP performance while the resulting higher rate burst can let the WNI work more efficiently.

Prototype Implementation Add a new function to client WNI driver: D-Link DWL-G520 wireless card (Atheros chipset) Madwifi 0.9.2 driver under Linux 2.6.18 Comparing with 4 other schemes CAM: Continually Aware Mode (no power saving) CC: Client-Centric (IWQoS’04) PSM: Power Saving Mode (IEEE standard) PSM-A: PSM Adaptive (focus on comparing with) Our prototype implementation is based on the madwifi 0.9.2 driver. Our Linux kernel version is 2.6.18, and the wireless network interface card we used is D-LINK G520, with is equipped with Atheros chipset. We compared our scheme with 4 other schemes. CAM is Continually Aware Mode, which means no sleep will be performed for power saving. CC is another client-centric scheme proposed at IWQos’04 aims to reduce the energy consumption on TCP downloading by increasing the TCP transmission time. PSM and PSM-A are introduced before. Here we mainly compare our scheme with PSM adaptive since it can guarantee the delivery quality while the other two power saving schemes often degrade the quality of service.

Performance Evaluation Lab and Internet Experiments: We evaluated the prototype within our lab environment by using NIST Net emulator, and also evaluated the prototype in the Internet as well. We focused on the media servers with bandwidth throttling engaged. And we are trying to save power for the wireless client with our PSM-throttling mechanism.

Performance Evaluation Results -50% -75% For Windows and Real media streaming, PSM-throttling achieves comparable throughput comparing with the PSM adaptive method, but the energy consumption is about half or 25% of the PSM adaptive method. Windows and Real media streaming

Performance Evaluation Results (cont.) -75% -58% For YouTube traffic, PSM-throttling can also save up to 75% of the power consumption, while the transfer throughput doesn’t degrade. For HTTP-based media file downloading, the throughput of PSM-throttling is the same as PSM adaptive, while the consumed energy is less than half of the PSM adaptive. YouTube pseudo streaming; HTTP downloading

Summary Internet bandwidth is no longer critical bottleneck, but servers due to increasingly high volume of simultaneous requests Conventional traffic smoothing methods are no longer useful Bandwidth throttling addresses this problem We take this unique opportunity to design and implement PSM- throttling to create receive/sleep periods for power saving on WNI PSM-throttling has the merits of: No additional infrastructure support Application independent and client-centric Save up to 75% of the power and keep the TCP throughput Applicable for cellular networks and WiMax networks Hints from applications can further improve PSM-throttling Bandwidth throttling is widely used to address this problem.

Thank you. Enhua Tan: etan@cse. ohio-state. edu http://www. cse Thanks for your time, any questions?

PSM-throttling: Adaptation to Server Transmission Rate Dynamically adjust the receive window size If the throughput is not decreasing, increase the recv wnd size If sleep time falls below a RTT, decrease the recv wnd size

Evaluation of PSM-throttling Adaptation to Server Transmission Fluctuations As title