ahmad nazir raja

8/4/2019 Ahmad Nazir Raja

http://slidepdf.com/reader/full/ahmad-nazir-raja 1/81

Energy Efficient Client-centricShaping of Multi-flow TCP Traffic

Ahmad Nazir Raja

Kongens Lyngby 2010

IMM-M.Sc.-2010-46



Technical University of Denmark

Informatics and Mathematical Modelling

Building 321, DK-2800 Kongens Lyngby, Denmark

Phone +45 45253351, Fax +45 45882673

[email protected]

www.imm.dtu.dk

IMM-M.Sc.: ISSN xxxx-xxxx



Abstract

With the explosion of mobile devices, there is a pressing need to explore optimalways of battery consumption. One of the widely used mechanisms for energyconservation is the IEEE 802.11b Power Save Mode (PSM). The mechanismsuggests that the wireless interface should be transitioned to a low power, sleepstate when idle. PSM needs infrastructure support and studies have shown that

it adversely affects the throughput in some cases. Other than using PSM, thereare various power saving mechanisms that either suggest a trade-off betweenperformance and energy consumption, propose usage of power aware protocolsor require additional infrastructure support. We have implemented a modifiedversion of the client-centric PSMT protocol which is capable of minimizing en-ergy consumption while maintaining the throughput. The protocol works byexploiting the TCP flow-control mechanism and our implementation can bedeployed without changing the existing TCP functionality. Furthermore, theclient-centric nature of the protocol enables easy deployment of the solution.The protocol is application independent but is targeted for bulky TCP trans-fers. Our solution can be used on Linux based systems and is kept portable as

it can be deployed with different wireless devices without major modifications.We have tested our solution with real web-servers and our results show thatthe protocol can achieve upto 80%, 65% and 45% savings for one, two and fouractive connections respectively.



ii



Acknowledgments

The thesis was conducted in Data Communications Software Lab at Departmentof Computer Science and Engineering, Aalto University.

I owe my deepest gratitude to Associate Professor Christian W. Probst (DTU)and Associate Professor Peter Sjodin (KTH) for supervising the thesis work.

I especially want to thank my instructor, Zhihua Jin, for his extended supportand active collaboration during all stages of the thesis. His constructive criti-cism, encouragement and excellent advice has kept me focused and has led meto the completion of the project.

I would like to thank Matti Siekkinen for the stimulating discussions that I’vehad with him and his feedback on numerous topics has certainly been valuable.

I am grateful to Mohammad Ashraful Hoque, who was involved in the initial

phases of the project and contributed with his interesting ideas and solutions.

I wish to thank my parents who have always been a source of inspiration andmotivation for me. Nothing would have been possible without their blessingsand constant guidance. I am thankful to my accommodating brother and myloving sister for their support and encouragement.

Espoo, 30th June 2010

Ahmad Nazir Raja



iv



Abbreviations and Acronyms

AP Access Point

APSD Automatic Power Save Delivery

BSS Basic Service Set

CAM Constantly Awake Mode

CSMA Carrier Sense Multiple Access

CSMA/CA Carrier Sense Multiple Access/Collision Avoidance

CSMA/CD Carrier Sense Multiple Access/Collision Detection

CTS Clear to Send

DCF Distribution Coordination Function

DNS Domain Name Server

DTIM Delivery Traffic Indication Map

EBSS Extended BSS

IBSS Independent BSS

IEEE Institute of Electric and Electronic Engineers

IOCTL Input Output Control

I-TCP Indirect TCP



vi

LWE Linux Wireless Extensions

MIMO Multiple Input Multiple Output

MSR Mobility Support Router

MSS Maximum Segment Size

PCF Point Coordination Function

PSM Power Save Mode

PSMP Power Save Multi-Poll

PSNA Power Saving Network Protocol

PSP Power Save Protocol

PS-Poll Power Save-Poll

PSM-T PSM-Throttling

RTS Request to Send

RTT Round Trip Time

S-APSD Scheduled Automatic Power Save Delivery

STA Station

STPM Self-Tuning wireless network Power Management

TCP Transmission Control Protocol

TIM Traffic Indication Map

U-APSD Unscheduled Automatic Power Save Delivery

UDP User Datagram Protocol

VoIP Voice over Internet ProtocolWE Wireless Extensions

WLAN Wireless Local Area Network

WMM-PS Wifi Multimedia-Power Save

WNI Wireless Network Interface

WNIC Wireless Network Interface Card



vii



viii Contents



Contents

Abstract i

Acknowledgments iii

Abbreviations and Acronyms v

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 IEEE 802.11 Power Management 52.1 IEEE 802.11 WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Power Save Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Performance of PSM . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Extensions and Other Techniques . . . . . . . . . . . . . . . . . . 11

3 Related Work 13

4 Client-centric Traffic Shaping - PSM Throttling 174.1 PSM Throttling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Modifications to PSM Throttling . . . . . . . . . . . . . . . . . . 22

5 Design 255.1 Design Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 The Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 28



x CONTENTS

5.4 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Implementation 316.1 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.3 WNI Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.4 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.5 Protocol Tuning Parameters . . . . . . . . . . . . . . . . . . . . . 426.6 Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Experimentation and Results 477.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 Protocol Parameter Values . . . . . . . . . . . . . . . . . . . . . 477.3 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . 487.4 Single Connections . . . . . . . . . . . . . . . . . . . . . . . . . . 507.5 Multiple Connections . . . . . . . . . . . . . . . . . . . . . . . . . 547.6 Discussion and Future Work . . . . . . . . . . . . . . . . . . . . . 63

8 Conclusion 65



Chapter 1

Introduction

1.1 Motivation

Mobile computing is currently one of the most popular means for accessing theInternet. Mobile devices with better computation power and greater storagecapacity are being produced at a very fast pace. As these capabilities continueto grow, so does the need for better batteries and their optimal usage. Ourresearch is motivated on the same lines i.e. optimal usage of energy in mobiledevices without having any affect on the performance as perceived by the user.

Wireless cards use considerable amount of energy when idle. To overcome this

problem, IEEE 802.11b power saving mechanism is most widely used and isknown as the Power Save Mode (PSM). PSM suggests that the wireless inter-face should be switched to a low power, standby state when idle. However,the implementation of such a technique comes with its own complexities sincedetermining the exact time to switch to and from the low power mode is diffi-cult. Staying awake wastes energy while switching to the low power mode earlyenough might lead to loss of incoming traffic. Further more, the technique canhave an adverse affect on the throughput of connections that undergo bulkydata transfers.

There are a number of strategies that try to fix this issue, some suggest a trade-



2 Introduction

off between performance and energy consumption, some propose usage of poweraware protocols where some suggest the addition of a third entity or proxy be-tween the server and the client responsible for traffic management. Ideally, asolution is required that can be implemented with the least effort and can ef-fectively minimize the time that the wireless device needs to stay in the awakemode without degrading throughput. Hence, the motivation of our researchis implementation of a client-centric technique that can be deployed easily onthe wireless device, maintains throughput and yields better or at least similarresults than existing power saving mechanisms. We have proposed a modifiedversion of the client-centric protocol known as PSM-Throttling (PSMT), for en-ergy efficient usage of wireless network interfaces compliant with IEEE 802.11bstandard. Apart from being client-centric, the main advantage of the proto-

col is that it minimizes energy consumption without having an affect on thethroughput. Furthermore, we show that our modifications help in increasingthe performance of the protocol.

1.2 Related Work

There has been some research on client-centric power conservation strategiesthat focus on yielding better results with a focus on connection throughput.

Yan et al. proposed a client-centric mechanism to maximize sleep intervals byconvincing the server to send data in bursts [25, 26]. However, their solutionincreases the data transmission time as a trade-off. They worked on both typeof connections i.e. the web access and bulk data transfers while testing theirtechnique with single connections at a time. They acquired their results bysimulation the wireless device and the access point. Tan et al. proposed thePSM-Throttling protocol based on a similar client-centric mechanism. PSM-T is capable of minimizing power consumption on TCP-based bulk traffic byeffectively utilizing available Internet bandwidth without degrading the appli-cation’s performance perceived by the user. According to their results, PSM-T

is capable of effectively improving energy savings and/or QoS for bulk transfers[22]. They tested their solution on a single connection at a time. Also, theirimplementation was hardware specific. The mentioned research studies haveformed the basis of our work.

1.3 Scope

The scope of our work is limited to mobile devices that are equipped with the

802.11b wireless cards. We have tested our solution in an infrastructure wireless



1.4 Methodology 3

network whereas it should also work fine in an ad-hoc configuration because of the client-centric nature of the protocol. We tackle only TCP traffic whichis the most common transport layer protocol used for both web browsing andbulk data transfers (i.e. file downloads as well as multimedia streaming). Theprotocol requires a stable and constant traffic flow to function and therefore it ismost suitable for applications that require bulky data transfers. Our techniqueis based on exploiting the TCP’s congestion control mechanism and hence doesnot support any UDP traffic such as VoIP, DNS queries etc. Furthermore,the protocol is not suitable for applications with sporadic traffic patterns e.g.gaming applications etc. Lastly, the protocol focuses on scenarios in which themobile client is the data receiver. Even though, energy savings while sendingdata is a much simpler case, it is not a very common one in mobile devices and

is not accounted for in our solution.

1.4 Methodology

We have designed and implemented our solution to be portable which enablesdeployment on any machine that runs the Linux Kernel. We have tested oursolution on various machines including Nokia’s N900 that runs the Linux based

Maemo OS. However, the results discussed in this thesis are acquired fromrunning our solution on an IBM z61m Thinkpad running Ubuntu 9.10 (KarmicKoala) and using a LinkSys Wireless Router as the access point. We measure thetotal time saved instead of the actual energy consumption of the device whichgives us a good idea of the overall energy savings. We believe that the methodyields significantly accurate results as their is a linear relationship between thetime for which the wireless network interface is in the idle state and the actualenergy savings. This approach for approximation of energy savings is discussedin detail in section 7.3. Our research is constructive and empirical in nature aswe implement our solution on a real device and conduct our experiments getresults using real web-servers.

1.5 Outline

Chapter 2 provides a short overview of IEEE 802.11b networks and IEEE 802.11PSM functionality. It also describes performance inefficiencies of PSM and listssome industrial variants that are currently being used to solve these issues.Chapter 3 gives an insight into the related research works. Chapter 4 discusses

the PSM Throttling protocol proposed by Tan et al. in [22]. The chapter



4 Introduction

also includes our suggestions for modifications to the protocol which help inimproving the performance of the protocol. Chapter 5 deals with the designof our solution by discussing the core components and their interaction witheach other. Implementation related details are provided in chapter 6. Chapter7 contains the experiments and their outcomes along with our analysis of theresults and possible extensions to our work. We conclude the thesis in chapter8.



Chapter 2

IEEE 802.11 Power

Management

The most basic form of power management in wireless devices is specified inthe IEEE 802.11 standard, referred to as the Power Save Mode (PSM) [ 19]. Inorder to understand PSM functionality, it is important to know how differentcomponents within a wireless network interact as specified by the standard.

2.1 IEEE 802.11 WLAN

There are four basic components of a wireless network [14]: the Station (STA),the Access Point (AP), the Wireless Medium and the Distributed System (DS).The Stations are the entities that carry wireless network interfaces. These areeither laptops, mobile phones etc. Wireless networks are built so that data canbe transferred between these mobile devices. The Access Points perform thefunction of wireless-wired bridging and are responsible for relaying traffic toand from the Stations. The Distributed System is the logical entity responsiblefor relaying traffic from one wireless network to another with the help of AccessPoints. These individual networks when connected together are collectivelyknown as a Distributed System whereas the most basic wireless network can

also be referred to as a Distributed System.



6 IEEE 802.11 Power Management

The Basic Service Set (BSS) is the basic building block of the 802.11 network.It comprises of a group of stations (with or without an access point) that com-municate with each other. BSSs can be chained together with some backbonetechnology into a larger network called the Extended BSS (EBSS). The BSS canbe of two types:

1. Independent BSS: The Independent BSS or IBSS is a group of sta-tions that communicate with each other in an ad-hoc manner. Each sta-tion within the network must communicate with another station directly.Therefore, all target stations must be in range of the sender since there isno traffic relaying entity. Also, because of the absence of a central entity,

power management within an IBSS is very complex.

2. Infrastructure BSS: Within an infrastructure BSS, all stations commu-nicate with each other with the help of access points. The stations don’tneed to be in range of each other to communicate, they just need to beable to communicate with the access point. One of the main advantagesof infrastructure networks is that since the access points are the centralentity, they are aware of the conditions of every station in the BSS. Thismakes power management easier as access points can temporarily bufferdata for stations that are trying to conserve energy.

There are two coordination functions specified in 802.11 standard, which areused to control access to the wireless medium: the Distribution Coordination Function (DCF) and the Point Coordination Function (PCF). The DCF uses acarrier sense multiple access (CSMA) scheme to control access to the underlyingtransmission medium. Unlike the Ethernet or wired-LAN, DCF uses a collisionavoidance scheme (CSMA/CA) instead of collision detection (CSMA/CD) whichreduces traffic on the medium. The concept is that whenever a station needs totransmit data, it sends a Request-to-Send (RTS) signal which is responded bya Clear-to-Send (CTS) signal by the receiver. The RTS signal helps in silenc-

ing all stations which receive the signal. Similarly, the CTS signal also silencesstations in the immediate vicinity and also reserves the medium for some timeperiod. The data exchanges one frame at a time and every frame is acknowl-edged. Keeping in mind the power consumption of the stations, the RTS andCTS signals constitute of a large volume of traffic and also incur additionallatency before the transmission starts. Hence, the mechanism consumes signif-icant amount of energy. A threshold can be set on the size of the frame calledthe RTS-threshold which determines whether RTS/CTS signals should be ex-changed before data transmission or not. PCF is built on top of DCF and is usedwhen contention-free service is required. The PCF is not widely implemented

[14].



2.2 Power Save Mode 7

2.2 Power Save Mode

According to [19], the wireless network interface card (WNIC) can be in eitherthe Awake or in the Doze state. When operational, the wireless device canbe either Transmitting , Receiving , Waiting or Idle. Since maximum energy isrequired to keep the WNIC in the awake state, 802.11 PSM focuses in transitionthe WNIC to the Doze state when idle, without sacrificing connectivity.

The 802.11 standard specifies power management strategies for both the infras-tructure and independent wireless networks. In infrastructure networks, thetask is relatively simpler as all traffic is routed through the access points. The

access points are in a position where they can buffer incoming data for dozingstations and send it to them when requested. On the other hand, power conser-vation in ad-hoc networks is complex and not as efficient. The sender is reliedupon to ensure that the receiver is active. Receivers need to be more awake andcan not sleep for same periods of time as in infrastructure BSSs.

Even though the standard defines strategies for conserving power within ad-hoc networks, most of the wireless devices do not support the functionality.The reason is that ad-hoc networks are usually created for very limited timee.g. Data transfer, conference call etc. The vendors don’t invest their time in

implementing something which is not used by the end user or rarely required.The focus of our work is also limited to infrastructure BSS networks, which weuse for conducting our experiments. However, our solution should work fine inan ad-hoc configuration as well.

2.2.1 PSM in Infrastructure BSSs

The access point is the logical center of an infrastructure BSS and is assumedto have access to continuous power unlike the mobile stations. Therefore, it is

an ideal candidate that can be held responsible for power management for allassociated stations. The main idea behind 802.11 PSM is that the access pointmaintains a record of the stations currently operating in PSM, and buffers thepackets addressed to these stations until either the stations specifically require toget the packets by sending a polling request, or until they change their operationmode. The stations need to inform the access point when and for how long theyintend to sleep so that data can be buffered for them until they wake up orget out of power save mode. Synchronization is the key for smooth functioningof PSM. The access point is responsible for sending signals called the beaconsat regular intervals of time, usually 100ms. The beacons contain the time-

stamp and all listening stations have to synchronize themselves accordingly.




Figure 2.1: Basic PSM Operation in an Infrastructure BSS

The beacons also contain the traffic indication map (TIM) which is a virtualbitmap indicating that unicast data is buffered for specific stations. It is thestation’s responsibility to respond to the TIM to fetch its data from the accesspoint. The station does this by sending a PS-Poll control frame to the accesspoint requesting for the buffered data. The station in PSM can resume sleepingin the following two conditions: if the incoming data frame doesn’t carry anyindication that more data is buffered for it at the access point or it receives aTIM saying that there is no data buffered for that station.

In case of multicast traffic, a special type of traffic indication map is used calledthe Delivery Traffic Indication Map (DTIM). The multicast data is delivered tothe stations immediately after the beacon containing DTIM is sent. The accesspoint is configured to send DTIM containing beacons after certain number of beacons. Multicast traffic is not buffered for the stations and therefore everystation must wake up for the beacon containing the DTIM if it wants to receivemulticast data.

All stations need to listen to the beacons even if they are in the power savingmode. However, stations can be configured to sleep for longer periods of time

by setting a listen interval parameter. This parameter determines the number



2.3 Performance of PSM 9

Figure 2.2: Increase in wait time

of beacons that the station can ignore before waking up again. The parameteris also a contract between the station and the access point since the access pointneeds to agree if it can buffer data for the station for that period of time. Byconfiguring the listen interval with a high value, the station is able to save moreenergy at a cost of higher latency.

2.3 Performance of PSM

The main strategy behind PSM is to switch the mobile device’s WNIC to a lowpower state whenever it is idle. Unfortunately this technique does not accountfor the time when the device is waiting for data to arrive. This situation caneasily occur when the access point is handling multiple clients. The standarddoes not specify any limit on the waiting time for the client after sending aPS-Poll control frame. There is a high probability that the PS-Poll frames arenot responded to immediately, forcing the client to stay active till it receives itsdata or gets an indication that no more data is buffered for it. Chandra et al.[10] identified a few limiting factors of the 802.11 power saving mode arguing

that the mechanism is only suitable for data traffic that is sporadic whereas




Figure 2.3: Beacon Transmission gets delayed by ongoing data transfer

multimedia streams tend to be isochronous.

In high contention networks, PSM fails to save significant amount of energy whenthe beacon delivery is delayed due to an ongoing data transfer. In such a case,the beacon transmission has to be delayed till after the ongoing data transfer iscomplete or till the next beacon transmission time arrives. The stations need towake up as scheduled to listen for the beacons since it is not possible for themto predict this scenario. This adds to the total time a station spends waitingand end up wasting energy and degrading throughput.

In general, non-deterministic TIM interval and the associated Wait interval canhave a significant impact on power savings of the device [10]. PSM works wellfor normal web access since the traffic is discontinuous and bursty allowing theWNIC to go into the sleep mode. On the other hand, PSM works poorly dur-ing bulk data transmissions since the WNIC needs to stay active continuously.Krashinsky et al. showed in [17] that PSM had an adverse impact on short TCPconnections whose performance is dominated by the round trip time (RTT) i.e.PSM can cause an increase in RTT from 16-232 %. They also showed that theuse of PSM could lead to performance inversion where TCP may achieve higher

throughput over a lower bandwidth link. Hence, there are two main problems



2.4 Extensions and Other Techniques 11

associated with 802.11b PSM i.e. it is not application-aware and it has poorsupport for multiple clients.

2.4 Extensions and Other Techniques

There are a number of techniques that focus on improving the battery life of wireless devices. However, in this section we discuss on some of the commercialsolutions that concentrate on power saving by minimizing the time that a clientspends in waiting or the idle state.

When a wireless device is operating without any power saving technique, itis said to be in the Constantly Awake Mode (CAM). Wireless devices usuallyoperate in the CAM mode due to fear of throughput degradation and becausepower-saving features are disabled by default. PSM is the most basic formof power management in the 802.11 standard, however there are other powerconservation technologies being used commercially. Most of the techniques arebased on the 802.11 PSM and focus on improving its efficiency. Some of themare listed as below:

1. Power Save Mode - Adaptive (PSM-A): As mentioned in 2.3, PSMhas a number of performance issues. In some cases, PSM has provedto degrade the throughput [10, 17]. PSM-A is a concept which adaptsto the traffic trends deciding whether to use PSM or not. The usualimplementation of PSM-A in wireless cards is to stay in CAM and go inPSM only if no traffic arrives e.g. for 75 ms [22]. The bounded slowdownprotocol is an example which dynamically adapts to network activity anduses PSM accordingly [17]. Intel came up with their own implementationfor adaptive PSM [7]. Cisco products refer to PSM-A as Fast PSP [1].

2. Automatic Power Save Delivery (APSD): The APSD mechanism is

an extension to the standard 802.11 PSM and was introduced in the 8thamendment to the standard i.e. 802.11e. The technique is used for datawith specific QoS levels and has two operating modes i.e. unscheduled and scheduled . With S-APSD, the clients are scheduled to wake up in ascheduled manner to receive their data frames. In U-APSD, the mobilestations can poll the access point for data frames any time they want,provided that no other data transmission is taking place. The techniquesare used in case of real-time transmissions and U-APSD is specially used incases of applications transferring full-duplex data over WLAN e.g. VoIP.The technique also enables polling with the help of outgoing frames. This

minimizes the delay caused by separate polling.




3. Wifi Multimedia-Power Save (WMM-PS): The technique was in-troduced with the development of 802.11e and the Wifi Multimedia spec-ification [24]. This power saving mechanism is based on U-APSD and isoften implemented in handsets. As the name suggests, the main focus hereis power management for multimedia applications.

4. Power Save Multi-Poll (PSMP): PSMP is part of the 802.11n stan-dard for wireless devices with multiple transceivers. The technique con-cerns MIMO-based products since they have the capacity to send out andreceive multiple streams of data at the same time. The technique usesthe U-APSD and S-APSD mechanisms mentioned above. PSMP providesthe same delivery-enable and trigger concepts and it extends the client’s

ability to schedule the frames that it transmits which trigger the deliveringthe down-link frames [11]. The mechanism reduces contention between theclient and the access point and is considered to be appropriate for heavytraffic loads.

5. Spatial Multiplexing Power Save: Spatial Multiplexing Power SaveMechanism is a concept that was also introduced in the 802.11n standardwith the PSMP technique [11] . It has two operational modes: staticand dynamic. In static operational mode, the MIMO-based radios can beswitched down to less aggressive radio configurations e.g. 1x1 from 3x3which means only one transmitter and one receiver will be working. In

the dynamic mode, the wireless device can wake up other radios whenrequired.

6. Wake-on-Wireless: The Wake-on-Wireless is a strategy similar to thewake-on-LAN technique that is frequently seen in the Ethernet adapters.To reduce the idle power, the device is essentially shut-down and its wire-less network card when the device is not being used and can be poweredon with an incoming frame [21] .

Most of the solutions being used in the industry use a trade-off between energy

savings and throughput. In the following chapter, we discuss PSM-Throttlingor PSM-T protocol and propose our solution for energy conservation based onit. We have selected the PSM-T protocol as the basis of our work because of its capacity to minimize energy consumption while maintaining the throughput.Other than this unique characteristic of the protocol, it is client-centric whichenables relatively easy deployment. However, our solution can also be usedadaptively by determining when it’s use will prove to be more beneficial.



Chapter 3

Related Work

The use of PSM is the most basic approach for power conservation in case of mobile devices carrying 802.11b wifi cards. However, A number of performancerelated inefficiencies are attributed to the well known 802.11b power savingmechanism [10, 17].

In an attempt to decrease the affect of PSM on throughput, PSM-A or adaptivePSM is most widely used in the industry. The concept is to keep the WNICin CAM when there is a possibility of arrival of data and only switch to PSMif no more incoming traffic is predicted. This technique performs much betterin terms of throughput than the regular PSM but doesn’t save as much energyin some cases e.g. Web Access. The mechanism has a number of commercial

variants [7, 1].

There has been significant amount of research based on just minimizing theactive time of the wireless device so that the WNIC can be switched to the sleepmode as often as possible. In an attempt to improve standard PSM in a similarmanner, Krashinsky et al. came up with their own variant called the Bounded Slowdown (BSD) protocol. The BSD protocol dynamically adapts to networkactivity while guaranteeing that a connection’s RTT does not increase by morethan a factor p over the base RTT. They showed that PSM has an adverse affecton RTTs since it rounds them to the beacon interval time e.g. 20 ms RTT will

be rounded to 100ms where beacon interval is 100ms. They also showed that



14 Related Work

PSM can incur a performance inversion affect where TCP may achieve higherthroughput over lower bandwidth. Even though the BSD protocol is effectivein saving energy for web sessions as compared to the PSM and also avoidssignificant delays, the goal of BSD protocol is to reduce energy consumptionduring periods of user think times and not during transmission times. A similartechnique that follows the adaptive concept is Self-tuning wireless network power management (STPM). STPM adapts to application access patterns, networkinterface characteristics, and the system on which it is running [4].

Another approach of reducing the idle power to a minimum is Wake on WLAN [21]. The solution suggests that the client should just go to sleep whenever itis not receiving packets and the access point should be responsible for waking

up the client. Even though this solution has high potential for energy saving,it requires modification within the hardware of the mobile client. Also, thefunctionality at the access point needs to be implemented so that it can signalthe client to wakeup or sleep.

Some studies suggest that the transport layer should me modified for powerawareness. Bakre et al. came up with Indirect-TCP (I-TCP) by arguing thatTCP, as a transport layer protocol, is not suitable for mobile devices and theycompared their solution with BSD protocol [6]. I-TCP splits the standard TCPconnection into two connections: one between the access point and the mobile

client and the other between the access point and the server. The access pointis responsible for bridging the connections and hence is called the Mobility Sup-port Router (MSR). I-TCP avoids the throughput degradation caused by thecombined effect of the packet loss in the wireless network and the congestioncontrol mechanism. Based on this work, there has been some research on powerconservation of the whole machine rather than just the wireless device [18]. Toachieve both the TCP reliability and better power consumption, Anastasi et al. came up with Power Saving Network Architecture (PSNA), an extension of I-TCP [12].

Another area of research is the use of proxies for better energy consumption.

Chandra et al. identified that 802.11 PSM doesn’t work well in case of mul-timedia streams and came up with a server-side proxy solution for shapingmultimedia streams [10, 9]. They showed that server-side application specifictraffic shaping along with client-side history based prediction could save upto80% energy required for network reception. However, their focus was on onlypopular multimedia formats. Shenoy et al. also came up with a proxy basedsolution [20]. The idea was to use a proxy that resides at the access point andschedules the traffic in such a way that the mobile client’s power saving mecha-nism, being 802.11 PSM, is used optimally. The main problem with proxy basedsolutions is that they require a change at the access point. Shaping data for

specific multimedia formats is a separate challenge making the proxy solution



15

more complex.

Most of the above mentioned techniques require a change in the access point, theclient’s hardware or the transport protocol being used. Client-centric solutionshowever focus on just modifying the client to get better energy conservation.BSD and STPM are client based solutions but they don’t have to capability tocontrol the sender’s behavior for better power consumption at the client’s end.Based on this concept, Chan et Al. proposed the Ack Regulator to improveTCP performance on a 3G wireless link by regulating the flow of acknowledg-ments back to the sender [8]. Yan et al. proposed a client-centric scheme forconserving energy by reshaping the TCP traffic into bursts and switching theWNIC into sleep mode between the bursts [25]. The technique lacks specific

consideration for streaming traffic and trades-off between the data transmissiontime and energy consumption. The trade-off works fine for normal web accessbut can have an adverse affect for some bulk transmissions such as TCP basedvideo streaming. Yan et al. compared their strategies with 802.11b PSM andthe bounded slowdown protocol using their former work [26]. They use the tech-nique for two basic applications: Web browsing and Large File Downloads orBulk Transfers. Their results showed that for web browsing, the technique saved21% energy compared to PSM and incurred less than a 1% increase in trans-mission time compared to regular TCP. For large file downloads, the schemesaved 27% energy on average with a transmission time increase in 20%. They

tested with multiple connections while dealing with the first application i.e webbrowsing. However, for bulk transfers they performed their tests using a singleconnection. Wireless device was simulated in case of both [25, 26] which is aseparate challenge and requires the solution to be hardware dependent.

Using the techniques in [25], Tan et al. came up with a similar client centricmechanism which they called PSM Throttling (PSM-T) which is capable of minimizing power consumption on TCP-based bulk traffic by effectively utilizingavailable Internet bandwidth without degrading the application’s performanceperceived by the user. The main objective was to maintain the throughput of the TCP connection, specifically a video stream. The technique was compared

with the following power modes: awake mode or the CAM, 802.11b PSM, PSM-A and the client-centric approach developed by Yan et al. [25]. Their resultsshow that PSM-T is capable of effectively improving energy savings (upto 75%)and/or QoS for bulk transfers. However, this work also deals with a singleconnection.

There are other solutions as well that give the receiver or the mobile clientin this case the capability to control the sender’s behavior such as Reception Control Protocol (RCP) [16] or TCP-Real [23]. However, these are new pro-tocols and require development on both connection ends. Our work is based

on the client-centric strategies proposed in [22, 26], specifically the PSM-T pro-



16 Related Work

tocol. The protocol requires modification at the client end only. We focus onusing the mentioned client-centric techniques to handle multiple connections byholistically shaping TCP traffic.



Chapter 4

Client-centric Traffic Shaping

- PSM Throttling

As already discussed in earlier sections, one of the most efficient ways to savepower is by turning the WNI to a standby state when no packets are arriving orbeing sent. In case of outgoing traffic, the state of the WNI can be controlledbut it is very difficult to predict the arrival times of incoming traffic with ahigh degree of probability. Due to this fact, the WNI has to be kept in the

awake state which wastes energy. Even though, with 802.11 PSM, the accesspoint synchronizes sending of packets at regular intervals allowing the WNI atthe mobile client to sleep in between, it can affect the throughput of the TCPconnection and is not an optimum solution for bulk data transfers. Also, the802.11 PSM implementation in different access points differ and don’t alwaysperform as they are supposed to and can further degrade the throughput.

This chapter describes a client centric technique for traffic shaping called PSMThrottling proposed by Tan et al. in [22], along with a few modifications. Weimplement the modified version for enhanced performance and test it for the

thesis.



18 Client-centric Traffic Shaping - PSM Throttling

4.1 PSM Throttling

PSM Throttling is a technique that detects unused bandwidth between theserver and the client and uses it to shape traffic and increase predictability of packet arrival. High predictability of incoming traffic can be used to switch thestate of the WNI for energy efficient communication.

PSM Throttling is client centric and unlike 802.11 PSM, it does not requireadditional infrastructure support. The technique is application independentand can minimize power consumption for TCP-based bulk data transfers. Thetechnique effectively utilizes available Internet bandwidth without degrading the

application’s performance as perceived by the user [22].

In order to understand the working of the technique, it is important to under-stand the TCP Flow Control Mechanism which is discussed in the followingsection.

4.1.1 TCP Flow Control

Figure 4.1: TCP Windowing Flow Control

TCP uses a windowing mechanism to control the flow-rate between the senderand the receiver. The sender sends a predetermined number of bytes to theclient and waits for acknowledgement before sending more data. The maximumnumber of bytes that the sender is allowed to send to the receiver is determined

with the help of Receiver Window Size that the receiver sets in every acknowl-



4.1 PSM Throttling 19

Figure 4.2: TCP Windowing Flow Control with Persist Timer

edgement. The sender can not send more data until the previously sent data isacknowledged by the receiver.

A receiver may also set the window size with a zero value which means thatit’s buffer is full and can not accept any data. In such a case, the sender stopssending data and waits for a window update from the receiver. However, in casethe window update gets lost, the sender is required to probe the receiver for thewindow update after a certain amount of time. TCP uses persist timers whichdetermine the wait time before probing the receiver. The probe is sent in theform of a TCP Keep Alive packet which is simply a request for the receiver tosend back an acknowledgement, which by default also contains the window size.As the name suggests, TCP Keep Alive packet helps in determining whether theTCP connection has terminated or not. The TCP Keep Alive is simply a TCPACK with zero payload. The mechanism helps in protecting the TCP from adeadlock situation where the sender and client stop communicating, mainly due

to network problems.

4.1.2 Protocol Design

PSM Throttling relies on the fact that there can be unused bandwidth be-tween the server and the client and uses it to minimize energy consumptionwithout sacrificing throughput. Therefore, the technique consists of two parts:Bandwidth Throttle Detection and Traffic Burst Generation . The first part de-

termines whether the protocol should enter the burst generation mode or not.




4.1.2.1 Bandwidth Throttle Detection

Multimedia servers such as Youtube and Google Video use a pseudo-streamingtechnique to deliver content [15], which means that the data is sent in smallbursts. In such a case, it is easy to identify whether there is unused bandwidth ornot. However, in case of other multimedia servers that provide a steady streamof data, it is not as evident to figure out whether they throttle bandwidth ornot. Unused bandwidth can be detection with a quick bandwidth throttling

detection algorithm with a low overhead.

The basic concept behind throttle detection is to exploit the TCP flow controlmechanism where the client chokes and un-chokes the connection to determinewhether there is un-utilized bandwidth or not. The client chokes the connectionby sending an ACK with window size set to zero. On reception of the ACK, TCPat the server-side stops sending any data to the client but the application layerof the server keeps on sending data to it’s TCP. The data keeps on accumulatingin the TCP’s buffer. The client, after some time, sends an acknowledgement

with the proper window size signaling the server that it is ready to receive data.Once, this packet is received by the server, the data stored in the buffer of TCPis sent in a burst. On reception of the burst, the client can determine whetherthe throughput of the connection is controlled by the server or not, with thehelp of the total bytes in the burst and time taken for the transfer.

For efficient execution of the detection algorithm, RTT for the TCP connectionis required. TCP time-stamp option is normally enabled for most TCP basedservices and the same can be used to calculate the RTT. The algorithm begins

with the calculation of the flow-rate r , which takes place after some time T (where T >5 secs). Next, the client sends a choke ACK to the server i.e. bysetting the receiver window size in the ACK to zero. This restricts the serverfrom sending more packets, however the client might keep getting data for aRTT as packets take half RTT to reach the server. In case of throttle detection,the server’s transport layer buffers the data sent by the application layer until itgets a window update. The connection is unchoked by the client by restoring theoriginal window size after 2RTT and the new flow-rate r’ is calculated for 2RTT* r number of bytes. If r’ >r , it means that more than half of the bandwidthbetween the server and the client is not being utilized and can be exploited to

save energy at the client side.



4.1 PSM Throttling 21

Figure 4.3: Traffic Burst Generation

4.1.2.2 Traffic Burst Generation

A concept similar to the one used during throttle detection is used to generatebursty traffic. The client sends ACKS with specific window sizes and then waitsfor the amount of data to arrive. On the arrival of the first packet, the clientacknowledges it by sending a choke ACK preventing the server to send in moredata. The client keeps on receiving data for 1 RTT after having sent the chokeACK. The client counts the number of bytes it receives and sends an open ACKonce all the expected data has arrived. If the time taken to receive the burst is

T recv and the interval between is called T idle so that total burst time T burst isequal to the sum T burst = (T recv + T idle), then it makes sense to shift the WNIto the sleep state for time period T idle as long as it is non-trivial (i.e. T idle ≥RTT).

It is very important to set the value of the receiver window size small enoughthat that all the data can arrive within an RTT. If the number of bytes, asspecified in the window size, takes more than 1 RTT to reach the client, thenthe algorithm will fail as the subsequent choke ACK will prevent the server fromsending more data and the client will keep on waiting for the data to arrive.

Therefore, an appropriate sized window should be set to avoid any deadlock.




On the other hand, a very small sized window will also lead to a lot of overheadand protocol might consume more energy than normal.

4.2 Modifications to PSM Throttling

PSM Throttling protocol is the basic technique for energy savings that we usedfor our work. However, we have proposed a few changes to the protocol design:

1. Use of Timers to transition between states: During the T recv periods of bursty traffic generation, the client waits for all the expecteddata to arrive. If for some reason, there is a loss of data, the client willkeep on waiting. This is because the client chokes the connection on thefirst acknowledgement and the server is stopped from sending in moredata. This causes a temporary deadlock until the server sends a TCPKeep Alive packet to check if the connection is alive or not. We proposethat timers should be used, and if no packets arrive after the client havingsent a choke ACK, the connection will stop waiting for data and send anopen ACK to resume TCP communication. This reduces the time periodT recv to a minimum i.e. maximum value can be 1 RTT. This slightmodification can help reduce the overall idle time.

2. Use of TCP Keep Alives: As explained above, there can be scenar-ios where the protocol might get stuck in a deadlock. The use of TCPKeep Alives can be very useful to quickly resume data transfer withoutdegrading throughput of the connection.

3. Keeping the TCP functionality intact: The PSM Throttling pro-tocol proposes that the TCP functionality should be slightly modified togenerate bursty traffic. According to the protocol description in [22], dur-ing bursty traffic generation, only the first packet arrived after sendingan open ACK is acknowledged by sending back a choke ACK. The au-thors don’t mention whether other packets should be acknowledged ornot. Also, retransmission is a complex scenario which should be handledby TCP itself. TCP might acknowledge all the packets coming in or mightacknowledge certain packets in a burst depending on it’s implementation.We are of the opinion that the new protocol should be implemented as asupporting mechanism rather than a modification to the TCP stack. Mod-ification of TCP leads to numerous problems which should be avoided.

4. Determining the Window Size: The authors of the protocol haven’t

specific how to chose the appropriate size of the receiver window size.



4.2 Modifications to PSM Throttling 23

Making the right choice is very important as a higher value might lead toa temporary deadlock, as explained above, and a very low value can causeextra overhead.

5. Multiple Connections: The original protocol was implemented andtested with only a single connection. In order to make the protocol usablein real life scenarios, the states of multiple connections using the proto-col need to be monitored so that the state of the WNI can be controlledaccordingly.



Chapter 5

Design

5.1 Design Objectives

Designing the overall solution requires us to make some important decisions.Following are the most important factors that we kept in mind while designingthe solution:

1. Least Hardware Dependency and Portability: Even though, con-trol of the wifi device might need some sort of modification of the devicedriver, the implementation of the psm protocol should be independent of

the hardware and it should be possible to implement the protocol withother wireless devices.

2. Existing Protocol Stack Behavior: There should be no (or least) mod-ification of existing functionality of the protocol stack. The end solutionshould supplement the protocol stack, not modify their behavior. Thiswill also help in reducing the communication overhead.

3. Quick Execution: Since, the overall energy saved depends on how oftenthe WNI is transitioned to the sleep state, it is important to make thesedecisions quickly. Hence, the execution time of the protocol should be

sufficiently fast.



26 Design

4. Low Computation Overhead: It is important to keep a balance be-tween the energy saved and extra energy consumed due to communicationand computation overhead. It should be kept in mind that computationoverhead should be kept to a minimum as it can adversely effect the overallenergy consumed.

5. Ease of Deployment: A solution that requires an infrastructuralchange is difficult to deploy. Since PSM Throttling is a client centricprotocol, it is easy to deploy. However, it should be kept in mind that thesolution should not be dependent on some other software dependencieswhich might make it difficult to deploy.

5.2 The Components

The solution can be mainly divided into three components, the Traffic Shaping Protocol , the Scheduler and WNI control . The traffic shaping protocol is solelyresponsible for increasing the predictability of incoming packets and informingthe scheduler about the idle times. The scheduler’s job is to keep track of theidle times of all the TCP connections and invoking the WNI control componentaccordingly. The WNI control component is responsible for transitioning the

state of the wireless network interface card based on the individual TCP con-nection states. In implementation, the traffic shaper and the scheduler can begrouped together but the WNI controller has to be kept separate. This sepa-ration is necessary for satisfying one of the important design goals i.e. LeastHardware Dependency and Portability. As the WNI control part is hardwaredependent, it is very difficult to come up with a single portable solution capableof performing all tasks.

The components are discussed individually in the following sections:

5.2.1 Traffic Shaping Protocol

The function of the traffic shaping protocol is to increase the predictability of incoming packets so that the underlying device can be put to sleep as often aspossible. As already discussed, the technique used to perform this task in ourcase is PSM Throttling. The protocol is client centric, application independentand focuses on energy savings for TCP-based bulk transmission without sig-nificantly affecting the throughput. The protocol is designed to work with thelatest Linux kernel (ver 2.6.31-20 at the time of implementation). This means

that the protocol shapes TCP-based traffic on any device which runs a Linux



5.2 The Components 27

Figure 5.1: Placing the PSM-T protocol in the TCP/IP model

kernel. This design decision has helped us test the solution on different Linuxmachines.

The protocol is required to operate between the network and data-link layer of the TCP/IP protocol stack within the Linux Kernel so that it has access to theTCP and IP information for both outgoing and incoming packets. The posi-tioning of the protocol between the network and data-link layer means that theimplementation has to reside inside the kernel for interception and modificationof packets. Although writing code in the kernel space is more challenging and

time consuming, it helps to reduce computation overhead and decrease codeexecution time.

We have chosen to use the hooks provided by the Netfilter Framework for packetinterception and modification. The Netfilter Framework is a subsystem withinthe Linux Kernel and forms the basis for programs such as Iptables, the popularfirewalling tool for Linux. By using Netfilter hooks, the protocol can be deployedin the form of a kernel module and can be installed or removed while the kernelis running. Also, this enables us to keep the implementation separate from the

core Linux Kernel code making it more manageable.



28 Design

5.2.2 Scheduler

The scheduler is called when there is a change in the state of the TCP connectioni.e. idle or busy. Whenever the scheduler is called, it checks all the connectionstates and if all of them are idle, it asks the WNI control component to transitionto the sleep state. This model of the scheduler is very simple and passive innature as it does not influence the behavior of the connections. However, moreadvanced techniques can be used to schedule the traffic and synchronize theconnections for maximum energy savings, which we leave for future versions of the protocol.

5.2.3 WNI Control

This component is basically responsible for changing the state of the WirelessNetwork Interface or WNI i.e. to and from the sleep state when the PSMThrottling Protocol is in operation. However, in cases where PSM Throttlingis not considered to perform sufficiently well or in case of normal web accessrather than bulk transfers, the device should operate in PSM. Though PSMmight affect the throughput of the connection, it is the default solution to saveenergy for most wireless devices. We have chosen the Linux Wireless Extensions

(LWE) to transition between operation modes i.e. CAM and PSM.

The Wireless Extension (WE) is a generic API allowing a driver to expose tothe user space configuration and statistics specific to common Wireless LANs.As long as the wireless driver supports Wireless Extensions, a single set of toolcan support all the variations of Wireless LANs, regardless of their type [ 3].Also, since these parameters may be changed on the fly without restarting thedriver (or Linux), it is a good choice in our case.

Even though LWE is slowly being replaced with other technologies, it is still the

most prevalent technique for configuring the wireless device and is supportedwith almost all the drivers.

5.3 Design Overview

The three components mentioned above together can be called the EC module(short for Energy efficient Client Centric Communication). Figure 5.2 gives abig picture of where the module resides. As established before, the module re-

sides within the kernel space, part of it overlaps the Netfilter framework and



5.3 Design Overview 29

Figure 5.2: Design

the particular component overlapping is responsible for interception and modi-fication of TCP packets. Other part is responsible for scheduling and changingthe states and operational modes of the wireless device. Ideally, we would liketo talk to the wifi device to switch the WNI state but it requires modificationof the device driver itself which is a tedious task. To transition between CAMand PSM, Linux Wireless Extensions are used.

The solid lines represent the data flow where the data is generated and receivedby the user-space application which can be a browser, media player, FTP client

etc. The data is passed to the kernel so that it is processed by the TCP/IP stackon its way out or in. It also passes through the Netfilter framework and throughthe hooks where we have placed our code for traffic shaping. The dashed linesshow how the operational mode of the wifi device is controlled. The figure onlyshows the use of Linux wireless extensions to transition between CAM and PSMand does not describe control of the WNI state which is a hardware dependentfunction.

We have deliberately tried not to use any user-space application since it can havea negative impact on the performance of the kernel module. However, activities

such as waiting for some event to happen or simply delaying the packets can be



30 Design

done in the user-space. Techniques are discussed in section 7.6 where packetsmight need to be delayed in order to increase energy savings.

5.4 Debugging

Since, the implementation is supposed to reside in the kernel space, there mustbe some way that the developer can communicate with the module for debuggingpurposes, like dumping the current states of all TCP connections, when the userwants. For this specific reason, we have designed the solution to work with kernel

signals. On the receipt of a signal, the module should be capable of performinga specific task that is relevant to the function under development.



Chapter 6

Implementation

“Nobody really creates perfect code the first time... except me ..but there is only one of me” - Linus Torvalds

To evaluate the efficiency of PSM Throttling for energy savings, we need animplementation for the protocol. As already discussed in previous sections, wechoose the Linux system to build a prototype for the mechanism (kernel ver2.6.31-20 at the time of implementation). Since, we work in kernel space, thebest solution is to come up with a kernel module which is installable duringruntime.

The module should perform three functions: traffic shaping using psm throt-tling, scheduling and controlling the WNI state. However, implementation of the traffic shaping component is the basic objective which should enable us toconduct tests by simulating the wifi device or WNI control.

This section deals with the implementation of the components of the prototype

which we refer to as the EC module.



32 Implementation

6.1 Traffic Shaping

Traffic shaping is the core component of the energy saving mechanism. Thissection discusses how we have implemented the PSM Throttling technique fortraffic shaping and deployed it inside the kernel TCP/IP stack in a modularmanner.

6.1.1 Using Netfilter Hooks

The first consideration for implementation of the technique is where to registerour code within the Linux kernel. The Netfilter Framework is a subsystemwithin the Linux Kernel and forms the basis for programs such as Iptables, thepopular firewalling tool for Linux. By using netfilter hooks, the protocol can bedeployed in the form of a kernel module and can be installed or removed whilethe kernel is running.

The framework provides five positions or hooks where functions can be regis-tered. The hook positions are:

1. Pre-Routing: All the traffic that reaches the machine passes throughthe pre-routing hook. It is not necessary that data arriving is actuallymeant for any local process running on the machine.

2. Post-Routing: All traffic leaving the machine passes through the Post-routing hook. The data reaching this does is not necessarily coming froma local process.

3. Forward: Any data that is not mean for processes running on themachine pass through the forwarding hook.

4. Local In: Traffic intended for local processes pass through the Local Inhook.

5. Local Out: Traffic coming from the local processes pass through theLocal Out hook.

Figure 6.1 represents the five positions that netfilter framework exposes. Itmakes perfect sense that we use the Local In and the Local Out Hooks forregistering our functions to implement the traffic shaping protocol. Intuitively,the function registered at the Local Out hook is responsible for out going packets

and performs tasks such as modification of the receiver window size in the TCP



6.1 Traffic Shaping 33

Figure 6.1: Using appropriate Netfilter hooks

header, if required. Similarly, the function registered at the Local In hookis responsible for all the incoming packets and is responsible for a number of tasks depending on the state of the connection. During Throttle Detection, thefunction determines the payload of the TCP packets and calculates the flowrates. During PSM Throttling, the function keeps track of the amount of dataarrived in a burst and informs the scheduler accordingly. However, both thefunctions need to identify the specific TCP connection that packet belongs tobefore carrying out their tasks.

6.1.2 Connection Tracking

Since, we are intercepting the packets somewhere in the TCP/IP stack and arerequired to take specific actions according to the connection’s state, it is impor-tant to come up with a mechanism to identify and manage the TCP connectionslocally. This will enable the functions registered at the netfilter hooks to per-form appropriately. Hence, the building stone of our protocol implementation

is the connection management library that is used by the registered functions.



34 Implementation

Connections need to be identified with a unique value. To simplify the im-plementation, we have used the client side port as the identifier for the TCPconnections. This means that for all the connections initiated by the client, theconnection identifier will be the source port in outgoing TCP packets whereasfor all the connections initiated by some other machine, the identifier will bethat machines source port in incoming TCP packets. As the client will alwaysinitiate the connection by requesting data from a server, it have a random portwith the value higher than 1024.

It is important to mention here that our traffic shaping protocol will only workin cases where the client is the receiver of the bulk data transfer and the protocolwill fail to shape traffic where the local machine is supposed to send bulky trafficto some other machine, which is a separate problem though a simpler one tohandle. However, our implementation does not affect the existing behavior of the protocols and the client will be able to send bulky data if it wants to butwill not be able to send it in bursts.

6.1.3 Storing Connection Information

The module maintains the states of all the intercepted TCP connections locallyin the form of a linked list and also keeps track of information such as theconnection id, window scale for the connection, maximum segment size, roundtrip time, variance in round trip time. We have used the ‘tcp info’ struct toaccess the mentioned TCP attributes, which can be accessed from the socketbuffer struct (or ‘sk buff’ ) of the packet. Hence, we haven’t done any localcalculations to get these values.

Each instance of the connection also keeps track of states related to operational

modes i.e. Throttle Detection and PSM Throttling. The functions registered atthe local in and local out hooks determine the connection id from the TCP portsof a packet and take actions based on these states. The connection instancesalso keep track of the idle state which simply says that the wifi device can beput to sleep as far as that connection is concerned. It is the responsibility of the scheduler to determine whether all the connections are in idle state beforeasking the WNI control module to transition to the sleep state. The connectioninstances also carry timers which help in transition of the states. Lastly, mutexlocks are also available which can be used in case there is a possibility that twotasks might modify the connection information at the same time. However, we

haven’t detected such a behavior and haven’t used them.




6.1.4 Connection States

The protocol needs to keep track of the TCP states along with the new statesfrom PSM Throttling. We use an 8-bit unsigned integer variable to store stateinformation, where each bit position corresponds to a specific state as shownin Table 6.1. States corresponding to the high values are the ones that theconnection has acquired in its life time. Hence, the state value gives the completehistory of the connection. The current state can be acquired just by looking atthe state name corresponding to the most significant bit of the state variable.

State Value BinarySyn 1 0000 0001Syn Ack 2 0000 0010Established 4 0000 0100Throttle Detection 8 0000 1000Normal Operation 16 0001 0000PSM Throttling 32 0010 0000Closed 64 0100 0000Unknown 128 1000 0000

Table 6.1: State Naming Convention

The first three states Syn, Syn Ack and Established are the states for the TCPhandshake and every connection must go through them. Once the connectionis established, it enters the first state of the protocol i.e. Throttle Detection.If unused bandwidth is detected (two times the used bandwidth) between theserver and the client, the connection enters the PSM Throttling state where isstarts to shape traffic in bursts. Otherwise, the connection just enters the Nor-mal state which is the standard TCP operation. The connection goes into theUnknown state, if TCP handshake is not detected by the module. This normallyhappens when the the module is installed during active TCP connections.

Figure 6.2 shows an example of a connection having state value equal to 47

which means that the connection passed through Syn, Syn Ack, Establishedand Throttle Detection during its life time and is currently operating in thePSM Throttling state. The thread of events that the state value representhas helped us greatly in detecting abnormal behavior and code debugging. Itwouldn’t have been possible for the connection to enter in the PSM Throttlingstate without having passed through any of the earlier states. On the contrary,if the state value does give such information, we can surely say that there issome error in connection management.

Other states specific to the operational modes i.e. Throttle Detection and PSM

Throttling are discussed in the following sections.



36 Implementation

Figure 6.2: Representing Connection States

6.1.5 Throttle Detection

Once the module detects that a TCP connection is established, it tries to detectthe unused bandwidth between the server and the client for the connection. If the detected bandwidth is greater than a certain ratio which we call Bandwidth

Ratio, the connection enters the PSM Throttling state.

The general idea is to measure the flow rate of the incoming data while theconnection is in the Established state and enter the Throttle Detection stateafter some predetermined time (10 secs in our case). The connection is chokedand then unchoked after 2 RTT time. The flow rate is measured again rightafter unchoking the connection for exactly the same amount of time for whichit was choked i.e. 2 RTT. By comparing the two different flow rates, we get thebandwidth ratio. If the ratio is greater than a certain value (2 in our case), theconnection starts generating bursty traffic otherwise resumes its normal TCP

operation.




We have four states to implement the algorithm:

1. Pre-Choke: The throttle detection algorithm is initialized in Pre-Chokestate. The connection enters Post-choke state once a zero size windowadvertisement is sent to the server in the form of an ACK packet. Hence,the transition is event based.

2. Post-Choke: The connection remains in Post-Choke for 2 RTT timei.e. advertise zero window sizes for all the out going acknowledgments,and then transitions to the Open ACK state. It takes half an RTT for thechoke packet to reach the server meaning that the last of the data packets

from the server will arrive after 1 RTT time at the most. We choke theconnection for 2 RTT time period just to be sure in case there is somedelay.

3. Open ACK: The client sends an open acknowledgement to resume theTCP connection. Since, the protocol is not able to create its own ACKpackets, it needs to delay the first ACK that arrived at the local out hookafter the connection was choked. The new flow rate is calculated for 2RTT time after which the connection moves to a No-operation state.

4. No-Operation: No further calculation on the flow rates is done. Based

on the two flow rates, the bandwidth ratio is calculated and a decisionis made whether to go into PSM-Throttling state or resume normal TCPoperation.

Figure 6.3 shows the transitions while the connection is in the Throttle Detectionstate. By convention, the solid lines show even-based transitions whereas thedotted lines show time-based transitions.

6.1.6 PSM Throttling

If the Throttle Detection algorithm detects unused bandwidth (at least twicethe amount of used bandwidth), the connection transitions to the PSM Throt-tling state in order to generate predictable bursty traffic. As the protocol isoperating below the transport and network layer, it only intercepts packets (formodification, if required) and does not create new TCP packets. However, thefunctionality for creation of TCP ACKs is required if reliance on TCP KeepAlives is to be eliminated.

This mode of operation consists of five states of operation explained below:



38 Implementation

Figure 6.3: State Diagram - Throttle Detection

1. Initial Choke: All the data is choked initially for 2 RTT time. Thestate is exactly like the the Pre-choke state during Throttle Detection. Itis necessary to start PSM Throttling by choking the connection completelyso that there is no problem with calculation of data received later on.

2. Initial Wait: The state is exactly like the Post-Choke state duringThrottle Detection. The function registered at the local out hook keepson sending zero sized ACKs. The connection transitions to the AdvertiseWindow State after 2 RTT time.

3. Advertise Window Size: Since, the traffic is choked completely, werely on the TCP Keep Alive packets sent by the server to resume the TCPconnection. A calculated window size is set in the ACK to the TCP KeepAlive packet. The window size is calculated keeping in mind the through-put of the connection which should not change. However, if the throughputchanges, the user might experience some degraded performance.

4. Choke: Once the specific window size is advertised, the function reg-istered at the local in hook starts counting the total data arrived. If packets arrive with zero payload (as in case with TCP Keep Alives), win-

dow size is re-advertised, else a choke ACK is sent in response to the




Figure 6.4: State Diagram - PSM Throttling

arrived data packet(s) after which the connection moves to Receive Pack-ets state. Since, it is normally not possible to get data packets after 1RTT from when the choke ACK was sent, a timer is used to move back tothe Advertise Window Size state after an RTT.

5. Receive Packets: The function registered at the local in hook keeps oncounting packets and once all the data has arrived, the connection movesto advertise window size state. However, if the data doesn’t arrive within1 RTT time, the connection moves to the Advertise Window Size stateanyway due to the timer started during Choke state.

6.1.7 Determining Window Size

Apart from energy efficiency, the advantage of PSM Throttling is that it main-tains throughput. This is achieved only if the window size is correctly advertised.A window size with a higher value will have an adverse impact on the protocol,as the local in hook will keep on waiting for the complete burst (until the timerexpires) which will keep the WNIC awake, affecting the energy savings. On the

other hand, a relatively smaller window size will affect the throughput since



40 Implementation

the number of bytes arriving over a period of time will be less. Hence, it isimportant to keep a check on the throughput and adjust the window sizes of the packets accordingly so that the throughput is maintained.

Initially, the window size is calculated by taking the product of the referencethroughput (detected at the beginning of the connection) and the RTT. Thewindow size is advertised and the resultant throughput is constantly monitoredand the window size adjusted accordingly.

We maintain two thresholds for throughput in our implementation where theeffective throughput must remain in between the specified thresholds. Theupper threshold determines maximum throughput achieved using the proto-

col whereas the lower threshold determines the lowest allowed throughput. Incase the throughput decreases below the lower threshold, the window size is in-creased by the Maximum Segment Size (MSS) which we found to be 1452 bytesin our experiments. The throughput thresholds can be configured as protocoltuning parameters, also discussed in section 6.5.

6.2 Scheduler

The Scheduler is the component of the EC module which keeps track the con-nection states of the locally stored TCP connections along with their idle states.The scheduler is responsible for two tasks: determining wheter the wifi deviceshould operate in PSM Throttling mode or not and if operating in PSM Throt-tling mode, when to transition to the sleep state and when to wake up. Once,these decisions are made, the Scheduler invokes the WNI Control which takescare of modifying the wifi device’s physical state based on the command received.

Our implementation of the scheduler is passive in nature as it is invoked by thetraffic shaping component and can not control the TCP connections’ behavior

on its own. However, an active version of the scheduler is also discussion in 7.6.

6.3 WNI Control

As discussed above, the WNI Control is responsible for two tasks: changing themode of operation i.e. CAM/PSM and if operating in the PSM Throttling state,transition the WNI state to sleep or awake based on the scheduler’s decisions.

It should be kept in mind that while operating in the PSM Throttling mode,



6.3 WNI Control 41

the WNI will remain in CAM and will be instructed to sleep and wake up atcertain times determined by the scheduler.

Linux Wireless Extensions use a set of user-space tools to configure the wirelessdevice which we have used to implement features such as mode switching be-tween CAM and PSM. Even though, LWE are supposed to work from the userspace, we have reverse engineered the IOCTL calls made by commands suchas iwconfig and implemented the same functionality from the kernel domain.Hence, we don’t need to go to the user-space to call the commands. However,the equivalent user-space command for switching to and from PSM is:

iwconfig wlan0 power [on|off]

Also, the PSM mode of operation can be modified using the same technique e.g.changing the timeout or period values. Following are some of the examples of equivalent user-mode operations, respectively:

iwconfig wlan0 power timeout 300u all

iwconfig wlan0 power period 2

The WNI Control component is partly simulated. Since, transitioning to thesleep state is a hardware dependent feature, we have opted not to implement thatpart. We simply accumulate the total time for which the device was supposed tosleep and then compare it with the actual time that the device remained awake.This gives us a good idea of how much time it is possible to sleep while usingPSM Throttling technique which gives us an idea of the ratio to which energycan be saved. We believe that this method of detecting energy savings leads us

to accurate results since the relationship between the time saved and the actualenergy savings is somewhat linear. We further discuss this idea in section 7.3.

Even though we emulate the WNI for our experiments, it is very simple touse our implementation with a real device. We have left stub functions fortransitioning the WNI to sleep and awake states. The stub functions can beimplemented by the user who intends to use the protocol with the hardwaredevice of choice. It is possible to switch between using the emulation and thefunctions by just configuring a protocol parameter EMULATE WNIC. Oncethe parameter is set to ‘0’, the stub functions are called. Hence, plugging our

solution with various types of hardware devices is painless.



42 Implementation

6.4 Debugging

Working inside the kernel is challenging in a number of ways. One of the greatestchallenge is to debug the kernel-space code at runtime where debuggers used foruser-space applications can not be used. The code can not use breakpoints as itaffects the execution of all kernel applications. One solution to debug is use of a virtual machine and kernel specific debuggers. However, since we needed todetermine how the protocol implementation behaves in actual scenarios, we haveimplemented a signal based mechanism between a user-space application andthe kernel module for debugging purposes. Before installing the kernel module,the debug file system or ‘debugfs’ is mounted which is used for writing data by

the kernel module to a predetermined file. The file can be read by the user-spaceapplication for execution status/codes.

Once the kernel module is installed, the user-space application can be used tosend the module an arbitrary signal which is acts as an interrupt to the kernelmodule indicating that it should perform some predefined functionality. Afterhaving sent the signal, the user-space application reads the file in the debugfile system for any data from the kernel module. The kernel module on theother hand performs the specific task such as displaying all connection statesand information on receipt of the signal and writes the execution code to thefile. Once the response is written, the user-space application reads it and exits.

This method of debugging the protocol implementation in real-time helps inanalyzing connection information in actual scenarios and data.

6.5 Protocol Tuning Parameters

In order to achieve accurate prediction of the incoming packets, it is necessary

to tune the protocol parameters properly. This section discusses, the significantparameters that can be modified depending on server load, network conditionsand hardware specifications. Parameters fall into two categories: Algorithmrelated parameters and Hardware or WNIC related parameters.

6.5.1 Algorithm related Parameters

1. Playout Buffer Wait: The play-out buffer wait is the time period thatneeds to be waited at the start of the connection. In case of video stream-

ing, data at a higher rate is sent by the server and the protocol operation



6.5 Protocol Tuning Parameters 43

needs to start after this initial data has been sent. We set this wait timeto 5 secs which is based on the default play-out buffer size of widely usedmedia players such as Windows media player [2, 22].

2. Flow-rate Calculation Period: In order to start throttle detection todetermine unused bandwidth, it is required to detect the normal flow-rate when the connection is established. By comparing the normal flowrate and the flow-rate during throttle detection, unused bandwidth canbe detected. The flow-rate calculation period determines the duration forwhich the normal flow-rate is calculated. It is set to 5 secs in our casewhich gives us a good estimation of the reference flow-rate.

3. Bandwidth Ratio: This is threshold which determines whether to use

PSM Throttling protocol or not, if some un-utilized bandwidth is deter-mined. The connection uses PSMT protocol only if

F Ractual/F Rnormal > BR

where F Rnormal is the normal flow rate of the connection and F Ractual

is the detected flow-rate or the available flow-rate of the connection. BRdenoted Bandwidth Ratio.

4. Choke Factor: The choke factor determine the duration for which thedata is choked during throttle detection. A choke factor of 2 means thatthe data will be choked for 2 RTT time.

5. Maximum and Minimum PSMT Throughput Thresholds: Thethresholds determine the boundaries for acceptable throughput duringPSMT mode of operation. If the throughput falls below the minimumthreshold, the window size is increased which increases the throughput.Similarly, the maximum threshold determines when to reduce the windowsize since it is not possible to achieve more than the normal throughput.The thresholds are stored as percentages of the normal throughput. In ourcase, the maximum threshold is set to 97 whereas the minimum threshold

is set to 95.6. Aggression Factor: The aggression factor is the value which determines

how aggressive is the prediction scheme for incoming packets. During thePSMT state of operation, the WNIC goes to sleep after having receiveda full burst and wakes up 1 RTT after having sent an acknowledgement.However, as a safety precaution it is required to wake a little early astheir can be a slight possibility that the packets might arrive a little earlydepending on the RTT Variance. The safest estimate would be to not waitfor the whole RTT to wake up. We use RTT Variance to calculate a morerealistic waking up time (i.e. RTT - Variance). The aggression factor

determines upto what extent the RTT Variance value should be used to



44 Implementation

calculate the waking up time. Also, it is required to cater for the WNICtransition time (Sleep to Wake) so that no packets are dropped. Hence,the wake up time can be calculated as:

T wakeup = T ack + RT T − (RTTVar ∗ AF )− T T wake

where,

T wakeup = Wakeup time of the WNICT ack = Time of Sending the AcknowledgmentAF = Aggression FactorT T wake = WNIC Transition time from sleep to wake state

6.5.2 Hardware related Parameters

Hardware related parameters need to be tuned keeping in mind the specifica-tions of the underlying wireless device. In order to maintain portability of ourimplementation, these parameters need to be tuned according to the wirelesscard being used.

1. Sleep to Wake Transition Time: In order to receive the packets intime, it is necessary to cater for the WNI transition times specially Sleepto Wake time. According to [22], mode switching overhead i.e. betweenPSM and CAM has been significantly reduced and the authors of thePSMT protocol claimed that this overhead was 4ms for Atheros chipsetWNI. Since, we are talking about only Sleep to Wake transition time andnot the complete mode switch between two different modes of operationi.e. PSM and CAM, we use 3ms as the transition time for our tests. Thereason is that no packets are sent or received during this transition whereas

some packet exchange is required during mode switching.

2. Wake to Sleep Transition Time: The transition time from Wake tosleep states is negligible [5]. Hence, we use 0ms as the transition time fromwake to sleep state.

3. Single Packet Sending Time: We use 1ms as our single packet sendingtime. We believe that it is a safe estimate since a mode switch whichincludes the transition of the WNI from sleep to wake state and alsoexchange of information between the wireless device and the AP, requiresonly 4ms [22]. The time required for a device that is sleeping and needs to

send an acknowledgement can be represented as T T wake + T P packet where



6.6 Other Considerations 45

T T wake is the transition time from sleep to wake state and T P packet is thetime to send the packet. Hence, in our case, the total time required willbe (3+1)ms or 4ms.

6.6 Other Considerations

6.6.1 Security

Applications that reside in kernel space are vulnerable to security issues sincethe code executes with root privileges. Since our implementation also residesin kernel space, it opens doors to security issues. Further more, a single nullpointer error can cause the system to crash. We have tried our best to eliminateany such flaws in our code and have made the code robust but since securitywasn’t the primary concern for the thesis, there might be unknown scenariosin which the implementation could be exploited. A thorough security analysisof the solution has been left for future as it was considered out of scope of theproject.

6.6.2 Sending Bulky Traffic

PSMT protocol tackles the scenarios where the user is receiving bulky traffic.For cases where the user is required to send bulky traffic is not a primary focusof the protocol and is a separate problem altogether. However, implementationof such a scenario is comparatively easier as user can control sending of the dataand therefore control the WNI accordingly.

6.6.3 Sporadic Traffic

The protocol works fine for bulky TCP connections but will not work for trafficpatterns which are sporadic in nature such as gaming applications. In such ascenario, the wifi can be transitioned to CAM by the help of intelligent trafficpattern recognition, so that throughput is not affected.



46 Implementation



Chapter 7

Experimentation and Results

7.1 Setup

As our implementation works on any Linux kernel, we had a variety of op-tions to chose from before conducting our tests. We performed basic sanitytests on different Linux machines including Nokia’s N900 and got positive re-sults. However, all the experiments and results discussed in this section havebeen acquired by running our implementation of the PSM-T protocol on anIBM z61m ThinkPad (Intel Core Duo 1.83GHz T5600, 1 GB RAM) runningUbuntu 9.10 (Karmic Koala). The network controller used was Intel Corpora-

tion PRO/Wireless 3945ABG using iwl3945 wifi driver. The access point weused for our tests was Linksys Compact Wireless-G Broadband Router (Model:wrt54GC v2.0).

7.2 Protocol Parameter Values

We have used the following protocol tuning parameters for getting results, which

are also discussed in detail in section 6.5.



48 Experimentation and Results

Parameter ValuePlay-out Buffer Wait 5 secsFlow-rate Calculation Period 5 secsBandwidth Ratio 2Choke Factor 3Max Throughput Threshold 97Min Throughput Threshold 95Aggression Factor 1/2Sleep to Wake Transition Time 3 msecsWake to Sleep Transition Time 0 msecsSingle Packet Sending Time 1 msecs

Table 7.1: Protocol Tuning Parameters

7.3 Experiment Design

Our parameter for energy savings is idle time of the connection i.e. the timefor which the connections are predicted to be in the idle state and for whichthe WNI can be put to sleep. We believe that this method of determiningenergy savings leads us to accurate results as the relationship between actualenergy saved and the idle time is linear. The energy consumption while thedevice is active depends very little on the operating state [13] and for thatreason a constant value is usually used for calculating the energy consumption.For Enterasys Networks RoamAbout interfaces, energy consumption while thedevice is in active state is about 750mW and during idle is 50mW [17]. Also, theenergy consumption during sleep to wake transition is almost the same as thatin active state whereas energy consumption is negligible while transitioning fromwake to sleep state [17]. We have also seen linear relationship between energyconsumption and idle time detected from the works of Tan et al. in [22]. Hence,by accurately predicting the time for which the WNI can be put to sleep, wecan have a relatively accurate idea of how much energy can be saved by using

PSM-T protocol.

Most of our tests were performed on real web-servers such as Youtube. Wetested the protocol for stable connections (constant flow-rate from server side)as well as for connections encountering fluctuations from the server. We testedthe solution for multiple connections and tried to emulate the WNIC to seethe combined affect of all the connections actively using the PSM-T protocol.We have tried to acquire and analyze three factors from the experiments: thestability of the protocol, performance threshold and throughput maintenance,which are discussed in the following sections. Furthermore, we have tried to

discuss the factors which have an effect on the overall energy savings.



7.3 Experiment Design 49

7.3.1 Stability

The stability of the connection depends on how much energy is saved as timepasses by. Hence, the factor can be achieved by plotting the idle time (IT) withthe connection time lapsed (TL). A linear relationship shows stability of theprotocol however fluctuations from the server might affect this linear relation-ship.

7.3.2 Performance Threshold

Performance threshold determines how quickly the protocol achieves signifi-cantly acceptable performance. This factor determines when can the protocolbe used for good results i.e. the protocol might not perform well for connectionsthat only last a few seconds. We try to determine the least duration of theconnections for which the protocol can be useful.

The threshold can be determined by plotting the accumulated savings over timewith the time lapsed since the connection was established (or entered PSMTstate). Accumulated Savings can be represented as:

AS = (IT/TL) ∗ 100

where,AS = Accumulated SavingsIT = Idle TimeTL = Time Lapsed

7.3.3 Throughput Maintenance

It is important to see how the protocol maintains throughput over a period of time with reference to the flow-rate detected a the beginning of a connection.We plot the throughput achieved by the PSM-T protocol with the connectiontime lapsed. The graph helps in visualizing the dynamic window advertisementmechanism and how throughput is maintained between the predefined through-put thresholds. Also, a fluctuation in the graphs shows that the stability of the

protocol is affected.




7.4 Single Connections

As mentioned in the previous section, we determine three factors from each test,the stability, performance threshold and throughput maintenance. Figures 7.1,7.2 and 7.3 show the results of using PSM-T protocol for a single connection.The attributes for the connection that we tested are provided in table 7.2:

Attribute ValueLink http://www.youtube.com/watch?v=

VpfSrINjhr0&playnext_from=TL&videos=GE_

hhBo3dTs&feature=rec-LGOUT-exp_fresh%2Bdiv-1r-9-HM

Description Play guitar Blues lick of week minor pentatonic bluesscale on fender strat and free jam tracks

RTT 46RTT Var 22

Table 7.2: Connection Attributes

Figure 7.1 is a graph acquired by plotting the idle time detected by the PSM-Tprotocol with the time lapsed since the connection entered the PSMT state.The connection time lapsed does not account for the initial 10 secs for the play-out buffer and flow-rate calculation. It can be observed that the relationship islinear which means that the protocol is capable of providing a constant level of energy savings.

Figure 7.2 is a graph acquired by plotting the percentage of savings i.e. (IdleTime/Time Lapsed) * 100, with the time lapsed. This graph helps in deter-mining the threshold after which the protocol provides maximum accumulativesavings. It can be observed that the value converges to 75% which means thatif the protocol is used for a significant amount of time, it is capable of giv-

ing about 75% of savings. Also, the accumulative savings rise above 70% afterhaving spent approximately 100 secs in the PSMT state or a total of 110 secssince connection establishment. This time marks the threshold which can be adecision factor for the usage of PSM-T protocol i.e. if a connection is supposedto stay active for about 2 minutes, the protocol will be effective in maximizingenergy savings.

Figure 7.3 deals with how the protocol maintains the required throughput. Asalready mentioned, our minimum and maximum throughput threshold levels are95 and 97 respectively. This means that the protocol is required to maintain

the connection’s throughput in between these two levels while minimizing energy

http://www.youtube.com/watch?v=VpfSrINjhr0&playnext_from=TL&videos=GE_hhBo3dTs&feature=rec-LGOUT-exp_fresh%2Bdiv-1r-9-HM










7.4 Single Connections 51

Figure 7.1: Stability of a Single Youtube stream using PSM-T protocol

Figure 7.2: Accumulated Savings of the PSM-T protocol over time




Figure 7.3: Throughput Maintenance using the PSM-T protocol

usage. As seen from the figure, there is an initial spike which can be explainedas the data is choked right before the connection enters the PSMT state. Afterthe initial stabilization period, the protocol maintains the required throughput

by dynamically adjusting the advertised window sizes.

7.4.1 Effect of Fluctuations

We tried to see the effect of fluctuations on the energy savings and throughputfor a connection using the protocol. The attributes of the connection tested aregiven in table 7.3 :

Attribute ValueLink http://www.youtube.com/watch?v=

RPuQF5PkwWg&playnext_from=TL&videos=

3pd8zvHLtCQ&feature=rec-LGOUT-exp_fresh%

2Bdiv-1r-4-HM

Description How to play blues lead guitar soloing lesson solo skillsRTT 41RTT Var 19


http://www.youtube.com/watch?v=RPuQF5PkwWg&playnext_from=TL&videos=3pd8zvHLtCQ&feature=rec-LGOUT-exp_fresh%2Bdiv-1r-4-HM










7.4 Single Connections 53

Figure 7.4: Fluctuations in a single Youtube stream using PSM-T protocol

Figure 7.5: Accumulated Savings with fluctuations from the Server




Figure 7.6: Throughput Maintenance with fluctuations from the Server

Figure 7.4 and 7.5 show that the protocol stopped saving energy for some time atapproximately 240 secs and 420 secs. This can be explained from figure 7.6 which

shows that the flow-rate decreased below a certain level (95% of the referenceflow-rate) at the exact same times. This can be marked as a fluctuation from theserver side where it failed to maintain the flow-rate. However, the protocol triedto maintain the maximum flow-rate possible at the cost of energy savings. Assoon as the required flow-rate was achieved, the protocol started saving energyagain. It can be observed that the fluctuations had an effect on the savings,giving us about 55% accumulated savings. By using more lenient throughputthresholds, the energy savings can be increased at the cost of throughput.

7.5 Multiple Connections

We conducted tests on multiple connections running the PSM-T protocol andemulated the WNIC the combined effect of all the connections on the overall

savings.



7.5 Multiple Connections 55

7.5.1 Two Active Connections

Figure 7.7 presents sets of results for two separate Youtube connections runningon the PSM-T protocol, which were setup about 30 secs apart. Attributes forthe connections are listed in table 7.4.

Connection 1Link http://www.youtube.com/watch?v=

e5HHl-SQRIo&feature=related

Description Guitar Lesson learn pinch harmonics or artificial har-monics

RTT 39RTT Var 24

Connection 2Link http://www.youtube.com/user/rockongoodpeople#

p/u/0/bQsDRY4oQjA

Description Learn how to play guitar ska reggae dub easy songsrhythm techniques

RTT 40RTT Var 29


It can be observed from figure 7.7 that connection#1 is more stable than con-nection#2 as we see a relatively more linear relationship between the idle timeand the total time lapsed. Also, the slight fluctuations affect the accumulativesavings for connection#2.

Figure 7.8 represents the combined affect of both the connections on the over-all energy savings. It can be observed at there is a marked decrease in theaccumulated savings at about 40 secs which is the time at which the secondconnection entered the PSMT state. For the two connections, we were able toachieve about 65.89% energy savings, only accounting for the time when theconnections were in the PSMT state. However, if the initial overhead is alsoconsidered for both the connections, the total energy savings over a period of 480 secs is about 64.44%.

http://www.youtube.com/watch?v=e5HHl-SQRIo&feature=related


http://www.youtube.com/user/rockongoodpeople#p/u/0/bQsDRY4oQjA









Figure 7.7: Results for two connections using PSM-T protocol




Figure 7.8: Accumulative effect on savings - Emulating the WNI with two activeconnections using PSM-T protocol




7.5.2 Four Active Connections

In this section we discuss the results of running four Youtube connections setupabout 20 secs apart. This means that once a connection is setup, it takes about30 secs for the next connection to enter PSMT state. Since the graphs showeffects of connections in PSMT state only, we expect to see some fluctuation atabout 30 secs intervals in the overall energy savings.

Table 7.5 contains the links of the four connections used along with the RTTand RTT variance values measured by the transport layer.


e5HHl-SQRIo&feature=related

Description Guitar Lesson learn pinch harmonics or artificial har-monics

RTT 45RTT Var 23

Connection 2Link http://www.youtube.com/user/rockongoodpeople#

p/u/0/bQsDRY4oQjA

Description Learn how to play guitar ska reggae dub easy songsrhythm techniques

RTT 44RTT Var 24


P99dj8j1xVM&feature=related

Description Ska Reggae guitar lesson in style of SublimeRTT 41RTT Var 13


lMMkibA5uvM&feature=channel

Description Guitar lesson: String Bending Blues & ROCK How toplay

RTT 45RTT Var 22


Figures 7.9 and 7.10 present sets of three graphs for each connection. As dis-

cussed earlier, the first graph represents the stability of the protocol in the form





http://www.youtube.com/watch?v=P99dj8j1xVM&feature=related


http://www.youtube.com/watch?v=lMMkibA5uvM&feature=channel













Figure 7.9: Results for the 1st and 2nd connection using PSM-T protocol




Figure 7.10: Results for the 3rd and 4th connection using PSM-T protocol




of a linear relationship between the time saved or idle time and the total time.The second graph shows how quickly the PSM-T protocol reaches its maximumperformance level and the third graph shows how the protocol maintains the re-quired throughput by dynamically adjusting the window sizes to be advertised.It can be observed that apart from some fluctuation at around 230 secs in con-nection#1, all other connections are fairly stable. This fluctuation is expectedto be seen in the overall energy savings graph which is acquired by emulating theWNIC. We see that due to the fluctuations, connection#1 achieves slightly lessamount of savings i.e. 70% as compared to those of connection#2, connection#3and connection#4 which provide more than 80% percent savings.

With reference to the time required to achieve maximum performance, we see

that connection#2 and connection#4 only take about 120 secs (2 minutes) togive about 75% savings whereas connection#1 and connection#3 take some timeto stabilize, due to which they achieve peak performances relatively later. Thiscan be explained with the additional time required to stabilize as seen from thethroughput maintenance graph. During these periods, the protocol stops savingenergy at the cost of maintaining the throughput. As already discussed in sec-tion 7.4.1, energy savings can be increased by lowering the minimum throughputthreshold parameter.

Figure 7.11 represents the combined effect of the active connections on energy

savings. It is evident that the relationship between the idle time and timelapsed is not as linear nor as steep as that of individual connections, depictingthe combined affect of all the connections on the savings. It seems that therelationship is more steeper after 390 secs which is due to the termination of connection#1 and subsequently other connections. Since each connection issetup after 20 seconds from the previous one, it takes about 30 secs for nextconnection to enter the PSMT state. The graph with accumulated savingsplotted over time shows that the combined energy savings stabilize after 90secs which is the time when all four connections enter the PSMT state. Thereis a decrease in accumulated savings at about 220 secs which is the effect of connection#1 facing fluctuations. We see that it is possible to achieve 44%

savings over a period of 390 secs (termination time of connection#1).




Figure 7.11: Accumulative effect on savings - Emulating the WNI with fouractive connections using PSM-T protocol



7.6 Discussion and Future Work 63

7.6 Discussion and Future Work

We have observed from the experiments that our implementation of the PSM-Tprotocol is capable of yielding positive results, provided there are no fluctuationsfrom the server side. However, in case of fluctuations, energy savings can beincreased by setting up more lenient throughput threshold levels. We have seenthat most of the connections achieve their peak performance after 120 secs or 2minutes. This information can be used to determine whether the protocol shouldbe used or not. The duration of the connection can be approximated with thehelp of reference throughput detected at the beginning of the connection andtotal bytes to be transferred.

PSM-T is a mechanism of energy savings that relies on transitioning the WNIto the sleep state between two bursts. Hence, larger the interval is, greater arethe savings. Therefore, this method proves to be more effective in cases whenthe connection’s RTT is large. Larger the RTT, greater are the savings. Theirony is that higher RTTs are known to adversely affect the throughput of theconnection. Furthermore, connections with a greater RTT, usually have highvariance which limits the protocol in saving more energy.

However, RTT of a connection can be artificially increased by adding a constant

delay, delta , at the client end. Theoretically, it can be argued that as long as theadvertised window size is equal to the bandwidth-delay product, the protocolshould function just fine without any affect on the throughput. In our case,the bandwidth is not the actual link capacity between the server and the client,but the reference or normal flow-rate calculated at the start of the connection.This means that it should be possible to increase energy savings without havingany affect on throughput by artificially increasing the RTT by delta along withappropriate increase in the advertised window size so that the following equationholds true:

F Rnormal ∗ (RT T + detla ) = W S

where,

F Rnormal = Reference or normal flow-rate, detected at the beginning of theconnectionRT T = Actual round trip time of the connectiondelta = The artificial delay added to the RTTW S = The advertised window size




However, this artificial increase might have some affect on the throughput inreal life scenarios. One of the possibilities include increasing the RTT to morethan a certain limit in which case the server might start sending TCP KeepAlive packets. For example if the value of RTT+delta is more than the timervalue after which the server sends the Keep Alive packets, the throughput willbe affected. Also, if some packets are lost during the connection, it will takerelatively more time to send back the acknowledgments. The overhead in thementioned scenarios can affect the throughput of the connection. We leave thistechnique to further maximize savings for future work.

Another domain where energy savings can be maximized is by re-designing theway the scheduler component works. Currently, the scheduler behaves in a very

passive manner. It is invoked by the traffic shaper component when the stateof the connection is changed. All that scheduler does is listen for signals andinvoke the WNI Control if all the connections are in the idle state. Since, thescheduler is aware of the states of all the connections and their attributes, itcan be designed to intelligently increase the connections’ RTT to synchronizethe burst reception of all the connections. The RTT can be artificially increasedusing the techniques mentioned above. Though re-designing the scheduler insuch a manner can help in increasing overall savings, there are a few issues thatneed to be accounted for. Other than the problems associated with increasingthe RTT, the active scheduler can fail when if it tries to synchronize unstable

connections. Even if one of the connections is not stable, resynchronizationmight affect all the active connections. Hence, active scheduling has to be beintelligently designed by keeping in mind erroneous scenarios.

Our implementation of the protocol is portable in nature. It can be used on anyLinux based machine as long as the wireless driver is modified to take commandsfor transitioning between wake and sleep states. Once the wireless driver is readyto receive such commands, the stub functions in the WNI Control componentof our implementation can be easily modified to call the respective functions.Hence, the protocol can be tested for actual results instead of using the featurefor emulation of WNI. We have left this work for future due to limited time.

Since it is not possible for a single protocol to yield the best results in all cases,we believe that the PSM-T protcol should be used with other energy savingmechanisms, each mechanism responsible for a specific scenario. Keeping inmind such a configuration, we have also developed the functionality to transitionbetween modes of operation such as PSM and CAM. The functionality uses theLinux Wireless Extensions and can be effectively used if PSM is considered tobe more efficient, based on the type of connections e.g. Normal Web Accessinstead of bulk transfers.



Chapter 8

Conclusion

PSMT protocol is a client centric and application independent protocol, suitablefor energy savings in bulky TCP connections. The beauty of the protocol liesin the fact that it saves energy without compromising the throughput of theconnection i.e. it remains the same as perceived by the user. We have suggesteda few modifications to the PSMT protocol and have implemented the modifiedversion so that the end solution is portable as long as it runs with a LinuxKernel. Hence, our implementation can be used with different hardware devicesand is uniquely different from the original implementation of the protocol whichwas hardware dependent. In our opinion, the modifications further maximizethe energy savings and we have shown that in our experiments and results.Furthermore, our implementation of the protocol complements standard TCP

functionality and does not require modifications to it. We have tested oursolution with real web-servers and have found that the protocol yields positiveresults in most cases. In case of fluctuations, our solution tries to maintainthe throughput at the cost of less energy savings. However, the protocol canbe tuned to give more energy savings in such a scenario. We believe that theprotocol is a highly suitable alternate energy saving mechanism for bulky datatransfers and where throughput is the main concern. Applications that canhighly benefit from the protocol are file downloads and video/audio streamingservices that use TCP as their transport layer protocol. However, the protocol isnot suitable if the traffic is sporadic in nature such as normal web Access, gaming

applications etc. Furthermore, the protocol is not targeted for applications using



66 Conclusion

the UDP protocol and hence will not work for applications such as VoIP clientsetc.

It is safe to argue that there is no single mechanism that proves to be the bestin terms of energy savings and throughput for all cases and all sorts of trafficpatterns. We believe that by identifying each scenario, the appropriate energysaving mechanism can be selected for operation. Hence, the PSM-T protocolcan be used with a number of other energy saving mechanisms, each responsiblefor yielding the best possible results for a specific scenario. The client-centricnature of the PSM-T protocol enables easy deployment in such a configuration.In support of the arguments stated, we have implemented the functionality totransition between CAM and PSM and by intelligently identifying each sce-

nario, PSM-T protocol or the widely deployed IEEE 802.11 PSM can be usedaccordingly for maximum energy savings.



68 BIBLIOGRAPHY

[8] Mun Choon Chan and Ramachandran Ramjee. Tcp/ip performance over3g wireless links with rate and delay variation. In MobiCom ’02: Proceed-ings of the 8th annual international conference on Mobile computing and networking , pages 71–82, New York, NY, USA, 2002. ACM.

[9] Surendar Chandra. Wireless network interface energy consumption impli-cations of popular streaming formats. In In MMCN , pages 85–99, 2002.

[10] Surendar Chandra and Amin Vahdat. Application-specific network man-agement for energy-aware streaming of popular multimedia formats. InATEC ’02: Proceedings of the General Track of the annual conference on USENIX Annual Technical Conference, pages 329–342, Berkeley, CA, USA,2002. USENIX Association.

[11] Cisco. 802.11n: The Next Generation of Wireless Performance, 2009.

[12] Marco Conti and Willy Lapenna. A power saving network architecture foraccessing the internet from mobile computers. Design, Implementation and Measurements, The Computer Journal , 46:3–15, 2003.

[13] Laura Marie Feeney and Martin Nilsson. Investigating the energy consump-tion of a wireless network interface in an ad hoc networking environment.In In IEEE Infocom , pages 1548–1557, 2001.

[14] Matthew S. Gast. 802.11 Wireless Networks: The Definitive Guide.O’Reilly, April 2002.

[15] Lei Guo, Songqing Chen, Zhen Xiao, and Xiaodong Zhang. Analysis of multimedia workloads with implications for internet streaming. In WWW ’05: Proceedings of the 14th international conference on World Wide Web ,pages 519–528, New York, NY, USA, 2005. ACM.

[16] Kyu-Han Kim, Yujie Zhu, Raghupathy Sivakumar, and Hung-Yun Hsieh.A receiver-centric transport protocol for mobile hosts with heterogeneouswireless interfaces. Wirel. Netw., 11(4):363–382, 2005.

[17] Ronny Krashinsky and Hari Balakrishnan. Minimizing energy for wirelessweb access with bounded slowdown. In MobiCom ’02: Proceedings of the8th annual international conference on Mobile computing and networking ,pages 119–130, New York, NY, USA, 2002. ACM.

[18] Robin Kravets, Karsten Schwan, and Ken Calvert. Power-aware communi-cation for mobile computers. In In 6th Intl. Workshop on Mobile Multimedia Communications, 1999.

[19] LAN/MAN Standards Committee of the IEEE Computer Society. WirelessLAN Media Access Control (MAC) and Physical Layer (PHY) Specifica-

tion , June 2007.



BIBLIOGRAPHY 69

[20] Prashant Shenoy, Peter Radkovdepartment, and Computer Science. Proxy-assisted power-friendly streaming to mobile devices. In In MMCN , pages177–191, 2003.

[21] Eugene Shih, Paramvir Bahl, and Michael J. Sinclair. Wake on wireless:an event driven energy saving strategy for battery operated devices. InMobiCom ’02: Proceedings of the 8th annual international conference on Mobile computing and networking , pages 160–171, New York, NY, USA,2002. ACM.

[22] Enhua Tan, Lei Guo, and Songqing Chen. Psm-throttling: Minimizingenergy consumption for bulk data communications in wlans.

[23] V. Tsaoussidis and C. Zhang. Tcp-real: receiver-oriented congestion con-trol. Comput. Netw., 40(4):477–497, 2002.

[24] WiFi Alliance. WMMTM Power Save for Mobile and Portable Wi-Fi RCERTIFIED Devices, 2005.

[25] Haijin Yan, Rupa Krishnan, Scott A. Watterson, David K. Lowenthal, KangLi, and Larry L. Peterson. Client-centered energy and delay analysis fortcp downloads. In In IEEE International Workshop on Quality of Service,2004.

[26] Haijin Yan, Scott A. Watterson, David K. Lowenthal, Kang Li, Rupa Kr-ishnan, and Larry L. Peterson. Client-centered, energy-efficient wirelesscommunication on ieee 802.11b networks. IEEE Transactions on MobileComputing , 5(11):1575–1590, 2006.

ahmad nazir raja

Documents