Saving energy in network hosts with an application layer proxy :

Saving energy in network hosts with an application layer proxy :

Material Information

Saving energy in network hosts with an application layer proxy : design and evaluation of new methods that utilize improved bloom filters
Jimeno, Miguel
Place of Publication:
[Tampa, Fla]
University of South Florida
Publication Date:


Subjects / Keywords:
Data structures
Energy efficiency
Performance evaluation
Network applications
Dissertations, Academic -- Computer Science and Engineering -- Doctoral -- USF ( lcsh )
non-fiction ( marcgt )


ABSTRACT: One of the most urgent challenges of the 21st century is to investigate new technologies that can enable a transition towards a society with a reduced CO2 footprint. Information Technology generates about 2% of the global CO2, which is comparable to the aviation industry. Being connected to the Internet requires active participation in responding to protocol messages. Billions of dollars worth of electricity every year are used to keep network hosts fully powered-on at all times only for the purpose of maintaining network presence. Most network hosts are idle most of the time, thus presenting a huge opportunity for energy savings and reduced CO2 emissions. Proxying has been previously explored as a means for allowing idle hosts to sleep yet still maintain network presence. This dissertation develops general requirements for proxying and is the first exploration of application-level proxying. Proxying for TCP connections, SIP, and Gnutella P2P was investigated. The TCP proxy keeps TCP connections open (when a host is sleeping) and buffers and/or discards packets as appropriate. The SIP proxy handles all communication with the SIP server and wakes up a sleeping SIP phone on an incoming call. The P2P proxy enables a Gnutella leaf node to sleep when not actively uploading or downloading files by handling all query messages and keyword lookups in a list of shared files. All proxies were prototyped and experimentally evaluated. Proxying for P2P lead to the exploration of space and time efficient data structures to reduce the computational requirements of keyword search in the proxy. The use of pre-computation and hierarchical structures for reducing the false positive rate of a Bloom filter was explored. A Best-of-N Bloom filter was developed, which was shown to have a lower false positive rate than a standard Bloom filter and the Power-of-2 Bloom filter. An analysis of the Best-of-N Bloom Filter was completed using Order Statistics to predict the false positive rate. Potential energy savings are shown to be in the hundreds of millions of dollars per year assuming a modest adoption rate of the methods investigated in this dissertation. Future directions could lead to greater savings.
Dissertation (Ph.D.)--University of South Florida, 2010.
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains X pages.
General Note:
Includes vita.
Statement of Responsibility:
by Miguel Jimeno.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
E14-SFE0003309 ( USFLDC DOI )
e14.3309 ( USFLDC Handle )

Postcard Information



This item has the following downloads:

Full Text
xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 22 Ka 4500
controlfield tag 007 cr-bnu---uuuuu
008 s2010 flu s 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0003309
XX9999 (Online)
1 100
Jimeno, Miguel.
0 245
Saving energy in network hosts with an application layer proxy :
b design and evaluation of new methods that utilize improved bloom filters
h [electronic resource] /
by Miguel Jimeno.
[Tampa, Fla] :
University of South Florida,
Title from PDF of title page.
Document formatted into pages; contains X pages.
Includes vita.
Dissertation (Ph.D.)--University of South Florida, 2010.
Includes bibliographical references.
Text (Electronic dissertation) in PDF format.
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
3 520
ABSTRACT: One of the most urgent challenges of the 21st century is to investigate new technologies that can enable a transition towards a society with a reduced CO2 footprint. Information Technology generates about 2% of the global CO2, which is comparable to the aviation industry. Being connected to the Internet requires active participation in responding to protocol messages. Billions of dollars worth of electricity every year are used to keep network hosts fully powered-on at all times only for the purpose of maintaining network presence. Most network hosts are idle most of the time, thus presenting a huge opportunity for energy savings and reduced CO2 emissions. Proxying has been previously explored as a means for allowing idle hosts to sleep yet still maintain network presence. This dissertation develops general requirements for proxying and is the first exploration of application-level proxying. Proxying for TCP connections, SIP, and Gnutella P2P was investigated. The TCP proxy keeps TCP connections open (when a host is sleeping) and buffers and/or discards packets as appropriate. The SIP proxy handles all communication with the SIP server and wakes up a sleeping SIP phone on an incoming call. The P2P proxy enables a Gnutella leaf node to sleep when not actively uploading or downloading files by handling all query messages and keyword lookups in a list of shared files. All proxies were prototyped and experimentally evaluated. Proxying for P2P lead to the exploration of space and time efficient data structures to reduce the computational requirements of keyword search in the proxy. The use of pre-computation and hierarchical structures for reducing the false positive rate of a Bloom filter was explored. A Best-of-N Bloom filter was developed, which was shown to have a lower false positive rate than a standard Bloom filter and the Power-of-2 Bloom filter. An analysis of the Best-of-N Bloom Filter was completed using Order Statistics to predict the false positive rate. Potential energy savings are shown to be in the hundreds of millions of dollars per year assuming a modest adoption rate of the methods investigated in this dissertation. Future directions could lead to greater savings.
Advisor: Kenneth Christensen, Ph.D.
Data structures
Energy efficiency
Performance evaluation
Network applications
Dissertations, Academic
x Computer Science and Engineering
t USF Electronic Theses and Dissertations.
4 856


Saving Energy in Network Hosts With an Application Layer Proxy: Design and Evaluation of New Methods That Utilize Improved Bloom Filters by Miguel Jimeno A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Kenneth Christensen, Ph.D. Rafael Perez, Ph.D. Miguel Labrador, Ph.D. Stephen Suen, Ph.D. Rahul Tripathi, Ph.D. Date of Approval: December 11, 2009 Keywords: Data structures, energy efficiency, perfo rmance evaluation, proxying, network applications Copyright 2010, Miguel Jimeno


To God, my wife, and my family.


Acknowledgements I would like to thank my advisor at USF Dr. Kennet h Christensen. His support has been important for me to grow as a researcher during the 4 years I hav e stayed in Tampa. I express my sincere thanks to D r. Rafael Perez, Dr. Miguel Labrador, Dr. Stephen Suen and Dr. Rahul Tripathi for serving on my committe e. I would also like to thank Bruce Norman, for his he lp on the topic of power management of network host s. His work and support has been a guide in my researc h. I thank Dr. Allen Roginsky for his assistance on the mathematical part through the sections of Chapter 4 I appreciate the help provided by Beverly Caggian o, from the USF Library, who provided a list of 2 mill ion book titles used in Chapter 4 to evaluate searc h algorithms presented. I express also my deepest gra titude to my wife for her constant support in this journey even in the troublesome moments.


i Table of Contents List of Tables iii List of Figures iv Abstract vii Chapter 1: Introduction 1 1.1 Background 1 1.1.1 Energy Use of ICT Equipment 1 1.1.2 Energy Savings Opportunities 3 1.2 Motivation for Research 4 1.3 Contributions Made in This Research 6 1.4 Organization of This Dissertation 7 Chapter 2: Background and Literature Review 9 2.1 Overview of Power Management for ICT Hosts 9 2.1.1 Power Management in Wireless Devices 13 2.2 Induced Power Consumption in Network Hosts 14 2.2.1 Client-Server Applications as a Cause of In duced Energy Use 15 2.2.2 P2P Applications as Cause of Induced Energy Use 20 2.3 Overview of the Gnutella P2P File Sharing Prot ocol 22 2.3.1 Query-Based Protocol 23 2.3.2 Tasks of a Leaf Peer and Ultrapeer 24 2.4 Existing Approaches to Save Energy Wasted Due to Induced Use 25 2.5 Network Connectivity Proxying (NCP) for Power Management 28 2.5.1 Early Work in Proxying of ARP 30 2.5.2 Proxying for UPnP 31 2.5.3 Current and Recent Efforts to Define and St andardize Proxying 32 2.6 String Search Algorithms and Data Structures 33 2.6.1 Hash Tables 33 2.6.2 Bloom Filters 35 Applications of Bloom Filters 38 2.6.3 Algorithms for String Searching 41 2.7 Chapter Summary 43 Chapter 3: Proxying as a Means of Reducing Induced Energy Use 44 3.1 General Requirements for a Network Connectivit y Proxy (NCP) 45 3.2 Covering TCP Connections 48 3.2.1 Design of gSOCKS 49 3.2.2 Prototype Implementation 52 3.2.3 System Evaluation 54 3.3 Covering Application Protocols – SIP 57 3.3.1 Design of SIP Catcher 57 3.3.2 Prototype Implementation 61


ii 3.3.3 System Evaluation 62 3.4 Chapter Summary 66 Chapter 4: Improved Probabilistic String Search Wit h an Application to P2P Proxying 67 4.1 Requirements for Better Probabilistic String S earch Methods 68 4.2 The Best-of-N Method for Bloom Filters 68 4.2.1 Design and Implementation 68 Generating Hash Values With an RNG Metho d to Reduce Execution Time 70 4.2.2 Analysis 71 4.2.3 Experimental Evaluation 77 4.3 Two-Tier Bloom Filter 82 4.3.1 Design and Implementation 83 4.3.2 Analysis 84 4.3.3 Experimental Evaluation 85 4.4 Signature Array Hash Table (SAHT) 87 4.4.1 Design and Implementation 88 4.4.2 Analysis 89 4.4.3 Experimental Evaluation 92 4.5 Bloom Filter Based Keyword Search 93 4.5.1 Design and Implementation 94 4.5.2 Analysis 96 4.5.3 Experimental Evaluation 97 4.6 Chapter Summary 101 Chapter 5: Design and Evaluation of a Gnutella P2P Proxy 103 5.1 Specific Requirements for a Gnutella P2P Proxy 103 5.2 Stateless P2P Proxy 105 5.2.1 Design 105 5.2.2 Prototype Implementation 108 5.2.3 Experimental Evaluation 109 5.2.4 P2P Application State Conservation With the P2P Stateless Proxy 112 5.3 Stateful P2P Proxy 113 5.3.1 Design 113 5.3.2 Prototype Implementation 118 5.3.3 Experimental Evaluation 120 5.3.4 P2P Application State Conservation With the P2P Stateful Proxy 123 5.4 Chapter Summary 124 Chapter 6: Summary and Directions for Future Resear ch 125 6.1 Predicted Energy Savings From Application Leve l Proxying 126 6.2 Directions for Future Research 126 References 129 About the Author End Page


iii List of Tables Table 4.1. Summary of Best-of-N Method Improvement 75 Table 4.2. Best-of-N Method (for N =100) Against Power-of-2 Improvement 75 Table 4.3. Numerical Results for SAHT 92 Table 4.4. Numerical Results for Bloom Filter 92 Table 4.5. Experimental Results for SAHT 93


iv List of Figures Figure 1.1. 2006 US Electricity Usage (Not to Scal e) [101] 2 Figure 2.1. Power Consumption Versus Utilization 12 Figure 2.2. Yahoo Messenger IM System Architecture 16 Figure 2.3. Magic Jack Device for VoIP Phone Calls 18 Figure 2.4. Components and Start of a Communication with SIP [117] 19 Figure 2.5. Timing Diagram for the Start of a SIP C all 20 Figure 2.6. Timing Diagram for File Querying in a P 2P Gnutella Network 24 Figure 2.7. Magic Packet Format 26 Figure 2.8. Verdiem Surveyor Infrastructure [137] 27 Figure 2.9. Operation of an NCP 28 Figure 2.10. Hash Table Algorithms to Add a String and to Find a String 34 Figure 2.11. An Example of a Bloom Filter [20] 36 Figure 2.12. Bloom Filter Algorithms to Add a List of Strings and Test a String 37 Figure 2.13. Power-of-2 Algorithms From Lumetta and Mitzenmacher [86] 40 Figure 3.1. System View of the NCP 45 Figure 3.2. Packet Processing by the NCP 47 Figure 3.3. Architecture of the NCP 50 Figure 3.4. Architecture of Power State Signaling 51 Figure 3.5. The Target System: Linksys WRT54G 52 Figure 3.6. Test-Bed to Evaluate gSOCKS 55 Figure 3.7. Results From IM Experiment 56 Figure 3.8. Architecture of SIP Catcher 58 Figure 3.9. Timing Diagram for a SIP Call Initiatio n Proxied by the SIP Catcher 60


v Figure 3.10. The Test-Bed for SIP Catcher 63 Figure 3.11. The PC and Router Used for the SIP Cat cher Test-Bed 64 Figure 3.12. Messages Sent by the SIP Registrar Ser ver When Phone Sleeps 65 Figure 4.1. Variables for Best-of-N Method 69 Figure 4.2. Best-of-N Method for Bloom Filter 69 Figure 4.3. RNG Hash Method for Bloom Filter 70 Figure 4.4. Probability of False Positive for m / n = 16 74 Figure 4.5. Probability of False Positive for m / n = 32 76 Figure 4.6. Improvement Factor for Various m / n 76 Figure 4.7. Histogram of String Lengths for Test Se t 78 Figure 4.8. False Positive Calculated With Eq. (2.4 ) Using Perfect Hashing 79 Figure 4.9. False Positive Calculated With Eq. (2.4 ) Using Four Hash Functions 80 Figure 4.10. False Positive Measured Empirically 80 Figure 4.11. Results from Run-Time Experiment 81 Figure 4.12. System Design of the Two-Tier Bloom Fi lter 83 Figure 4.13. pcache as a Function of mcache and 87 Figure 4.14. S as a Function of mcache and 87 Figure 4.15. An Example of the SAHT Data Structure 89 Figure 4.16. Variables for SAHT Algorithms 90 Figure 4.17. SAHT Algorithms to Add List of Strings and Test String 90 Figure 4.18. Variables for Bloom Filter Based Searc h Algorithms 94 Figure 4.19. Bloom Filter Based Keyword Search Algo rithms 94 Figure 4.20. A Bloom Filter Based Keyword Search Al gorithm Implementation 96 Figure 4.21. Histogram of String Lengths for a File With Book Titles 98 Figure 4.22. Fixed Length Strings Experiment 100 Figure 4.23. File Size Experiment 100 Figure 4.24. Variable Length Strings Experiment 101 Figure 5.1. The SmartNIC With Proxy Capability 104


vi Figure 5.2. Sleeping Host With P2P Application Prox ied by a Stateless Proxy 105 Figure 5.3. Main Programs for Host and Proxy 106 Figure 5.4. Functions and Processes Common to Host and Proxy 107 Figure 5.5. Processes Specific to Host or Proxy 107 Figure 5.6. Netburner Development Kit 108 Figure 5.7. Results From Query Forwarding Experimen t 111 Figure 5.8. Results From Query Hit Experiment 111 Figure 5.9. Sleeping Host With P2P Application Prox ied by a P2P Stateful Proxy 113 Figure 5.10. Architecture of the P2P Stateful Proxy 115 Figure 5.11. Gnutella Message Processing by the P2P Catcher 117 Figure 5.12. The Test-Bed for P2P Stateful Proxy 119 Figure 5.13. Test-Bed Used to Test the P2P Stateful Proxy 121 Figure 5.14. Query Hit Response Sent by the Awake H ost 122 Figure 5.15. Query Hit Response by Proxy 122 Figure 5.16. Messages Sent by the Host if Proxy Doe s Not Discard Messages 123 Figure 6.1. Future Directions for Network Connectiv ity Proxying 127


vii Saving Energy in Network Hosts With an Application Layer Proxy: Design and Evaluation of New Methods That Utilize Improved Bloom Filters Miguel Jimeno ABSTRACT One of the most urgent challenges of the 21st centu ry is to investigate new technologies that can enable a transition towards a society with a reduce d CO2 footprint. Information Technology generates about 2% of the global CO2, which is comparable to the aviation industry. Bei ng connected to the Internet requires active participation in responding to prot ocol messages. Billions of dollars worth of electri city every year are used to keep network hosts fully pow ered-on at all times only for the purpose of mainta ining network presence. Most network hosts are idle most of the time, thus presenting a huge opportunity for energy savings and reduced CO2 emissions. Proxying has been previously explored as a means fo r allowing idle hosts to sleep yet still maintain network presence. This dissertation develops genera l requirements for proxying and is the first explor ation of application-level proxying. Proxying for TCP con nections, SIP, and Gnutella P2P was investigated. T he TCP proxy keeps TCP connections open (when a host i s sleeping) and buffers and/or discards packets as appropriate. The SIP proxy handles all communicatio n with the SIP server and wakes up a sleeping SIP phone on an incoming call. The P2P proxy enables a Gnutella leaf node to sleep when not actively uploading or downloading files by handling all quer y messages and keyword lookups in a list of shared files. All proxies were prototyped and experimental ly evaluated. Proxying for P2P lead to the exploration of space a nd time efficient data structures to reduce the computational requirements of keyword search in the proxy. The use of pre-computation and hierarchical structures for reducing the false positive rate of a Bloom filter was explored. A Best-of-N Bloom filt er was developed, which was shown to have a lower false po sitive rate than a standard Bloom filter and the Po wer-


viii of-2 Bloom filter. An analysis of the Best-of-N Blo om Filter was completed using Order Statistics to predict the false positive rate. Potential energy savings are shown to be in the hun dreds of millions of dollars per year assuming a modest adoption rate of the methods investigated in this dissertation. Future directions could lead to greater savings.


1 Chapter 1: Introduction One of the most urgent challenges of the 21st centu ry is to investigate new technologies that can enable a transition to a sustainable society with a reduced CO2 footprint. This is key, given that results from most recent studies show that accumulation of green house gases in the atmosphere is growing faster th an initially predicted [125]. This dissertation addres ses solutions to save energy in PCs, the major cont ributors of CO2 for Information and Communication Technology (ICT) 1.1 Background It is important to quantify how much energy ICT is consuming and also how much it is contributing to total CO2 emissions. With this information, the energy waste of PCs can be calculated and the reasons for it determined. This quantification helps measuring the potential energy savings of proposed solutions for energy savings. 1.1.1 Energy Use of ICT Equipment The CO2 footprint of the IT industry has been estimated to be 2% of the global CO2 footprint, which is roughly the same as that of the aviation industry [ 46]. Figure 1.1 shows electricity use in the U.S. f or 2006 [101]. Calculations state that ICT and consumer ele ctronic devices will consume close to 200 TWh in 20 09. But forecasts estimate that this number will double by year 2030 [62]. Network hosts consume a large a nd growing amount of energy. Data centers and servers consumed an estimated 1.2% of total U.S. electricit y consumption in 2006 for a total cost of about $4.5 billion [78], [116]. However, even greater is the electricity consumed by network hosts not in data c enters, as has been calculated by several studies. The most updated source [101] calculates it as more tha n the 2% shown in Figure 1.1. The work presented in [99] was the first publicatio n where measurements of power consumption of PCs were presented. The authors took measurements i n offices located in Canada. This publication did n ot consider them as network hosts, and did not forecas t power consumption of all PCs in the country. The first


2 authoritative source on energy use of all the netwo rk hosts was that published by Lawrence Berkley National Laboratory (LBNL) in a 2001 report [75]. I t stated that office and network equipment consumed 74 TWh/year at that time. That represented about 2% of the total electricity consumption of the U.S. A bout 9% of the electricity consumed by commercial buildi ngs is from office equipment – much of this equipment being network-connected office PCs [118]. A single PC consuming 100 W (a not unreasonable power consumption for a desktop PC) powered-on at a ll time for one year is equal to [51]: 0.88 metric tons of CO2 0.12 passenger cars for one year 77.3 gallons of gasoline consumed 0.09 homes for one year The last item means that the addition of a single P C powered-on at all time will add about 9% to the u tility bill of a typical U.S. household (based on 11,965 k Wh/year, according to [51]). Beyond PCs are the growing number of commercial and consumer devices – such as set-top boxes and game consoles – that are connected to the Internet and have become network h osts. It is expected that in the future even more t ypes of devices will become network hosts. Much of the electricity consumed by network hosts i s wasted. Being connected to the Internet requires some active participation. When hosts fail to do th is, they “fall off the network” and applications fa il. Billions of dollars worth of electricity every year are used to keep network hosts fully powered-on at all Buildings electricity ~2700 TWh = $270 billion Electronics ~250 TWh = $25 billion All PCs ~100 TWh = $10 billion Enterprise PCs ~65 TWh = $6.5 billion All electricity ~3700 TWh = $370 billion Figure 1.1. 2006 US Electricity Usage (Not to Scale ) [101]


3 times only for the purpose of maintaining network c onnectivity or “presence” [100]. If not for the nec essity of network connectivity most of these hosts could b e asleep the majority of the time, with resulting i n energy savings. It is the need to maintain network connectivity that contributes to the disabling of e xisting power management features in many PCs, game console s, and other PC-like devices. 1.1.2 Energy Savings Opportunities Why are the majority of office and home PCs left po wered-on even when not in active use, such as overnight and during weekends? Surveys have found t hat between 50% and 60% of office desktop PCs are left on continuously [109], [115]. Specifically the survey in [109] explains why employees leave compu ters on all night. Around 31% of the surveyed employees in the U.S. said that they leave computers on durin g the night for reasons that induce computers to cons ume power when they do not use them. They answered, among other responses, that they forget to turn the ir PCs off (13% of the employees responded so), lea ve it on for updates to be installed during the night (9% ), or also because it is a policy of the company (9 %). The following two major reasons for leaving PCs on duri ng the night can be extracted from this: 1. The annoyance to a user of having to wait for a PC to wake-up out of the sleep state, and 2. The need to maintain network connectivity at all ti mes to allow for remote access and/or for network-centric applications to maintain their stat e. The first reason is becoming less significant as PC s become able to wake up faster [4], while the seco nd reason is becoming more significant as more applica tions and protocols rely on persistent Internet connectivity. The need to maintain network connecti vity at all times is becoming even more urgent to address as the number of PC-like devices, including set-top boxes, game consoles, and so on proliferat e. All of these devices are connected to the Internet and many require full connectivity at all times to provide the services they are intended to deliver. To maint ain network connectivity, a host must be able to su pport a number of application and protocol primitives, incl uding: 1. Maintain host-level reachability by responding to p eriodic ARP requests in order to not age-out of the last-hop router ARP cache, 2. Maintain its IP address by generating periodic DHCP lease requests in order to not lose its IP address (if using DHCP to obtain an IP address), 3. Maintain its manageability by responding to ICMP pa ckets, such as ping,


4 4. Support NetBIOS name resolution by responding to Ne tBIOS name queries as appropriate (if running NetBIOS protocol and applications), 5. Maintain application-level reachability by respondi ng to TCP SYN packets sent to open (listening) ports, 6. Maintain or preserve application state (e.g., curre nt user workspace and data) for any applications with open long-term TCP connections, 7. Maintain or preserve application state by respondin g to any number of application-level messages including heartbeat messages and specific requests for service. If a host can remain reachable even when sleeping a nd keep its NIC powered-on, it can then be wokenup from the network by “trigger” packets that the N IC recognizes. The Magic Packet was invented for th is purpose in the mid-1990s [8]. Most NICs today suppo rt both Magic Packet and the ability to pattern mat ch for specific packets to trigger a wake-up. However, wake-up does not completely solve the problem of network connectivity. Wake-up triggered on pattern matching can cause both missed and unnecessary host wake-ups resulting in applications that fail and/or reduce energy savings. Estimating the exact cost of the network connectivi ty problem is difficult. One study suggests that ha lf of all electricity consumed by PCs is wasted [99]. Energy consumption and waste of network hosts is examined later in this dissertation. Clearly, solvi ng the network connectivity problem must be of urge nt interest as a research problem 1.2 Motivation for Research Saving the wasted energy due to the need to maintai n network connectivity can be done by 1) redesigning network protocols and applications, or 2) encapsulating the intelligence for maintaining network presence in an entity other than the core o f the networked devices. The second option has been termed Network Connectivity Proxying (NCP) [25], [2 8], [53], [100]. An NCP is an entity that maintains full network presence for a sleeping network host [ 100]. The NCP concept was first proposed in the lat e 1990s in the context of an ARP proxy [25] and defin ed further in the early 2000s [23], [53]. Currently a basic NCP functionality is being standardized by Ec ma [34] and is also already part of the EPA Energy Star Specification for Computers [112]. This current wor k addresses items 1) to 5) in the list in the previ ous section. Current and previous work related to the N CP concept is described later in this dissertation. What


5 is lacking in all current and previous work is a fo cus on network applications that drive induced ener gy use – items (6) and (7) in the list in the previous sec tion. Induced energy use is formally defined as the increment for higher power state of a device needed to maintain network connectivity. There are two motivating topics that this dissertation addresses: 1. Network applications driving energy waste in PCs an d PC-like devices, and 2. The need for more efficient methods of directory an d keyword searching so that P2P applications can be proxied. Network applications require connectivity to mainta in presence and, in some cases, to preserve the local and remote state. Two examples can be given t o demonstrate the need for network connectivity: 1. VoIP phones relaying on the SIP communication proto col are left on for long periods of time for the sole purpose of receiving calls. In the U.S., e nergy wasted is close to 4 TWh/year due the use of these applications, and 2. P2P applications that force users of hosts running them to leave them on during long periods of time to keep connected to the P2P network. In the U .S., the energy wasted is about 2 TWh/year due to the sole purpose of keeping hosts connected to the P2P networks. These applications and the protocols they use need to be able to respond to incoming messages at all times. Thus, these applications effectively induce energy consumption even when not in active use. In many enterprises, PCs are left powered-on overnight so that they can be remotely managed (e.g., for installing software updates). Problems of remote ma nagement of sleeping PCs are already well addressed in previous work (e.g., by commercial tools such as [5 9], [137], [60] and [14]). This, however, targets o nly office PCs. Although many of the ideas can be used for home PCs, the decentralized and heterogenic asp ect of networks of home PCs allows further room for res earch. The NCP as being defined and standardized by Ecma [ 100], does not consider applications with longlived TCP connections such as telnet, SSH, IM, and others. It has generally been considered too diffic ult, except in very specialized cases related to high-pe rformance servers [79], to hand-off TCP connections between entities. Can TCP connections be proxied wi thout requiring full hand-off of connections betwee n the host and proxy? There are other applications th at rely on incoming connection requests to provide some type of service. This is the case for low-usage web servers, that provide service for file requests, a nd VoIP


6 phones that accept new connections to initiate phon e calls over the IP network. Can low-usage web serv ers and hosts running VoIP phones sleep and be woken up only to provide their service? And what is necessa ry to allow these hosts to sleep for long periods of t ime? A key class of applications that is driving increas ed energy use of desktop PCs is P2P file sharing. A P2P node must remain fully connected to the network at all times while it is sharing files. A P2P node must be able to forward Query messages and directly resp ond to query messages. A P2P node must respond to all query messages that have keywords matching file s stored (and shared) by the node. A key question addressed in this dissertation is: can P2P applicat ions be proxied using the NCP concept? P2P applications place a large demand on the host p rocessor to implement string search for keywords in directory lists (of shared files). P2P nodes may share thousands to millions of files, each file id entified with a file name string that can be many words in l ength (e.g., the title of a song or name of a movie ). Each incoming query message generates a search of the di rectory list for keywords. To implement directory search in an NCP would currently require significan t processing capability (and thus large power consumption). Are there ways in which directory sea rching can be simplified – made less computationall y complex – to enable implementation on small, low-po wer devices with relatively small processors? A key observation is that the response to a P2P que ry does not need to be precise – a rare “false positive” is acceptable (and would be resolved manu ally by a user searching for files). This suggests the possibility of using a probabilistic data structure such as a Bloom filter [15] for implementing direc tory lists. Bloom filters have been well studied for imp lementation in hardware, but less so for software. Can Bloom filters be both improved and applied to the d irectory search problem to make proxying of P2P applications feasible? It is key to explore how eff icient and suitable this data structure is when use d by a type of proxy, in terms of space and time usage. 1.3 Contributions Made in This Research This research addressed the open problems described in the previous section. In doing so, the following contributions were made: 1. The first exploration of application-level proxying as a means to reduce energy consumption of network hosts. The research in this contribution ar ea focused on system-level prototyping and evaluation of a TCP connection proxy, a SIP proxy, and a Gnutella P2P proxy.


7 2. The first use of pre-computation and hierarchical s tructures for reducing the false positive rate of a Bloom filter. The research in this contribution are a focused on algorithm design, implementation, and analysis, including a study of a signature-base d hash table compared to a Bloom filter. 3. One of the first applications of Bloom filters to m easurably reduce the computational requirements of keyword search, in this case applied to a Gnutel la P2P proxy. The research in this contribution area focused on system-level prototyping and perfor mance measurement in the scope of the Gnutella P2P proxy from contribution (1). Contribution 1) was published in [69], contribution 2) was published in [70], [71], [68]. Contribution 3) was published in [67]. 1.4 Organization of This Dissertation The remainder of this dissertation is organized as follows: Chapter 2 contains background and a literature revi ew. The chapter describes current work in power management and proxying, and reviews Bloom fi lters and string search methods. Chapter 3 describes the design, implementation, and evaluation of an NCP for proxying TCP connections for SSH and IM, and SIP for IP phones. Chapter 4 describes the design, implementation, and evaluation of new search algorithms that could be used to improve energy efficiency of a pro xy for a P2P application. The algorithms are: the Best-Of-N and the two-tier Bloom filter, which are search algorithms for probabilistic Boolean responses. Also, a data structure and a search algo rithm that allow information retrieval are presented. They are: Signature Array Hash Table (SA HT) and Bloom filter based keyword search, respectively. Chapter 5 describes the design, implementation, and evaluation of two types of a proxy for a P2P application. The first is the P2P Stateless proxy, which covers for a P2P application running on a sleeping host. This proxy requires TCP connections to be closed and re-established each time the host changes from a sleep to an awake state and vic e versa. The second is the P2P Stateful proxy, which covers for a P2P application by keeping the T CP connections established by the host open for as long as the host sleeps. The Stateful proxy combines the ideas of TCP connection proxying in Chapter 3 and uses the Bloom filter based keywor d search algorithm from Chapter 4.


8 Chapter 6 concludes the dissertation by describing benefits of the contributions presented, including calculations of potential energy savings. It also describes possible directions for future work.


9 Chapter 2: Background and Literature Review To understand how energy can be saved, it is necess ary to identify what is driving power consumption in network hosts. This is necessary to fully unders tand how the ideas in the following chapters contri bute to reducing energy consumption of network hosts. 2.1 Overview of Power Management for ICT Hosts Power management in hosts is the addition of hardwa re and software features to reduce their power consumption when not being used [104]. An early ver sion of this concept was used in [99], where Newsham and Tiller proposed the use of stickers pas ted on top of office computers to persuade users to save energy by turning off computers when they leav e the offices. Power management policies have been proposed through different approaches. Those that h ave had the most impact are proposed by efforts or groups, usually composed by government agencies and companies with high influence. Solutions to improve energy savings through power management hav e been also proposed by independent researchers. During the last two decades several groups involvin g industry, government and academia have been formed to propose ideas for power management of ICT hosts. The Advanced Power Management (APM) specification was the first attempt of computer man ufacturers to enable power management capabilities in PCs [2]. The first version of this specification wa s created in 1992, and the last one in 1996. This specification was an effort between Intel and Micro soft, and the idea was to develop an interface betw een the operating system and the BIOS to achieve power management. This development includes the definition of power states, which are the basis of the power states used today in power management. An improved specification was released in 1996 under t he name of Advance Configuration and Power Interface Specification (ACPI) [1]. In this specifi cation, a group of power states are defined, from w hich states S0 to S5 can be found in almost any device t oday.


10 The most important states are as follows: State S0 is for Working (when the power consumption is the highest) States S1 through S4 are sleeping states, different iated by the components that remain poweredon. In S3 (Suspend), main memory is still powered-o n, while in S4 (Hibernation), main memory content is saved on a disk, and all the components are powered-off. State S5 is called Soft Off (when the power consump tion should be the closest to zero). In states S1 through S4, power consumption should b e the closest to that in S5. This specification des cribes the structures and mechanisms necessary for the pow er management to be directed by the operating syste m. Hardware and software in a computer use this specif ication to comply with power management policies. I f a device is on (or in S0 state according to the ACP I power states), the operating system running on a device with power management policies enabled will always log time-stamps of the last time a user input was detected. It will start a timer and if during a cer tain period no new input is received, it will move to a sleep state. This period of time is called power manageme nt delay time by the authors of [76]. A technique that focuses on shortening the power management delay ti me (or saturating it) was proposed in that publicat ion. To shorten the delay time means that the PC will wa it less time to go to sleep. The authors of the publication calculated potential energy savings by shortening power management delay times in office P Cs, printers, copiers and displays. To do this, delay t imes were varied between 5 minutes and 60 minutes. The energy savings achieved in periods during which the devices stayed in power saving states were about 4 times more when the delay time was set to 5 minutes instead of 60 minutes. However, one of the finding s of the study is that many users got annoyed by smal l delay times and decided to set delays of about 60 minutes. The authors suggested the study of the use of technologies that could diminish the user annoy ance. There are several public agencies and laboratories dedicated to proposing and implementing power management policies. The U.S. government through th e Department of Energy created the Energy Information Administration (EIA) and the Lawrence B erkley National Laboratory (LBNL). The EIA has been in charge of publishing many forecasts and ana lysis regarding energy use in the country and its i mpact on the economy [38]. LBNL is one of the laboratorie s that have been more dedicated to the promotion of power management in computers. The report in [104] is a clear attempt to promote power management in PCs and monitors. Other reports like that in [103] and [114] have calculated potential savings by the


11 aggressive use of power management policies in offi ce equipment. However, LBNL presented another report in 2001 where the authors found that despite these efforts, only around 44% of computers were turned off at nights [138] during informal walk-thr oughs in offices. The U.S. government also created the Environmental Protection Agency (EPA) in 1970. The EPA created the Energy Star program in 1992 as a program where manufacturers of electronic devices c ould voluntarily label their products as energy efficient [37]. The program started with the issue of an Energy Star logo for PCs and monitors manufacturers that comply with given specified requ irements. These requirements issued by Energy Start for PCs are currently in specification version 5.0 [112]. The specification classifies the PCs accordi ng to the hardware parts that compose them. According to the classification, computers must consume less tha n a posted amount of kWh a year to be issued the Energy Star logo. The logo is stamped on these devices, and it is promoted by EPA with monthly lists of the dev ices that bear that logo. The results of this progr am have been evaluated in a report [119]. This report eval uated all devices that bear that logo and made calc ulations of energy savings since the first specification for each type of device appeared. Private groups and laboratories from academia have also been involved in efforts to increase energy savings of the Internet, and especially PCs. Univer sity of South Florida and University of California Santa Barbara among many others, have contributed with th eir projects [131], [132]. Groups like the Climate Group have focused on reducing the carbon print of business and government in general. Reports from th at group, such as “Smart2020”, have given a broad idea of how ICT can contribute to decrease the energy u se of each country [125]. Another group is the Climate Savers Computing group, founded by Google and Inte l in 2007 [30]. This group and others like the Green Computing Impact Organization [50], are private eff orts by consumers and business to reduce the power consu mption of enterprises. A key reference in power management is the work by Gupta and Singh in [54]. They addressed the power consumption of the networking devices that co nnect the Internet and proposed different solutions They started by dividing the energy use by all the components: hubs, switches, and routers. They descr ibed how devices spent too much time being idle, thus be ing energy inefficient for the whole network. They proposed the modification of the protocols used by the Internet to enable more power management polici es in the devices that are connected to it. To decreas e energy use of the devices, they proposed modifyin g


12 them in such a way that some components can be turn ed off when not in use, or at least put in power sa ving states. This leads to energy use rates more proport ional to the load of the devices. The case of energy proportional computing in server s was studied in [12]. The authors proposed the modification of how servers are designed, such that they consume energy proportionally to how much the y are used. They suggested that manufacturers should focus on building components which have energy proportionality in mind. This is key to saving ener gy during periods where the utilization is low, but the power consumed is already high. The idea of energy proportional computing is the final goal of power management. Figure 2.1 shows power consumption vers us utilization, where the typical curve depicting t he power consumption as the utilization increases is c ompared with the idealistic one (the straight line) Ideally, a PC should consume no power when it is no t being used, very low power when it is barely used and in general, a proportional amount of power to u tilization. Today, PCs consume marginally lower pow er when idle or barely used compared to when fully use d. As stated in [12], the system components are sti ll not achieving energy proportional computing togethe r. In the hardware level this is hard to achieve, a s the system component manufacturers are different. PCs s hould consume power proportionally as they are utilized, and solutions can be explored that go bey ond what the components of the systems can do, and this is the goal of this dissertation. Dynamic Power Management (DPM) is a design methodol ogy that configures an electronic device to be able to provide certain services with the use of the minimum necessary components, acting at its Figure 2.1. Power Consumption Versus Utilization 0 20 40 60 80 100 020406080100Power consumption (%)Utilization (%) Typical Linear


13 minimum possible load [13]. This is key to consider given that systems do have different workloads du ring different periods of time. A survey presented in [1 3] describes power-managed systems by first definin g and giving examples of power-manageable components of a system, and how they interact to configure the system to be power-managed. At the same time, the a uthors of the survey developed a mathematical framework to highlight advantages and disadvantages of DPM techniques. They also described different DPM techniques for system components, and how they were currently implemented. 2.1.1 Power Management in Wireless Devices Power management in networks composed by wireless h osts has been studied more thoroughly than networks of wired hosts. Most of the wireless hosts are mobile hosts and as such do not have an endles s source of power (like wired hosts which are plugged to power outlets) but instead relay on batteries. This makes power management a mandatory topic of researc h. The research community has long been interested in methods to reduce power consumption in order to increase battery life. According to [72], research has been focused on improving the energy efficiency of hardware components of wireless hosts, but of inter est is what can still be done to allow software compone nts to contribute to the energy efficiency of the s ystem. The authors describe energy efficient network proto cols through the different layers of the protocol s tack. They describe, for example, how different protocols and standards in the MAC layer were designed havin g the energy efficiency of the hosts in mind. In the case of the 802.11 standard [57], it was proposed w hat could be done in case the host wanted to save energ y. In the transport layer, the protocols include modifications of the TCP protocol to make it aware of the wireless environment. The design of applications usually pays no attentio n to the power needs of the host when the application is running. Critical energy resource in mobile computing is drawing the attention of resea rchers towards how applications are not aware of power con sumption and resources available. The authors of [3 6] proposed that operating systems should be designed to allow applications participate in the power management policies of the device. The publication presented an application developed for a Palm Pilot The intention was to establish what kind of informa tion the operating system could give to the softwar e to improve the energy efficiency of the device. The st udy was based on power consumption measurements when the application performed different tasks. Alt hough the target system was a mobile device, this i dea could be used in all types of devices.


14 One approach that has been explored is to have a hi erarchy of hardware components ranging from high-power and high-function at the bottom, to lowpower and low-function at the top. The low-power components do work for the high-power lower tiers, and thus allow the high-power components to sleep. One example of this is “Wake on Wireless” where a l ow-power out-of-band wireless component is used to wake up a (relatively) high-power PDA [122]. Anothe r example is a laptop with three levels of hardware where the lower-power components perform simple net work tasks (such as keeping email up to date) allowing the higher power components to sleep [126] The term “proxy-based architecture” is used in [126]. The work in Chapter 3 of this dissertation i s more general in scope than that of [122] and [126 ]. In general, aggressive power management ideas commo n for wireless hosts are not usually found in wired hosts. One reason for this could be that the wireless community is relatively new, which allowed designs of protocols and standards to take into acc ount issues like power consumption. The adoption of new designs in already deployed networks of wired h osts, such as those that compose the backbone of th e Internet might not be a easy to adopt approach. 2.2 Induced Power Consumption in Network Hosts Increasingly, networked applications have been foun d to “induce” energy use in PCs and other networked devices. Induced energy use occurs when d evices are required to remain fully powered-on – even when no user is present and network access is only sporadic or incidental – in order to respond t o network protocol messages [102], and has been consi dered as a driver of energy use in hosts [26]. One example of an application producing induced energy use is peer-to-peer (P2P) file sharing. A desktop P C, or host, participating in a P2P network must be ful ly powered-on at all times in order for it to make its files available to other P2P hosts. This is the case even if the actual time during which files are download ed from a P2P host is very small. The participative no tion of this application forces hosts to remain con nected to contribute to the network. Some applications tha t use the client-server model also induce energy us e. Users may prefer to leave applications running all the time to receive updates, notifications and/or s ervices. Many application messages flow over TCP connections a fact that makes network connectivity harder to maintain, because TCP uses sequence numbers. For a third party to maintain a TCP connection open, i t would have to know the sequence number of the last packet. If the right number is not used, the connec tion will be dropped by the other side. Not only will th e application layer require constant connectivity, for


15 messages like keep-alives, but in some cases the tr ansport layer will also require it because TCP is u sed. The main purpose of TCP is to assure delivery of by tes in both sides of a connection. For that reason the protocol requires both sides to be responsive at al l times. Otherwise retransmissions, back-off times and eventually connection drops will occur. Some applic ation messages flow over UDP, in which case the network connectivity problem is at the application layer only. 2.2.1 Client-Server Applications as a Cause of Indu ced Energy Use Three examples of client-server applications that d rive the waste of induced energy use are described here. Secure Shell (SSH) is an application protocol used for secure remote login and other services ov er an insecure network [141]. It is used as a secure tel net replacement for remote access to a terminal con sole. SSH uses a TCP connection. If the TCP connection is dropped, the application state is lost in the remo te computer. In addition, a lengthy re-login process i s required to reconnect. As a result, users with SS H connections typically disable power management in t heir local (client) hosts. During an active SSH connection, messages can flow from the remote compu ter to the console. For a host that has a SSH sessi on open to be able to sleep, the TCP connection must b e preserved and any messages queued for later displ ay on the console window in the host (that is, for whe n the host wakes up). Otherwise, the host will have to remain awake. Another application is Instant Messaging (IM), a co mmunication that is established in real time. It is often used in multi-way chat sessions. IM uses a TC P connection from IM client to an IM server, so it uses the typical client-server architecture. A study sho wn in [65] provided an overview of the communicatio n architectures used by different IM clients. They st udied the technologies used by AIM, MSN Messenger, and Yahoo Messenger. In order to allow millions of IM clients to be connected to the servers at the s ame time, the architecture has to be designed to be sca lable. This leads, according to the study, to two t ypes of approaches: a symmetric and an asymmetric approach. In a symmetric architecture, each server performs the same functions so that it is irrelevant to the client to which server it connects to. In an asymme tric architecture, each server performs a different func tion, like logging in, discovering other clients on the network, maintaining a chat room, or forwarding a m essage from one client to another one. From the IM architectures studied in the paper, the simplest is the one used by Yahoo Messenger, shown in Figure 2 .2. The client performs all the functions over persiste nt TCP connections established with one of the Yaho o


16 servers. Three types of messages are sent through t hose connections: 1) login messages, 2) control messages and 3) IM (chat) conversation messages. If a client TCP connection is dropped, the client is removed from the multi-way chat and any IM messages sent during the disconnected period will not be received by the disconnected client. For an IM clie nt to be able to sleep and not lose incoming messag es during its sleep period, the TCP connection must be preserved and any messages queued for later displa y on the IM client application in the host, similar t o the above described SSH case. The third example of applications that drive induce d energy use is Voice-over-IP (VoIP) phones. VoIP is a term used for a group of technologies that del iver voice communication over IP networks instead o f the common phone system. Soft-phones and hard-phones ar e used to deliver the communication. Soft-phones are software applications that implement VoIP using a host. VoIP hard-phones are specialized telephone s for VoIP use only. VoIP hard-phones (or just IP pho nes) are replacing conventional telephones in companies. VoIP phones represented about 27% of the total installment of phone lines in 2005, accordin g to [111]. About 25 million IP phones were sold that year worldwide, according to the same source, and IP phones were being sold more than conventional telep hones. Only recently has the environmental impact o f using IP phones as a replacement for landlines been studied. An example is the analysis shown in [24] where the authors explained the issues to be taken into account when moving from conventional landline s to VoIP. One of the issues was power consumption. C alculations were made for the whole VoIP infrastructure, consisting of a VoIP gateway, a rou ter, a call manager and the hard-phones used. Ener gy requirements for three scenarios were calculated. T he first two scenarios were a mix of IP phones and two types of conventional telephones, and the third one used only IP phones. It was shown that the third o ne consumed 2.5 times more power than the first scenar io and 2 times more power than the second scenario. Figure 2.2. Yahoo Messenger IM System Architecture Yahoo Messenger IM host Yahoo Messenger Server Internet 1) Login messages2) Control messages3) IM and chat messages


17 The interest of this dissertation is on the IP phon es only, not on the core of the VoIP network. IP ph ones manufacturers include power saving states in the ph ones so that they consume less power when idle. Sil l, with these states, the estimated average of 6 W per IP phone can be considered to include periods of idleness or actual use. The power consumption of IP phones can be calculate d as follows. An IP phone consumes an average of 6 W when active, according to a report from a pr ivate company that measured and compared Cisco and ShoreTel IP phones power usages [133], and from a w hite paper from Cisco [22]. This average is likely to increase because phones are being designed with fea tures that consume more energy. Assuming that companies apply policies to turn off phones during nights and weekends, IP phones can still be powered -on about 12 hours a day during weekdays. There is no p recise source to determine actual use of IP phones (that is when used to specifically make or receive calls). It can be assumed that phones are in active use for only 5% of the time. So, if one assumes phones are used a 1/2 hour per day, the energy that IP phones are wasting is then the energy used during 95% of the t ime (when not used for calls). According to the sam e white paper from Cisco [22], there is no significan t difference in power usage when being active or wh en being idle. A single IP phone then consumes 18.7 kW h a year, which costs $2 dollars at $0.10 dollars p er kWh (based on 12 hours a day being powered-on durin g 5 days a week). The power consumption could be calculated for the phones of a company. It can be a ssumed that a company has 10,000 IP phones. A total of 187 MW are needed to power up the phones and the co mpany spends around $18,000 dollars a year to pay for that energy. The annual worldwide shipment of I P phones (around 25 million according to [111]) consumes about 467 GWh a year. This clearly shows t he impact of the power consumption of IP phones. Because IP phones are idle most of the time, most o f this energy can be saved. Besides the power consumption of IP hard-phones, th e soft-phones also drive the power consumption of the hosts on which they are running. For a call to reach the soft-phone, the host has to be running all the time. There are cases like Magic Jack [87] where even the soft-phone disables power management options of the host. Magic Jack is a physical device (shown in Figure 2.3) that can be plugged into a PC, and runs a soft-phone. It uses USB port to connect to one of t he USB ports of the PC. It also has a port to conne ct a conventional telephone handset. When the device is connected to a PC, it installs a soft-phone that implements the SIP protocol for call session contro l. The hardware inside of the device creates an int erface


18 between the software installed in the PC and the co nventional telephone. The manufacturer of Magic Jac k provides interconnection with the telephone network at the same time, which allows the device to be us ed to make and receive calls. The VoIP phones use several session control and com munication protocols. Typical protocols used to control the call session are H.323 (standardized by the ITU-T), SIP (standardized by IETF), and the Sk inny Call Control Protocol (SCCP) (proprietary protocol from Cisco). The common protocol used by IP softphones and hard-phones is the SIP protocol. H.323 a nd SCCP are not implemented in soft-phones. Session Initiation Protocol (SIP) is an application layer p rotocol used to establish, modify and terminate a communication session (or call) between two or more participants [117]. The participants are called Us er Agents (UA) and use SIP service providers as interm ediates. UAs register with SIP registrars located a t the domain of the provider and a SIP proxy server (loca ted at the same domain) will route requests to/from that UA. The SIP protocol is based on an HTTP-like reque st/response transaction model, where a UA participates as client and another UA participates as server. A SIP communication between two UAs (Ali ce and Bob) is shown in Figure 2.4 and is established in the following way. First Bob has to register to a SIP service provider (, step (1). The regist rar stores BobÂ’s information in a Location Service (2). If Alice wants to contact Bob, Alice will have to know the address of Bob. Alice sends the request to the proxy server of (3). The proxy queries t he Location Service to find the exact location of B ob (4) and (5), then sends the request to Bob directly (6) After the communication is successfully establish ed, Alice and Bob will establish a Peer-To-Peer communi cation using protocols to transport voice and video like Real-time Transfer Protocol (RTP). The SIP ses sion is established and remains so until one of the ends terminates the communication. It is important to no te that although the registrar and the proxy server of the Figure 2.3. Magic Jack Device for VoIP Phone Calls USB port to PC RJ-11 port to conventional phone


19 domain are drawn as separate devices, they are logi cal services that can be executed by the same physi cal device. A typical SIP message contains message header, meth od, status code, and other fields. The message header is used to provide details about the SIP ses sion. Details include content type, length, languag e, identification of the session, and so on. The metho d is a function the UA likes to invoke in the SIP p roxy server. Typical methods are REGISTER, INVITE, and B YE. The REGISTER method is used by a UA to register to the SIP registrar of a certain SIP prov ider. An INVITE is sent by an UA when it wants to establish a communication with another UA. A BYE me thod is used to terminate a communication. The status code contains the correct status of a call. Possible statuses are grouped as Informational, Cli ent-error, and Server-error. If no error occurs, statuses are just of the Informational type, and include TRYING, and RINGING. A TRYING status is set in the first SIP me ssage sent by Bob when it is contacted (it receives the INVITE). A RINGING status is set when BobÂ’s pho ne is actually ringing. The initialization of a SI P call (a Caller to the IP phone) is shown in Figure 2.5. This figure includes the last hop router the I P phone is connected to. One of the available fields for the message header of a SIP message is the expiration field (Expires) that establishes the relative time after which the message (or content) expires. The meaning of this Figure 2.4. Components and Start of a Communication with SIP [117] (1) REGISTER (6) INVITE Bob (at cube2214a (3) INVITE Bob (at server com) Proxy (sip server com) (2) Store (4) Query (5) Response Bob (UA) cube2214a Alice (UA) Registrar (server com) Location Service


20 expiration is method dependent. In the case of a re gistration, it is used by the UA that wants to regi ster (establish a binding) with a certain SIP registrar. The Expires is set to negotiate the expiration tim e of the binding to be established. The SIP registrar then a grees with the requested expiration time or sets it to a new value. The SIP protocol defines a way for SIP r egistrars to remove unused bindings from their syst em. The Expires field of the header is used for this pu rpose. So each IP phone with a binding at the regis trar will have to re-register after the expiration time. Assuming the IP phone is connected for the first t ime to the network (e.g. turned on), the first thing it wi ll do is registering with its SIP registrar. 2.2.2 P2P Applications as Cause of Induced Energy U se A P2P network is an overlay network on the Internet P2P hosts (or peers) are directly connected to a group of their neighbors by TCP connections. Neighb ors need not be physically nearby, and the process of identifying neighbors involves a bootstrapping proc ess. P2P networks are typically used to share media files, but are also used to share computational res ources. File sharing applications became popular in the early 2000s. A relatively new study [73] showed tha t the use of file sharing applications is still wid e spread in the Internet. A study presented in [129] found t hrough traces that although a low percentage of P2 P users leave the network after a few hours of being connected, about 30% remain with high probability o f being connected for more than 16 straight hours. Th is shows that P2P nodes remain connected to the network for long periods of time. Figure 2.5. Timing Diagram for the Start of a SIP C all Alice (Caller) SIP proxy server Last hop router Bob (IP phone)


21 P2P networks are used not only for file sharing but for other network applications. A survey of P2P architectures is presented in [85], where the autho rs also discussed possible future uses of P2P netwo rks, including P2P overlay computing, mobile location-ba sed services and mirrored content delivery. The stu dy focuses mostly on the comparison of structured and unstructured P2P networks. In structured networks, the topology is controlled and content is placed in spe cific locations that will make query routing more efficient. In unstructured networks topology is not controlled and content can be at random places. In unstructured networks the peers participating need to use more of its resources to make the network wo rk. Constant participation in the routing of queries, r esponses to queries, and traffic control messages i s important. Unstructured networks are more commonly used and the Gnutella network is a good example. The well known software Skype uses a P2P network to share traffic routing of the VoIP calls among the peers that are connected to the network. According to classification of architectures presented in tha t publication, the Skype peers construct an unstructu red network. According to [52], Skype uses an ultra peerleaf architecture similar to that used by Gnutella. They use the concept of superpeer (supernode) and ordinary peers (nodes), which construct a 2-layer o verlay network. The network allows peers to transfe r files to each other, send IM messages and conduct V oIP calls. The P2P network is used to send control traffic, IM messages, and requests to initiate VoIP and file-transfer sessions. It is important to have an idea of how P2P applicat ions can drive power consumption of the hosts they are running on. A P2P application used to share fil es is nearly idle 99% of the time. Here idle is con sidered as not uploading a file. This is calculated as foll ows: A typical P2P host will be downloading or uplo ading files only 1% of the time (and thus is idle 99% of the time). We calculate this as follows. There are 1 billion downloads per week from 9 million users online at a ny time [105]. Thus, the average P2P host transfers about 16 files per day. Two different studies calcu late the average file size between 4 Mbytes [130], and 8 Mbytes [43]. If a 1 Mb/s download rate is assumed a s typical [120], then about 17 minutes per day are spent transferring files, which is about 1% of 24 h ours. However hosts running P2P applications must remain “on the network” so that other P2P users can query the host to learn if a requested file is bei ng shared. Gnutella is a P2P file sharing protocol that uses s mart query flooding to find files in the network. I t is the most common protocol used to implement file sha ring applications because it is open source and the


22 standard is not complicated. One of the most used P 2P applications implementing Gnutella is Limewire [84]. The simplicity and popularity of Gnutella mak e it a desired target to implement a solution to sa ve energy for hosts running P2P applications. 2.3 Overview of the Gnutella P2P File Sharing Proto col The first standard Gnutella protocol version is 0.4 and defines five message types; Ping, Pong, Query, Query Hit, and Push [47]. After that, a version 0.6 was published. The main modification of this versi on is the introduction of ultrapeers [48]. Gnutella is a protocol that has evolved after that, although no o ther version was published. Limewire has introduced modi fications to the protocol and usually publishes the m in their webpage. Peers can be leaf peers or ultrap eers. A leaf connects to ultrapeers and shares with it the list of shared files. By default, all new peers con nect to the network as leafs. Different application s implementing Gnutella have different ways to select ultrapeers. The most common way is by using a selection criterion, such as the time the peer has been connected to the network, or the upload and download speed available. If the criterion is satis fied, the application advertises itself to the netw ork as an ultrapeer. A handshake occurs between two peers when one wants to enter the network. After that, the exchange of Gnutella messages occurs. Files are downloaded f rom a host using the HTTP protocol. Thus, each Gnutella host is also an HTTP server. The details o f the messages are the following: The Ping message is used to discover Gnutella hosts in the neighborhood. It is sent to the closest peers of the host sending it, which forward it to t heir peers. It is one of the first messages sent by a host when it connects the network, and is mainly us ed to build information about the neighborhood (reachable hosts, bytes shared, etc.) It is also used by some implementations to test if a connection is still alive or not (the pinged p eer might not be reachable anymore). The Pong message is sent in response to a Ping. It contains information about the host sending it, such as uptime (time it has been connected to the n etwork), amount of bytes shared and if it is willing to receive connections from the host that s ent the Ping. The Query message is used to find files; a host put s keywords in it and sends the message to its neighbors. The neighbors forward the message for up to a maximum number of times, specified in the TTL field of the Query.


23 The Query Hit message is the response from a Gnutel la host that received the Query that contains a file or list of files that contain a combination of the keywords in the Query received. The Push message is used by a Gnutella host that wa nts to download a file from a host that is behind a firewall. The host that receives a Push ha s to now open a new TCP connection with the host that sent the Push. With this connection, the host can request the file from the firewalled host. Other approaches are used if both hosts are behind a firewall. A host running a P2P application that implements th e current version of Gnutella works in 5 steps, from when it connects to the network for the first time until it closes the connections to all the pe ers it is connected to: 1. A host entering the network connects to at least on e peer (from a list received from a bootstrap). From this peer, it will get a list of other possibl e peers to which it can connect. 2. The new peer explores the neighborhood to discover new peers willing to accept new connections from it. After the maximum number of connections al lowed is achieved, the host will just stay connected participating in the network. If the peer acts as a leaf, it will deny attempts from other peers to connect to it. If it is acting as an ultra peer, it will accept new connections from other pee rs (ultrapeers or leaves) as long as the maximum slots of peers has not been filled. 3. The peerresponds to messages accordingly, and forwards Quer ies or responds to Queries received from other peers. In case the user generates a sear ch for a set of keywords, it will also submit a Query with the keywords to the list of peers is con nected to. It also responds to Pings messages. 4. The peer sends a download request to one or more pe ers from the list of peers sharing a desired file. It also has to accept upload requests of file s it is sharing. 5. The peer repeats steps 3 4 or disconnects from th e network if the user triggers an action to do so. 2.3.1 Query-Based Protocol The most important responsibility of a peer in a Gn utella network is to process Query messages by forwarding them if necessary or responding to them if the peer shares one or more media files whose na mes contain one or more keywords of the received Query. Figure 2.6 describes the timeline which shows how the process of querying for keywords, responding to the Query, and requesting a file works. P2P host A and B are peers connected to a set of peers that do not necessarily have peers in common. In the figure, A is


24 connected to ultrapeer X and B is connected to ultr apeer Y. P2P host B shares a file named X. It is as sumed that Host B is not located behind a firewall. The p rocess happens in the following way: 1. Host A generates a Query message that is sent over the TCP connections established with other peers of the network. The Query is assumed to have a keyword found in the name of a file shared by host B. The message eventually reaches host B af ter being forwarded by its peers. 2. Host B spends some time to match the keyword with o ne or more of the files it shares. It then responds to the Query with a Query Hit containing t he file X. The Query Hit can be sent over the same TCP connection used to send the Query to host B, or sent directly through UDP to host A. In case it is sent over the TCP connection, it will be forwarded over the same path that was used to send the message from host A to host B. In the exam ple, the message is sent over UDP directly. 3. Host A requests the file X by sending an HTTP reque st over a new TCP connection and the download starts after host B accepts the request. 2.3.2 Tasks of a Leaf Peer and Ultrapeer While the peer behaves as a leaf, it has to perform several tasks as participant of the network. These tasks have to be performed no matter whether the P2 P application is being used (there is a user runnin g Figure 2.6. Timing Diagram for File Querying in a P 2P Gnutella Network P2P host A ultrapeer X ultrapeer Y P2P host B Match keyword with file names Trigger file request File download 1) 2) 3)


25 commands) or not. They are independent of other tas ks that are only performed if the user wants to (e. g. searching, manually connecting to peers). The tasks of a leaf are the following: 1. Respond to Query messages received only if it share s files that contain the keywords in the Query. 2. Accept or deny requests to upload files to hosts th at request a file from it. 3. Establish new TCP connections to hosts that send Pu sh messages to it. This happens when that peer is behind a firewall and wants to download a f ile from the leaf. 4. Respond to Ping messages received from other hosts with Pong messages containing information about them. An ultrapeer on the other side helps to diminish th e amount of traffic generated by Gnutella networks. It can accept many connections from leaves and routes their Query messages and Query messages from other ultrapeers, based on the knowledge they have about the files shared by leaves. Once a leaf becomes an ultrapeer, it will have an extra set of tasks to pe rform. It will continue with the first tasks, but n ow it will also: 1. Accept or deny new connections from other ultrapeer s and possible new leaves. The P2P application has a maximum number of connections so that bandwidth and performance of the host is not affected. 2. Retrieve the list of keywords from the files that e ach of its new leaves are sharing. It will be used to decide to which peer each received Query can be forwarded. 3. Forward Queries received by its leaves or ultrapeer s, if the TTL of the message allows it. Queries will be forwarded to its leaf only if a searched ke yword is in the list of keywords for the host to which the message will be forwarded. 2.4 Existing Approaches to Save Energy Wasted Due t o Induced Use A technology was invented in 1996 by IBM to remotel y wake up PCs without the need to manually turn them on, and was popularized later through an alliance with IBM. The technology is currently know n as Wake-On-LAN (WoL) and enables PCs to be woken up by an administrator. The idea consists of using a packet that should trigger the PC receiving the pac ket through the network to power up from a poweredoff state or a sleeping state. This implies that the NI C of the PC has to remain on all the time in order to detect


26 the packet. To support this technology, motherboard s were modified to keep NICs powered-on when the PC is turned off or sleeping. Manufacturers produce d NICs that could detect the patterns used to wake up. AMD invented a technology called Magic Packet [8] a s a packet with a specific pattern to trigger wakeups. The format of the Magic Packet is shown in Fig ure 2.7. It contains in its payload 6 bytes where a ll bits are set to 1, (six times the hexadecimal FF), follo wed by the MAC address of the PC to be woken up. Th e packet is sent by an administrator in a MAC frame t o the broadcast domain of the PC that is sleeping. The NIC of the PC to be powered-on will detect and reco gnize its MAC address in the Magic Packet received and will power up the PC. Because there is no way f or a PC to know the MAC address of a PC that it is outside of the same LAN it is on, there is no way f or a PC to use WoL to wake up a PC outside of its domain. This is the most important limitation of Ma gic Packet. Routers are usually set to discard dire ct broadcast frames, so they are not forwarded outside of the LAN. This is done to prevent excess traffic in the network. APIs for NICs, like Network Driver Int erface Specification (NDIS) used for most of NICs, have included a set of patterns that NICs can suppo rt to trigger a wake-up of the host. These include, among other patterns, TCP SYN packets in IP version 4 and 6, and Magic Packet. The problem with the use of patterns to trigger wake-ups is that the hos t might wake up too often for TCP SYN packets direc ted to ports not used by any of the applications runnin g on the host or by applications not running by the time the SYN packet is received. There have been several efforts to improve reachabi lity of PCs beyond the possibility of being simply woken up. One approach is to enable NICs to respond to ARP packets even when the PC is sleeping. Ethernet NICs that support DMTFÂ’s Alert Standard Fo rmat (ASF) Specification 2.0 [5] can respond to ARP packets. Intel has developed a series of techno logies implemented in some series of their motherboards to improve wake-up. One of them is Int el vPro targeted to companies that wanted to improv e remote manageability of computers inside of their n etwork [61]. The most important feature was to mana ge Figure 2.7. Magic Packet Format 6 bytes 102 bytes 2 bytes 6 bytes Destination MAC Source MAC Six times FF followed by dest. MAC repeated 16 times Type


27 information directly obtained from the PCs even if they were turned off or the operating systems were not working properly. The problem with this improved wa ke-up is that it implies the use of new hardware (Intel motherboards) and requires modifications of existing applications to interact with Intel. Usual ly software vendors wait to see if the technology rema ins in the market to consider modification of their products. Intel also created Remote Wake Technology (RWT) [60]. This technology allows applications running in a PC with an Intel motherboard that has this feature to allow remote wake-ups to the PC usi ng an interface provided by Intel. The problem with th is technology is that applications that want to all ow the user to remotely wake up the PC have to be modified to interact with the Intel motherboard to allow packets from this application to wake up the PC. Tw o examples of applications given by Intel are a VoI P application and a remote management application. Th is technology is then limited to the group of applications modified to work with the Intel RWT AP I. A series of companies have created their own improv ed version of wake-up technology. One company is VERDIEM, which has several power management prod ucts. The most important is a solution called Surveyor [137] that uses the Intel vPro technology. It is an infrastructure focused on power managing PCs in a company. The architecture, shown in Figure 2.8 consists of a server that will receive wake-up re quests from IT staff or from remote requests from employee s. They invented the concept of Wake-On-WAN, which relies on a Surveyor proxy to directly wake u p PCs using Wake-On-LAN packets. This proxy receives requests from the Surveyor server, which r outes the requests. Another company is 1E which has focused on power consumption of network hosts and h as several commercial solutions. They focus mainly Figure 2.8. VerdiemSurveyor Infrastructure [137] Surveyor server Surveyor database Remote wake-up request Surveyor proxy Surveyor client Surveyor client Surveyor client Wake-OnLAN packets


28 on enhancing wake up capabilities inside of the com pany network by assuring remote wake up is possib le and by keeping track of whether the wake up attemp t was successful or not. At the same time they have been publishing surveys about power consumption and power management policies in office equipment [109]. There are other existing works based on putting hos ts (or components of them) to sleep and waking them up when needed. An example presented in [3] is an approach to manage power consumption of mobile devices that run VoIP applications over Wi-F i. Wi-Fi interfaces represent a large percentage of the power used by mobile devices. Due to the strongly c onstrained batteries of mobile devices, especially cellphones, the authors used the approach of turning of f the Wi-Fi and turning it on only when necessary. The authors developed an architecture called “Cell2Noti fy” that wakes up the interface when an incoming Vo IP call is detected. For this purpose, it uses the cel lular network to detect incoming calls. 2.5 Network Connectivity Proxying (NCP) for Power M anagement An NCP is an entity that maintains full network pre sence for a sleeping network host [100]. Figure 2.9 shows the fundamental concept behind the NCP – the ability of the NCP to “cover” for a sleeping host. The figure shows how state and control is transferred b etween the host and NCP when the host enters and ex its the sleep state. The operational steps are 1. The host determines that it is time to go to sleep (e.g., based on inactivity), 2. Notice and state are passed to the NCP, and the hos t goes to sleep, Figure 2.9. Operation of an NCP Sleeping host NCP (2)(4, 5) (1) (3) Network


29 3. The NCP maintains full network presence, responding to and generating, protocol and application packets as needed, 4. The NCP determines when a packet requiring the full resources of the host has arrived and signals the host to wake up (the host could also wake up on user activity or from an internal timer), and 5. Once the device has fully woken up, state is passed back from the NCP to the host, and the host returns to normal fully powered-on operation. This dissertation is focused on open problems and q uestions related to the NCP concept. For example: 1. What are the requirements for the NCP to maintain f ull network presence for a sleeping host? 2. What is the type of information that the host needs to pass to the NCP for it to maintain a presence? The use of “performance enhancing proxies” (PEP) to mitigate link-related degradations is described in RFC 3135 [19]. A means of handing TCP connection s during periods of disconnection is described whereby a proxy would “zero window” a server host d uring the disconnection period. Handling optionally reliable links and hosts is further considered unde r the scope of Delay-Tolerant Networks (DTN) [39]. Proxying for maintaining networking connectivity fo r sleeping hosts was first explored by different authors in the mid-1990s for shared Ethernet networ ks [25]. This work was later refined for IP network s in general [28], [53], [100]. A specific goal of being able to proxy low-level tasks including ARP, DHCP, and ICMP was explored. A simple prototype was developed and is described in [53]. In [7] an initial exploration of the architectural constructs require d to support selective connectivity was presented. Selective connectivity is the notion that a host ca n choose the degree to which it maintains a network presence, rather than today’s binary “connected” or “disconnected”. A key architectural construct to support selective connectivity is an assistant that stands in for a host that is sleeping. Thus, [7] b egins a more mature thinking of the long-term implications of network presence and how to support it in future networks. Recently, University of California San Diego (UCSD) has begun to prototype a scheme called Somniloquy whereby a secondary low-power processor covers for the main processor of the PC [4]. The prototype has been developed on a USB-based gumstix device. Somniloquy appears to be a general purpose architecture that can also support applicat ions via application stubs. Somniloquy builds upon many


30 of the ideas in [28], [53], and [100]. Somniloquy i s not able to preserve TCP connections between host awake and sleep, which might be needed for some app lications that relay user sessions. The future dire ction for Somniloquy, and possibly for the work in this d issertation, is to host the NCP on a NIC. NICs are becoming more capable, and many now include onboard processors. Other works on proxying like that of Nedevschi [97], has already started to look at the classification of packets arriving to hosts, presen ting different approaches to classify them. The most imp ortant approach was to deconstruct types of packets by grouping them into multicast and unicast packets. T he grouping was a basis for determining policies ab out how to process packets (if responses were needed, o r if not, how urgent the packets were, and so on). TCP Chimney is a Microsoft NDIS 6.0 architecture fo r full TCP offload [89]. TCP Chimney provides a direct connection between applications and an off load-capable NIC to reduce TCP-related processing load on the host CPU. This enables the NIC to perfo rm TCP processing for offloaded connections, including maintaining the protocol state. TCP Chimn ey does not explicitly address network connectivity beyond that of TCP connections. Other works have at tempted to make application connections robust without the direct intention of proxying the connec tivity for power management. One approach is by creating an extra layer between the application and the transport layers. The early work by Zhang and Dao [143] and the work by Zandy and Miller [142] create d a special library that adds another layer to the communication stack, which makes the connections re liable and independent of mobility. Others have focused explicitly on making TCP connections reliab le. The targets of these solutions have usually bee n mobile devices, where failures in the transmission might occur during the connection [6], [35]. 2.5.1 Early Work in Proxying of ARP Proxying for applications or network protocols has been done for a few decades. In 1987 the idea of implementing a proxy functionality inside of a rout er to proxy for ARP was published in RFC-1027 [21]. The original purpose was to be used by subnet route rs to allow hosts to communicate without being awar e of the existence of subnets. This was called an “AR P proxy.” The mechanism worked clearly with the example of a host A trying to communicate with anot her host B located in another subnet. Both subnets, however are connected by a subnet router. Host A wi ll send an ARP to query for the physical location o f host B. The router will respond on behalf of host B with the knowledge that B is located in a subnet of which the router is aware. Thus, the router proxies the response of the ARP originally sent to host B, and


31 both hosts are unaware of the existence of the subn ets. The same concept can be used by a proxy with t he purpose of saving energy. The proxy can send ARP pa ckets on behalf of a proxied host when it is sleepi ng. The work in [25] explained the design and prototype of a power management proxy server to mainly keep TCP connections open. One of the proposed extension s is to respond to ARP packets sent to the sleeping host, so that applications can reach the host. 2.5.2 Proxying for UPnP The Universal Plug and Play (UPnP) set of networkin g protocols [136] is another example of a network application that demands constant connectiv ity of the hosts connected to the network. UPnP is intended to enable a simple and robust connectivity among different electronic devices, regardless if their network connectivity is wired or wireless. The most used protocol from this set is the Simple Service Discovery Protocol (SSDP), which is the service in charge of discovering network services. The protoco l requires all devices participating in the network t o be powered-on so that they can send and receive S SDP messages. Devices participating in UPnP network hav e the capability of offering a service, or being a control point. A printer can offer services like pr inting or faxing. A control point can make use of t hose services. Alive messages are sent by devices to adv ertise a service, discovery messages are sent to di scover services. If a device is in a sleep state, it canno t respond to discovery messages and it will not be able to update the advertisement of a service. In [81] a power management proxy for UPnP was desig ned and evaluated. This work describes the design of an invisible proxy and a cooperating prox y. An invisible proxy responds to discovery message s sent to a sleeping device, and periodically sends s ervice advertisement messages on behalf of the slee ping device. It is invisible because it requires no modi fication of the devices being proxied and it does n ot advertise its presence. It is able to detect when a device is sleeping by checking the last alive mess age update sent by the device. It can take over a sleep ing device by broadcasting an ARP packet to change the location of the IP of the sleeping device. Packets to that IP will be sent to the proxy as long as the device is sleeping. The cooperating proxy on the other side a nnounces its presence to the devices connected to t he network. This implies adding a power management cap ability to devices implementing UPnP. With that service, devices can tell the proxy it is entering or leaving a sleep state. The proxy will then start or stop processing messages on behalf of the device. A simi lar approach was used in [66] to create a power


32 management architecture for home networks, composed of different devices. One of the components of the architecture was an Energy-aware Plug and Play prot ocol used by clients and servers. 2.5.3 Current and Recent Efforts to Define and Stan dardize Proxying Different groups have been involved recently in the attempt to standardize Network Connectivity Proxying. The Ethernet Alliance published a white p aper in 2007 with the intention of defining proxyin g for Ethernet-connected devices [100]. The authors o f the paper gave an introduction to the problem of energy waste of networks and then gave two possible solutions. They considered one feasible option to be “Encapsulating the intelligence for maintaining net work presence in an entity other than the core of t he networked devices” [100]. This white paper defined three approaches to implement proxying: 1) Self proxying, 2) Switch proxying, and 3) Third-party pr oxying. Self proxying means that proxying functionalities would have to be implemented on the hardware of the same host to enable energy savings Switch proxying puts the functionality into the rou ter to which the host is connected. Third-party pr oxying puts the functionality in another host that might b e located elsewhere in the network other than the r outer to which the host is directly connected. The work of t his dissertation can be classified as Self-proxying and Third-party proxying. There is a current effort by Ecma International (an industry association dedicated to ICT standardization) to standardize the idea of proxyin g to support sleeping hosts, as explained in TC32-T G21 [34]. It is an ongoing work where the final purpose is to provide an overall architecture for proxies and provide details of how to proxy for key protocols. Key protocols can be understood as application prot ocols that are commonly used and that can be generating t raffic from/to the host regardless if the host is b eing used or not. As part the work of the group working on the standard, the interest is also to develop us e cases to understand what cases should be in the standard or not. This use cases should explain how to classi fy an application as key protocol, and how the proxy shou ld act when the host is sleeping. This will help al so to determine possible solutions where proxying might n ot be the answer. The group expects to create a specification that defines the information that has to be exchanged between the proxy and the host, wh at should be the capabilities of the proxy that the ho st should be aware of, and what should be the behav ior of the proxy if it works on Ethernet or Wi-Fi. As part of this, requirements for network management proto cols are being established, like ARP, SNMP, DHCP, IGMP, among others.


33 Implementations of the NCP for applications like P2 P could be extremely constrained by the device on which they are running. With the objective of savin g energy in mind, one possible option is a device t hat consumes much less energy than the proxied host. In this way, the proxy could remain powered-on at all time proxying for the host. For a P2P, processing o f Query messages in the proxy is needed, with the purpose of searching the keywords and discarding Qu ery messages that do not match files being shared. This requires keyword search algorithms and data st ructures that are optimized as much as possible for small and low-power consuming devices that could be used as proxies. 2.6 String Search Algorithms and Data Structures Different string search algorithms and data structu res are explained in this section. The problem consists of finding a string (or pattern) in a text (or set of strings). An algorithm to solve this fi nds a string by either responding with a Boolean variable if the string exists or not in the text, or by returning a set of all the occurrences of the string in the text. The alg orithms can be divided into two types: algorithms t hat construct data structures over the text to be searc hed and algorithms that scan the text sequentially to find the pattern (Chapter 8 in [11]). Bloom filters and hash tables are signature data structures, because they store signatures of an original text, constructed b y using hashing [11]. The resulting data structure can save space but adds limitations regarding the depth of t he information they can represent. Hash tables and Bloom filters are handled with the balls and bins m odel, where n balls are thrown into m bins [92]. 2.6.1 Hash Tables A hash table is a data structure represented with a table that maps certain keys to their associated elements. Elements that are mapped (or inserted) ca n be of many different types, for example, strings. In this dissertation, implementations of hash tables w ill use strings as elements. Elements are mapped in buckets of the table with the use of an element key (also known as element signature). The element key has to be unique for each element mapped, and is later used to locate the element. The mapping is done by using a hash function that has the element key as i nput, and returns a bucket index of the array. Diff erent element keys might produce the same bucket index, w hich is called a collision. At this time, different collision resolutions can be applied. Hash tables a re used in applications where search time is an iss ue, because search time on hash tables takes (1) on average, regardless of the size of the table [31].


34 There exist different collision resolution approach es used by hash table algorithms. Insertion, deleti on and search algorithms depend on what collision reso lution approach is used. The most common approaches are the following: 1. Chaining: Elements are not stored in the buckets se lected by the hash function but instead inserted into a list associated with that bucket. Buckets no w are used to point to the list created with all elements mapped to that bucket index. When another element key collides in the same bucket, the insertion algorithm will just add that second eleme nt to the same list. 2. Open Addressing: Elements are mapped into the buck et selected by the hash function if the bucket is empty. If an element is to be inserted in to a non-empty bucket, an approach is used to select the next bucket to be proved, until the next empty bucket is found. The insertion algorithm then depends on the collisi on resolution approach used. Figure 2.10 shows the algorithms for mapping a string and finding a strin g in the hash table hashTable of size b buckets. The input of the algorithm mapString() is the key and t he string to be inserted. A the input of the hash( ) function is the key and it returns an index that is used to select the bucket to attempt an insertion. A global variable collisionRes is used to store the collision resolution approach selected. If Chaining is used (line 2), the function insertAtList() is used to insert the s tring at the end of the list associated with the se lected bucket. If Open Addressing is used, (line 4) first, newProbe() in line 5 is called to select the index of the next available bucket. This function will use one o f the approaches used to probe for empty buckets. Then the string is inserted into the bucket selected, ca lling insertAtBucket() in line 6. Figure 2.10. Hash Table Algorithms to Add a String and to Find a String mapString( mapKey mapString ) 1. index hash( mapKey ) mod b 2. if ( collisionRes = CHAIN) 3. insertAtList( hashTable, mapKey mapString ) 4. else if ( collisionRes = OPENADDR) 5. index newProbe() 6. insertAtBucket( hashTable mapKey mapString ) findString( inKey ) 1. index hash( inKey ) mod b 2. outString find( hashTable, index inKey ) 3. return ( outString )


35 A key feature of hash tables is that the number of buckets in the table can be increased as needed. To know when resizing should occur, the concept of loa d factor is used. Load factor of a hash table is th e ratio of non-empty buckets of a hash table. Usually, if t he load factor goes beyond a threshold, the table s ize will be increased. If it falls below another threshold, the size is decreased. The load factor determines h ow often collisions will occur. It can range from 0 to 1. If the load factor is too high, collisions will occur often, then decreasing the mapping and searching time. Differen t hash tables implementation check if the load fact or is too high given a desired threshold. It is typical t o check it after certain number of insertions or de letions of elements have occurred in the table. The implementa tion decreases the size of the table or increases i t if the load factor is below or above the desired threshold respectively. An algorithm to delete an element o f the table is not shown here. There have been many different improvements to hash tables, most focusing on improving access time. Perfect hashing was proposed in 1984 as an approach to achieve (1) even in the worst case [45]. Since then, hashing techniques have been considered as pe rfect hashing if the access time is (1) in the worst case [31]. The basic idea is to use two use two sch emes of hash tables, the main hash table, and small hash tables associated with each of the buckets of the m ain hash table. For this purpose two hash functions are used. Different techniques can be used to achieve t his, as shown in [32]. Later Silverstein proposed a n improvement of previous techniques in [123], work t hat derived in the Google Sparse Hash Table [49]. I n [45] the authors used a sparse array to save space by allocating space only for locations in use. Spac e is allocated as signatures are inserted. Signatures ar e pointed to by a second array used as a reference. However, it is not clear which data structure the a uthors used to implement it. 2.6.2 Bloom Filters A Bloom filter is a probabilistic data structure th at represents a set of elements (strings in most of the applications used in this dissertation) [15]. A Blo om filter consists of an array of m bits, initially all set to 0, used to represent n strings. A group of k hashes are used to map (or “store”) strings and to test for membership. Compared with hash tables, Bloom filter s are more limited because elements cannot be searched and retrieved. Instead, this data structur e can only answer search attempts with a probabilis tic response, in form of a true or false, meaning the e lement probably is or definitively is not in the ar ray. Figure 2.11 shows an example of the mapping and tes ting in a Bloom filter. The Bloom filter starts wi th all


36 bits set to zero when there is no element mapped in Elements X1 and X2 (and the rest of the set of elements) are mapped, and two elements might set th e same position to 1. When testing for elements, Y1 is definitively not in the array (because one of the p ositions is not set to one), and element Y2 probably is in the array (it might be false positive, or a true po sitive). Figure 2.12 shows the two key algorithms f or a Bloom filter: mapStrings() and testString() In mapStrings() m strings are hashed k times each, and the hash values are used to identify bit locations in bloomArray to be set to 1. In testString() an inString is hashed k times and the k bit locations are tested. If all k locations are a 1, then probabilistically, the Blo om filter “contains” inString In both algorithms, the hash() function is used t o generate a hash and its input are a string and an index. The index is used by hash() to return a different hash each time the function is called for the same string (thus generating k different hashes). The hash() function returns a h ash value that then is mapped to one of the m positions in the array (with “mod m” in line 5 of mapStrings() and line 2 in testString()). In the analysis of a Bloom filter false positive ra te it is typically assumed that the hash functions are perfect, whereby they produce an independent and ra ndom index value for each object and thus the false positive rate is only a function of m n and k The “classic” analysis of Bloom filter false posi tive rate is as follows (this analysis is often attributed to Bloom [15], but his original analysis was different, thi s classic analysis probably first appeared in a paper by Mull in [94]).It is assumed that a hash function selects each array position with equal probability. When n objects are mapped in, the probability that an arb itrary bit is not set is ( ) knm 1 1 Then, the probability, p that a given bit is set in a Bloom filter is Figure 2.11. An Example of a Bloom Filter [20] 000000000000 010101001100 010101001100X1X2 Y1Y2 … …


37 [] knm p = = 1 1 1 set is bit given a Pr. (2.1) A false positive occurs when a tested string that i s not a member of the Bloom filter maps to k bit positions that are set (i.e., have been set by strings mapped into the Bloom filter). This event occurs as [ ] kp = positive false Pr. (2.2) The false positive probability can be approximated as [] ( ) k m kne- 1 positive false Pr. (2.3) For a Bloom filter with s bits set, m s p = and thus [] km s = positive false Pr. (2.4) The value of k that minimizes the exact expression in eq. (2.3) c an be solved for directly and is ( ) n m m kopt = 1 ln 2 ln. (2.5) The value of k that minimizes the approximate expression in eq. ( 2.3) can be solved for directly and is Figure 2.12. Bloom Filter Algorithms to Add a List of Strings and Test a String mapStrings( stringList ) 1. for i 1 to m do 2. bloomArray [ i ] 0 3. for i 1 to n do 4. for j 1 to k do 5. index hash( stringList [ i ], j ) mod m 6. bloomArray [ index ] 1 testString( inString ) 1. for i 1 to k do 2. index hash( inString i ) mod m 3. if ( bloomArray [ index ] = 0) 4. return (FALSE) 5. return (TRUE)


38 () n m kopt2 ln =. (2.6) As m becomes large, the values of optk in eq. (2.5) and eq. (2.6) converge to the same. A table of false positive values for varying m n and k based on eq. (2.6) is presented in [41]. In practi ce, k has to be an integer and the chosen k might be above or below the optimum value. The val ues exposed there however use an approximation of eq. (2.6). With the optimum k half of the bits in bloomArray are set to 1. For 16 = n m (i.e., 16 bits of bloomArray allocated for each mapped string), 11 = k. For each string test that results in a “hit,” k hashes and k memory accesses (or memory lookups) are needed. On average, 2 hashes and memory accesses are needed for a string test that results in a “miss”. This can be calculated as follows. The expected fraction of bits of a Bloom filter that are set to 1 after mapping n elements is 1/2, for large Bloom filters [20]. So, the probability, p ’, that when testing a bit position it contains a zero, is 1/2.Let U be a random variable for the number of lookups. [] 2 5.0 1 1 1,= = = p U Emiss. (2.7) An element can easily be added to a Bloom filter, a nd the algorithm to do so is similar to mapStrings( ), except that instead of adding a set of elements, on ly one element is added. It is, however, not possib le to remove elements from a Bloom filter without creatin g the possibility of a false negative. This is a ma jor shortcoming of Bloom filters. Applications of Bloom Filters Bloom filters have found use in spell checkers, dis tributed databases, distributed caching, and in man y other areas. A survey of network applications of Bl oom filters is in [20]. Improvements to Bloom filte rs have been studied by many researchers. Counting Blo om filters was proposed by Fan et al. [40] (and improved by Bonomi et al. [16]) as a means of allow ing insertion and deletion of elements (standard Bl oom filters do not allow for element deletion). A count ing Bloom filter uses multiple bits (typically 4) f or each location. Thus, a 4-bit counting Bloom filter requi res 4x the amount of memory. Another well known improvement is the compressed Bloom filter [91]. Th e author presented a novel idea to reduce the numbe r of bits transmitted through the Internet when a Blo om filter is to be sent between two hosts. The numb er of


39 bits set in the filter is reduced (compressed) befo re sending it as message and then the filter is uncompressed back again to the original size. Bloom filters have been used extensively in caching of web servers. Fan et al. [40] proposed the use o f modified Bloom filters to construct summary caches that are to be transmitted among servers. The modification consisted of allowing element deletion s. This was achieved by using 4 bits per original b it position, used as a counter for the number of eleme nts mapping to that position. These modified Bloom filters were later called Counting Bloom filters. B loom filters have also been used for packet inspect ion. The logic behind packet inspection is a form of str ing matching. The work in [121] presented a tiered architecture of Bloom filters of different sizes (c alled hierarchical Bloom filters) to classify paylo ads of packets. The advantage of their solution is that wi th the use of this architecture, pieces of the payl oad could be tested, and it was not necessary to find a match for the whole payload, but excerpts of it. The wor k in [33] focused on taking advantage of hardware implem entations to test several Bloom filters at the same time. The purpose of the hardware implementation wa s for fast packet inspection. Another approach for packet inspection from the same authors mixes Bloom filters and hash tables to provide exact matches instead of probabilistic matches as the original Bl oom filters do. Their results claim that their solu tion decreases the number of memory accesses per lookup compared to hash tables. Lumetta and Mitzenmacher [86] applied the idea of p ower of two choices to Bloom filters to reduce the probability of false positives (called here Pow er-of-2). Lumetta and Mitzenmacher use two groups o f hash functions for mapping elements and testing for element membership. They considered two settings: online and offline. When mapping an element with th e online setting, the two groups of hash functions are used to test which one adds the least amount of bit s to the Bloom filter. This is done for each of the elements. The algorithm for the online setting (not shown in the original paper) is shown in Figure 2. 13. For mapStrings(), each string is checked twice (one per each choice of hash functions) and the choice generating the least amount of bits is used to actu ally set the bits (in lines 8 and 10 of the algorit hm). When mapping with the offline setting, the whole gr oup of n elements are mapped with each choice of group of hash functions to see which group yields t he least number of bits set in the Bloom filter. Ma pping of each element is repeated through rounds to check if choosing another group of hash functions might yield a better rate of bits set. This increase in p rocessing results in a decrease in probability of f alse


40 positive. The improvements reported factor of 2 to 3 reduction in probability of false positives. Howe ver, the added expense in computation when testing for a n element depends on the number of choices. If for example, two choices are taken, two times the numbe r of generated hashes is needed, and thus two times the number of accesses compared to the original Blo om filter. An optimal Bloom filter replacement was studied by Pagh et al. [107]. Their approach is to use dynamic multisets to reduce membership testing time and space usage (and thus also probability of false positives for a given space allocation). This work is theoretical with no reported experimental implement ations or results. Figure 2.13. Power-of-2 Algorithms From Lumetta and Mitzenmacher [86] mapStrings( stringList ) 1. for i 1 to m do 2. bloomArray [ i ] 0 3. for i 1 to n do 4. count1 count2 0 6. for j 1 to k do 7. hashVal1 [ j ] hash1( stringList [ i ], j ) mod m 8 if ( bloomArray [ hashVal1 [ j ]] = 0) 9. increment count1 6. for j 1 to k do 7. hashVal2 [ j ] hash2( stringList [ i ], j ) mod m 8 if ( bloomArray [ hashVal2 [ j ]] = 0) 9. increment count2 6. for j 1 to k do 7. if ( count1 < count2 ) 8 bloomArray [ hashVal1 [ j ]] 1 9. else 10. bloomArray [ hashVal2 [ j ]] 1 testString( inString ) 1. tempFlag1 tempFlag2 TRUE 2. for j 1 to k do 3. index = hash1( inString j ) mod m 4. if ( bloomArray [ index ] = 0) 5. tempFlag1 FALSE 6. break 7. for j 1 to k do 8. index = hash2( inString j ) mod m 9. if ( bloomArray [ index ] = 0) 10. tempFlag2 FALSE 11. break 12. if ( tempFlag1 = FALSE) and ( tempFlag2 = FALSE) 13. return (FALSE) 14. return (TRUE)


41 For faster hashing for Bloom filters, Kirsch and Mi tzenmacher [77] explored the use of pseudo hashing. Given two hash functions, ( ) x h1 and ( ) ,2x h additional pseudo hash values can be generated as ( ) ( ) ( ) x h i x h x gi 2 1 + = (2.8) where i is the hash value index (where i = 1, Â… k ) and x is the string value being hashed. Kirsch and Mitzenmacher describe the application of this metho d to Bloom filters. To generate k indexes into a Bloom filter requires only two actual hashes and 2 k iterations of (2.8) which is a considerable reducti on in processing compared to needing k actual hashes. It is shown in [77] that using this method does not increase the asymptotic probability of false positi ves. This approach will result in higher false posi tive rates when the initial hash values are the same for diffe rent strings. Most application use a large Bloom filter of many M B in length [20], [40]. However, there are applications that use small Bloom filters of a few bytes in length, with some examples as follows. Mul lin has investigated the use of small Bloom filters to speed up string search [95]. Mullin employed a firs t algorithm to build an index of Bloom filters of one per document and a second algorithm to use the resulting Bloom filter index for searching. A speci fic example was developed and demonstrated where titles and author names from articles in the Communications of the ACM for 1983 and 1984 were used for the search text. The expected (predicted) performan ce of the new algorithm was not studied by Mullin. Whitaker and Wetherall [139] used small Bloom filte rs embedded in packets to detect and halt forwardin g loops in networks (and to do so faster than a timeto-live field would). In their scheme, named Icarus an extra field is added to a packet header that consis ts of a small Bloom filter which registers the netw ork interfaces through which the packet has been by set ting pre-determined random bits in the Bloom filter header. If at a given interface the bits do not cha nge (that is, no bits are changed from 0 to 1), the packet is determined to be probably looping (that is, has pro bably passed through this interface already). Loopi ng packets are removed after more than one such determ ination. An analysis of expected hop count before a false positive was given as a function of Bloom fil ter size. 2.6.3 Algorithms for String Searching String search is an area of information retrieval t hat has been subject of study for many years [10], [44], [128]. This kind of search can be performed t o find exact matches or approximate matches. The


42 search can end with probabilistic or deterministic responses. String search algorithms are used to fin d all the occurrences or the first occurrence of a string in a given text [10]. The string to be searched (a lso known as “pattern” in the literature) and the text are st rings over some alphabet. They might however contai n some patterns described by a language (e.g., consonants and vowels arranged according to the English langua ge). Many string search algorithms have been created sin ce the 1970s, and new ones based on complex approaches have been presented relatively recently, like a multiple string pattern matching algorithm based on a compact encoding scheme, presented in [80]. Th e performance of these algorithms is evaluated by measuring the execution time to search for a string in the worst, average and best case. In the case t hey need a preprocessing phase, the time needed for pre processing and the space required are also used to compare performance. The algorithms can be classifi ed using many different criteria. For example, they can be classified using the direction they take to traverse the text to be searched (some can go right -to-left, others can go left-to-right). Another classificatio n uses the preprocessing required as classification criteria. The preprocessing might be done on the text or on t he pattern. Preprocessing on the text can be divide d into several types of operations. Typical operations are : 1) lexical analysis of the text to treat punctuat ion and cases, 2) elimination of stop-words and 3) stemming of the remaining words to remove affixes, among others operations (see Chapter 7 of [11]). Based on the preprocessing required, the classification can be divided into algorithms that do not perform preproc essing at all, and algorithms that perform some kin d of preprocessing. The basic string algorithm uses the nave approach. It consists on traversing the text one character a t a time and each time comparing all the characters of the pattern with the subset of text characters that starts at the current character being checked. The basic algo rithm does not perform any preprocessing on the pat tern or the text. The Knuth-Morris-Pratt algorithm publi shed in 1977 in [82] takes advantage of unsuccessfu l characters comparisons and avoids comparing those a gain, thus speeding the search. To achieve this, th e pattern is preprocessed to construct a table that s tores for each character the index of the next char acter to be processed if that character caused a mismatch. T his algorithm does not preprocess the text. Anothe r well known algorithm is Boyer-Moore, created also i n 1977 [17]. The main characteristic is that it tra verses the pattern from right-to-left to find a match in t he text. If there is a mismatch, it computes a shif t to move the pattern to the right and restart the comparison s. This algorithm is considered the most efficient in the


43 average case. This algorithm also falls into the ca tegory of algorithms that perform some partial preprocessing. Karp and Rabin [74] presented an al gorithm that uses a hashing technique. It calculate s a signature for each substring of the text of size m and compares it to the signature of the pattern, u sing of course the same hash function for the text and the pattern. Depending on how well the hash function is chosen, the occurrences of collisions might be low. A collision occurs when the pattern and a substrin g of the text have the same signature but there is no tr ue match. To avoid false responses, the pattern and the substring are checked and compared character by cha racter to see if they have equal signatures. 2.7 Chapter Summary In this chapter, research on power management for a n ICT host has been described to understand the background of the main work of this dissertation. A s part of this, the concept of induced energy use w as explained and a detailed description of what are th e typical applications that drive the induced energ y use of hosts was given. Then the concept of Wake-On-LAN and the improvements that have been proposed were explained. It is clear now what the disadvanta ges are of relying only on waking up the host when it is needed in order to achieve energy savings. Thus, th e existing work on Network Connectivity Proxying (NCP) was explained as a better solution for saving energy, given the advantages of maintaining the network presence of the host while it sleeps. Backg round on string search algorithms was explained the n as a base for potential NCP implementations that run o n resource constrained devices. In the next chapter, the first detailed architectur e of an NCP with a design to proxy for IP phones running SIP, and also for some types of client-serv er applications, is described.


44 Chapter 3: Proxying as a Means of Reducing Induced Energy Use Hosts connected to a network maintain their presenc e to other hosts by generating and responding to messages for network and applications protocols. A network host then, as defined here, is a host that is connected to the Internet using IP version 4. A Net work Connectivity Proxy (NCP), as proposed in [100] is an entity that implements the key network presence capabilities of a network host in order to allow th e host to sleep, yet it allows the host to appear to other devices as fully operational and connected to the network. Thus, an NCP can enable a network host to sleep and save energy whereas without the NCP it could not sleep even if inactive or idle. For IP version 6, n o fundamental change should be needed. There are ne twork management protocols that are new in version 6, but are beyond the scope of this work. Figure 3.1 shows a network with two network hosts l abeled as a host A and remove host and an NCP located within a switch to support host A. The NCP could also be located in another host on the networ k, within a wireless access point, or within the NIC i n the sleeping host. As a first step towards design ing an NCP, formal assumptions, goals and requirements are defined. The following assumptions must hold for the network host covered by an NCP: 1. Have a sleep mode that can be entered/exited on app lication or operating system command. 2. Be able to fully exit sleep mode in the time span o f a few seconds or less. 3. Have a sleep mode that preserves all local protocol and application states. 4. Support a remote packet-based wake-up method such a s Magic Packet and/or pattern matching (if the NCP is in a remote location, not in the NIC of the host). 5. Support the ability of applications in hosts to be able to block the host from entering a sleep state if and when the application is actively using CPU, network, or other resources.


45 The following are the system-wide goals that a syst em with a network host covered by an NCP should achieve: 1. A host must be allowed to sleep and not lose its ne twork presence. a. A host must maintain its IP address and be reachabl e by edge routers and switches. b. Valid incoming requests for TCP connections to a ho st must be honored. c. Existing TCP connections to a host must not be drop ped and data must not be lost. d. UDP packets sent to a host must not be lost. 2. During the time the host is sleeping, remote state (such as application state in a remote host) must be maintained in all cases. a. Application keep-alive messages and/or other applic ation messages must be responded to as required by the application. 3. Changes to network applications and protocols must not be required in the host or the remote host. 3.1 General Requirements for a Network Connectivity Proxy (NCP) The NCP has assumptions and general requirements. T his work is the first to address application level proxying for TCP connections. The work done by Ecma for the proxy specification is focused on working on network management protocols and IP connectivity [34]. The assumptions that hold for the NCP are: 1. It is always fully powered-on and connected to the network. 2. It is within the same MAC-level domain (and thus sa me IP subnet as well) as the covered host. Figure 3.1. System View of the NCP Note: The NCP within the router covers for host A when it is sleeping to maintain full network presence. Remote host Router Remote host to NCP packet flows Network NCP to host A packet flows NCP Host A


46 3. It has equivalent security measures in place as the host for which it is covering. The general requirements for the NCP are organized into four categories: IP connectivity, TCP connections, UDP data flows, and network applicatio ns and higher-layer protocols. The minimum requirements for supporting IP connectivity are: 1. Have a much smaller incremental energy use than a n etwork host (e.g., 10x less). 2. Know the power state – minimally, off, sleep or on (awake) – of the network host. 3. Use of the IP address(es) of the host for which it is covering 4. Be able to support ARP, DHCP, and ICMP protocols fo r a sleeping host to maintain its host reachability, address, and manageability. 5. Be able to operate behind a typical NAT service. Additional general requirements for supporting TCP connections are: 6. Be able to listen for valid TCP connection requests and other requests coming from other network hosts to a sleeping host. a. Be able to wake-up a host for a valid incoming TCP connection request and enable the connection to be established. 7. Be able to maintain permanent TCP connections for a sleeping host and buffer incoming data. a. Be able to immediately re-start TCP connection data flow to a host when it wakes up. b. Be able to immediately deliver buffered TCP data to a host when it wakes-up. c. Be able to close TCP connections when it can be det ermined that a host has been removed and is no longer present. 8. Be able to wake up a sleeping network host when NCP buffers are nearly full to prevent buffers from filling up and potentially losing packets or b locking the server from sending data. Additional general requirements for supporting UDP data flows are: 9. Be able to buffer incoming UDP packets for sleeping hosts. a. Be able to immediately deliver buffered UDP packets to a host when it wakes up. Additional general requirements for supporting netw ork applications and higher-layer protocols are: 10. Be able to keep network applications executing as i f the host was not sleeping. a. Be able to respond to routine application messages as required by the application.


47 b. Be able to generate routine messages as required by the application. Requirements (1), (2), (6), (7), and (10) (that is, power state signaling and support for TCP connecti ons and keeping network applications executing) are address ed in this chapter and Chapter 5. Requirements (5), (8), and (9) are beyond the scope of this dissertation. Those 3 requirements are simple to design and imple ment. Requirements (3), (4), and (5) have been largely ad dressed in previous work (see Section 2.5 of Chapte r 2 of this dissertation). The NCP follows a sequence of steps when it starts proxying for the host and when it stops proxying for it. These steps include getting notification of the power state, states of applications, and maint aining full network presence. When the NCP is covering for a sl eeping host it receives packets intended for the ho st. Each received packet results in one of the followin g actions: directly respond to the packet, wake up the host, discard the packet, and/or queue the packet f or later processing by the host when it is awake. F igure Figure 3.2. Packet Processing by the NCP Note: Queued packets are delivered to the host when it wakes up. Respond? Queue the packet Packet received by NCP Discard the packet N Y Trigger a wake-up Generate a response Wake-up? Discard? N N Y Y


48 3.2 shows the flowchart of actions for each receive d packet. Each packet is evaluated to see if it sho uld trigger a wake-up, and/or if the NCP should generat e a response, and/or if the NCP could simply discar d it or buffer it. For example, low-level packets such a s ARP and ICMP packets can be responded to directly Other packets, such as an SNMP GET, may require the host to be woken-up if the host is running the service corresponding to the received packet. An SN MP GET has a finite lifespan, it cannot be queued f or later response (that is, it does not make sense to respond to an SNMP packet many minutes later). Some application packets can be queued for later process ing by the host when it wakes up. Two network applications, where queuing of packets makes sense for later processing and where proxying can enable a host to sleep, were specifically considered and are SSH and IM. Beyond SSH and IM are a broad range of future appli cations under the rubric of Rich Internet Applications (RIA). RIAs are web-based applications where the web client executes the user interface a nd the back-end application server executes the applic ation itself. RIAs support both pull and push of da ta via TCP connections and potentially split a state betwe en a server and client. RIAs have the potential to have major impact on power management in network hosts. An NCP can support energy efficient operation of RIAs by maintaining connections and buffering data to enable the client host to sleep. 3.2 Covering TCP Connections For applications like IM and SSH, it is necessary t o keep the TCP connections open when the host goes to sleep to be sure the user session is not cl osed (login with the IM and SSH servers) and for th e host to receive messages sent even if it is sleeping. In both cases, if the host goes to sleep, it will not acknowledge bytes received by its TCP stack anymore The TCP stack of the remote server will start to retransmit the last unacknowledged bytes and buffer the rest of the messages the application attempts to send. If a group of retransmitted bytes is not ackn owledged, the stack will back off and calculate the next time at which it will attempt a new retransmission of the same group of bytes. The TCP stack of the re mote host does so until it reaches a maximum interval ti me between retransmissions, (variable called TCP_MAX_RTO in the TCP implementation), after which it will continue retransmissions at that maximum until it reaches the maximum number of retr ansmissions (variable called TCP_MAX_RETRIES2 in the TCP implementation). The TC P stack then drops the connection if no packet is acknowledged. This will result, in the case of S SH, in the shutdown of the session and the loss of user


49 session information. In the case of IM, the session with the IM server will be shutdown and messages w ill not be received. For that reason, the NCP will prox y those TCP connections by keeping them open for as long as the host sleeps. To describe this process, first the NCP components will be explained, and the n the prototype and its evaluation are described. 3.2.1 Design of gSOCKS NCP requirements (6) and (7) are to allow new inbou nd TCP connections to be established and to preserve TCP connections. To meet these requirement s, the SOCKS service is used. The SOCKS standard [83] describes how TCP connections and UDP packet f lows can be relayed through an intermediate host that executes a SOCKS server. SOCKS is an Internet service that comprises a client library and a serve r program. The SOCKS server is typically executed in a firewall, to allow for secure (that is, relayed f rom a secure host) TCP and UDP client access to a network The server supports both outbound and inbound TCP connection requests and UDP packet flows. To use SO CKS, a client application must be “socksified” to support encapsulation of key sockets functions usin g the SOCKS client library. The result of this encapsulation is that a client application can tran sparently connect via the SOCKS server to an applic ation server, or an application server can transparently connect to a listening client application. Most web browsers and FTP, SSH, and telnet client applicatio ns already support SOCKS, since it is a popular ser vice used in firewalls. The SOCKS standard supports IPv6 addresses allowing for future migration to IPv6. T he SOCKS service is used here as a key component in th e NCP (called here “green SOCKS” or “gSOCKS”) to meet the requirements for supporting TCP connect ions and UDP data flows. Figure 3.3 shows the architecture of the NCP with t he gSOCKS component. The packet processing component handles packet discard, packet response g eneration, and wake-up (that is, the first three de cision blocks of the flowchart in Figure 3.2). The gSOCKS component consists of an unaltered SOCKS server and a new NCP control point program. The SOCKS serv ice relays TCP connections (similar to what is shown in Figure 3.1) and contains buffering. The us e of gSOCKS requires that the NCP be fully powered on at all times so that all TCP connections to be p reserved during host sleep are relayed at all times Shortlived TCP connections (e,.g., HTTP connections as p art of web browsing that occur only when the client host is awake and in active use) that do not need t o be preserved when a host sleeps are not relayed t hrough the NCP gSOCKS component. In Figure 3.3, Control (1 ) communicates the host sleep state to NCP packet


50 processing. Control (2) is used to change the TCP r etransmission time-out. Data path (3) is used to se nd response and wake-up packets to the host. For the SOCKS service to be used to preserve TCP co nnections for sleeping hosts one change must be made to TCP in the NCP to prevent a time-out and di sconnect of a connection. When a host goes to sleep any TCP connections from the NCP to the host trying to deliver a packet to the host will go into an exponential back-off period (due to time-out caused by delivery failure). If the host wakes up in the middle of a back-off period, it may still take many second s before the current back-off period completes and the retry packet is successfully resent and received. Only at this time can any queued packets flow on th e connection (as a result of the ACK from the host fo r the successfully delivered retry packet). In addi tion, after a fixed number of back-offs (which varies wit h TCP implementation), a backed-off connection will “give up” and close. To meet NCP requirements (7a) and (7b), the back-off of all NCP-to-host connectio ns should be “frozen” when the NCP determines that the host is asleep (done via control (2) in Figure 3.3 ). Then, when the NCP determines that the host is agai n awake, the back-off timer for each NCP-to-host Figure 3.3. Architecture of the NCP NCP control point Control port (2) To/from network gSOCKS TCP/IP stack To/from host NCP control (1) Note: Control (1) communicates host sleep state to NCP packet processing. Control (2) is used to change th e TCP retransmission time-out. Data path (3) is used to s end response and wake-up packets to the host. SOCKS Packet processing NCP (3)


51 connection is reset to zero. This will cause an imm ediate resend of any unacknowledged packets and the n all data flows will immediately resume. It is necessary to design the signaling of the host sleep state to the NCP. The NCP requirement (2) is to know the power state of the network host that the N CP is covering for. How this is done depends on the location of the NCP. If the NCP is located outside of the sleeping host (e.g., in a switch in the netw ork), then host sleep state signaling can be accomplished via a process running in the host that captures op erating system sleep and wake-up interrupts (e.g., via ACPI in Windows and Linux), and communicates these interrupts to the NCP via a packet-based protocol ( note that if the NCP is located within a NIC, this signaling is not needed). A notification packet is defined that contains a field that can contain two values signifying that 1) the host is now entering a sleep state, or 2) the host is now awake after having be en in a sleep state. Figure 3.4 shows the architecture for power state signaling where a TCP connection is established between the host process and the NCP co ntrol point. The NCP listens for these connections on a pre-defined port. Before the host goes to sleep, th e host opens the TCP connection, sends the state, a nd closes the connection. When the host wakes up, it o pens a new TCP connection, sends the state to the N CP, and closes it. If a host being proxied physically disconnects from the network, the NCP must stop covering for the host and clean-up NCP resources including closing a ny TCP connections that it may be relaying via the gSOCKS component. There are several possible ways f or an NCP to determine that a host has physically disconnected. They are: Figure 3.4. Architecture of Power State Signaling Note: Host process catches wake-up and sleep interrupts a nd communicates them to the NCP. Host Host sleep state NCP control point NCP control connection NCP Host process


52 The host periodically wakes up (e.g., based on an i nternal timer) and “checks in” with the NCP by using the sleep and wake-up notification packets de scribed above. The NCP periodically polls the host to determine it s presence. The poll could be to the host NIC (e.g., via an ARP if the NIC can directly respond t o an ARP) or it could be a full wake-up of the host and its operating system and applications (e.g ., by sending a Magic Packet) followed by the sending of notification packets. The NCP determines that the host is disconnected th e first time that the NCP needs to wake up, the host and the host fails to wake-up thus signaling i ts absence. In the design of an NCP, a periodic timer-based wak e-up of the host is required to exchange wakeup and sleep notification packets with the NCP cont rol point. A process in the host can implement this periodic wake-up using a hardware timer that i s always running, even when the host is asleep. If a host fails to wake up and communicate with the NCP at its designated time-out, then the NCP will assume that the host is disconnected. A ten mi nute periodic wake-up is used in the prototype. 3.2.2 Prototype Implementation The gSOCKS component of the NCP was prototyped in a low-end router. A Linksys WRT54G version 2.2 SOHO router was used (see Figure 3.5) and the o riginal firmware was replaced with the open source WhiteRussian distribution of OpenWrt [106]. The WRT 54G has a processor running at 216 MHz and 16 MBytes of RAM. The router has a NAT service, so app lications running on remote servers connected to a Figure 3.5. The Target System: Linksys WRT54G


53 host behind the router only see the router’s IP. Th e router consumes about 8 W when all four Ethernet ports are connected to a link. Network equipment such as this router would typically remain fully powered-on at all times. The addition of gSOCKS to the router did not change the power use (of the router), so NCP requirement (1) was met. The WRT54G router does not have a SOCKS server incl uded, however the Srelay package [134] has already been developed for OpenWrt. It is a softwar e program that implements the SOCK protocol, it is written in C and was ported to the OpenWrt firmware The Srelay was used for the prototype gSOCKS implementation. An NCP control point program for th e router and a power state signaling application to run in a Windows-based client host are implemented. The NCP control point is a sockets application that executes in the router. The control point applicati on listens on a pre-determined port for a connectio n and message from the client host. The only two messages supported are: Host is going to sleep. Host is now awake. The client host application generates these two mes sages in response to an operating system interrupt (an ACPI interrupt) signaling power state changes in th e host. A TCP connection is established and closed just to send the one control message. The message sent b y the client contains the IP of the client host. Th e control program in the client host resumes executio n when it wakes up and detects another message from the operating system signaling that the system just woke up. This triggers a “host is now awake” messa ge that is sent to the NCP control point. A freezing and reset of TCP back-off in the NCP as described in the previous section was not possible to implement. To implement NCP requirement (7b), tw o TCP variables needed to be modified. The TCP_MAX_RTO was set to 1 second and TCP_MAX_RETRIES 2 to very large (it was made 10,000). This means that retransmissions will be made every 1 sec ond as maximum for a period no longer than 10,000 seconds (which is about 3.6 hours). The value set i n TCP_MAX_RETRIES2 can be tuned to be as much as needed. This should be guided by the time the host is expected to be sleeping. It can be also set for a reasonable time, after which the host can be woken up to send or receive software updates as it might require. Thus, when a client host goes to sleep, t he gSOCKS will retry any undelivered packets every


54 second and otherwise not “give up” and close the co nnection. To implement this method, a modification of the TCP implementation in the Linux kernel was nece ssary to expose the key variables. A customizable TCP Back-off patch presented in [140] was used to a chieve this. This method of achieving requirement (7b) generates much more overhead traffic than the stated design (of freezing the time-out), but achie ved the goal. This approach works well for a single cli ent supported by gSOCKS. For a gSOCKS supporting many clients (some sleeping and some awake at any g iven time), a different approach might be needed. T o prevent the TCP stack from keeping connections open when the host is disconnected from the network, a timer is used to give a sleeping host a maximum sle ep time. If the client does not wake up before the timer expires, all TCP connections are reset and the TCP_ MAX_RTO and TCP_MAX_RETRIES2 variables are reset to default values. This satisfies requirement (7c). 3.2.3 System Evaluation In this section the evaluation of the prototype imp lementation is described. Specifically, it was addressed that the gSOCKS meets requirement (7). Al so it is discussed how requirement (9) could be met but constraints in the Linksys router prevented ful l implementation. The test-bed configuration is shown on Figure 3.6. It consisted of a Linksys router WRT54-G version 3 with the gSOCKS (Srelay SOCKS plus NCP control poin t) implemented. The client host to be proxied (called “host A”) was a Dell Optiplex desktop PC wi th a 3.2 GHz Pentium 4 and 1 GByte RAM running Windows XP. The PC had a Broadcom NetXtreme 5755 NI C supporting ASF 2.0 (and thus the ability for the NIC to respond to ARP packets when the PC was a sleep). When necessary, two other PCs with the same configuration labeled as host B and C were als o used. All hosts were connected to the router, but only host A was covered by the NCP. Two types of experiments were conducted to show tha t the NCP successfully proxies for network applications. The experiments types were: 1. Application proxying: the purpose was to show that TCP connections could be preserved for SSH and IM when the client host was sleeping. 2. Throughput experiments: the purpose was to check if the use of relayed TCP connection does have an effect on the throughput of network applications


55 The SSH experiment was run as follows: The sessionoriented application used for this experiment was the SSH client in the Putty program [113]. Putty ha s SOCKS support built in. For the purpose of the experiment, a simple test application was developed with the purpose of outputting messages to the con sole every few seconds (the messages were text strings s uch as, “Message #1,” “Message #2,” and so on). Thi s application was run on a remote host running a SSH server and messages were sent to host A through the SSH connection to appear on the SSH console window on host A. For the experiment, host A was put to sleep for 30 minutes during which the application w as running in host B (and outputting messages on th e console window in host A). The experiment was run w ith and without SOCKS support enabled in Putty. When host A was returned to a fully powered-on stat e, the contents of the console window were examined for lost messages. The IM experiment was run as follows: The Yahoo IM client was used for this experiment. The Yahoo IM client had SOCKS support built in. For this expe riment three hosts were used (hosts A, B, and C wit h users Miguel Angel Jimeno, Miguel Jimeno, and Migue l Jimeno Paba, respectively) to participate in a three-way chat session. Only host A had its connect ion to the Yahoo IM server relayed through the gSOCKS. Host A was put to sleep in the middle of a three-way chat for 30 minutes. On wake-up of host A the IM client window (in host A) was examined for l ost messages. Figure 3.6. Test-Bed to Evaluate gSOCKS Remote server Router Remote host to gSOCKS packet flows Internet gSOCKS to host A packet flows gSOCKS Host A Host C Host B


56 The results from both experiments showed that no me ssages were lost when the host A connection was relayed through gSOCKS. The results also showed that the application – the SSH console window and IM client window – updated immediately upon host wa ke-up. Figure 3.7 shows the results from the IM experiment. The messages that would not be received when host A was not covered by the NCP are shown. The throughput experiment was run as follows: The t hroughput achievable on a relayed TCP connection (for FTP) was measured through the Linksys router. A relayed connection was handled by the router control processor. The host was connected to an FTP server located on the USF campus and downloaded a 200 MB file. The throughput of the relayed connecti on was about 1.5 Mb/s, which is less than the throughput of a non-relayed connection measured on the same host (2.5 Mb/s). This suggests that performance needs to be a future consideration for applications that have long-term TCP connections an d have high throughput needs. IM typically does not r equire high throughput. Most SSH connections are fo r low data rate console messages, but large file tran sfers can also be done via SSH. It was also noticed that some client applications (such as Windows Live Mess enger) are able to detect when the client host goes to sleep and signal the server of this state change vi a an application message. This would cause a logoff of the client from the server – an undesirable condition, since the whole purpose of proxying was to prevent logoff to make sleeping invisible to the serveran d needs to be further investigated and addressed. Figure 3.7. Results From IM Experiment MessagesthatarenotreceivedwhenhostAnotproxied. Window on host B Window on host A


57 Finally, the evaluation showed that the NAT capabil ity of the Linksys router caused a conflict with SOCKS support for UDP data flows. Specifically, UDP flows bypassed SOCKS and went directly to host A. This should be resolved if the NAT can be “turne d off,” or disabled, in the Linksys router. 3.3 Covering Application Protocols – SIP In this section the design and implementation of th e SIP Catcher is described. The SIP Catcher is a proxy that covers for calls directed to IP phones t hat implement the SIP protocol. The design is based on the design of the NCP. The SIP Catcher enables IP p hones to sleep when idle (not making or receiving calls). The proxy will wake up the phones if they receive a call. It is shown that the SIP Catcher ca n save most of the power currently consumed by IP phones. 3.3.1 Design of SIP Catcher The goal of the SIP Catcher is to allow IP phones t o sleep when not in active use. The following are assumptions that must hold for an IP phone that is covered by a SIP Catcher: 1. The IP phone has a sleep state where it consumes mu ch less power than that consumed when idle or in use. This implies that the phone would need a mechanism to quickly move to a higher power state so that it can be used to make calls in a rea sonable time (< 1 second) and can be fully woken up to receive a call. 2. The IP phone has a mechanism that the SIP Catcher c an use to detect its power state. 3. The IP phone can be woken up with a Magic Packet or another mechanism and can fully resume operation after this. 4. The transport protocol used by the IP phone is UDP. The following are the specific requirements for SIP Catcher needed to fulfill general requirement (10) of the NCP (which is be able to keep network applic ations executing as if the host was not sleeping): 1. To proxy for an IP phone that is allowed to sleep w hen idle and be woken up when needed. 2. No modification of the hardware or software of the IP phone itself must be necessary. 3. No modification of the SIP protocol must be necessa ry. The requirement (1) is a consequence of the general objective of the SIP Catcher. It proxies SIP calls directed to a sleeping IP phone and can enable it t o sleep when idle. Wake-ups will be only necessary if the


58 registration of the phone with a SIP registrar serv er is necessary or if an incoming call to the phone arrives. Details of how this is achieved are explained durin g this section. To achieve requirement (2), a syste m that catches SIP protocol traffic coming/going to/from t he IP phone is designed. The system is based on a packet tracer. The system has to be located where t he SIP traffic can be captured. The IP phone does n ot have to be modified because of the assumptions expl ained before. The SIP Catcher is a program that run s on a host located in such a way that it can capture the network traffic of the IP phone with a packet filter. The filter is based on the tcpdump packet filter [6 3] and it is used by the program to capture only SI P packets. Figure 3.8 shows a design of the program. The link-level driver makes a copy of each SIP pack et that arrives to the network interface of the host a nd sends it to the SIP Catcher program. All other p ackets follow the regular path to the protocol stack of th e host and other programs. The prototype implementa tion of SIP Catcher works for only one phone. But only s mall changes would be necessary for it to proxy for more than one phone, and even then, the SIP traffic will not be high and the load of the host would no t be SIP protocol packet filter Link-level driver TCP/IP stack Figure 3.8. Architecture of SIP Catcher To other applications To/from network To/from IP phone NCP control Note: Control (1) communicates the host sleep state to th e SIP Catcher to start or stop catching SIP calls. Contro l (2) is used to send wake-up packets to the IP phone and for SIP message s forwarding. SIP Catcher Control point (1) (2)


59 affected. This complies with the idea of the system being transparent; this host will be in the middle of the path of SIP packets between the host making the cal l and host receiving the call. The program uses the tracing capabilities to gather information about th e IP phone, such as for example, the SIP user used to register to the SIP registrar server, and IP of tha t server. To explain how requirement (3) is achieved, a focus on assumption (4) is needed. Because the IP phone is assumed to use UDP to transport the SIP pa ckets, the SIP Catcher can transparently emulate bo th sides of a SIP call when necessary. When the phone is sleeping and a caller initiates a call, the SIP Catcher proxies the response of the phone by sending a TRYI NG message on behalf of it. It then acts on behalf of the caller when it replicates the original INVITE a nd sends it to the phone when it is finally up. Re plicating the message and successfully delivering it to the p hone is not possible if TCP is used as transport pr otocol. In this case, the SIP Catcher would probably have t o register to the SIP provider on behalf of the IP phone and modifications to the phone or the SIP protocol might be necessary. To achieve energy savings, the SIP Catcher has to r un on a host that consumes less power than the IP phone or where it does not represent increase of po wer consumption. Two options for this are possible: 1. Using a network host or equipment that is always po wered-on for other reasons (so that it does not represent extra power consumption). This can be one of the servers being used to connect the phones to the VoIP network. 2. Locating the SIP Catcher in the last hop router to which the IP phone is connected. This option does not incur in extra power consumption, because the router is already in use. The disadvantage might be that depending on the capabilities of the router, the performance of the router might be affected by the packet tracer. For simplicity of the prototype, the second option was selected. It is necessary to explain how the SIP registration in the server is preserved. The process is as foll ows: 1. When the phone registers to the SIP registrar of it s SIP service provider, the SIP Catcher program running on the router detects where the IP phone is located. The SIP registrar (also the SIP proxy server of the SIP service provider) then knows wher e that User Agent is located, and responds, accepting the binding and approving the expiration time of that binding. 2. The SIP Catcher detects from the registration the a ccepted expiration time of the binding.


60 3. When the phone goes to sleep, the SIP Catcher waits for the expiration time and just before the registration expires, it wakes up the phone for it to update the registration. After a few minutes, th e phone will return to a sleep mode if it is not used This process repeats so that the phone will be woke n up again just before the second expiration time expires. The SIP registrar is the server that appro ves the expiration time requested by the phone. Thi s expiration time could be set to a maximum in the SI P registrar (according to the maximum time the phon e is expected to be idle). It is important to explain how the design of the SI P Catcher introduces delay time to the initiation o f a SIP call. Figure 3.9 shows the timing diagram of th e start of a SIP call when the IP phone is sleeping and the SIP Catcher is catching SIP calls directed to i t. Assuming the time for the IP phone to wake up i s close to zero, the delay appears when the caller receives two TRYING messages. The first message is sent by the SIP Catcher and the second one is sent to the IP ph one after it has woken up. The call initiation dela y time added (which is the same as the time between the tw o TRYING messages) is the sum of the following parts: 1) the time that the SIP Catcher takes to se nd a Magic Packet to the IP phone, plus 2) the time for the IP phone to wake up, process the INVITE, and genera te a TRYING response, plus 3) the time that the INVITE message generated by the IP phone takes to a rrive to the caller. Figure 3.9. Timing Diagram for a SIP Call Initiatio n Proxied by the SIP Catcher Caller SIP proxy server SIP Catcher IP phone time Wake-up time assumed close to zero Delay added by SIP Catcher


61 3.3.2 Prototype Implementation Existing commercial IP hard-phones do not allow use r-created applications to be installed on them. To test the implementation, a PC running an IP soft ph one was used. An application to advertise the power state of the PC was installed on it; this emulates the assumption (2). The PC can be woken up by a Mag ic Packet and can go to a sleep state that consumes al most zero Watts. The SIP Catcher was implemented as a program runnin g on the last hop router to which the IP phone is connected. The last hop router selected was a Links ys router WRT54-G version 3. The original firmware was removed and replaced with OpenWrt [106]. Then, the SIP Catcher was developed using the C language and installed in the router as an applicat ion package. The Pcap libraries [63] were used in t he code to trace all packets directed to the IP phone. A pa cket filter determined the types of packets that wi ll reach the SIP Catcher. The packet filter was set to pass packets sent to the ports used by the SIP protocols All Ethernet frames arrive to the SIP Catcher, where th e frames have to be parsed to detect the type of me ssage (e.g., if it is actually a SIP message, or if it is an INVITATION message). This has to be done for ea ch packet arriving to the SIP Catcher. A modified vers ion of the power state signaling program used by th e NCP and described in Section 3.2.1 (also shown in F igure 3.4) was used by the SIP Catcher to determine the power state of the IP phone. Once the caller s tarts the call and the SIP proxy server forwards th e SIP call to the network where the IP phone is located, the program detects the INVITE message. Immediately it responds with a TRYING message, which makes the cal ler's device wait. The SIP Catcher then wakes up the IP phone using a Magic Packet. For the prototyp e of the SIP Catcher, it waits for a few seconds be fore forwarding exactly the same INVITE message as was r eceived. The time waited was to give time to softphone to wake up and be ready to receive messages. However, this time could be set to almost zero if t he IP phone can wake up in less than one second as assump tion (1) states. After the phone wakes up, the phon e is ready to receive the INVITE, reply to it and starts ringing. The ringing in the soft-phone should be a sound generated by the software. It is important to note that there is no need to modify the SIP proxy serve r to which the proxied IP phone is connected. For the SI P proxy server, the presence of the SIP Catcher is not noticed.


62 3.3.3 System Evaluation The prototype of the SIP Catcher used for the evalu ation consisted of four parts: 1. IP phone to be proxied. The phone has to use the SI P protocol for session initiation, and has to use UDP as transport protocol. For prototyping purposes it can be represented by a host running a soft-phone. 2. The SIP Catcher and the host on which it runs. 3. The SIP proxy server: The VoIP service provider tha t implements the SIP protocol and to where the IP phone connects. 4. The caller: A phone to make calls to the proxied IP phone. Depending on the VoIP service provider used, the caller can be another IP phone o r a conventional phone. The key questions to answer are if the SIP Catcher can successfully proxy for VoIP phones and what is the maximum time the proxy can enable phones to sleep. First, the configuration of the test-bed is shown, an experiment is then described and the results are sh own. Two types of experiments were performed: 1. Proxying experiment: This type of experiment was de signed to test if the proxy could successfully proxy calls directed to sleeping IP phones. 2. SIP session preservation experiment: This experimen t was designed to test if the SIP Catcher can enable the phone to sleep for as long as it remains idle. The test-bed (shown in Figure 3.10) consisted of an IP phone, a SIP proxy server, the last hop router to which the phone was connected, and a conventional t elephone to make calls to the IP phone. The IP phon e was represented by a PC running the SJphone soft-ph one from SJ Labs [124]. This soft-phone used UDP as the default transport protocol, but has the option of using TCP. The PC used was a Dell Optiplex deskt op PC with a 3.2 GHz Pentium 4 and 1 GByte RAM running Windows XP. The SIP service provider consisted of an SIP proxy server and registrar from a VoIP se rvice provider called Tpad [135]. The last hop rout er was a Linksys router WRT54-G version 3, which runs a NAT server. Traces of the communication were used to check the results of the experiments. A PC (called “the tracer”) was used to trace the packets sent and received by the SIP Catcher and to trace the pa ckets received by the IP phone. Two different types of traces in the test-bed were taken. One trace was fo r packets from the Internet to the router. Another trace was packets from the router to the IP phone. For th e first trace, the router and the tracer were conne cted to a


63 hub so that the tracer could detect the packets goi ng in and out of the WAN interface of the router. T o trace the packets received by the IP phone, the tracer an d the PC with the IP phone were connected to the hu b, and the hub to the router. A picture of the IP phon e and the Linksys router used for the test-bed is s hown in Figure 3.11. The Wake-On-call experiment was run as follows : The purpose of the experiment was to show that the proxy could successfully proxy a phone call for a s leeping IP phone. At the same time, the intention w as to measure the call delay time that the SIP Catcher in troduced in the initialization of a SIP call. The d esign of this experiment is described in the following steps : 1. The PC where the soft-phone is running is put to sl eep. 2. While the PC was sleeping, packet traces of the tra ffic directed to the interface of the PC were taken to verify that the SIP Catcher was successful ly proxying the SIP calls. 3. After 5 minutes of the PC being sleeping, a convent ional phone was used to make a phone call to the phone number used by the soft-phone. The SIP session preservation experiment was run as follows : The purpose of this experiment was to determine if the IP phone can be put to sleep for p eriods of time longer than the expiration time of t he binding with the SIP proxy server. This would deter mine that the phone can sleep even beyond the Figure 3.10. The Test-Bed for SIP Catcher IP Phone (Callee) PSTN network SIP proxy server Last hop router SIP messages from SIP proxy server Internet SIP Catcher messages to phone SIP Catcher Conventional telephone (Caller)


64 expiration time of the session. For this, an option in the configuration menu of the soft-phone was us ed. This option set the expiration time of the binding with the SIP server. The approach was the following : 1. Set the expiration time to a large value (several h ours) to allow the SIP registrar server to negotiat e for is the maximum binding expiration time allowed. 2. Set up the control program in the SIP Catcher to wa ke up the host running the IP phone before the negotiated expiration time expires. Verify the maxi mum sleep time of the IP phone. The results of the repetitions of the Wake-On-call experiment were as follows. While the PC was sleeping, the traces (in Figure 3.12) showed the SI P registrar server sending messages to the router t o keep the tunnel through the NAT server established in or der to communicate with the IP phone. The purpose o f this was to prevent the NAT server running on the r outer from closing the tunnel. No other types of pa ckets were detected from the IP of the SIP proxy server. After some minutes the conventional phone was used to make a phone call to the IP phone. Several seconds after the number to contact the IP phone through it s VoIP provider is dialed in the phone, the PC woke u p and the phone started to ring. The display of the PC did not turn on given the configuration of the oper ating system (it does not turn on unless there is u ser input like keyboard or mouse movement), but it was possib le to move the mouse to turn it on and see that the PC was actually up. The phone call could be answered w ithout problem. Figure 3.11. The PC and Router Used for the SIP Cat cher Test-Bed Linksys WRT54G router Soft-phone (PC with SJ labs VoIP phone)


65 The experiment was run again, now using another pho ne from SJ Labs running in another PC. The purpose of this was to trace the SIP traffic in the caller. To be sure the IP phone was up and ready t o receive the INVITE from the router, a delay of 5 se conds was manually set in the SIP Catcher. Other de lays below 6 seconds were tried but were not sufficient because the INVITE arrived too early to the IP phon e. No call was dropped on the caller side during all t he repetitions of this experiment with a delay of 6 seconds (the call initiation delay time response va riable). For information purposes, a modification o f this experiment consisted on not waking up the phone but sending the TRYING message to the caller. After 1 minute, the caller dropped the call. The results of the SIP session preservation experim ent were as follows. First, the desired expiration time of the binding was changed before the soft-pho ne connected to the SIP proxy server. A set of expiration times was used in the IP phone (24 hours 12 hours, and 6 hours). However the SIP proxy ser ver (from Tpad) did not accept those values and negotia ted the expiration time to be its maximum of 1 hour or 3600 seconds (the units used by the SIP protocol). The PC with the soft-phone was put to sleep and th e proxy program was started in the router. The contro l program running on the router was set to wake up the PC with the soft-phone when the binding with the SI P proxy server was about to expire. After about a minute of waking up, the IP phone re-registered wit h the SIP provider. Because the PC did not detect a ny user input, after a few minutes the PC went back to sleep. For the experiment, this was repeated durin g several hours. No call was made during that period. The phone remained sleeping most of the time and j ust woke up a few minutes every hour to re-register. Th us the energy savings could be substantial. Figure 3.12. Messages Sent by the SIP Registrar Ser ver When Phone Sleeps Messages sent by SIP registrar server


66 3.4 Chapter Summary In this chapter formal requirements to support appl ication level proxying in the NCP were presented. The first proxy to keep TCP connections open for ho sts that are in sleep states was described. The ide a was implemented through the use of a relay server to be used by the host so that the TCP connections of ce rtain network applications were maintained when the host slept. This was achieved by setting variables in th e TCP stack implementation of the device where the pr oxy is running, to prevent it from closing the TCP connections with the sleeping host. At the same tim e, other variables were set to allow a fast connect ion recovery when the host came back from the sleep sta te and was able to restore the connectivity with ot her network hosts. The proxy was proven to be successfu l for applications like IM and SSH that rely on use r sessions to receive update messages. The update mes sages were buffered by the proxy and delivered when the hosts woke up. The SIP Catcher was presented as a proxy for SIP ca lls directed to IP phones. The proxy now allows IP phones to sleep when idle, and be woken only to rec eive calls. This was achieved by tracing packets directed to the phone, parsing them to detect SIP c alls invitations, generating a response to prevent the call from being dropped and waking up the phone. This pr oxy allows IP phones to sleep as long as not being used, thus saving most of the wasted energy used by IP phones.


67 Chapter 4: Improved Probabilistic String Search Wit h an Application to P2P Proxying In a P2P Gnutella host, string search algorithms ha ve to be used when answering Gnutella Query messages. P2P hosts receiving Query messages have t o quickly search the keywords in their list of shar ed files to check for matches. To make a P2P proxy spa ce and time efficient, string search algorithms use d by the proxy have to consume the least possible amount of time and space. In order to keep the costs of an NCP implementation low, the device where it runs should be limited in both computational and memory capabilities. To stor e a large list of file names being shared by a host would require considerable memory. Bloom filters ha ve been used to “compress” lists of information tha t need to be shared [40] to run queries on them. Thus the application of Bloom filters to proxying for a P2P application and how to make a Bloom filter as time and space efficient as possible are studied here. B loom filters are considered mostly for applications wher e set element membership testing is sufficient, and where memory is limited. In more complex cases – where th e use of a keyword is needed to retrieve informatio n – more sophisticated data structures and search algor ithms are needed. Bloom filters are useful for devices that are extre mely memory space constrained because they are the most space efficient data structures for membership testing. Depending on the device used, a Bloom fil ter could be used to proxy for P2P applications, but mo re complex data structures are needed to fully implement Query message responses in a proxy. For t his, it is important to study possible improvements to existing string search algorithms. In this chapter methods to improve string search in P2P applicati ons are presented. The methods presented are of two types: 1) new methods that give only Boolean responses (tu re or false) and allow false positives as a possible r esult of a search. (Best-of-N Bloom filter and twotier Bloom filter), and 2) new methods that are used to retrieve information and do not introduce false pos itives as a possible result of a search (Signature Array H ash Table (SAHT) and Bloom-filter-based keyword search). Best-of-N is inspired in the work from Lum etta and Mitzenmacher [86], explained in Chapter 2, where the authors used the theory of power of two c hoices to improve false positive probability of Blo om


68 filters. First, the goals, assumptions and requirem ents for better probabilistic string search methods are presented, and then the methods are described and e valuated. 4.1 Requirements for Better Probabilistic String Search Methods The goal of an improved probabilistic string search method for use on a P2P proxy is as follows: To design, implement and evaluate a new search method with the purpose of using it as search method in a P2P proxy. This proxy is intended to run on a host where memory space and computational capabilities a re reduced. The assumptions expected to hold for bette r string search methods for a P2P proxy are: 1. Objects to be searched can be represented by charac ter strings. 2. The probability of collision of the hash function u sed by the search method is not statistically significant. The specific requirement for better string search m ethods for a P2P proxy is: 1. No false negatives can be accepted due to the natur e of P2P applications. Preventing some files of a host from being shared could lead to the isolatio n of the least requested files. 4.2 The Best-of-N Method for Bloom Filters The Best-of-N a method that reduces the false posit ive rate of a Bloom filter but requires preprocessi ng computations. 4.2.1 Design and Implementation A Bloom filter with the Best-of-N uses a method tha t needs additional computation to generate a Bloom filter with a reduced probability of false positive s. For a given list of elements (e.g., file name st rings) to be mapped into a Bloom filter, the Best-of-N method fi nds a Bloom filter instance with the least number o f bits set to 1. Using N different groups of hash functions, N instances of a Bloom filter are generated sequentially. The instance with the least number of bits set to 1 defines 1) the Bloom filter instance and 2) the hash group that is then used to check for membe rship in the filter. The Best-of-N method is shown in Figure 4.2 (Figure 4.1 defines the variables used). Two functions are given, one to generate the Bloom filter and the other to test for membership. A Bloom filte r has m bits. The constant K (same as k ) is the number of hash functions in a hash group.


69 In Figure 4.2, the function hash( string i ) generates a hash value for string using hash function i The value then has to be moduloed (using mod operand). Lines 8 to 12 map an element and increment setCount After all the elements have been mapped, this varia ble is used to check if the instance just created i s the one with the least amount of bits created so far (with “if” statement in line 13). An optimization can be done to bloom [ ] Bloom filter of length m bits tempBloom [ ] Temporary Bloom filter strList Input list of strings nextString Next string in input list of strings hashValue Hash value (integer value from 1 to m) setCount Current count of bits set to 1 minCount Minimum count of bits set to 1 hashGroup Index of hash group producing best ratio of 1s inString Input string to test for membership memberFlag Membership flag Figure 4.1. Variables for Best-of-N Method mapBloom( strList ) 1. clear bloom [ ] 2. minCount m 3. for i 1 to N do 4. clear tempBloom [ ] 5. setCount 0 6. while (strings remain in strList ) do 7. nextString next string in strList 8. for j 1 to K do 9. hashValue hash( nextString ( i –1) K + j ) mod m 10. if ( tempBloom [ hashValue ] = 0) 11. increment setCount 12. tempBloom [ hashValue ] 1 13. if ( setCount < minCount ) 14. minCount SetCount 15. bloom [ ] tempBloom [ ] 16. hashGroup i 17. return ( bloom [ ], hashGroup ) testBloom( inString, hashGroup ) 1. memberFlag TRUE 2. for i 1 to K do 3. hashValue hash( inString ( hashGroup –1) K + i ) mod m 4. if ( bloom [ hashValue ] = 0) 5. memberFlag FALSE 6. break 7. return ( memberFlag ) Figure 4.2. Best-of-N Method for Bloom Filter


70 check every time a new bit is set if the new number of values set is already greater than the minCount That means the current instance already has more bits th an the best instance, and there is no point to cont inue mapping all the elements. One way to implement mul tiple hash functions from a single hashing method i s to seed the method with the value i For example, CRC32 can be used as a hashing metho d and the CRC accumulator is seeded with different values to obta in different hash functions. In the case of SHA1, t he digest can be updated every time a different hash i s needed. In case the hash function does not accept an update, the string can be modified by appending a d ifferent character each time a new hash was needed, thus producing a totally different hash. Intuitively, the larger the N value, the lower the probability of false positive s and the longer the time required to create the Bloom filter instance. In Se ction 4.2.2 the analysis of the reduction of probab ility of false positives as a function of N is shown. Generating Hash Values With an RNG Method t o Reduce Execution Time The use of pseudo hashing in [77] is extended here to reduce testing and mapping time in Bloom filters. The hash values generation is continued by using a linear congruential generator (LCG) random mapString( nextString ) 1. seedValue hash( nextString ) mod m 2. bloom [ seedValue ] 1 3. seedRNG( seedValue ) 4. for i 1 to K do 5. hashValue randInt() mod m 6. bloom [ hashValue ] 1 testString( inString ) 1. memberFlag TRUE 2. seedValue hash( inString ) mod m 3. if ( bloom [ seedValue ] = 0) 4. memberFlag FALSE 5. if ( memberFlag = true) 6. seedRNG( seedValue ) 7. for i 1 to K do 8. hashValue randInt() mod m 9. if ( bloom [ hashValue ] = 0) 10. memberFlag FALSE 11. break 12. return ( memberFlag ) Figure 4.3. RNG Hash Method for Bloom Filter


71 number generator (RNG) where a single hash value is used as a seed to generate additional pseudo hash values. Figure 4.3 shows the method for mapping str ings into, and testing for membership in, a Bloom filter. The value seedValue is the initial hash value from an actual hashing o f the string. The function seedRNG() seeds the RNG. The function randInt() ret urns a random integer between 1 and m from the RNG. The returned value is the pseudo hash value. I n the function testString(), testing of bits is exp licitly halted at the detection of the first 0 bit. Compare d to the method of Kirsch and Mitzenmacher to gener ate hashes (explained in Chapter 2), the RNG method pro posed here requires only one actual hash and it can use a “good” LCG RNG algorithm (i.e., one with well -known properties) for generating the pseudo hash values. In the implementation of the RNG hash metho d the following LCG (from Jain [64]) is used, ( ) 1 2 mod 731 1 5=n nx x (4.1) where nx is the n th random integer value. The computation time and p robability of false positives were evaluated for both the method from Kirsch and Mitze nmacher, and RNG methods later in this section. 4.2.2 Analysis In this section an expression for probability of fa lse positives for the Best-of-N method is derived. Defining S as the random variable for the number of bits set in a Bloom filter, expressions for mean and variance of S are derived. Assuming a normal distribution of S and using order statistics, a computable expression for probability of false positives as a function of N is reached. The derivation of the probability of false positive s of a regular Bloom filter (a Bloom filter with Be stof-N where 1 = N) is described in Section 2.6.2. The mean of S is the probability that a bit is 1 multiplied by the total number of bits, [ ] mp S E =. (4.2) The variance of S requires the derivation of the second moment of S Let iU (m i ,2 ,1 = ) be the random variable that is set to 1 if bit i is set to 1 and 0 otherwise. When n objects are mapped in, the probability that an arbitrary bit is not set is [] kn im U = = 1 1 0 Pr. (4.3)


72 Then mU U U S + + + = 2 1 where [] kn im U = = 1 1 1 1 Pr. (4.4) The probability [ ] 1 Pr =iU means the probability that bit i =1 is set to 1. Hence, [][][] = + + + =kn mm m U E U E U E S E 1 1 1 ] [2 1, (4.5) For the second moment, [ ] [] [ ] [ ] + = + + =j i j i i i mU U E U E U U E S E2 2 1 2, (4.6) after similar terms are grouped. Since i iU U =2, it is already known that [][] = + +kn mm m U E U E 1 1 12 2 1. (4.7) It can be noticed that [ ] j iU U E is equal to the probability that both bits i and j are set (this occurs when 1 = j iU U). This is, [][][][]0 and 0 Pr 0 Pr 0 Pr 1 1 Pr = = + = = = =j i j i j iU U U U U U (4.8) but [ ] 0 Pr =iUis already known from eq. (4.3). And [ ] 0 and 0 Pr = =j iU U is the probability that two bits are not set So then eq. (4.8) is [] kn kn j im m U U + = = 2 1 1 1 2 1 1 Pr. (4.9) There are ( ) 1 m mterms in the second summation in eq. (4.6). Thus th e second moment can be obtained directly using results from eq. (4.9). [] () + + =kn kn knm m m m m m S E 2 1 1 1 2 1 1 1 1 12 (4.10) From eq. (4.5) and eq. (4.10) the variance [ ] S2s can be obtained.


73 [] [ ] []S E S E S2 2 2=s (4.11) Replacing in eq. (4.11) the expressions derived in eq. (4.5) and eq. (4.10), eq. (4.11) is reduced to [] kn kn kn knm m m m m m m m m m m m S2 2 2 21 2 2 1 + =s (4.12) Order statistics [56] is used to determine the prob ability function of the first order statistic (the minimum value of samples NS S S , ,2 1 which is selected as Best-of-N). The mean value of S given N samples (i.e., N instances of a Bloom filter) is then calculated. F or the random variable S with probability distribution function ( ) s f, cumulative distribution function ( ) s F, and N independent samples , ,2 1 NS S S the minimum value of the samples is the first orde r statistic, () ( ) NS S S S S , min2 1 1 min = = (4.13) The probability distribution function of the rth statistic is () ()() () ()() ()()s f s F s F r N r N s fr N r rth-= 1 !1 !1, (4.14) from which the probability distribution function of the first order statistic (minf here) is then ( ) ( ) ( ) ( ) s f s F N s fN 1 min1-=. (4.15) The mean value of S can be computed as []() -= ds s sf S Emin min. (4.16) The normality assumption for the distribution of S can be used now. Thus, () ( ) 2 222 1s mp s-=se s f (4.17) and () + = 2 1 2 1s ms erf s F (4.18) where [ ] S E = m and [ ] Ss s=. Substituting eq. (4.17) and eq. (4.18) into eq. ( 4.15) it is derived


74 () () =-2 22 1 1 min2 1 2 2 1s mp s s ms N Ne s erfc N s f. (4.19) [ ] minS E is computed by substituting eq. (4.19) into eq. (4 .16) [] () ds e s erfc N s S Es N N =2 22 1 1 min2 1 2 2 1s mp s s m (4.20) It can be calculated now an expression for the prob ability of false positives of the Best-of-N method, [] [] km S E =minpositive false Pr (4.21) For a given m and n the value of k to minimize the probability of false positives of a Bloom filter can be determined. The probability of false positives f rom eq. (2.1) and eq. (2.2) is [] k m kn k kne m =-1 1 1 1 positive false Pr. (4.22) For a given m and n where k is chosen optimally, the probability of false posi tives as a function of N is studied. A software tool is used to calculate eq. ( 4.21). Figure 4.4 shows a plot of the probability o f false positives (i.e., from eq. (4.21)) as a function of N for 16 = n m and 11 = optk. Figure 4.4 shows that the 3.5E-04 3.7E-04 3.9E-04 4.1E-04 4.3E-04 4.5E-04 4.7E-04 4.9E-04 5.1E-04 0102030405060708090100Pr[false positive]Number of instances ( N ) Figure 4.4. Probability of False Positive for m / n = 16 12%


75 false positive probability can be reduced up to 12% for these Bloom filter parameters (0.0004062 again st 0.0004588). The reduction is important when calcula ted up to 10 instances ( N =10) and the improvement stabilizes close to N =70. Figure 4.5 shows the same plot for 32 = n m and 22 =optk. The maximum reduction achieved is 18% for these parameters. For Figure 4.4 1000 = n and 000 16 = m corresponding to an almost 16 KB Bloom filter with 1000 strings(or 1000 files shared in this P2P application) mapp ed into it. For Figure 4.5 the same value of n is used and m is increased to 32,000. It can be seen that Best-o fN results in a reduction in probability of false po sitives. Figure 4.6 shows the improvement factor for 8 = n m, 16 = n m (from Figure 4.4), 32 = n m (from Figure 4.5), and 64 = n m. Table 4.1 summarizes the improvement for = N 2, 5, 10, 50, and 100 from Figure 4.6. It can be seen that as n m increases, the improvement factor also increases. For 32 = n m an almost 19% reduction in probability of false positi ves is achieved for 100 = N. Best-of-N is similar to the online setting proposed in [86], where two or three choices of groups of hash functions are used to check which one adds few er ones to the Bloom filter. The difference is that in Best-of-N the whole set of strings is mapped in and then checked if it increases the number of ones, i nstead of comparing each time a new string is mapped in. T able 4.2 shows a comparison between the Best-of-N and [86], called here Power-of-2. For Power-of-2, o nly two choices were taken into account. It can be seen that the probability of false positives for Best-of -N is better than that of Power-of-2 for 4 = n mand Table 4.2. Best-of-N Method (for N =100) Against Power-of-2 Improvement 4 = n m 8 = n m 16 = n m 32 = n m 64 = n m Best-of-N 1.072 1.096 1.129 1.188 1.275 Power-of-2 0.710 0.919 1.146 1.388 1.612 Table 4.1Summary of Best-of-N Method Improvement N 8 = n m 16 = n m 32 = n m 64 = n m 2 1.021 1.028 1.058 1.057 5 1.043 1.058 1.083 1.119 10 1.058 1.078 1.111 1.161 50 1.086 1.115 1.167 1.243 100 1.096 1.129 1.188 1.275


76 8 = n m, where the improvement is close to 10% for Best-of -N. For these parameters Power-of-2 actually produces even more false positives than using only one choice of groups of hash functions (that is the original Bloom filter). The authors of [86] did not address this issue. For larger values of n m it can be seen that Power-Of-2 outperforms Best-of-N. The Bes t-of-N is faster for testing. Only one group of has h functions is used to map the whole set of elements. This allows the application to store the index of the group that was used. In Power-of-2, however, there is no way to know which group was used, so there i s the need to perform string tests with all the choic es of groups of hash functions, to see which one tr iggers a 1.6E-07 1.7E-07 1.8E-07 1.9E-07 2.0E-07 2.1E-07 2.2E-07 0102030405060708090100Pr[false positive]Number of instances ( N ) Figure 4.5. Probability of False Positive for m / n = 32 18% 1.00 1.05 1.10 1.15 1.20 1.25 1.30 0102030405060708090100Improvement factorNumber of instances ( N ) m / n = 32 m / n = 16 m / n = 8 m / n = 64 Figure 4.6. Improvement Factor for Various m / n


77 positive. This means that membership testing when t he Bloom filter returns a hit is 2 times faster in software implementation of Best-of-N, assuming two choices are used in Power-Of-2. 4.2.3 Experimental Evaluation Two key measures of performance for a Bloom filter are 1) the probability of a false positive and 2) the computational effort required to test for membe rship. In this section the analytical model is comp ared to a real implementation of the Best-of-N method for probability of false positives. The comp utation time when run on a typical desktop PC is also evaluated. An implementation of a Bloom filter with the BestofN method was written in C. The following four hashi ng methods were implemented (input was a list of strings): SHA1, using the implementation from the standard [4 2]. SHA1 was chosen as a widely used and known hash function, well known for its randomness. CRC32, using an 8-bit table look-up implementation from [110]. CRC32 was chosen as a widely used and relatively efficient hash function which c an be implemented in software. Kirsch and Mitzenmacher’s method from [77], using C RC32 for the seed hashes. The new RNG hashing method from Section, us ing CRC32 for the seed hash. In addition to the above four hashing methods used to hash and map real strings into a Bloom filter, a “perfect hashing” was implemented using an RNG to g enerate a random sequence of values. This perfect hashing served as a control to eliminate any effect s of possible collisions from the real hashing meth ods. One critical aspect of the experiments was to creat e N groups of hash functions based on one hash function implementation. For CRC32, the CRC accumul ator is initialized with a different value each tim e a new hash function was needed. For the SHA1 implemen tation, a different value at the end of the string is added to be hashed each time a new hash function wa s needed. The experiments were designed as follows. All exper iments were executed on a Dell OptiPlex GX620 PC (Pentium4, 3.4 Ghz, 2 MBytes cache) with 1 GByte RAM with WindowsXP as the operating system. The gcc compiler (version 3.4.2 mingw-special from Dev C++ [90]) with no optimizations was used in all cases. Execution time was measured using C time fun ctions with an accuracy of 10 ms on Windows XP. A list of 25,000 strings of unique music file names was obtained using Bearshare [96]. The list of music file names was generated manually by searchin g names of artists and compiling a list of the song s


78 retrieved by the queries. Each string consists of a rtist name and song title. This list of strings was used for the input to all experiments (except for the “perfe ct hashing” experiments, where no strings were hash ed). Figure 4.7 shows a histogram of string lengths from the test set. The mean string length was 47 bytes. Thus, with 16 = n m there are 16 bits (or 2 bytes) per each string tha t was mapped into the Bloom filter resulting in a storage savings of over 20 times (i.e., )5. 23 2 47 = The two response variables of interest were: Probability of false positives for the Bloom filter Execution time to generate a Bloom filter. Probability of false positives was measured in two ways: 1. Analytically by counting the number of bits set to 1 and using eq. (2.4), and 2. Empirically by testing for membership with a list o f 25,000 test strings where none of the strings in the list were already represented in the Bloom f ilter. The factors of interest were: Hashing method used. Bloom filter parameters m n and k. Best-of-N parameter N Number of strings used in the string test set. Figure 4.7. Histogram of String Lengths for Test Se t 0 0.005 0.01 0.015 0.02 0.025 0.03 020406080100120140160180200220ProbabilityString length (bytes) min = 4 charactersmax = 223mean = 47.0


79 Experiments were designed to evaluate the probabili ty of false positives, (including comparison of the analytical model to actual implementation) and comp utation run time (CPU time). All experiments, unles s otherwise stated, were executed using the four hash ing methods and “perfect hashing” using an RNG. For all experiments n was set to 1000 (corresponding to a reasonable num ber of files shared by a P2P node) and m set to 16,000 corresponding to 16 = n m ( k was chosen optimally as 11 = optk from [41]). The experiment was designed to measure probability of f alse positive using eq. (2.4) and empirically, and also to measure runtime: For the setup of the false positive probability cal culated with eq. (2.4), N was varied from 1 to 100. Then the number of bits set to 1 was measured and t he probability of false positive was calculated usi ng eq. (2.4). The mean from 10,000 iterations for each value of N was collected. To empirically measure the false positive probabili ty, it was necessary to repeat the previous experiment, except the false positive was measured empirically. To measure the run-time, it was necessary to repeat the false positive experiment and collect the runtime (CPU time) for each value of N 3.5E-04 3.7E-04 3.9E-04 4.1E-04 4.3E-04 4.5E-04 4.7E-04 4.9E-04 5.1E-04 0102030405060708090100Pr[false positive]Number of instances ( N ) Analysis Perfect hash Figure 4.8. False Positive Calculated With Eq. (2.4 ) Using Perfect Hashing


80 The results of calculating the false-positive proba bility using eq. (2.4) are shown in Figure 4.8 for perfect hashing and in Figure 4.9 using the four ha shing methods studied. In Figure 4.8 it can be seen that the probability of false positive from the implemen tation and analysis agree perfectly (within 1% for all values of N ). This validates the analytical model, including t he assumption of normality for the number of bits set to 1 ( S ). Figure 4.9 shows that using a real, non-ideal ha sh function results in a probability of false positives with greater variability compared to usin g a “perfect hashing” function. However, variabilit y is also below 1% for all values of N 3.5E-04 3.7E-04 3.9E-04 4.1E-04 4.3E-04 4.5E-04 4.7E-04 4.9E-04 5.1E-04 0102030405060708090100 Pr[false positive] Number of instances ( N ) Analysis SHA1 CRC32 RNG method Kirsch Figure 4.10. False Positive Measured Empirically 3.5E-04 3.7E-04 3.9E-04 4.1E-04 4.3E-04 4.5E-04 4.7E-04 4.9E-04 5.1E-04 0102030405060708090100Pr[false positive]Number of instances ( N ) Analysis SHA1 CRC32 RNG method Kirsch Figure 4.9. False Positive Calculated With Eq. (2.4 ) Using Four Hash Functions


81 The results of measuring the false positive probabi lity empirically are shown in Figure 4.10. This figure specifically shows a lower probability of fa lse positives for the RNG method compared to the method of Kirsch and Mitzenmacher. The variability for the Kirsch method is close 8% for N =1 (0.0004945 for Kirsch against 0.0004588 for the ana lysis). For N =100 the variability is close to 9%. The results from Kirsch can still be considered useful. The variability for the RNG method is much better, close to 1% for N =1 and close to 4% for N = 100. All the other methods are always below 1% of variability. The results for the run-time experiment are show in Figure 4.11. The graph shows the CPU time to generate one Bloom filter using the Best-of-N metho d with the four different hashing methods, given a set of 1,000 strings to be mapped into the Bloom filter For the test PC the results for1 = N: SHA1 requires 40 milliseconds CRC32 requires 4.9 milliseconds RNG method requires 1.5 milliseconds Kirsch and Mitzenmacher method requires 1.3 millise conds These times increase linearly with N There is some variability with CRC32. For example between N =34 and N =35 the measured run-time values were 176 milliseco nds and 172 milliseconds. However the difference can be considered insignificant. The RNG and Kirsch and Mitzenmacher methods are about the same, and CRC32 is 3 times greater in CPU time requ ired than these two methods. For example, for N =50, 0.0E+00 1.0E-01 2.0E-01 3.0E-01 4.0E-01 5.0E-01 6.0E-01 0102030405060708090100CPU Time (sec)Number of instances ( N ) SHA1 CRC32 RNG method KirschFigure 4.11. Results from Run-Time Experiment


82 the time for CRC32 is 200 milliseconds against 62 m illiseconds in RNG. SHA1 is 8 times greater than CRC32 for N =50, and the time was 1.7 seconds to calculate 50 i nstances of Bloom filters with the parameters explained before. The results in this section clearly show that the e ffect of using methods like Kirsch or the RNG metho d instead of the conventional hash functions like SHA 1 or CRC32 for creating Bloom filters is not significant, especially in the case of the RNG meth od. Figure 4.10 shows a variability of up to 4% for RNG when measuring false positives empirically. Figure 4.11 shows that the trade-off of variability is pai d-off with the run-time improvement achieved when using K irsch or RNG. 4.3 Two-Tier Bloom Filter Testing for element membership in a Bloom filter re quires hashing of a test element (e.g., a string) a nd multiple look-ups in memory. A design of a new twotier Bloom filter with on-chip hash functions and cache is described. For elements with a heavy-taile d distribution for popularity, like Gnutella Query messages with search for popular keywords, membersh ip testing time can be significantly reduced by usi ng a small Bloom filter to support queries for popular keywords. Less testing time means less computation al requirements for resource limited systems. In the l iterature, Bloom filters have been adapted before t o popularity of elements as in [144] where different numbers of hashes were used according to the popula rity of the element. Different approaches exist already for improving search in P2P networks, based on the popularity of the elements. The work in [88] stores in the fastest memory the most requested files, an d removes them depending on different content managem ent policies (similar to caching). The approach followed in [108] was to cache Query messages in so me points of the network. In the case of this dissertation, the proxy used to perform searches ar e space constrained, so storing the files is not an option. Membership testing time of Bloom filters is a funct ion of the time to 1) compute up to k hashes and to 2) perform up to k lookups in memory where the Bloom filter array is stored. Memory look-up times depend on the type of memory in which the Bloom fil ter is stored (e.g., high-speed localized SRAM or slower main memory DRAM). In this section, the memb ership testing time for a Bloom filter is reduced b y implementing hashing directly in specialized hardwa re and by introducing a second tier cache Bloom fil ter to reduce the number of accesses required into slow er main memory.


83 4.3.1 Design and Implementation A two-tier Bloom filter design is proposed to reduc e membership test time. Figure 4.12 shows the basic design of a single component (such as a speci alized chip) containing hashing circuitry and a Blo om filter. The two tiers might exist in a hardware imp lementation of a Bloom filter, or between processor cache and main memory in a computer. An on-chip Bloom fil ter can be implemented using fast SRAM (Static Random Access Memory), but it is limited in size to about Mb 4 = m. Using 32 = n m and 22 = k (as recommended in [40]) to achieve a low probability o f false positives, the number of elements that can be mapped into the on-chip Bloom filter is 072 131 = n. For applications with more than 072 131 elements, the on-chip Bloom filter can be used as a cache for a larger off-chip Bloom filter stored in the main memory (typically implemented in DRAM (Dynamic Rand om Access Memory), with slower look-up time than SRAM). The two-tier Bloom filter takes as inpu t the element (e.g., a string) to be mapped into, o r tested for membership, and outputs the k hash values and a single test output to indicate i f the element being tested for was found (or “hit”) in the on-chi p cache Bloom filter. If the cache hit output is fa lse, then the computed hash values are used to test the exter nal Bloom filter in main memory. If the element is found in the external Bloom filter the main hit input cau ses the cache Bloom filter to learn the element (if the cache is not yet full). Thus, the cache Bloom filte r contains a subset of the elements mapped into the main memory Bloom filter (the main memory Bloom filter c ontains mappings for all elements). How well the cache learns the most popular elements determines t he performance (measured in membership testing time ) of the two-tier Bloom filter. Element to test Hashing component Cache miss Cache Bloom filter Hashes Note: If cache hit is false then hashes are used fo r look-up in an external Bloom filter in main memory. If main hit is true t hen the cache learns the element. Main hit Figure 4.12. System Design of the Two-Tier Bloom Fi lter Bloom filter Main memory Cache


84 The parameters of the two-tier Bloom filter are the n: Size of the external Bloom filter (mainm). Size of the cache Bloom filter (cachem). Number of elements stored in the external Bloom fil ter ( N or mainn). Number of elements stored in the cache Bloom filter (cachen). Number of hash functions ( k ). 4.3.2 Analysis Membership testing time (testT) is a function of hashing time (hasht), cache Bloom filter testing time (cachet), main memory Bloom filter testing time (maint), and probability of a successful membership test in the cache Bloom filter (cachep). The membership testing time is ( ) main cache cache hash testt p t t T + + = 1 (4.23) for the two-tier Bloom filter and main hash testt t T + = for a single Bloom filter in main memory. When testing for an element, first the hashes have to be calculated (which takes hasht time), then the cache has to be tested (which takes cachettime) and then there is a probability cachep that the element is found in the cache. There is a probability ( ) cachep 1that the element is not found in the cache, in whic h case the main memory Bloom filter is tested (taking maint time). The summation of these factors are testT.In order for the two-tier Bloom filter to have a smaller members hip testing time than that of a single Bloom filter in main memory, 0 < -main cache cachet p t must hold. The speed-up ( S ) of testT is the ratio of the time required by the two-tier Bloom filter divided by th e time required by a single Bloom filter stored in main memory. The speed-up expresses the relative (percen tage) reduction in membership testing time by using the two-tier Bloom filter. Speed-up is, () main cache cache hash main hasht p t t t t S + + + = 1. (4.24)


85 4.3.3 Experimental Evaluation The specific target application for the two-tier Bl oom filter is membership testing for a file system containing millions of files, each file with a uniq ue identifier (e.g., path plus file name). It is we ll known that the distribution of the requests for files in some applications such as P2P file sharing and web caching follow a Zipf-like distribution [29], [18], where t he probability of requesting the element ranked j th in popularity among a population of N elements is [] aj j W = Pr (4.25) where W is the normalization constant and a is the shape parameter. The normalization constant is the inverse sum of aj 1 for N j , 2 ,1 = For 0 = a the distribution is uniform and as a increases the distribution becomes skewed and heavy tailed. For P 2P file sharing, a values between 0.60 and 0.83 have been measured [29]. Other studies (e.g., [127] and [55]), have shown similar results. In this experimental evaluation, simulation is used to study the speed-up, S of the two-tier Bloom filter compared to a single Bloom filter stored in main me mory. The speed-up of the two-tier Bloom filter for a stream of Zipf distributed membership tests is a fu nction of several variables. The factors of this ev aluation were then: The number of elements, N The popularity of the elements (modeled with a Zipf distribution, parameters N nmain= and a ). The hashing and memory access times hasht, cachet, maint, and cachep (the subscripts cache and main describe the parameter as applying to the cache an d main memory Bloom filters, respectively). The probability cachep is a function of the size of the cache (cachen). How well the cache learns the cachen most popular elements. If the cache Bloom filter learns (and thus represen ts) the cachen most popular elements – called a “perfect cache” here – for the population of N elements, then the probability of a cache hit is t he cumulative probability mass of elements cache , 2 ,1 n, =W =cachen j cachej p1a. (4.26)


86 In reality, the cache will learn a set of elements that are less than perfect. This is called the “rea listic cache” in this section and its cumulative probability mass can be computed as follows. Given N distinct elements that are sampled with replacement, let jx be the probability of drawing an element of type j Sampling continues until M elements of different types are sampled (this corr esponds to the cache being fully loaded). Here M is cachen and N is mainn. The cumulative probability, P corresponding to cachep for a realistic cache is ()[ ] types of subsets all of first sampled is subset Pr1N M G x PM i i ui == = (4.27) where G is the subset { } Mu u u , ,2 1 and where the summation is calculated over all M subsets of N types of elements. This summation is likely intractable t o compute, given the very large number of subsets possible for a large N Given this intractability, a simulation model of the two-tier Bloom filter was created. From this simulation model cachep for a realistic cache could be experimentally esti mated. The factors explained above were varied in the foll owing way. For the elements, a value of 610 8 = N was selected. An example of an application queryin g such a large set is the caches for web servers found in [40], where queries are made in se ts of millions of URLs using Bloom filters. For the Zipf distribution, a parameter 1.0 0.2, 0.1, ,0 = a was selected. This models 8 million elements in th e population with popularity ranging from uniform (0 = a ) to highly skewed (1 = a ). For hashing and memory access time, 0 =hasht (to focus on speed-up from caching effects only), 1 =cachet, and 5 =maint (modeling SRAM as 5 times faster than DRAM). For th e cache Bloom filter the parameter values were Mb 4 =cachem and Mb 16 =cachem, and 22 =cachek. For the main memory Bloom filter the parameter values were b 10 2566 =mainm (or about 30.5 MB to be able to represent 610 8 = N elements with 32 bits for each element), and 22 =maink. Figure 4.13 shows the results for cachep from eq. (4.21) for a perfect cache and from simul ation for a realistic cache. The simulation results for cachep for a realistic cache are the average of 30 trials for each value of a It can be seen that cachep increases when a increases. It can also be seen that cachep for the perfect and realistic caches could be up to 100% di fferent for a between 0.4 and 0.7. Figure 4.14 shows


87 the results for speed-up. It can be seen that the s peed-up is achieved for values of 7.0 > a and the larger cachem is, the greater the speed-up. The results show tha t even with a small cache memory, the two-tier Bloom filter can achieve faster membership testing for a heavy-tailed distribution of elements. The relationship between cachet and maint affects the possible speed-up. 4.4 Signature Array Hash Table (SAHT) Bloom filters are chosen mainly for their space eff iciency. The types of answers they give to queries, (Boolean response: it might be in the set, it is no t in the set) limits their usability. For applicati ons like P2P applications, Bloom filters could be used to preven t the application from accessing large and slow dat a 0 10 20 30 40 50 60 70 80 90 100 4 Mb realistic 4 Mb perfect 16 Mb realistic 16 Mb perfect Figure 4.13. pcacheas a Function of mcacheand 0.8 1.2 1.6 2 2.4 2.8 3.2 ( S )a 4 Mb realistic 4 Mb perfect 16 Mb realistic 16 Mb perfect Figure 4.14. S as a Function of mcacheand


88 structures (like the two-tier Bloom filter). But P2 P applications need to access information on the el ement about which it is being queried, i.e., the full fil ename and properties of the file (size, bitrate, et c.). For that reason, a new data structure is proposed to be able to give additional information when a Query is processed. The particular motivation is to improve Query processing time and search time of proxies i n resource constrained devices. Common to file search applications are the need for 1) fast search for a string match, 2) low memory use (for storing the list of filename strings), and 3) the ability to add and remove filename strings. In this section an alternative probabilistic data structure to Bloom filters is explored. This new data struct ure is called the Signature Array Hash Table (SAHT) and it is shown that it has many desirable properties and advantages. This work is similar to [45], explained in Chapter 2. This work uses a dense array instead which allocates space for the expected size of the set. For SAHT, there is no wasted space since the s et size is known from the beginning. 4.4.1 Design and Implementation Hash tables with linked-list chains can be used to store string signature values (where signatures are the hashes of the strings). Hash tables support eas y addition and removal of values. However, hash tab les require a significant amount of memory due to point ers that are stored with each value in the hash tab le chains. To eliminate the memory needed for pointers the idea is to store hash chains in blocks in a signature array and use another array to contain of fsets to the blocks. The actual values stored are signatures of the strings. Thus, a false positive w ill occur if an input string hashes to the same off set location (i.e., chain) and same signature value as a non-matching stored string. Figure 4.15 gives an example of the SAHT. A signature array ( sigArray ) is created to store signatures. They are grouped in blocks and a table called ptrArray is used to access the signatures in a fast way. Th e block start positions ( sigOffset ) and lengths of the blocks in number of signatures ( blockLen ) are stored in the ptrArray Figure 4.17 shows the two key algorithms for the SA HT, the variables defined in Figure 4.16. The algorithm mapStrings() maps m strings into the SAHT and uses a hash function to generate hash values, hash 1 and hash 2, for each string. Lines 1 to 4 create and sort a temporary array called tempArray The function sortByHash1() sorts tempArray by hash1 values. Lines 5 and 6 create sigArray by copying the hash2 values from tempArray The rest of the algorithm creates the prArray On exit, two arrays are

PAGE 100

89 defined and comprise the SAHT: ptrArray consisting of m < sigOffset blockLen > pairs, and sigArray consisting of m stringSig values, where sigOffset is the offset into sigArray for a chain with index hash 1 modulo m and blockLen is the length of the chain stored in this block. A temporary array tempArray is defined within mapStrings(). For a 32-bit machine, hash 1 and hash 2 can be defined to be 32 bits, sigOffset to be 24 bits, chainLen to be 8 bits, and stringSig to be 16 or 32 bits. The values of sigOffset and chainLen are derived from hash 1 and hash 2 in the function. A 24-bit sigOffset value limits m to be less than 216 777 16 224= (i.e., no more than 16,777,216 strings can be mapp ed into the SAHT with the variables defined in size as they are here). The arrays ptrArray and sigArray are used in the testString() algorithm to test for membership of an input string. This algori thm first generates the block index ( blockIndex ) and the signature of the string ( stringSig ) in lines 1 and 2. Since the line 3, the algorithm s test for stringSig since location blockIndex 4.4.2 Analysis The probability of false positives of the SAHT can be computed as a balls-and-bins problem where the number of balls and bins are equal. For m strings and b bits in stringSig Figure 4.15. An Example of the SAHT Data StructureÂ…ptrArray sigArray 0signature 11signature22signature33signature4 4signature 55signature6 998signature 7999signature8 004142 Â…485600 Â…999982 sigOffsetblockLen b bits

PAGE 101

90 mapStrings( stringList ) 1. for i 1 to m do 2. tempArray [ i ]. hash 1 hash( stringList [ i ], 1) mod m 3. tempArray [ i ]. hash 2 hash( stringList [ i ], 2) 4.sortByHash1( tempArray) 5. for i 1 to m do 6. sigArray [ i ] tempArray [ i ]. hash 2 7. i j count sumCount 0 8. while ( i < m ) do 9. if ( tempArray [ i ]. hash 1 = j ) 10.increment i 11.increment count 12. else if ( count = 0) 13. ptrArray [ j ]. sigOffset 0 14. ptrArray [ j ]. blockLen 0 15. increment j 16. else 17. ptrArray [ j ]. sigOffset sumCount 18. prtArray [ j ]. blockLen count 19. sumCount sumCount + count 20. increment j 21. count 0 22. if ( count > 0) 23. ptrArray [ j ]. sigOffset sumCount 24. prtArray [ j ]. blockLen count testString( inString ) 1. blockIndex hash( inString 1) mod m 2. stringSig hash( inString 2) 3 .offset ptrArray [ blockIndex ]. sigOffset 4. len ptrArray [ blockIndex ]. blockLen 5. if ( len > 0) 6. for i offset to ( offset + len ) do 7. if ( sigArray [ i ] = stringSig ) return (TRUE) 8. return (FALSE) Figure 4.17. SAHT Algorithms to Add List of Strings and Test String stringList [ ] List of m strings tempArray [ ] Temporary array of signatures sigArray [ ] Array of m signatures prtArray [ ] Array with pointers to blocks of signatures sumCount Number of signatures to be stored in a block inString Input string of testString algorithm stringSIg signature of inString blockIndex Index of block to test incoming string offset Displacement at which the block starts len Number of signatures in the block Figure 4.16. Variables for SAHT Algorithms

PAGE 102

91 [] = =m i i b i m im m i m12 1 1 1 1 1 1 positive false Pr. (4.28) In eq. (4.28) the first binomial expression is the probability of a m i ,2 ,1 = strings mapping to a given block in sigArray and the second expression is the probability of th e string having a unique stringSig in the chain at the given block and assumes that there may already be duplicate stringSig values in a chain. Eq. (4.28) cannot be simplified into a closed form. However, if it is assumed that each chain contains only non-duplicated values, then the second express ion is bi 2. Depending on how many bits are used for the signature, this assumption is reasonable (e.g., 64 bits per signatures gives 264 possible different signatures). And eq. (4.28) simplifies to, [] b 2 1 positive false Pr =. (4.29) In practice, it was found that equations (4.28) and (4.29) compute to numerical values that are close to each other (less than 1% of difference). It is solved now for the mean number of look-ups fo r the SAHT for the case of a miss and hit. Let U be a random variable for the number of lookups. Then, 2 1 1 1 1 1 1 ] [1= + = + = = m i i m i missm m i m i U E (4.30) where the initial “1” is for the look-up in the ptrTable and the summation is the mean chain length. The mean chain length of SAHT is calculated the same wa y the length of collision lists are calculated in h ash tables that solve the collisions with chaining, and it has been shown to be 1 [31]. For ] [ U Ehit it is conditioned on the probability of a block (or bin) being non-empty. Thus, () 0] length chain Pr[ 1 1 1 ] [ = + = U Ehit (4.31) where e mm1 1 1 ]0 length chain Pr[ = = (4.32)

PAGE 103

92 Eq. (4.32) follows same analysis than the probabili ty of false positives of a Bloom filter, shown in t he Chapter 2. Then, 582 .2 ] [ = U Ehit for large m In the SAHT, a mapped string can be removed by sett ing its mapped sigArray value to zero (this assumes that the hash function always returns a non -zero value). A new string can be added at a somewh at greater cost: sigArray needs to be shifted-down to create a space for a n ewly mapped-in stringSig Using the equations in this section, the memory tra de-off between the SAHT and Bloom filter is determined. The SAHT will require more memory for a given false positive rate. Table 4.3 shows the numerical results for an SAHT with 1 million string s mapped-in and 16 = b and 32 = b, and can be compared with the memory requirements for Bloom fil ters, shown in Table 4.4. For both cases, a Bloom filter with the closest possible false positive rat e was selected. It can be seen that the Bloom filte r with approximately matching false positive rate to an SA HT with 16 = b requires about 2.1 times less memory (i.e., 2.875 million bytes compared to 6 million by tes) and for 32 = b requires about 1.4x less memory. However, comparing the number of number lookups to determine a hit between the Bloom filter and the SAHT, the SAHT needs fewer lookups ( 582 .2 ] [ = U Ehit), than the Bloom filter if m/n is set to a large value (e.g., m/n =23 in Table 4.4). For that m/n, the value of k is 16, which means 16 lookups are needed when there is a hit in the Bloom filter. 4.4.3 Experimental Evaluation It is key to compare SAHT and Bloom filters in term s of the performance metrics of the Bloom filters. Thus, the response variables are: Table 4.3. Numerical Results for SAHT Pr[false positive] Memory required b = 16 1.5310 5 6 million bytes b = 32 2.3310 10 8 million bytes Table 4.4. Numerical Results for Bloom Filter Pr[false positive] Memory required m / n = 23 ( k = 16) 1.5910 5 2.875 million bytes m / n = 46 ( k = 32) 2.5210 10 5.750 million bytes

PAGE 104

93 Memory accesses: number of accesses required to get a positive or negative response. Execution time: execution time to test for one stri ng. The factors of interest for the experiments were: Ratio of test strings producing a hit. Bloom filter parameters ( m/n, k ). The ratio of test strings producing a hit was contr olled to measure the number of accesses as a functi on of ratio of hits in the test strings. A Bloom filter a nd SAHT were implemented in ANSI C to measure the mean number of lookups (and actual processing time) for hit and miss. For the Bloom filter 23 = n m was used (similar to numerical analysis in the previous section). The optimum k was selected for this configuration. CRC32 was used for a hash function. One million strings of mean length 50 bytes were mapped and tests with 6 million strings of the same mean length were performed. The gcc 3.4.5 compiler was used under Windows XP, on a Dell PC with a 3.2 GHz Pentium 4 and 1 GB of RAM. Table 4.5 shows the results. The time to test the 6 million strings was calculated and the average per test was calcul ated and shown in the table. The ratio of strings producing a hit is 100% for the “All hits” row in the table, and 0% for the “All misses” row. It can be seen that the m ean number of lookups closely matches ] [ U Emiss and ] [ U Ehit from Section 4.4.2. The measured CPU time also cor responds to the relative differences in lookup time for miss and hit. This shows that the SAHT req uires less processing time than a corresponding Blo om filter. 4.5 Bloom Filter Based Keyword Search Searching for substrings or keywords within a text file comprised of multiple strings is a common application, not only for P2P applications, but for others such as searching text in web pages contain ing a given keyword. Fast string search algorithms – such as the Boyer-Moore algorithm [17] that is used in the Unix grep utility [9] – were described in Chapter 2 In this section, a keyword search algorithm that uses Table 4.5. Experimental Results for SAHT Memory Accesses Time (ns) SAHT BF SAHT BF All hits 2.50 16.00 668 4560 All misses 1.99 2.00 625 740

PAGE 105

94 small Bloom filters pre-pended to the strings in th e string list (e.g., pre-pended to book titles in a list of book titles) to speed-up the search time is describ ed. The algorithm was first presented in [95] but t his dissertation presents the first run-time evaluation The algorithm determines which strings in a list of strings contain a given keyword. Any strings contai ning the keyword are output. Strings in the text ar e separated either by new line characters or by punct uation characters, like periods, question and excla mation marks. Words in a string are separated by spaces or some punctuation characters like commas, and dashe s, or hyphens. 4.5.1 Design and Implementation The Bloom filter assisted keyword search algorithm has two parts. The first part (or phase) is genList () (shown in Figure 4.19) that pre-processes a list of strings to generate a matching list of Bloom filte rs, one stringList [ ] List of strings bfList [ ] List of Bloom filters inString temporal string, retrieved from stringList [ ] keyWord keyword to search for keyBloom Integer, Bloom filter generated for keyword bloom Integer, Bloom filter for string in stringList [ ] matchList [ ]list of matching strings Figure 4.18. Variables for Bloom Filter Based Searc h Algorithms genList ( stringList ) 1. clear bfList 2. for all strings in stringList do 3 inString next string in stringList 4. next position in bfList genBloom( inString ) 5. return ( bfList ) searchList ( bfList stringList keyWord ) 1. keyBloom genBloom( keyWord ) 2. for all Bloom filters in bfList do 3. bloom next Bloom filter in bfList 4. if (( bloom & keyBloom ) = keyBloom ) 5. inString string in stringList corresponding to bloom 6. if (scan( inString, keyWord ) = TRUE) 7. next position in matchList inString 8. return ( matchList ) Figure 4.19. Bloom Filter Based Keyword Search Algo rithms

PAGE 106

95 for each string. The second part is searchList() (a lso shown in Figure 4.19) that uses the generated l ist of Bloom filters to speed-up the search for a keyword in the list of strings. The variables used in both algorithms are shown in Figure 4.18. Each Bloom fil ter is generated by hashing and mapping each word i n a string. Thus, genList is used to pre-process a list of strings in prepara tion for multiple fast searches by searchList. The input to genList is a list of strin gs, stringList and the output is a list of Bloom filters, bfList Within genList, genBloom returns a Bloom filter gen erated by hashing and mapping each space-delimited word in inString The string inString is an input string consisting of one or more space -delimited words. Then, searchList returns all strings in stringList that contain keyWord The input to searchList is the list of strings stringList a list of Bloom filters bfList (from genList), and a keyWord The output is a list of strings, matchList which contains the strings in stringList that contain keyWord The variables keyBloom and bloom are Bloom filters. In searchList, scan() searches string inString for keyWord and returns true if a match is found and false otherwise. The purpose of scan() is to test if the keyword is actually found in the string, since not all Bloom filter matches in line 4 will be true (that is, some will be false positiv es). An index variable (e.g., a loop counter over all Bloom filters and strings) can be used to match the corresponding inString and bloom in line 5. This index variable has to be stored al ong with the bfList to know where in the text the corresponding string sta rts. The Bloom filter assisted keyword search algorithm trades space for search time. Additional space, over that of the input text file strList is needed for bfList The size of bfList is a function of the size of Bloom filter used and the number of strings in strList The search time is a function of the size of the Bloom filter used in bfList the number of strings in strList and the mean length of the strings in strList A larger Bloom filter will minimize false positives r esulting in less need for scanning of strings (that is, in line 6 of searchList) and thus a faster search time. The Bloom filter based keyword search algorithm was implemented in ANSI C. A Bloom filter size of 32-bits (one unsigned integer word) was used. Hashi ng for both the genList and searchList implementati ons was realized using the SHA1 hash with a 20-byte has h. For a 32-bit Bloom filter, a single hash would b e sufficient for up to 32 = k index positions. The list of Bloom filters, bfList generated by the implementation of genList was stored in a separate file. Each entry in the file – consisting of a 32-b it Bloom filter and 32-bit string pointer – correspond ed to one string in strList The pointer has the offset in

PAGE 107

96 bytes where the string starts in strList An example of the implementation is shown in Figu re 4.20. The implementation of searchList took as input bfList strList and the keyword to be searched for, and returned a list, matchList with all strings containing the searched-for keyw ord. The scan() function in the searchList algorithm was called when a Bloom filter returned a hit (either a true or false positive) and scanned inString to determine if keyWord existed in it. The Boyer-Moore-Gosper implementati on in [93] was used to implement the scan() function. The implementation o f strList was instrumented to determine the number of false hits and the overall execution time in CPU se conds. The execution time was measured only for the algorithm implementation and did include the time f or overhead such as loading strList from storage into memory. The implementations of genList and searchLi st are openly available. 4.5.2 Analysis Of interest are the execution time and memory requi rements of the Bloom filter based search algorithm compared to existing string search algorithms. Algo rithms for fast substring searches have been the su bject of much study. The general idea in these algorithms is to traverse, or scan, the text being searched f or a particular substring in different ways. The Boyer-M oore algorithm [17] is generally considered one of the fastest substring search algorithms and is used in the Unix implementation of grep [9], [93]. The Bloo m filter based keyword search algorithm implemented i n C is compared to the Boyer-Moore algorithm as implemented within grep. The execution time of the searchList algorithm is a function of the number of Bloom filter hits. For a given text file, strList comprised of n strings (and thus also n Bloom filters in bfList ), the following Figure 4.20. A Bloom Filter Based Keyword Search Al gorithm Implementation bfList stringList Offset 1string 1Offset 2string 2Offset 3string 3Offset 4string 4Offset 5string 5Offset 6string 6 0bloom 1Offset 11bloom 2Offset 22bloom 3Offset 33bloom 4Offset 44bloom 5Offset 55bloom 6Offset6

PAGE 108

97 variables are defined: Tall is defined to be the execution time if all n Bloom filters generate a hit and thus all strings are scanned for a match, Tnone to be the execution time if no Bloom filter genera tes a hit, Htrue to be the percentage of strings with a true hit for a giv en test keyword, and Hfalse to be the percentage of strings with a false hit (where 1 £ +false trueH H). The sum Hfalse + Htrue can be 1, meaning all the keywords searched report a hit in the Bloom filter. Then, th e execution time T for a given list of strings is, ( ) ( ) false true none all noneH H T T T T + + =. (4.33) The time Tnone is dependent only on the number of strings and the size of the Bloom filters. The time Tall is also dependent on the length of the words in the st rings and the number of words per string (string le ngth). The added memory requirement of the keyword search algorithm is a function of the number and length of strings in strList the size of the Bloom filter used for each string and (depending on implementation) the size of a pointer associated wi th each Bloom filter. The pointer locates the start of each string within the string list that is associated wi th a given Bloom filter. In the implementation, a 3 2-bit Bloom filter and a 32-bit pointer were used (thus, being able to index into a 4 GByte text file of str ings). Thus, for each string in strList an additional 64 bits of overhead is added in bfList Bigger Bloom filters could be used but execution time would not be as go od as with 32 bits. Processors with 32-bit register s can load Bloom filters of 32 bits faster than those of 64 bits. The chosen size of the Bloom filter is 32 bits as the use of 64 bits generates two much overhead space fo r small strings. 4.5.3 Experimental Evaluation The Bloom filter based search was compared with Boy er-Moore string search algorithm, which is the fastest on average [17]. The response variables of interest were: Overhead: space required by the algorithm to store the Bloom filters generated when the text is preprocessed. Runtime (Time to search for keyword): time taken si nce the keyword is preprocessed (by generating the Bloom filter for it) until the first match occurs. This time depends on the number of entries of the keyword in the text. The factors of interest were the following:

PAGE 109

98 Number of strings in the text. Number of words per string ( n parameter of a Bloom filter). Distribution of number of words per string. Size of the Bloom filter per string ( m parameter of a Bloom filter). Different factor levels needed to be considered. Th e number of strings in the text was varied. The tex t was stored in files, which means then that the file siz e would vary. Runtime was expected to increase as t he number of strings increases, but it was necessary t o check if this has any effect when comparing Bloom filter based search against Boyer-Moore. The size o f the Bloom filter was set to 32 bits. The number o f words per string would affect the Bloom filter base d search: The more words in the string, the more bi ts are set to one in the Bloom filter. This affects the pr obability of false positives of the data structure. If the Bloom filter has few bits set to one, the number of strings that will be checked due to a false positi ve will be less than if the bits set to one are more. Two d ifferent approaches were used to control the number of words per string. The first approach was to control the number of words per string by synthetically generating a file with strings that contain a fixed number of words per string. The words were generat ed with a RNG method that output characters from the E nglish alphabet; all contained a fixed number of characters (six, which is the average number of cha racters per English word). Different files were generated, each one varying the number of words per string. The second approach was to use a file with a large number of book titles. The number of words pe r string was then distributed (for this purpose, th e 0 0.02 0.04 0.06 0.08 0.1 0102030405060708090100ProbabilityString length(bytes) Figure 4.21. Histogram of String Lengthsfor aFile W ith Book Titles min = 1 charactersmax = 99mean = 10.6

PAGE 110

99 Library of the University of South Florida provided a list of 2 million book titles). The titles were cleaned; one-letter words and hyphens were removed. Figure 4 .21 shows the histogram of the number of words per string for the file provided by the Library. The fi le had a total of 1,972,847 strings. The mean numbe r of words per string after articles were removed is 10. 62 words. Runtime was measured in all of the following experi ments. For this, 10,000 randomly generated testing keywords were searched in the text file. Fo r testing purposes, the keywords were generated in such a way that none of them would be found in the text fi les. They consisted of strings with characters rand omly taken from the English alphabet plus a control char acter (a “#” or a “!”), which were not included in the text file. The time to test the 10,000 keywords was measured, and the average time to test each keywor d was calculated. The experiments were the following : Fixed-length strings experiment: Synthetically gene rated strings are used. Different files were used with a fixed size of 80 MBs, but the number of words per string was changed in each of them. The runtime was measured as a function of the number of words per string. The Bloom filter based search against Boyer-Moore search was compare d. File size experiment: Synthetically generated strin gs were used. The number of words per string was chosen to be 4 ( n in the Bloom filter), and the optimum k was selected. With these fixed parameters, files of different sizes were generated File size in this case was calculated as the number of strings per file (varied from 1 million s trings per file to 4 million strings per file). Runtime as a function of file size was measured. Th e Bloom filter based search against BoyerMoore search was compared. Variable-length strings experiment: Files with real strings were used (with variable number of words per string). Four files of different sizes we re used. The file size was calculated with the number of MB in the file, which varied between 20 M B and 50 MB. The runtime as a function of file size was measured. The Bloom filter based sear ch against Boyer-Moore search was compared. Results from the experiments are shown in Figures 4 .22 through 4.24. The most interesting results are shown in Figure 4.22, the fixed-length strings expe riment. The Bloom filter based search starts with a high search time, compared to the rest of the times for the same algorithm. This can be explained by the nu mber of strings per file. Because the file size was fixe d, but the number of words per string was varied, t he result

PAGE 111

100 of this is that the file for strings with one word per string contains 10 million strings, but the fil e with strings of 16 words contains 500,000 strings only, which is 20 times less. Testing 10 million Bloom fi lters takes more time than testing 500,000 Bloom filters. For Boyer-Moore, the increment of the execution ti me after 4 words needs further exploration. The execut ion time, however, augments about 20% after 4 words per string are used. It starts in 32 ms and ends in 38 ms for 16 words per string. The file size exper iment (Figure 4.23) shows an expected result. The number of words per string was set to n =4 to be a representative value for a Bloom filter with only a few words. The size of the file affects the execut ion time, which increases linearly for both algorithms as the file size increases. The time for the Bloom filter 0 20 40 60 80 100 120 1234 BF-based Boyer-MooreExecutiontime (ms)Millionsof strings (for m =32, n =4, k =6) Figure 4.23.File Size Experiment 20 30 40 50 60 70 80 12345678910111213141516 BF-based Boyer-MooreExecutiontime (ms)Number of words per string ( n ) Figure 4.22.Fixed Length Strings Experiment

PAGE 112

101 based search was always about a half of the time of the Boyer-Moore implementation. Figure 4.24 shows the variable-length strings experiment results. This ti me, the Bloom filter based search was about a third of the time spent by Boyer-Moore to search for a ke yword. 4.6 Chapter Summary The Best-of-N method for Bloom filters was presente d as a new method to reduce false positive probability with the trade-off of needing to calcul ate many instances of the Bloom filters to achieve the improvements beforehand. These calculations do not affect the performance of a P2P proxy because they are pre-processing calculations that can be done in the host to be proxied. With the improvement in th e false positive rate, fewer Query messages will trig ger unnecessary wake-ups of the proxied host due to incorrect answers to Queries generated by the P2P p roxy. The Two-tier Bloom filter saves slow memory lookups by using a small Bloom filter that can be l ocated in small but fast memory. This method can be used by the P2P proxy to speed up the search for ke ywords found in the Query messages received by it. The SAHT allows a limited amount of information to be retrieved when a Query is checked in the data structure. This gives an advantage against a Bloom filter, which only can reply if the keyword (elemen t) is possibly found in the list of shared files (or set of elements). The Bloom filter based string search previously presented [95] was compared for the firs t time against the Boyer-Moore search algorithm, an d it shown to be useful for a P2P proxy. None of the alg orithms presented yield false negatives, which fulf ills 0 10 20 30 40 50 60 70 80 BF-based Boyer-MooreExecutiontime (ms)Figure 4.24.Variable Length Strings Experiment Size of file (MBs)

PAGE 113

102 the requirement (1) (no false negative can be accep ted due to the nature of P2P applications) of the l ist of requirements for string search algorithms for P2P a pplications defined in section 4.1. All the algorit hms presented here improve at least one of the performa nce metrics of the existing comparable algorithms. In the next chapter, the design and implementation of P2P proxies is presented. Depending on the device used to implement them, one or more of the d ata structures and search algorithms described in t his chapter will be of use.

PAGE 114

103 Chapter 5: Design and Evaluation of a Gnutella P2P Proxy The network adapters used by many hosts to connect to the Internet may be a chip on the motherboard, or a separate add-on card. These adapters do not re spond to application layer messages, just low layer packets. It is the TCP/IP implementation within the operating system in the host and the applications running in the hosts, which generate and respond to packets and messages. P2P file sharing is one of t he applications that require hosts to be on all the ti me, as described in Chapter 2. In order to enable h osts running a Gnutella P2P application to be proxied, t his chapter first describes the assumptions, requir ements and goals of a Gnutella P2P proxy, and then describ es the design and evaluation two types of Gnutella proxy. The first type is called a Stateless P2P pro xy. The main idea is that TCP connections to other peers are reestablished when the host goes to sleep or wa kes up, so the state of the TCP connection is not k ept. The second type is called Stateful P2P proxy. The m ain idea here is that TCP connections to other peer s will remain open for as long as the host is sleepin g and reply to Gnutella messages that require respo nse. 5.1 Specific Requirements for a Gnutella P2P Proxy The goal of the Gnutella P2P proxy is to enable hos ts running a P2P Gnutella application to stay connected to the Gnutella network and continue adve rtising the shared files while they are sleeping. T he assumptions of the Gnutella P2P proxy are the follo wing: 1. If the proxy is required to establish connections t o peers, the proxy is able to find at least one pee r willing to accept incoming connections from it. 2. The list of files the P2P application is sharing is accessible by the proxy. 3. The computational capabilities of the proxy are suf ficient to at least process some of the Gnutella messages directed to the P2P application when the h ost is sleeping.

PAGE 115

104 Requirements (1), (2) (3), and (10) explained in Ch apter 3 for the NCP are needed here. In addition, the following specific requirement is needed for th e Gnutella P2P proxy, to fulfill requirement (10) o f NCP: 1. The proxy must have the complete list of files shar ed by the P2P application in the host for which it is covering. As stated in the requirements of the NCP to support IP connectivity, and the assumptions expected to hold explained in Chapter 3, the device where the P 2P proxy is to run needs to have a much smaller incremental energy use than the covered host. For t his purpose, two types of devices were targeted. T he first design uses the NIC of the host, thus is part of the hardware of the host, either as a periphera l or embedded in the hardware. The second design uses a router inside of the same LAN in which the host to be covered is located. Because the network equipment i s powered-on all the time to interconnect devices i n the network, the implementation of proxying capabilitie s on it represents no additional energy use. The first option is explored locating the proxy dir ectly on the NIC, thus it is a “SmartNIC.” showing Figure 5.1. In Figure 5.1(a) the SmartNIC is operat ing as a standard NIC passing all packets to and fr om the fully powered-on PC. When the host goes to slee p, as shown in Figure 5.1(b), the SmartNIC enables proxying and responds to all packets and wakes up t he host only when its full resources are needed (e. g., for a file transfer). In particular, the effective use of a Bloom filter is considered to test if a s earched keyword is used by any of the files stored (and sha red) within a P2P host and make Query message processing in the proxy as fast as possible. The sh ared files cannot be stored in the proxy due to its limited NIC (internal to host) Sleeping host Host fully on Figure 5.1. The SmartNICWith Proxy Capability Traffic flow from/to PC Internet (a) (b) Proxying is enabled Internet Traffic flow from/to NIC

PAGE 116

105 storage capabilities. When a request for a file – i n the form of an HTTP GET – is received at the prox y, the proxy will wake up the host and the host will then serve the file. 5.2 Stateless P2P Proxy In this section, the design, implementation and eva luation of a Stateless Gnutella proxy is presented. This proxy will be able to establish and maintain T CP connections to P2P nodes and respond to Query messages. When an HTTP GET request for a file downl oad is received, the sleeping system is woken up and control transfers from the proxy to the host. 5.2.1 Design Figure 5.2 shows a P2P host with a Stateless proxy. The proxy can be co-located within the host (e.g., on a NIC) or in another device (e.g., a LAN switch/ router). This design considers the use of the NIC. The proxy will be resource constrained and cannot store the files shared by the host. Compared to the host the proxy can be considered a sub-system because it wil l perform a subset of the tasks performed by the ho st or an application running on it. If the proxy is a sep arate sub-system not physically contained within th e host, it may have a different IP address from that of the host. A P2P application in a host includes a main program that supports a user interface for generating Query messages, displaying Query results, and initi ating file downloads. The design of the Stateless P 2P proxy assumes that the P2P application to be proxie d not only has to respond to Query messages, but a lso forward them to other peers (Gnutella version 0.4 r equires it). Query forwarding, as explained in Chap ter 2, Figure 5.2. Sleeping Host With P2P Application Prox ied by a Stateless Proxy Sleeping host Proxy State information and wake-up signal TCP connections to P2P neighborsTCP connections to P2P neighbors Only host or proxy active at any time

PAGE 117

106 is one of the tasks of a peer implementing Gnutella protocol version 0.4, and version 0.6. According t o this, the P2P application must also include capabilities for: 1. Initiating and accepting connections to and from ne ighbors, 2. Receiving and forwarding Query messages, 3. Generating a Query Hit message for a file that matc hes the searched keyword contained in a Query message, and 4. Serving files that are requested with an HTTP GET. A P2P proxy need only support a subset of this, whi ch are capabilities for: 1. Initiating and accepting connections to and from ne ighbors, 2. Receiving and forwarding Query messages, 3. Generating Query Hit messages, and 4. Waking up the host when an HTTP GET is received. Figures 5.3 to 5.5 show the programs for the host a nd the programs for the proxy. The first three line s of both programs shown in Figure 5.3 are the same f or both: then will listen for new incoming connecti ons, connect to a set of neighborsÂ’ IPs and process Quer y messages accordingly. The difference between the two programs is that the program running on the host ha s an interface that gets Query keywords from the us er Program hostProgram()1. start listen() 2. call neighborConnect()3. start queryHandler()4. start getServer()5. while (TRUE) 6. prompt user for name of file to search7. generate Query message for file8. send Query message to all neighbors9. receive and display results of Query Hit me ssages 10. prompt user for host name for download11. use HTTP to request file from selected hostProgram proxyProgram()1. start listen()2. call neighborConnect()3. start queryHandler()4. start redirector() Figure 5.3. Main Programs for Host and Proxy

PAGE 118

107 of the application, displays results and triggers f ile downloads if requested by the user (lines 5 thr ough 11). Figure 5.4 shows the processes and functions common to both the host and proxy. Figure 5.5 shows the processes specific to only the host(the getServer()) or proxy (the redirector()). The getServer is a simple HTTP server listening for incoming HTTP requests fo r files. In all cases, processes execute in paralle l and do not terminate (e.g., as Windows threads), and fu nctions execute and terminate. The redirector() pro cess uses an HTTP 302 redirect message to cause the requ esting host to resend its HTTP GET message. The GET can be forced to be resent to the same or anoth er IP address. A delay has to be used before sendin g the redirection to give to the host time to wake up. Ot herwise, the redirected GET might reach the host be fore the operating system is ready to accept incoming co nnections. Process listen()1. while (TRUE) 2. listen for and accept incoming connections3. update neighbor list with accepted connecti ons Function neighborConnect()1. connect to all hosts in neighbor listProcess queryHandler()1. while (TRUE) 2. for (each connection) 3. wait to receive a Query message4. forward Query message to all neighbors5. check for queried file6. if (file exists) 7. send a Query Hit message Figure 5.4. Functions and Processes Common to Host and ProxyProcess getServer() –Standard HTTP server Process redirector()1. while (TRUE) 2. wait for a connection on port 803. if (receive an HTTP GET) 4. wake-up the proxied host5. send an HTTP 302 to redirect request to host Figure 5.5. Processes Specific to Host or Proxy

PAGE 119

108 There is some state information that needs to be sh ared between the host and proxy, divided into power states and application states. The power states des cribe the current power state of the host and the application state contains information that describ es the current user session of the application. In the case of a P2P application, a user session is established each time the P2P application connects to the netw ork. For that reason, the following is the state informa tion that the P2P Stateless proxy needs from the ho st: Power state of the host – fully powered-on or sleep ing. List of names of files shared. List of IP addresses of neighbor nodes. The filenames can be shared between the host and pr oxy in the form of a Bloom filter. Both host and pr oxy will have to use the same hash functions to test an d map filenames in the Bloom filter. The host needs to create a Bloom filter with the list of shared files and then make it available to the proxy. When con trol is transferred from the host to the proxy, TCP connect ions to neighbors from the host are terminated and then re-established from the proxy. When control is tran sferred from proxy to host, the opposite occurs. 5.2.2 Prototype Implementation To emulate the implementation of a SmartNIC, an Eth ernet development kit was selected, based on the requirement that it must have a low cost processor (to lower the costs of the SmartNIC). The P2P proxy was implemented using a NetBurner MOD5270 Ethernet Development Kit [98] (shown in Figure 5.6) with Figure 5.6. NetburnerDevelopment Kit Serial ports MCF5270 processor 10/100 Ethernet link

PAGE 120

109 the following specifications: 32-bit Freescale Cold Fire processor running at 147 MHz, 512 KB of Flash memory, 8 KB Instruction/Data cache and 2 MB of SDR AM. The system runs the uC/OS operating system, which is designed for resource constrained devices. The uC/OS can run several tasks at the same time u sing different priorities, but it can have only one task at each of the priorities it uses. The host was a Dell OptiPlex PC with a Pentium 4 at 3.2 GHz with 1 GB R AM running Windows XP. Both systems support 100 Mb/s Ethernet. The NetBurner was selected for t he low-cost processor it uses and for its ability t o be programmed in C. A low-cost processor would be nece ssary to design a low-cost SmartNIC and its use could be popularized. The implementation was first developed in the host using a customized version of a C++ development environment, and then compiled usin g a customized C++ compiler and transferred to the NetBurner using a serial cable connected to one of the serial ports shown in Figure 5.6. The implement ation was transferred as a binary file executable by the NetBurner processor. The serial port was used only for transferring the compiled implementation and for de bugging purposes. There were other processes runnin g at the same time in the NetBurner, like FTP server to upload files, and a DHCP client. The uC/OS operating system runs threads as sequenti al tasks. Thus, the proxy program was implemented as a single task with a main loop where all the processes were run in a sequential manner. The proxy implementation used non-blocking sockets that were read using time-outs of one processor tick (which is 100 ns). A non-blocking socket was listen ing on each of the connections open by the proxy wi th the list of peers to which it has to connect. It lo oped through all of them looking for Gnutella messa ges to read in their buffers. For prototype purposes, a Bl oom filter with the list of shared files mapped int o it was assumed to be already in the proxy. The approach fo llowed was mapping entire filenames without tokenizing them into keywords. This, however, is a constraint because it forces Queries to be for full filenames to produce a match. For the P2P Stateful proxy, other methods to retrieve the list of shared files and to process Query messages were explored. The l ist of peers to which the proxy has to connect was also assumed to be in the proxy when the proxy program s tarts. 5.2.3 Experimental Evaluation The main purpose of the evaluation of the prototype of the P2P Stateless proxy is to show that a subse t of the functionalities of a P2P application can be run on a low-power device dedicated to proxy for th e host running the P2P application. As described in Chapte r 2, one of the most important tasks of a P2P node is to

PAGE 121

110 respond, and forward Query messages accordingly. A key question is then, how much computational capability is needed in the proxy sub-system in ord er to maintain a reasonable Query forwarding rate a t all times? The additional delay time to request and rec eive a file from a sleeping host also needs to be considered. Three experiments were designed to eval uate the key measures for the implemented prototype P2P proxy. The two response variables of the experi ments were the following: File download time from an awake and sleeping host. Query messages forwarding rate. The file download time measures the delay time intr oduced by the use of a proxy. It is important also to measure the Query messages forwarding rate to see h ow much this important variable will be affected. T he factors of interest are the following: Number of Gnutella peers (neighbors) to which the p roxy is connected to. Ratio of Query Hits: percentage of Queries resultin g in a match and then generating a Query Hit. For evaluation purposes, the application for the P2 P proxy is also run in the host. In the host, block ing sockets could be used in a threaded implementation running parallel processes, instead of non-blocking sockets and non-threaded functions. The idea is to compare the same implementation in both systems to evaluate how different the performance of the proxy is in each one. The Query messages forwarding experiment is as foll ows: For this, a PC running a “Query blaster” was used. The Query blaster is a C program that est ablishes a connection to a P2P host and sends Query messages as fast as possible. To evaluate the Query messages forwarding rate as a function of the numb er of neighbors, the first setup for this experiment w as as follows. Other PCs were used to connect to as P2P peers and the number of peers from 1 to 10 was vari ed. For this experiment, Query messages for files n ot in the host were generated, so the proxy would not res pond with a Query Hit message. For the second setup of this experiment, the Query forwarding rate (where a fixed percentage of the Query messages would resul t in a Query Hit message being returned) was evaluate d. The percentage of Query messages that resulted i n Query Hit messages was varied from 0% to 10%. The results from the Query forwarding experiments a re shown in Figure 5.7. The figure shows the Query forwarding rate per connection. The Query for warding rate for the proxy varied from 360 to 130 messages per second. The rate for the host varied f rom 12,547 to 324 messages per second. These result s

PAGE 122

111 show that as neighbors are added, the query forward ing rate per link decreases. The drop in the rate o f the host can be explained by the way the QueryHandler p rocess in Figure 5.4 was designed. Because the process loops through all the open connections, as neighbors are added, the process had to reach the l ast added connection until returning to the first one a nd processing packets from that connection again. Although there is a noticeable difference between t he rates, it has to be noted that the rates measure d on the NetBurner are still useful. The study shown in [58] is one of the most complete studies of the Gnutell a network including models and traffic characterizati on. The study logged 604,000 different Gnutella Figure 5.7. Results From Query Forwarding Experimen t 0 2000 4000 6000 8000 10000 12000 14000 12345678910Query forwarding (mess/s) Number of neighbors Host ProxyFigure 5.8. Results From Query Hit Experiment 0 400 800 1200 1600 012345678910Query forwarding (mess/s) Percentage of Query Hits (%) Host Proxy

PAGE 123

112 sessions and 267 million Gnutella messages. They t hen proposed a model of the traffic of Gnutella networks, and created a table that calculated the i nter-arrival times of all the Gnutella messages acc ording to the traces they made. Query and Push message wer e the messages that arrived more often, with mean inter-arrival times of 0.03 seconds and 0.06 second s respectively; which means 33 Query messages every second, and 16 Push messages arriving every second. So, the rate achieved by the NetBurner means that it can easily process messages arriving at a typical i nter-arrival time. The results for the Query Hit ex periment are shown in Figure 5.8. Similar to Figure 5.7, thi s figure shows the Query forwarding rate per connec tion. As the percentage of Query messages resulting in a Query Hit was increased from 0% to 10%, the Query forwarding rate remained roughly constant for both the proxy and host. This demonstrates that the over head to send a Query Hit message is very low. The File download time experiment is as follows: It took less than 1 second to download from an awake host. To measure the time in the NetBurner, t he proxy program was configured to wake up the host wait a delay time of a few seconds before sending t he redirection, and then send it. Several attempts with different delay times were tried. Delay times of le ss than 9 seconds prevented the host from being rea dy to receive HTTP file requests. It then took 9 seconds to download from a sleeping host that had to be wok en up. The wake-up time of WindowsXP was the dominant factor in the 9 seconds. The HT TP request did not time out, in any case. 5.2.4 P2P Application State Conservation With the P 2P Stateless Proxy It has been shown with the P2P Stateless proxy that a subset of the tasks of a P2P node can be run on a small system like an Ethernet Development kit and s till be able to perform the tasks in a way the typi cal participation of a P2P node requires. It is necess ary now to explore how to design a P2P proxy that a cts on behalf of the host in a way that preserves the stat e of the application. The P2P Stateless proxy relie s on the proxied host to send the list of peers the host was connected to before going to sleep. The proxy migh t encounter the problem of not being able to reconnec t to the list of peer IPs given by the host. A reas on for that might be that the remote peer to which the pro xy tries to connect might not be able to accept new connections and might deny the connection attempt f rom the proxy. In this case, the proxy would have t o attempt connections to other peers, after which the proxy would then be connected to a different list of peers than the one to which the P2P application in the host was connected. If this happens, it can be

PAGE 124

113 considered that the state of the P2P application is changing while the host is sleeping. When the host wakes up, it will have to reconnect again and possibly, i t will end up not connected to the same original se t of peers. Conservation of the state of the application might not always rely on the preservations of the connections with the same group of remote network h osts. This might not be a problem for client applications that, for example, always connect to t he same server (or set or servers). IM application s run 3way chat conversations through the IM servers, and all the IM servers should have the same login information about the user. This applies for all th e applications that need to login to an application server. 5.3 Stateful P2P Proxy In this section, the design, implementation and eva luation of a P2P proxy called Stateful P2P proxy is presented. 5.3.1 Design The Stateful P2P proxy is a system that consists of two software components: 1) An implementation of the NCP explained in Chapter 3 with the addition of some modifications to proxy for a P2P application, and 2) the P2P Catcher, in charge of processing Gnutell a messages when the proxied host is sleeping. The P2P Catcher is divided into two components: the Gnutell a tracer and the Files list manager. Figure 5.9 sho ws a P2P host being proxied by the P2P Stateful proxy lo cated in the last hop router/switch to which the ho st is connected. The host has to establish connections to other peers through the proxy. The proxy establish es Figure 5.9. Sleeping Host With P2P Application Prox ied by a P2P StatefulProxy P2P node Router P2P nodes to P2P proxy packet flows Network P2P proxy to host packet flows P2P Stateful proxy software Sleeping host

PAGE 125

114 the connections to the peers and then forwards all the packets in both directions. The Gnutella messag es flow over TCP connections in both parts of the conn ection: between the host and the gSOCKS, and between the gSOCKS and the peers in the network. Wh en the host is sleeping, the P2P Catcher traces Gnutella messages directed to the host. It cares on ly for Query messages sent towards the sleeping hos t, keep-alive messages in the form of Gnutella Pings, and requests for files. Query messages are answered with Query Hit messages if there is a match in the list of shared files with the keyword the Query con tains, and Ping messages replied to with Pong messages. Fi le requests in the form of HTTP GET messages trigger host wake-ups. Other messages are ignored. There is some application state information that ne eds to be shared between the host and the proxy: 1. The sleep state of the host. 2. Information pertinent to the peer itself. This incl udes: the Gnutella identifier (the unique 16-bytes identifier used by Gnutella protocol to identify so me of the messages sent by the host and connection speed. 3. The list of shared files: information used by the h ost to respond to Query messages, including file names, file sizes, and checksum of the files being shared, among other file information fields. The software components are shown in Figure 5.10, a s long as the control paths are used by the components. The Stateful proxy is a modified implem entation of the NCP, which adds the P2P Catcher to the system. The software components are the followi ng: Control point: software in charge of setting config uration variables depending on the sleep state of the host. gSOCKS: the SOCKS relay server used to relay TCP co nnections with Gnutella peers. Gnutella tracer (part of P2P Catcher): software tha t traces messages sent to the same port to which the power managed host is listening, and filters an d processes the important messages. Files list manager (part of P2P Catcher): software to retrieve the list of shared files from the host and to perform searches on the list when a Query is detected by the Gnutella tracer. The following is the design of the control program of the NCP. The main task of the control program is to detect the sleep state of the proxied host. For this, the data path (4) is used. A TCP connection i s open when the host wants to transmit its state, and clos ed once it finishes transmitting it. It is also in charge of

PAGE 126

115 communicating the state to other components so that tasks on those components can be performed accordingly. It first uses control (1) in Figure 5. 10 to force the gSOCKS to stop forwarding messages to the sleeping host. It also uses control (2) to activate the Gnutella messages tracing functionality of the P2P Catcher. It uses control (3) to change the TCP vari ables TCP_MAX_RTO and TCP_MAX_RETRIES2 to enable the TCP connections between the host and the relay server to remain open for long periods of ti me. The values set into these variables can be tuned fo r an expected host sleep period. When on the contra ry, the control program detects the host is awake, the message forwarding will restart, Gnutella messages will not be traced, and the TCP variables explained abov e needs be set to the original value. The design of gSOCKS is as follows. It implements a server program using the SOCKS protocol that works as relay server for the TCP connections. The program has a pair of open TCP sockets for each of the Figure 5.10. Architecture of the P2P StatefulProxy Note: Control (1) communicates host sleep state to gSOCKS Control (2) communicates host sleep state to P2P Catcher. Control (3) is use d to change the TCP retransmission time-out. Data path (4) is used to send response an d wake-up packets to the host. Control point (3) To/from network TCP/IP stack To/from host P2P proxy control (1) gSOCKS To other applications Link-level driver P2P Packet filter Gnutella tracer P2P Catcher Files list manager (2) (4)

PAGE 127

116 connections the host establishes with its peers. Ea ch pair consists of a socket for a connection relay to host, and a socket for the connection relay to peer. It c onstantly checks on both sockets for messages that will be forwarded to the other socket in the pair once dete cted in the reading buffer of the socket. The packe t forwarding process in the SOCKS server occurs in tw o different ways, depending on the host sleep state They are called rules and work as follows: Awake rule: action taken when host is awake. There is no specific action which means that messages are forwarded as if the relay server did n ot implement any proxy capabilities. Messages are passed down to the TCP stack. However, the gSOC KS is checking regularly (every 1 second) for a signal triggered by the control program to de termine that the host is sleeping, and that changing the forwarding rule is necessary. Sleep rule: action taken when the host is sleeping. When the gSOCKS detects that the host is sleeping, it will stop forwarding messages to the s ockets listening from the connection established with the sleeping host. The TCP stack of the router will not see any of the packets sent by the peers, because the messages are not being forwarded by the gSOCKS. The Sleep rule is used to prevent messages from bei ng buffered in the TCP stack when the host is sleeping. In the case of a proxy for P2P, this is i mportant because peers that send Query and Ping mes sages time out to receive responses. Responses received b y the other peers after the time-out are discarded. The Gnutella tracer follows the same approach follo wed in Chapter 3 for the SIP Catcher. It consists o f a program that runs as one of the components of NCP and is in charge of detecting specific Gnutella messages sent to the proxied host when it is sleepi ng, and HTTP requests for a shared file. Figure 5.1 1 shows the decisions the program takes when a messag e to the listening port is received. From all the Gnutella messages, the P2P Catcher only cares for t he Query, Ping, and Push messages. As the figure shows, Ping and Query messages require the generati on of a response. Those messages are then discarded There should not be Query Hit messages directed to the host because the host should not have triggered a Query, and Pong messages should not be received bec ause they are sent in response of a Ping (which was not sent by the sleeping host). A detected Ping, ho wever, might mean that a peer to which the host is connected wants to test the connection to see if th e host is gone or not. Thus, the response of a Ping is important in order to keep the connections with oth er peers open while the host is sleeping. Query

PAGE 128

117 messages should be responded to so that potential f ile downloads could be triggered by other peers wan ting files being shared by the host. In this way the hos t continues sharing files even if it sleeping. A re quest for a file might be received by the P2P Catcher in two di fferent ways, depending if the sleeping host is beh ind a firewall or not. If it is behind a firewall, Push m essages will be received. They mean that there is a n attempt to request a file. The approach to be followed is t o queue that message and wake up the host. Once the host is awake, the P2P Catcher should deliver the messag e to the host. A Push should make the power managed host attempt to open a new TCP connection with the peer that sent the Push. This action must only be d one by the host once it is awake, because it has the fi le that will be requested through that new TCP conn ection. The peer should then request the file (through an H TTP GET). Direct HTTP GET requests should be Figure 5.11. Gnutella Message Processing by the P2P Catcher Note: Queued messages are delivered to the host when it wakes up. Query? Message received by P2P Catcher Discard the message N Y Trigger a wake-up Generate a response Ping? HTTP Get? N N Y Y Push? N Y Queue the message Discard the message Trigger a wake-up

PAGE 129

118 detected on the same port used to exchange Gnutella messages. An HTTP GET detected by the Gnutella tracer generates an HTTP Redirect (302) message as response, which carries an IP to which the file req uest should be sent. This Redirect should make the reque ster peer send the request again to that IP, which is the same as the power managed host. Before the P2P Catc her sends the HTTP response, it should wake up the sleeping host. The design of the file list manager is as follows. It is a software component that is in charge of retrieving the list of shared files and performing searches for the keywords received in Query Hits. F or this, no modification of the P2P application on the proxi ed host should be needed. The application selected for the prototype implementation should use a mechanism to advertise the list of shared files if another p eer requests it. The list is then stored in a data stru cture. One of the string search algorithms presente d in Chapter 4 will be used as the search method when th e P2P Catcher detects a Query directed to the host. The one that best fits is the Bloom-filter-based search algorithm. This algorithm is able to retrieve info rmation from files (e.g. the list of shared files with prop erties for each of them) and it was shown to be fas ter than other string search algorithms. Because the device where the NCP is located is a router, some memory c an be traded in order to be able to respond to Query m essages with exact matches. The preprocessing part of this algorithm is applied to this data structure, w hich generates two files stored in the file system of the router. This part first creates two files. It first creates a file containing only the filenames, stor ed in the same order as in the list of file names. That file is used to create a file with a list of Bloom filte rs that have the keywords of the filenames mapped in, and the of fset in the file with filenames, so it is easy to l ocate of all the information for a file when its Bloom filte r returns a match for a keyword. 5.3.2 Prototype Implementation Figure 5.12 shows the test-bed where the P2P Statef ul proxy was implemented and evaluated. The power managed host uses a Gnutella P2P application that connects to the P2P network through a SOHO router. A Gnutella ultrapeer running in another hos t is used as one of the ultrapeers to which the pow er managed host is connected as a leaf peer. For testi ng purposes, another host running as a leaf peer is connected to the same ultrapeer. With this setup, t he leaf will be used as the starting point of Query messages to be sent to the power managed host.

PAGE 130

119 The implementation of gSOCKS is as follows. The las t hop router is a Linksys WRT54G version 3. As for the NCP implementation in Chapter 3, the origin al Linksys firmware was replaced with an OpenWrt firmware to allow installation of custom made appli cations called packages. The control program of the NCP is a package running on the router. The most im portant task is to listen for sleep state changes o n the power managed host. It then writes the sleep state to a file that will be read by the other components of the NCP. One of the applications installed in the firmw are is the Srelay package, which is a relay server, and is the main part of the gSOCKS. For the P2P Stateful p roxy, the relay server had to be modified to implem ent the message forwarding rules explained in the desig n. On the main function of the Srelay program, a ne w process is created that will check the sleep state file that the NCP control program updates when ther e is a sleep state change. This process was set to sleep 1 00 ms and updates a global variable with the most c urrent sleep state. This time was selected so that the for warding rules explained above could be changed as f ast as possible, and without generating too many processin g requirements on the router processor. A function on the relay server is in charge of forwarding the mes sages in both directions between a pair of open soc kets. This function was modified to check this global var iable each time a message was going to be forwarded from one socket to another one. The P2P application used in the proxied host and th e ultrapeer is Limewire. Limewire is an open source software project that is implemented using J ava [84]. The Limewire project was modified for prototype purposes only. The list of modifications is the following: 1. The leaf was modified to stop using compression al gorithms to send the Gnutella messages. Once this was done, Limewire sent the messages in plain ASCII text, and the P2P Catcher was able to Figure 5.12. The Test-Bed for P2P StatefulProxy ultrapeer Router P2P nodes to P2P proxy packet flows Network P2P proxy to host packet flows P2P Stateful proxy software Sleeping host leaf

PAGE 131

120 trace Query and Ping messages. This modification is not mandatory; however, it was simpler for prototype purposes to make the modification in Lime wire. A disadvantage of using uncompressed Gnutella messages is that it increases the traffic in the network. This issue was not explored in this dissertation. 2. In the ultrapeer some modifications were also neede d. Limewire will connect to the Gnutella network initially as a leaf. To be able to have a m anageable environment, Limewire was modified to force it to be an ultrapeer every time it connec ts to the network. 3. The ultrapeer was modified to prevent it from closi ng idle connections. An open connection with another peer is considered an idle connection after a timeout is reached. This timeout is reached if no message is received from that connection. Once c onsidered idle, Limewire will send a Ping to it, from which it expects a Pong. If no Pong is rec eived it will close the connection after a few minutes. The timeout used was set to 12 hours, mean ing that no connection is considered to be idle before 12 hours. The proxied host was expected to s leep for less than 12 hours. The P2P Catcher implementation is a program install ed as a package in the Linksys router. The main functionality is for the Gnutella tracer. The file list manager implementation is a function inside of the P2P Catcher that is called when the P2P Catcher package is started (it is assumed that the power managed h ost is up and the Limewire is running when the P2P Catc her is started). Limewire provides a mechanism that is not Gnutella compliant to advertise the list of sha red files. The file list manager sends an HTTP GET request to the same port the Limewire uses to liste n for incoming connections. If the Limewire is runn ing, it will reply with the list of shared files, containin g a file index, the filename, size in bytes, and a 16 bytes checksum. Besides the information of the files, Lim ewire sends the 16-bytes Gnutella unique identifier that it uses to generate some of the Gnutella messages. This is key for the P2P Catcher to have, because it will be used to generate the Query Hit messages, as reco mmended by the Gnutella specification. 5.3.3 Experimental Evaluation For the evaluation, the test-bed shown in Figure 5. 13 is used and connected to the Internet through th e USF network. It consisted of three Dell PCs, which act as one ultrapeer, and two leaves, the two conne cted to the ultrapeer. The three PCs used had Intel Pent ium 4 processors at 3.2 GHz, and run Windows XP. Th e ultrapeer has 2 GB of RAM memory and the two leaves 1 GB of RAM. The P2P application running is

PAGE 132

121 Limewire, version 4.18. The proxied host is connect ed to the LAN of the Linksys WRT54G router shown in the figure. The WAN interface of the router is c onnected to the network and uses IP T he other leaf and the ultrapeer are directly connected to the network of the university and use IPs and respectively. To te st that the proxy was successfully working, Wiresha rk was run on the leaf (IP The purpose of this evaluation is to show that the proxy is fu lly acting on behalf of the host by responding to Query messages when the host is sleeping, and also, that no buffering of messages sent to the host occurs when the host is sleeping. To show this, the following s teps were followed: 1. With the proxy off, and the host being awake, a Que ry was generated for a keyword containing the word “depeche" on the leaf and the reply of the hos t was traced. 2. With the proxy on, the gSOCKS on the proxy using th e sleep rule, and the host sleeping, a Query for the same keyword was generated and the reply of the proxy was traced. 3. With the proxy on, but the gSOCKS using the awake r ule, the host was put to sleep. Three different Query messages from the leaf were generat ed. The host was woken up, and the messages were traced. Figure 5.13. Test-Bed Used to Test the P2P Stateful Proxy Linksys router Limewire leaf Limewire ultrapeer Proxied host

PAGE 133

122 The trace for step 1, taken in the leaf, is shown i n Figure 5.14. The Query message is not shown in th e trace. It can be seen message number 27 is the Quer y Hit, and part of the content of the message is highlighted on the right (the name of the file is D epeche Mode Tribute-Ponytail Girl.mp3). Messages 25 and 26 are an exchange of messages between the leaf and the proxied host that does not follow the Gnut ella specification (Query Hits are accepted without any need of extra handshaking, as long as a Query has b een generated). Figure 5.15 shows a trace obtained in t he leaf, which shows the Query response of the prox y Figure 5.14. Query Hit Response Sent by the Awake H ost Query Hit message Shared file in the message Figure 5.15. Query Hit Response by Proxy Query Hit message Shared file in the message

PAGE 134

123 while the host was sleeping. It can be noted that t here is no extra exchange of messages between the l eaf and the proxy because this part was not implemented After the host was woken up, no messages are sent by the host in replay to the Query sent when it was sleeping. This means that the sleep rule worked accordingly by not forwarding the messages to the h ost when it was sleeping. For step 3, the trace is shown in Figure. 5.16. It can be seen that the host tries to start the same message exchange with the leaf a s it is shown in Figure 5.14. However, the leaf might have timed out to receive responses for those three Quer y messages. So, for that reason, no response from the leaf is seen in the trace. 5.3.4 P2P Application State Conservation With the P 2P Stateful Proxy The state of the P2P application being proxied by t he P2P Stateful proxy is preserved during the sleep period of the host. Because the TCP connections are being relayed with gSOCKS, they will remain open for as long as the host remains in the sleep state. This assures that the P2P application on the host remains connected to the same set of peers all the time (as long as the remote peer does not disconnect from t he network). As explained in Chapter 2, the time the h ost remains connected to the network, among other factors, is used to promote the P2P application to become an ultrapeer, according to Gnutella version 0.6. One of the consequences is that the peer will reach more peers when generating Query messages. This is the desirable advantage of becoming an ultrapeer, a nd is reachable by keeping the TCP connections open even if the host goes to sleep. Figure 5.16. Messages Sent by the Host if Proxy Doe s Not Discard Messages message from host

PAGE 135

124 Applications that need to preserve the TCP connecti ons with remote servers might benefit from this design. It has been shown already in Chapter 3 that applications like SSH, which establish a session w hen connected to the SSH server, benefit from the idea of relaying TCP connections to allow the host to sl eep. 5.4 Chapter Summary In this chapter, two types of P2P proxies for P2P G nutella applications were presented. The first prox y, P2P Stateless proxy, allows the host to close the T CP connections established with the peers before go ing to sleep. The proxy then reestablishes the TCP conn ections to the list of peers to which the covered h ost was connected. When proxying, it is able to respond and forward Query messages directed to the host. I t was also shown that this proxy is able to recognize HTTP requests for files directed to the host, and wake up the host to prepare it to serve the file request In the evaluation of this proxy, it is shown that although the Query message forwarding and response rates are below those rates achievable by the host, this sti ll can be acceptable given existing studies about typical inter-arrival times of Gnutella messages of this ty pe. The second proxy, P2P Stateful proxy, is located in the last hop router and covers for a host by keepi ng the connections open for as long as the host is sle eping. It does so by using a software component tha t consists of a relay server that proxies the TCP con nections established by the host. It prevents modifications to be made in the application running host. The use of the Bloom filter based string sea rch algorithm to process keyword searches was explained The proxy was shown to successfully cover for Query messages sent to the host.

PAGE 136

125 Chapter 6: Summary and Directions for Future Resear ch This dissertation presents the first investigation of application-level proxying to reduce induced ene rgy use in network hosts. The work presented in this di ssertation has been published in several conference papers which are [69], [70], [71], [67] and [68]. W ork at UCSD (the Sominoloquy project [4]) and at ot her universities has built on, (and cites) the work pre sented here. Most significantly, the work undertake n for this dissertation has directly influenced the Ecma standard (TC32-TG21 – Proxying Support for Sleep Modes) [34], evidence of which is the direct refere nce to [69] in the draft Ecma standard. To enable proxies to be lightweight in their proces sing and memory requirements (and thus be both low cost and low power) improved Bloom filters were investigated. It was shown how Bloom filters are a n ideal tool for keyword searching as needed for prox ying P2P protocols such as Gnutella. In Chapter 4 a Bloom filter based keyword search algorithm was dev eloped and measured. This algorithm had been previously proposed by Mullin [95]. The work in thi s dissertation was the first to fully measure the s peedup made possible from using Bloom filters to assist keyword search in a list of strings. Also in Chapt er 4 a new method (the Best-of-N method) of mapping elemen ts into a Bloom filter so as to reduce the false positive rate was shown. Best-of-N was shown to be better than existing improvements – such as the Power-of-2 Bloom filter [86] – for small m / n ratios. It is exactly small Bloom filters with sma ll m / n ratios that are of interest for the Bloom filter assisted keyword search algorithm. The better Bloom filters – and their application to a fast keyword search algorith m – will directly improve the performance of proxie s, such as the P2P proxy described in Chapter 5. This will especially be the case for P2P proxies that co ver for multiple leaf nodes sharing millions of files. The work in better Bloom filters has significant va lue beyond proxies. Theoretical work in understanding the true false positive rate has now been done and submitted to a journal as [27]. This new work is beyond the scope of this dissertation and w as not presented herein.

PAGE 137

126 6.1 Predicted Energy Savings From Application Level Proxying Depending on the application being proxied, use of the methods described in this dissertation could achieve the following: Gnutella P2P applications: Assume 10 million PCs ru nning Gnutella P2P applications at all time [105], of which 60% are left on all the time [115]. Using conservative calculations, the idle time of those PCs spent during night (around 10 hours) yiel ds 2,190 GWh/year at 100 W per PC. Given the fact that, only about 1% of the idle time is us ed to upload files, 99% of the idle time is wasted. Assuming the network connectivity problem due to th e use of P2P applications is solved for at least 25% of those PCs with the proxy presented her e, the savings could be 542 GWh/year, which is approximately $54 million dollars a year. IP hard-phones running SIP protocol: There is poten tial for saving all the energy wasted due to idle time of IP hard-phones, which amounts to 443 G Wh/year. With the SIP Catcher proposed in Chapter 3, IP hard-phones could be put to sleep and only be woken up to receive a call. Assuming 25% of those IP hard-phones could be proxied, the s avings could be 111 GWh/year, which is approximately $10 million dollars a year. The savings presented here are considered conservat ive because in both cases only 25% of the hosts are assumed to be using one or more of the ideas propos ed. Also, calculations are only for the application s proxied with the prototypes implemented during this research. Even if only a fraction of the above sav ings can be achieved, this research will still have made a significant impact in reducing the CO2 footprint of modern society. 6.2 Directions for Future Research This research has solved several problems in the ar ea of reducing induced energy use of network hosts, but it has also raised new questions and directions Figure 6.1 shows a taxonomy of future directions, or next steps, for proxying. Not all of these directio ns, however, are likely to be fruitful. Fundamental ly, one can explore how to improve proxies or finding new u ses of proxies. For improving proxies, open questio ns include:

PAGE 138

127 1. Can a proxy be made completely transparent to the h ost(s) and applications for which it covers? Proxying for network applications has been shown he re to be highly dependent on the application to be proxied. It is necessary to know the applicat ion that is to be proxied and certain application session data like the ports, types of messages that need to proxied and any personal account information if any is used during the execution of the application. The proxy should be able to learn what needs to be proxied, and do so without m odification of the operating system or the network applications. Although there has been resea rch on what needs to be proxied (e.g. [97]), the results presented on that work reflects just a snapshot of the popular applications today. Proxying should be independent of the type of the n etwork applications that need to be covered. 2. Can a proxy support mobility for wireless hosts? Th e design of the NCP presented in Chapter 3 relies on connections that are not prone to disrupt ion. In wireless networks, the typical mobility of hosts might lead to disruption in the connectivity. To solve the network connectivity problem for applications running on wireless hosts, the design of the proxy for application connections has to take into account the wireless environment, and ove rcome problems such as connections being closed due to loss of connectivity to the network b lamed on the mobility. 3. What are the potential energy savings of creating a proxy for an application server instead for hosts? The proxy was explored as physically located close to the proxied host (e.g., on the same LAN). This research did not require modifications o f the proxied applications. However, to proxy for certain types of network applications, personal user account information to login to the application servers might be needed. One such examp le is Skype, which uses a proprietary technology [52]. This might prevent some users from sharing their personal information with the Figure 6.1. Future Directions for Network Connectiv ity Proxying Next steps for proxying Better proxies New proxies New applications Cover for multiple hosts Less impact on host Support mobility Electrical equipment Data centers

PAGE 139

128 proxy to act on behalf of their applications. For t hese types of applications, it would be interesting to explore new types of proxies for network applica tion servers. This means that the hosts can use a network connectivity proxy that is in fact part o f the services provided by the same company running the application server. 4. What are the computational requirements for a proxy that can serve files on behalf of a sleeping host? Proxying for P2P applications have been explo red in this dissertation to enable hosts to sleep when idle. As described on Chapter 4, requests for files in a P2P application follow a Zipf-like distribution, where a very small group of files are requested most of the time. An approach similar to the two-tier Bloom filter could be used in the p roxy to cache frequently-requested files in hosts with a large amount of popular shared files. There are some hosts that receive file requests more often than others, because they share a large amoun t of popular files. With this proxy, hosts could sleep even when constant requests for frequent file s arrive because they are served by its proxy. It is important to explore what would be the trade-off between the amount of cached files and the length of sleep periods. These future directions can be fruitful paths for r esearch, resulting in even greater impact from prox ying as a means of reducing the CO2 footprint of ICT.

PAGE 140

129 References [1] Advanced Configuration and Power Interface Specific ation, Revision 4.0, June 16, 2009. URL: [2] APM – Advanced Power Management V. 1.2 specificatio n, 1996. URL: com/whdc/archive/amp_12.mspx. [3] Y. Agarwal, R. Chandra, A. Wolman, P. Bahl, K. Chin and R. Gupta, “Wireless Wakeups Revisited: Energy Management for VoIP over Wi-Fi Sm artphones,” Proceedings of the 5th International Conference on Mobile Systems, Applica tions and Services pp. 179-191, June 2007. [4] Y. Agarwal, S. Hodges, J. Scott, R. Chandra, P. Bah l, and R. Gupta, “Somniloquy: Augmenting Network Interfaces to Reduce PC Energy Usage,” Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation pp. 365-380, April 2009. [5] Alert Standard Format (ASF) Specification, Version 2.0, April 23, 2003. URL: http://www.dmtf. org/standards/documents/ASF/DSP0136.pdf. [6] L. Alvisi, T. Bressoud, A. El-Khashab, K. Marzullo, and D. Zagorodnov, “Wrapping Server-Side TCP to Mask Connection Failures,” Proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies pp. 329-337, April 2001. [7] M. Allman, K. Christensen, B. Nordman, and V. Paxso n, “Enabling an Energy-Efficient Future Internet Through Selectively Connected End Systems, ” Proceedings of the 6th ACM Workshop on Hot Topics in Networks November 2007. [8] AMD Magic Packet Technology, 2009. URL: http://www. white_papers_and_tech_docs/20213.pdf. [9] Austin Group, Single Unix specifications, shell and utilities: grep, 2008. URL: http://www. html. [10] R. Baeza-Yates, “Algorithms for String Matching: A Survey,” ACM SIGIR Forum Vol. 23, No. 34, pp. 34-58, April 1989. [11] R. Baeza-Yates and B. Ribeiro-Neto, “ Modern Information Retrieval ,” First Edition, Addison Wesley, 1999. [12] L. Barroso and U. Hlzle, “The Case for Energy-Prop ortional Computing,” Computer Vol. 40, No. 12, pp. 33-37, December 2007. [13] L. Benini, A. Bogliolo, and G. De Micheli, “A Surve y of Design Techniques for System Level Dynamic Power Management,” IEEE Transactions on Ver y Large Scale Integration (VLSI) Systems, Vol. 8, No. 3, pp. 299-316, June 2000. [14] Big Fix Incorporated, 2009. URL: http://www.bigfix. com/.

PAGE 141

130 [15] B. Bloom, “Space/Time Tradeoffs in Hash Coding with Allowable Errors,” Communications of the ACM Vol. 13, No. 7, pp. 422-426, July 1970. [16] F. Bonomi, M. Mitzenmacher, R. Panigrahy, S. Singh, and G. Varghese, “An Improved Construction for Counting Bloom Filters,” Proceedings of the 14th Annual European Symposium on Algorithms pp. 684-695, September 2006. [17] R. Boyer and J. Moore, “A Fast String Searching Alg orithm,” Communications of the ACM Vol. 20, No. 10, pp. 762-772, October 1977. [18] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. She nker, “Web Caching and Zipf-like Distributions: Evidence and Implications,” Proceedings of the 18th IEEE Conference on Computer Communications pp. 126-134, April 1999. [19] J. Broder, M. Kojo, J. Griner, G. Montenegro, and Z Shelby, “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations,” RF C-3135, June 2001. [20] A. Broder and M. Mitzenmacher, “Network Application s of Bloom Filters: A Survey,” Internet Mathematics Vol. 1, No. 4, pp. 485-509, 2004. [21] S. Carl-Mitchell and J. S. Quarterman, “Using ARP t o Implement Transparent Subnet Gateways,” RFC1027, October 1987. [22] Cisco Systems, “Cisco Unified IP Phones: Conserve E nergy with Intelligent Power Allocation,” White Papers, 2008. URL: /prod/collateral/voicesw/ps6788/phones/ ps379/white_paper_c11-481292.html. [23] Cisco Systems, 2009. URL: [24] H. M. Chong and H. S. Matthews, “Comparative Analys is of Traditional Telephone and Voiceover-Internet Protocol (VoIP) Systems,” IEEE International Symposium on Electronics and the Environment pp. 106-111, May 10, 2004. [25] K. Christensen and F. Gulledge, “Enabling Power Man agement for Network-Attached Computers,” International Journal of Network Management Vol. 8, No. 2, pp. 120-130, March/April 1998. [26] K. Christensen, B. Nordman, and R. Brown, “Power Ma nagement in Networked Devices,” Computer Vol. 37, No. 8, pp. 91-93, August 2004. [27] K. Christensen, A. Roginsky, and M. Jimeno, “A New Analysis of the False-Positive Rate of a Bloom Filter,” submitted to Information Processing Letters 2009. [28] K. Christensen, C. Gunaratne, B. Nordman, and A. Ge orge, “The Next Frontier for Communications Networks: Power Management,” Computer Communications Vol. 27, No. 18, pp. 1758-1770, December 2004. [29] J. Chu, K. Labonte, and B. Levine, “Availability an d Locality Measurements of Peer-to-Peer File Systems,” Proceedings of SPIE ITCom: Scalability and Traffic Control in IP Networks II Vol. 4868, pp. 310-321, July 2002. [30] Climate Savers Computing, 2009. URL: http://www.cli [31] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein “ Introduction to Algorithms ,” Second Edition, The MIT Press, 2001.

PAGE 142

131 [32] Z. Czech, G. Havas, and B.Majewski, “Perfect Hashin g,” Theoretical Computer Science Vol. 182, No. 1-2, pp. 1-143, August 1997. [33] S. Dharmapurikar, P. Krishnamurthy, T.S. Sproull, a nd J.W. Lockwood, “Deep Packet Inspection Using Parallel Bloom Filters,” IEEE Micro Vol. 24, No. 1, pp. 52-61, January/February 2004. [34] ECMA International, “TC32-TG21 – Proxying Support f or Sleep Modes.” URL: -M.htm. [35] R. Ekwall, P. Urban, and A. Schiper, “Robust TCP Co nnections for Fault Tolerant Computing,” Proceedings of the 9th International Conference on Parallel and Distributed Systems pp. 501508, December 2002. [36] C. Ellis, “The Case for Higher Level Power Manageme nt,” Proceedings of the 7th Workshop on Hot Topics in Operating Systems pp. 162-167, March 1999. [37] ENERGY STAR, 2009. URL: [38] Energy Information Administration (EIA), 2009. URL: [39] K. Fall, “A Delay-Tolerant Network Architecture for Challenged Internets,” Proceedings of the ACM SIGCOMM pp. 27-34, August 2003. [40] L. Fan, P. Cao, J. Almeida, and A. Broder, “Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol,” IEEE/ACM Transactions on Networking Vol. 8, No. 3, pp. 281-293, June 2000. [41] L. Fan, P. Cao, and J. Almeida, “Bloom Filters – Th e Math,” 2009. URL: ~cao/papers/summary-cache/node8.html. [42] Federal Information Processing Standards, “Secure H ash Standard,” Publication 180-1 1995. URL: [43] M. Fetscherin and S. Zaugg, “Music Piracy On Peer-t o-Peer Networks,” Proceedings of the IEEE International Conference on e-Technology, e-Commerc e and e-Service pp. 431-440, March 2004. [44] S. Fide and S. Jenks, “A Survey of String Matching Approaches in Hardware,” Technical Report TR SPDS 06-01, University of California Irvine, M arch 2006. [45] M. Fredman, J. Komls, and E. Szemerdi, “Storing a Sparse Table with O(1) Worst Case Access Time,” Journal of the ACM Vol. 31, No. 3, pp. 538-544, July 1984. [46] “Gartner Estimates ICT Industry Accounts for 2 Perc ent of Global CO2 Emissions,” Gartner Group Press Release, 2007. URL: http://www.gartner. com/it/page.jsp?id=503867. [47] Gnutella Protocol Specification Version 0.4, 2001. URL: gnutella_protocol_0.4.pdf. [48] Gnutella Protocol Specification Version 0.6, June 2 002. URL: src/rfc-0_6-draft.html. [49] Google Sparse Hash Table. URL: om/p/google-sparsehash/. [50] Green Computing Impact Organization, 2009. URL: htt p:// [51] Greenhouse Gas Equivalencies Calculator, EPA. URL:

PAGE 143

132 [52] S. Guha, N. Daswani, and R. Jain, “An Experimental Study of the Skype Peer-to-Peer VoIP System,” Proceedings of International Workshop on Peer-To-Pe er Systems February 27, 2006. [53] C. Gunaratne, K. Christensen, and B. Nordman, “Mana ging Energy Consumption Costs in Desktop PCs and LAN Switches with Proxying, Split T CP Connections, and Scaling of Link Speed,” International Journal of Network Management Vol. 15, No. 5, pp. 297-310, September/October 2005. [54] M. Gupta and S. Singh, “Greening of the Internet,” Proceedings of the 2003 ACM SIGCOMM pp. 19-26, August 2003. Revised version (2004) URL: htt p:// sigcomm03.pdf. [55] M. Hefeeda and O. Saleh, “Traffic Modeling and Prop ortional Partial Caching for Peer-to-Peer Systems,” IEEE/ACM Transactions on Networking Vol. 16, No. 6, pp. 1447-1460, December 2008. [56] R. Hogg and A. Craig, “ Introduction to Mathematical Statistics ,” Fifth Edition, Prentice-Hall, 1995. [57] IEEE 802.11 Wireless LAN Medium Access Control and Physical Layer Specification, 2009. URL: ml. [58] D. Ilie and A. Popescu, “Statistical Models for Gnu tella Signaling Traffic,” The International Journal of Computer and Telecommunications Networki ng Vol. 51, No. 17, pp. 4816-4835, December 2007. [59] Intel Corporation, “Active Management Technology.” URL: platform-technology/intel-amt/index.htm. [60] Intel Corporation, “Remote Wake Technology.” 2009. URL: technology/chipset/remotewake.htm. [61] Intel Corporation, “Intel vPro Technology.” 2009. U RL: vpro/index.htm. [62] International Energy Agency, “ Gadgets and Gigawatts: Policies for Energy Efficien t Electronics ,” First Edition, OECD Pulishing, 2009. [63] V. Jacobson, C. Lores, and S. McCanne, “PCAP Pack et Capture Library,” 2002. URL: [64] R. Jain, “ The Art of Computer Systems Performance Analysis ,” First Edition, John Wiley & Sons, 1991. [65] R. Jennings, E. Nahum, D. Olshefski, D. Saha, Z-Y. Shae, and C. Waters, “A Study of Internet Instant Messaging and Chat Protocols,” IEEE Network pp. 16-21, July/August 2006. [66] Y.-K. Jeong, I. Han, and K.-R. Park, “A Network Lev el Power Management for Home Network Devices,” IEEE Transactions on Consumer Electronics Vol. 54, No. 2, pp. 487-493, May 2008. [67] M. Jimeno and K. Christensen, “A Prototype Power Ma nagement Proxy for Gnutella Peer-to-Peer File Sharing,” Proceedings of the IEEE Conference on Local Compute r Networks pp. 210-212, October 2007. [68] M. Jimeno and K. Christensen, “P2P Directory Search : Signature Array Hash Table,” Proceedings of the IEEE Conference on Local Computer Networks pp. 506-508, October 2008.

PAGE 144

133 [69] M. Jimeno, K. Christensen, and B. Nordman, “A Netwo rk Connection Proxy to Enable Hosts to Sleep and Save Energy,” Proceedings of the IEEE International Performance C omputing and Communications Conference pp. 101-110, December 2008. [70] M. Jimeno, K. Christensen, and A. Roginsky, “A Powe r Management Proxy with a New Best-ofN Bloom Filter Design to Reduce False Positives,” Proceedings of the International Performance Computing and Communications Conference pp. 125-133, April 2007. [71] M. Jimeno, K. Christensen, and A. Roginsky, “Two-Ti er Bloom Filter to Achieve Faster Membership Testing,” IET Electronics Letters Vol. 44, No. 7, March 27, 2008. [72] C. E. Jones, K. M. Sivalingam, P. Agrawal, and J. C Chen, “A Survey of Energy Efficient Network Protocols for Wireless Networks,” Wireless Networks, Vol. 7 No. 4, August, 2001. [73] T. Karagiannis, A. Broido, N. Brownlee, K. Claffy, and M. Faloutsos, “Is P2P Dying or Just Hiding?” Proceedings of the IEEE Global Telecommunications C onference Vol. 3, pp. 15321538, December 2004. [74] R. Karp and M. Rabin, “Efficient Randomized Pattern -Matching Algorithms,” IBM Journal of Research and Development Vol. 31, No. 2, pp. 249-260, March 1987. [75] K. Kawamoto, J. Koomey, B. Nordman, R. Brown, M. Pi ette, M. Ting, and A. Meier, “Electricity Used by Office Equipment and Network Equipment in t he U.S.: Detailed Report and Appendices,” Technical Report LBNL-45917 Energy Analysis Department, Lawrence Berkeley National Laboratory, February 1, 2001. URL: http:// [76] K. Kawamoto, Y. Shimoda, and M. Mizuno, “Energy Sav ing Potential of Office Equipment Power Management,” Energy and Buildings Vol. 36, No. 9, pp. 915-923, September 2004. [77] A. Kirsch and M. Mitzenmacher, “Less Hashing, Same Performance: Building a Better Bloom Filter,” Random Structures and Algorithms Vol. 33, No. 2, pp. 187-218, September 2008. [78] J. Koomey, “Estimating Total Power Consumption by S ervers in the U.S. and the World,” Analytics Press February 2007. [79] H-y. Kim and S. Rixner, “TCP Offload Through Connec tion Handoff,” Proceedings of the 2006 EuroSys Conference pp. 279-290, April 2006. [80] S. Kim and Y. Kim, “A Fast Multiple String Pattern Matching Algorithm,” Proceedings of 17th AoM/IAoM Conference on Computer Science 1999. [81] J. Klamra, M. Olsson, K. Christensen, and B. Nordma n, “Design and Implementation of a Power Management Proxy for Universal Plug and Play,” Proceedings of the Swedish National Computer Networking Workshop September 2005. [82] D. E. Knuth, J. H. Morris, Jr., and V. R. Pratt, “F ast Pattern Matching in Strings,” SIAM Journal on Computing Vol. 6, No. 2, pp. 323-350, 1977. [83] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, an d L. Jones, “SOCKS Protocol Version 5,” RFC-1928, March 1996. [84] Limewire LLC, Limewire P2P Application, 2009. URL: [85] E. K. Lua, J. Crowcroft, M. Pias, R. Sharma, and S. Lim, “A Survey and Comparison of Peer-toPeer Overlay Network Schemes,” IEEE Communications Surveys and Tutorials Vol. 7, No. 2, pp. 7293, 2005.

PAGE 145

134 [86] S. Lumetta and M. Mitzenmacher, “Using the Power of Two Choices to Improve Bloom Filters ,” Internet Mathematics Vol. 4, No. 1, pp. 17-33, 2008. [87] Magic Jack, 2009. URL: ndex.asp. [88] M. Meo and F. Milan, “Content Management Policies i n Peer-to-Peer File Sharing Networks,” Proceedings of the IEEE Global Telecommunications C onference pp. 975-979, November 2005. [89] Microsoft, “Full TCP Offload,” 2009. URL: http://ms [90] MinGW Minimalist GNU for Windows, 2009. URL: http :// [91] M. Mitzenmacher, “Compressed Bloom Filters,” IEEE/ACM Transactions on Networking Vol. 10, No. 5, October 2002. [92] M. Mitzenmacher and E. Upfal, “ Probability and Computing: Randomized Algorithms an d Probabilistic Analysis ,” First Edition, Cambridge, 2005. [93] J. Mogul, Boyer-Moore-Gosper Implementation, 1986. URL: unix/volume5/bmgsubs.Z. [94] J. Mullin, “A Second Look at Bloom Filters.” Communications of the ACM Vol. 8, No. 26, pp. 570-571, August 1983. [95] J. Mullin, “Accessing Textual Documents Using Compr essed Indexes of Arrays of Small Bloom Filters,” The Computer Journal Vol. 30, No. 4, pp. 343-348, 1987. [96] Musiclab, BearShare P2P Application, 2009. URL: htt p:// [97] S. Nedevschi, J. Chandrashekar, J. Liu, B. Nordman, S. Ratnasamy, and N. Taft, “Skilled in the Art of Being Idle: Reducing Energy Waste in Network ed Systems,” Accepted for Publication: 6th USENIX Symposium on Networked Systems Design and Im plementation pp. 381-394, April 2009. [98] NetBurner MOD5270 Ethernet Core Module, 2009. URL: [99] G. Newsham and D. Tiller, “The Energy Consumption o f Desktop Computers: Measurement and Saving Potential,” IEEE Transactions on Industry Applications Vol. 30, No. 4, pp. 1065-1072, July/August 1994. [100] B. Nordman and K. Christensen, “Improving the Energ y Efficiency of Ethernet-Connected Devices: A Proposal for Proxying,” White Paper, Ver sion 1.0, Ethernet Alliance, October 2007. [101] B. Nordman and K. Christensen, “Greener PCs for the Enterprise,” IEEE IT Professional Vol. 11, No. 4, pp. 28-37, July/August 2009. [102] B. Nordman and R. Brown, “Networks: Tomorrow’s Big Challenge for IT Energy Use,” Woodrow Wilson Center Workshop on Environment and the Infor mation Economy: Next Steps for Research March 15, 2004. [103] B. Nordman, A. Meier, and M-A. Piette, “PC and Moni tor Night Status: Power Management Enabling and Manual Turn-off,” Technical Report LBNL-46099 Lawrence Berkeley National Laboratory, July 30, 1998. URL: http://repositories

PAGE 146

135 [104] B. Nordman, M. Piette, K. Kinney, and C. Webber, “U ser Guide to Power Management in PCs and Monitors,” Technical Report LBNL-39466 Environmental Energy Technologies Division, Lawrence Berkeley National Laboratory, January 1997 URL: [105] F. Oberholzer and K. Strumpf, “The Effect of File S haring on Record Sales: an Empirical Analysis,” Journal of Political Economy Vol. 115, pp. 1-42, February 2007. [106] OpenWrt: Linux Distribution for Embedded Devices, 2 009. URL: [107] A. Pagh, R. Pagh, and S. Rao, “An Optimal Bloom Fil ter Replacement,” Proceedings of the 16th Annual ACM-SIAM Symposium on Discrete Algorithms pp. 823-829, January 2005. [108] S. Patro and Y. Hu, “Transparent Query Caching in P eer-to-Peer Overlay Networks,” Proceedings of International Parallel and Distributed Processin g Symposium April 2003. [109] “PC Energy Report 2009, United States,” Alliance to Save Energy and 1E Inc., March 2009. URL: [110] A. Perez, “Byte-wise CRC Calculations,” IEEE Micro Vol. 3, No. 3, pp. 40-50, June 1983. [111] R. Poe, “IP PBXs: Features? What About The Price?,” VoIP News, July 21, 2006. [112] “Program Requirement for Computers: Version 5.0,” E PA ENERGY STAR Program, November 14, 2008. URL: c=revisions.computer_spec. [113] Putty: free Telnet/SSH Client, 2009. URL: http://ww [114] J. Roberson, G. Homan, A. Mahajan, B. Nordman, C. W ebber, R. Brown, M. McWhinney, and J. Koomey, “Energy Use and Power Levels in New Monitor s and Personal Computers,” Technical Report LBNL-48581 Lawrence Berkeley National Laboratory, July 23, 2 002. URL: [115] J. Roberson, C. Webber, M. McWhinney, R. Brown, M. Pinckard, and J. Busch, “After-hours Power Status of Office Equipment and Energy Use of Miscellaneous Plug-Load Equipment,” Technical Report LBNL-53729-Revised Energy Analysis Department, Lawrence Berkeley National Laboratory, May 2004. URL: http://enduse.l [116] “Report to Congress on Server and Data Center Energ y Efficiency,” EPA ENERGY STAR Program, U.S. Public Law 109 431 August 2, 2007. [117] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. John ston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol,” RF C-3261, June 2002. [118] K. Roth, F. Goldstein, and J. Kleinman, “Energy Con sumption by Office and Telecommunications Equipment in Commercial Buildings Volume 1: Energy Consumption Baseline,” Arthur D. Little Reference No. 72895-00 January 2002. [119] M. Sanchez, R. Brown, C. Webber, and G. Homan, “Sav ings Estimates for the United States Environmental Protection Agency’s ENERGY STAR Volun tary Product Labeling Program,” Energy Policy Vol. 36, No. 6, pp. 2098-2108, June 2008. [120] S. Saroiu, K. Gummadi, and S. Gribble, “Measuring a nd Analyzing the Characteristics of Napster and Gnutella Hosts,” Multimedia Systems Vol. 9, No. 2, pp. 170-184, August 2003.

PAGE 147

136 [121] K. Shanmugasundaram, H. Brnnimann, and N. Memon, “ Payload Attribution via Hierarchical Bloom Filters,” Proceedings of the 11th ACM Conference on Computer and Communications Security pp. 31-41, October 2004. [122] E. Shih, P. Bahl, and M. Sinclair, “Wake on Wireles s: An Event Driven Energy Saving Strategy for Battery Operated Devices,” Proceedings of the 8th Annual International Confere nce on Mobile Computing and Networking pp. 160-171, September 2002. [123] C. Silverstein, “A Practical Perfect Hashing Algori thm,” DIMACS Series in Discrete Mathematics and Theoretical Computer Science Vol. 59, pp. 23-47, 2002. [124] SJ Labs, 2009. URL: l. [125] “SMART 2020: Enabling the Low Carbon Economy in the Information Age,” The Climate Group, June 19, 2008. URL: [126] J. Sorber, N. Banerjee, M. Corner, and S. Rollins, “Turducken: Hierarchial Power Management for Mobile Devices,” Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services pp. 261-274, June 2005. [127] K. Sripanidkulchai, “The Popularity of Gnutella Que ries and its Implications on Scalability,” Technical Report, February 2001. URL: http://www.cs gnutella.html. [128] G. Stephen, “ String Searching Algorithms ,” First Edition, World Scientific Publishing Co., 1994. [129] D. Stutzbach and R. Rejaie, “Understanding Churn in Peer-to-Peer Networks,” Proceedings of the 6th ACM SIGCOMM Conference on Internet Measurement pp. 189-202, October 2006. [130] D. Stutzbach, S. Zhao, and R. Rejaie, “Characterizi ng Files in the Modern Gnutella Network,” Multimedia Systems Vol. 13, No. 1, pp. 35-50, September 2007. [131] The Energy Efficient Internet Project, University o f South Florida and University of Florida, 2009. URL: html. [132] The Institute for Energy Efficiency, University of California Santa Barbara, 2009. URL: [133] The Tolly Group, “Evaluation of Power Consumption f or ShoreTel vs. Cisco Unified Communication,” October 2008. URL: http://www.shor downloads/tolly_report_shoretel_power_usage.pdf. [134] S. Tomo, “Srelay: A Free SOCKS Server for Unix,” 20 03. URL: [135] Tpad, 2009. URL: [136] Universal Plug and Play Specification, v1.0, 2002. URL: [137] VERDIEM – Power Management for PC Networks, Verdiem Corporation, 2009. URL: [138] C. Webber, J. Roberson, R. Brown, C. Payne, B. Nord man, and J. Koomey, “Field Surveys of Office Equipment Operation Patterns,” Technical Report LBNL-46930 Lawrence Berkeley National Laboratory, September 2001. URL: http://en

PAGE 148

137 [139] A. Whitaker and D. Wetherall, “Forwarding without l oops in Icarus,” Proceedings of the 5th IEEE Conference on Open Architectures and Network Progra mming pp. 63-75, June 2002. [140] B. Woodard, “Customizable TCP Backoff Patch,” 2006. URL: [141] T. Ylonen and C. Lonvick, “The Secure Shell (SSH) A uthentication Protocol,” RFC-4252, January 2006. [142] V. Zandy and B. Miller, “Reliable Network Connectio ns,” Proceedings of the 8th ACM International Conference on Mobile Computing and Ne tworking pp. 95-106, September 2002. [143] Y. Zhang and S. Dao, “A ‘Persistent Connection’ Mod el for Mobile and Distributed Systems,” Proceedings of the 4th International Conference on Computer Communications and Networks pp. 300-307, September 1995. [144] M. Zhong, P. Lu, K. Shen, and J. Seiferas, “Optimiz ing Data Popularity Conscious Bloom Filters,” Proceedings of 27th ACM Symposium on Principles of Distributed Computing pp. 355364, August 2008.

PAGE 149

About the Author Miguel Jimeno received his B.Sc. in Systems Enginee ring degree from Universidad del Norte, Barranquilla, Colombia, in 2002. He is presently a Ph.D. candidate in the Department of Computer Scien ce and Engineering, at the University of South Florida Tampa, Florida. His research interests are in performance evaluation of computer networks, and ne twork connectivity proxying of computers. He is a student member of the IEEE.


Download Options

Choose Size
Choose file type
Cite this item close


Cras ut cursus ante, a fringilla nunc. Mauris lorem nunc, cursus sit amet enim ac, vehicula vestibulum mi. Mauris viverra nisl vel enim faucibus porta. Praesent sit amet ornare diam, non finibus nulla.


Cras efficitur magna et sapien varius, luctus ullamcorper dolor convallis. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Fusce sit amet justo ut erat laoreet congue sed a ante.


Phasellus ornare in augue eu imperdiet. Donec malesuada sapien ante, at vehicula orci tempor molestie. Proin vitae urna elit. Pellentesque vitae nisi et diam euismod malesuada aliquet non erat.


Nunc fringilla dolor ut dictum placerat. Proin ac neque rutrum, consectetur ligula id, laoreet ligula. Nulla lorem massa, consectetur vitae consequat in, lobortis at dolor. Nunc sed leo odio.