1. 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

2. 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.

3. 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 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?

4. 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 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.

5. 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

6. 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.

7. 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

8. 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.

9. 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

10. 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

11. 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

12. 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

13. 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.

14. 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.

15. 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

16. 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

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

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

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

20. 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.

21. 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.

22. 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.

23. Prototype Implementation
Add a new function to client WNI driver:
D-Link DWL-G520 wireless card (Atheros chipset)
Madwifi driver under Linux
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 driver. Our Linux kernel version is , 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.

24. 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.

25. 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

26. 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

27. 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.

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

29. 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

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