Characterizing and Conserving Energy Consumption in Mobile P2P Systems

1
Characterizing and Conserving Energy Consumption
in Mobile P2P Systems

• Selim Gürün
• Priya Nagpurkar
• Ben Zhao
• Department of Computer Science
• U.C. Santa Barbara

1st International Workshop on Decentralized
Resource Sharing in Mobile Computing and
Networking ACM MOBISHARE, Los Angeles,
CA September 25, 2006
2
Breaking News
.... The U.S. software maker also boasted that
Zune has what iPod doesnt have, music-sharing
capability. Using its Wi-Fi wireless function,
Zune users will be able to detect one another and
then share songs, recordings and pictures
wirelessly. ..

• How to implement P2P applications/routing stacks
  on resource-constrained mobile devices?

3
Underlying Research Questions

• What are the resource constraints of mobile
  devices and what makes P2P more challenging on
  such devices?
• How do current P2P protocols utilize mobile
  device resources, especially the limited energy
  supply?
• Can we implement a mobile-friendly,
  energy-efficient P2P application on such devices?
  How?

4
Decentralization-Induced Challenges on Mobile
Devices

• Mobile devices Very diverse
• Linux wristwatches, multi-core laptops and
  anything in between
• Our platform smart-phone and PDA like devices
• Energy constraints on mobile devices introduce
  unique challenges to distributed applications
• In Client-Server architecture clients offload
  tasks to wall-powered, resource-rich servers
• Easier to implement disconnected operation for
  client
• P2P nodes provide services to fellow nodes no
  servers
• Nodes have to be awake for providing services
• Always-on, always connected assumption hurts
  mobile P2P

5
Underlying Research Questions

• What are the constraints of mobile devices and
  what makes P2P more challenging on such devices?
• Energy is limited
• Always-on nature of servers restricts sleep
  options
• How do current P2P protocols utilize mobile
  device resources, especially the limited energy
  supply?
• Can we implement a mobile-friendly,
  energy-efficient P2P application on such devices?
  How?

6
P2P On Resource Restricted Devices

• Initial idea was
• To evaluate the performance of a
  proof-of-concept P2P application on a mobile
  device
• Not as trivial as it seems!
• Many P2P protocols are implemented with no
  embedded platforms in mind
• Simmud
• Peer-to-peer multiplayer game from UPenn.
• Back-ported to JRE 1.3 (inetsocketaddress, etc.)
• Not stable in our run-time environment
• FreePastry, Tapestry
• Extensive use of non-blocking IO
• Back-porting not feasible at all
• Simpastry C

7
Chimera A Light-Weight P2P Protocol

• Light-weight, structured P2P protocol based on
  Tapestry
• Developed in UCSB-CURRENT lab
• Implemented in C as an application library
• Easy to port Requires (only) OpenSSL, arm-gcc is
  fine!
• Chimera-CHAT
• A generic, command-line based chat application
• Forwards messages based on destination hosts
  node identifier
• Chimera Internals
• Borrows many concepts from Tapestry, e.g.
  circular address space
• Prefix based routing O(log(n)) hops in average
• Nodes keep links to nodes that are in close
  proximity for stability

8
Chimera Routing
3223
0230
3123
3011
3003
3001
2333
2331
1023
2011
Each node keeps a leafset of neighbors and a set
of routing nodes.
9
Chimera Internals

• Multi-threaded
• Uses Pthread library
• Multiple worker threads handle routing, message
  send/receive
• Chimera_check_leafset
• Runs as a separate thread
• Pings each member of the leafset every 20 seconds
• Exchanges leafsets with the leafset nodes every
  60 seconds
• Current leafset size 8
• Chimera_route
• Implements routing function
• If a node has message delivery rate lt 0.3, it is
  removed from routing table
• A removed node has to wait 30 seconds before it
  can be accepted to the network again (to provide
  network stability)

10
Stargate and Our Evaluation Bench
PowerTool
11
CPU Load Across Scenarios
12
Wireless Energy Use Across Experiments
13
Chimera Energy Consumption Results

• CPU utilization is low
• We do not observe any significant increase in CPU
  load when we increase network size from 25 nodes
  to 200
• Techniques like voltage/clock scaling can reduce
  CPU energy consumption significantly
• Analyzes with much larger networks pending!
• Wireless utilization is also low
• Idle 70 of the time, in average
• Better utilization of wireless interface needed
• Compared results to TMSNC
• A command line based MSN client
• Not a substantial difference

14
Underlying Research Questions

• What are the constraints of mobile devices and
  what makes P2P more challenging on such devices?
• Energy
• Always-on assumption (for server functionality)
• How do current P2P protocols utilize mobile
  device resources, especially the limited energy
  supply?
• Most energy wasted in idle state
• No large CPU demand difference between
  client-server and P2P applications
• Can we implement a mobile-friendly,
  energy-efficient P2P application on such devices?
  How?
• Should we depend on physical layer for energy
  savings? Or should we use application layer to
  manage it?

15
Reclaiming Idle Power in 802.11 Ad-Hoc Mode
A
A
D
A
R
P
A
L
A
L
L
A
A Active L Low Power
16
Physical Layer Power Saving Caveats

• Approximate energy savings rate (when idle)
• 1 (ATIM window/Beacon window)
• Real energy savings is lower sleep mode uses
  energy
• (Not good) Each data message requires one ATIM
  message an ACK
• ATIM window too small-gt not enough time for
  ATIM broadcast, too large -gt not enough time for
  data frames
• Cisco Aironet parameters
• Beacon period 20 to 1000 milliseconds, default
  100
• ATIM window 5 to 60 milliseconds, default 5
• The best beacon and ATIM parameters are
  application specific!
• Can we do better than this, if we let P2P routing
  protocols adaptively choose best parameters?

17
Wireless Card Sleep Policy
Can we use Chimera network manager for better
energy savings?
Wi gt 1 seconds
Active
Low Power
Wt gt 3 seconds
Wi Wireless Idle time Wt Wake up timeouts for
checking network state
18
Energy Savings Impact of Various Wi
42 savings
26 savings
19
Average Delay of Various Wi
20
Related Work

• Numerous energy saving protocols exist for ad-hoc
  networks
• IEEE 802.11 ad-hoc power savings protocol
• SPAN
• Jung et al. (Texas AM)
• Power profiling setups used in prior studies to
  characterize mobile power consumption
• Powerscope
• Other P2P Systems for mobile networks
• JXTA
• Jabber
• RockyRoad

21
Summary Future Directions

• Our Goal A resource-aware, energy efficient P2P
  protocol
• Tapestry like Java based implementations not
  suitable for mobile platforms
• Chimera Surprisingly efficient!
• Physical layer power saving protocols are useful
  but not enough!
• More savings possible by providing more feedback
  from P2P protocol later to physical layer.
• A lot of work is ongoing
• Compare power saving methods
• Evaluate in much larger mobile communities

22
Backup Slides
23
P2P on Mobile Systems

• Peer-to-peer paradigm
• Decentralized, highly-scalable,
• fault-tolerant networks

P2P

• P2P nodes are both clients and servers depending
  on context of operation.

• Mobile Systems
• More widespread than ever
• Wireless networks everywhere

• How to implement P2P applications/routing stacks
  on mobile devices when there are so many resource
  constraints?

24
Wireless Card Power Consumption
25
Most Expensive Functions
26
Jabber
In jabber, the peers communicate to each other
using servers. Not exactly a P2P architecture
Jabber Server
Jabber Server
Mobile Jabber Client
Mobile Jabber Client
27
JXTA
In JXTA, the peers has to ask rendezvous servers
who provides the service.
Rendezvous Server
Rendezvous Server
Service advertisement
Service Discovery
Mobile JXTA Peer
Mobile JXTA Peer
28
RockyRoad
In RockyRoad, routing and service discovery
protocols are designed by the developer.
RockyRoad is an API.
Rendezvous Server
Rendezvous Server
Developer Specific
Service advertisement
Service Discovery
Default Protocols Routing Forwarding Searching
Broadcasting
Mobile RockyRoad Peer
Mobile RockyRoad Peer
Support for J2ME and J2SE exist!.
29
SPAN

• SPAN sits on top of physical layer. It tries to
  minimize the number of nodes that have their
  wireless NIC turned on, while still maintaining a
  connected network

Localized decisions battery and of pairs that
it can connect