1 / 85

Salman Abdul Baset salman@cs.columbia Thesis defense October 29, 2010

Protocol and System Design, Reliability, and Energy Efficiency in Peer-to-Peer Communication Systems. Salman Abdul Baset salman@cs.columbia.edu Thesis defense October 29, 2010. Motivation and Contributions. Client-server communication system. node D. node C. ip addr A, B, C, D.

gianna
Download Presentation

Salman Abdul Baset salman@cs.columbia Thesis defense October 29, 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protocol and System Design, Reliability, and Energy Efficiency in Peer-to-Peer Communication Systems Salman Abdul Baset salman@cs.columbia.edu Thesis defense October 29, 2010

  2. Motivation and Contributions

  3. Client-server communication system node D node C ip addr A, B, C, D proxy server / registrar media relay server register (ip addr D) Up to 40% InternetVoIP calls need media relays register (ip addr C) Scaling for millions of users economic costs - servers - bandwidth - management register (ip addr A) register (ip addr B) signaling signaling media traffic (voice, video, IM) media traffic (voice, video, IM) NAT / firewall NAT / firewall node A node B

  4. What is a p2p communication system? node D node C media traffic over TCP (voice, video, IM) media traffic (voice, video, IM) ip addr A ip addr B,C signaling register (ip addr D) ip addr of B register (ip addr C) What is the ip address of B register (ip addr A) register (ip addr B) signaling ip addr D media traffic (voice, video, IM) NAT / firewall NAT / firewall node A node B

  5. ChallengesDesigning, building, and analyzing p2p communication systems • Protocol and system design • can we design a p2p communication protocol for diverse deployments such as ad hoc, enterprise, and Internet? • Reliability • are p2p communication systems reliable (dropped calls)? • Session quality • what is the quality of real-time traffic over TCP or through other nodes? • Energy efficiency • are p2p communication systems more energy efficient than client-server? • Measurement • how can we analyze the performance of p2p systems such as Skype?

  6. Contributions • Protocol and system design • first standardized, and interoperable protocol for building p2p communication systems • Peer-to-peer protocol (P2PP) and RELOAD [IETF I-D’s 2007 and 2010] • OpenVoIP – a P2PP proof-of-concept system [SIGCOMM’08 demo] • Reliability • a simple model to investigate the reliability of p2p communication systems [IPTCOMM’10] • Session quality • a comprehensive study of TCP’s feasibility for real-time traffic [SIGMETRICS’08] • Energy efficiency • first energy-efficiency study of VoIP systems[GreenNetworking’10] • Measurement • novel techniques for analyzing the workings of p2p communication systems [GI’08,Infocom’06]

  7. In this talk • Protocol and system design • first standardized, and interoperable protocol for building p2p communication systems • Peer-to-peer protocol (P2PP) and RELOAD [IETF I-D’s 2007 and 2010] • OpenVoIP – a P2PP proof-of-concept system [SIGCOMM’08 demo] • Reliability • a simple model to investigate the reliability of p2p communication systems [IPTCOMM’10] • Session quality • a comprehensive study of TCP’s feasibility for real-time traffic [SIGMETRICS’08] • Energy efficiency • first energy-efficiency study of VoIP systems[GreenNetworking’10] • Measurement • Novel techniques for analyzing the workings of p2p communication systems [GI’08,Infocom’06]

  8. Related work • Protocol and system design • Skype proprietary commercial system • Distributed Hash Table (DHT) design [Rhea05Sigcomm] • nodes on Planet Lab run OpenDHT and store data • no relaying service, only storage • P2PP allows nodes with ‘good’ connectivity to provide storage and relaying service, not just Planet Lab nodes • feasibility of making Session Initiation Protocol (SIP) peer-to-peer [Bryan06AAA, Singh06NOSSDAV] • explored the feasibility of distributing SIP registrar • protocol tied to SIP, could not be used by non-SIP protocols • P2PP can be used by non-SIP protocols

  9. Related work • Reliability analysis • Node isolation [Leonard07ToN] • probability that a node outlives its neighbors • I build a framework for understanding reliability of calls • Minimizing churn [Godfrey06Sigcomm] • not sufficient • I devise techniques to improve reliability • Energy efficiency study • p2p is more energy efficient than client-server for file-sharing [Valancius09CoNEXT, Nedevschi08Hotpower] • I analyze if it is also the case with VoIP systems • I also study where are energy inefficiencies in VoIP systems

  10. Outline • Introduction • Related work • Protocol and system design • Reliability analysis • Energy efficiency study of VoIP systems • Conclusion

  11. Protocol and system design Goal • design open, standardized, and interoperable p2p communication protocol for building systems • that distribute the functionality of proxy server, registrar, and media relay server to end-points • that work in diverse deployments, e.g., ad hoc, enterprise, Internet • that run on heterogeneous devices • that are extensible

  12. Requirements node D node C • Multiple overlay algorithms • Node heterogeneity • NAT and firewall traversal • Bootstrap and join desktop Emergency p2p Internet p2p portable NAT / firewall NAT / firewall new node node A node B

  13. Requirements ip addr A node D node C • Multiple overlay algorithms • Node heterogeneity • NAT and firewall traversal • Bootstrap and join • Resilience • Message reliability • Request routing • Security • Data model • Monitoring and diagnostics message node A node B

  14. Peer-to-peer protocol (P2PP) SIP API P2PP NAT TLS / SSL • Protocol stack of a P2PP node • A request / response binary protocol • protocol methods • Reuses existing protocols • Not a new DHT or bit-encapsulation • How does it meet the requirements? Published in IETF P2PSIP working group

  15. Meeting the requirements (1) node D node C • Multiple overlay algorithms Multiple overlay algorithms • LookupPeer method • find a peer in the overlay to fill node’s routing table • method customized for each overlay algorithm • Chord (X+2i,X+2i+1), Kademlia (XOR), etc. • ExchangeTable method • exchange routing tables • KeepAlive method • check liveness node A node B In another overlay algorithm In one overlay algorithm

  16. Meeting the requirements (2) node D node C • Multiple overlay algorithms • Node heterogeneity • NAT traversal • Bootstrap and join • Node heterogeneity • peers (super nodes) and clients (ordinary nodes) • peer vs. client decision left to the system designer • NAT traversal • a node encodes its host, NAT, and a relay IP address in every message • then performs connectivity checks • Bootstrap and join • Bootstrap, Join, Leave methods • Bootstrap server portable node A node A node B NAT / firewall NAT / firewall bootstrapserver new node

  17. Meeting the requirements (3) node D node C • Multiple overlay algorithms • Node heterogeneity • NAT traversal • Bootstrap and join • Resilience • Message reliability • Request routing • Resilience • KeepAlive method • Message reliability • hop-by-hop, e2e • ACK-based mechanismfor unreliable transports • Request routing • recursive vs. iterative • specified per message or per overlay message node A node B

  18. Meeting the requirements (4) Resource-ID sb@cs.columbia.edu Type 1 Phone record Sub-type 1 Sub-type 2 Desktop phone Value Value IP addr:port Signature 386af6194c4d node D node C • Multiple overlay algorithms • Node heterogeneity • NAT traversal • Bootstrap and join • Resilience • Message reliability • Request routing • Data model • Security • Monitoring and diagnostics • Data model • Publish, Lookup, Replicate methods • flexible data model • key / type-value pairs • data integrity (hash) • Security • identity (user, nodes) • enrollment server, X.509 certificates • Enroll method • message confidentiality • TLS, DTLS • Monitoring and diagnostics gathering (e.g., CPU, uptime) • GetDiagnostics method node A node B enrollment server

  19. P2PP – summary • Design summary • methods for implementing the common aspects of overlay algorithms • overlay algorithm defines components of specific methods • separation of mechanism vs. policy • P2PP now part of RELOAD protocol being standardized in the IETF • Limitations • not a replacement for network file systems • no permissions, store ephemeral data • does not replace delay-tolerant network protocols • Does it work in practice?

  20. OpenVoIP – a P2PP proof of concept bootstrap server monitoring server / Google maps Overlay 2 node C node D Overlay 1 node B node A NAT / firewall NAT / firewall node F node E SIGCOMM (demo) 2008

  21. OpenVoIP – key facts and lessons learned • 1000 node network on ~500 PlanetLab machines • DHTs: Kademlia, Bamboo, Chord • App: Windows XP / Vista, Linux • Code used and modified by Ericsson Labs, Nokia Labs, Telecom Italia, and many universities around the world • Lessons learned • DHT specific part is only 10-15% of the total code • want to test a new p2p protocol? • use the library provided

  22. Outline • Introduction • Related work • Protocol and system design • Reliability analysis • Energy efficiency study of VoIP systems • Conclusion

  23. Reliability of P2P comm. systems • Reliability=Proportion of completed calls (e.g., 99.9%) • Goals • understand reasons for call failure • devise techniques to address them • Reasons for call failure • (1) distributed search fails to find online callee • (2) distributed search fails to find a suitable relay • (3) relay fails during voice/video session Recall: up to 40% VoIP calls in the Internetneed relaying IPTCOMM’2010

  24. Understanding reliability of relayed calls (1) For desired reliability, minimum relays k per call? • Model • when ith relay fails, call is switched to (i+1)st relay which is instantly selected from the global pool of all relays. • Ri residual lifetime of a relay candidate (i.i.d.) • let D denote the call duration. D Rk-1 Rk R1 k 1 2 k-1 99.9% Qualitatively: if node lifetime >>> call duration, small k and vice versa

  25. Understanding reliability of relayed calls (2) Exponential node lifetimes Skype node lifetimes 95% of Skype relay calls last less than 1 hour Mean node lifetime Mean call duration lifetimes approximated as pareto For one hour Skype calls, minimum of 3 relays needed to maintain 99.9% success rate What if the system does not have enough relays?

  26. Approaches for addressing the reliability of relayed calls • Approaches • No-replacement (NR) • select k relays in the beginning of a call • do not replace failed relays • With-replacement (WR) • select k relays in the beginning of a call • replace failed relays after μ • Skype uses 2-relay with-replacement scheme • Model • complicated for arbitrary distributions • For exponential lifetimes, I used markov analysis pure death process (1) Why not make k arbitrary large? (2) Isn’t WR always better NR?

  27. Comparing the approaches for reliability of relayed calls • Why not make k arbitrary large? • i.e., add more relays? • diminishing returns • liveness checks overhead (2) Isn’t WR always better than NR? • yes, but the percentage improvement gains vary • depends on mean lifetime, call duration, repair time Skype: 2 relay with-replacement search time=60s Skype mean=12 hours Median=4 hours

  28. Outline • Introduction • Related work • Protocol and system design • P2PP • OpenVoIP • Reliability analysis • Energy efficiency study of VoIP systems • Conclusion

  29. Energy efficiency study • Goals (1) Where is energy consumed in IP-telephony systems? (2) How do different design choices (p2p vs. client-server) affect the energy consumption? (3) How can we make IP-telephony more energy-efficient? • IP-communication system classification • p2p vs. client-server • PSTN replacement always on, providing emergency calling vs. communication addendum GreenNetworking’2010

  30. Sources of energy consumption in IP-communication systems • End-point • handsets • VoIP conversion boxes • PCs • NATs and firewalls • Core • signaling / directory • media relaying • PSTN / mobile gateways • cooling • power utilization efficiency (PUE) • ratio of data center power draw to IT power draw • Network • joules per bit

  31. Approach Data (from client-server VoIP provider) 100K users (mostly business) 15 calls per second (CPS) peak ~5K calls in system NAT keep-alive traffic all calls relayed Modeling P2P Client-server • Measurements • End points • desktop clients • laptop clients • hardware SIP phones • Skype peers • Core • SIP server • relay server

  32. (1) Where is energy consumed? PSTN replacement VoIP servers consume less than 0.06% of total! 1 server 500k users ~200W 1 servers 50k simultaneous calls ~200W 500k phones, each phone ~5-7W even after a redundancy factor of 2, and conservative PUE of 2! Make PSTN replacement green? Reduce end-device power energy consumption

  33. Where is energy consumed? Non-PSTN replacement Typically run on desktops, laptops as soft phones If soft phone draws little additional power still likely that end-device biggest component but may not dominate consumption If users leave PCs on just as phones possibly even worse than PSTN!

  34. (2) Client-server vs. peer-to-peer? • Client-server model • C/S power consumption pc/s= #servers * Watts/server *redundancy factor * PUE • P2P model • S super nodes active • psWatts/super node P2P more energy efficient when: S *ps < pc/s • One active super node per relayed call (Skype) • 30% calls relayed • super nodes 1.5% of total nodes ps < 162mW P2P may consume more than client-server!

  35. (3) How can we make IP-telephony greener? Phones make phones energy efficient LCD, processor, Wake-on-LAN for phones? PCs wakeup on receiving calls NATs and firewalls eliminate NATs (IPv6 – at least in theory)

  36. Conclusion • Protocol and system design • first standardized, and interoperable protocol for building p2p communication systems • Peer-to-peer protocol (P2PP) and RELOAD [IETF I-D’s 2007 and 2010] • OpenVoIP – a P2PP proof-of-concept system [SIGCOMM’08 demo] • Reliability • a simple model to investigate the reliability of p2p communication systems [IPTCOMM’10] • Session quality • a comprehensive study of TCP’s feasibility for real-time traffic [SIGMETRICS’08] • Energy efficiency • first energy-efficiency study of VoIP systems[GreenNetworking’10] • Measurement • novel techniques for analyzing the workings of p2p communication systems [GI’08,Infocom’06]

  37. Publications Journal and magazine • Eli Brosh, Salman A. Baset, Vishal Mira, Dan Rubenstein, and Henning Schulzrinne, The Delay-Friendliness of TCP for Real-time Traffic, IEEE/ACM Transactions on Networking, Accepted. • Salman A. Baset and Henning Schulzrinne, Reliability and Relay Selection in Peer-to-Peer Communication Systems, in submission. • Salman A. Baset and Henning Schulzrinne, Making Peer-to-Peer Video Conferencing Work, in submission. Conference and workshop • Salman A. Baset, Joshua Reich, Jan Janak, Pavel Kasparek, Vishal Misra, Dan Rubenstein, and Henning Schulzrinne, How Green is IP-telephony?, in Proc. of SIGCOMM Green Networking workshop, New Delhi, India, August 2010 • Salman A. Baset and Henning Schulzrinne, Reliability and Relay Selection in Peer-to-Peer Communication Systems, in Proc. of IPTCOMM, Munich, Germany, August 2010 (Best paper). • Omer Boyaci, Andrea Forte, Salman A. Baset, and Henning Schulzrinne, vDelay: A Tool to Measure Capture-to-Display Latency and Frame Rate, in Proc. of International Symposium on Multimedia (ISM), San Diego, CA, USA, December 2009. • Katerina Argyraki, Salman A. Baset, Byung-Gon Chun, Kevin Fall, Gianlucca Iannaconne, Allan Knies, Eddie Kohler, Maziar Manesh, Sergiu Nedevschi, and Sylvia Ratnasamy, Can Software Routers Scale, in Proc. of second PRESTO workshop, Seattle, WA, USA, August 2008. • Eli Brosh, Salman A. Baset, Dan Rubenstein, and Henning Schulzrinne, The Delay-Friendliness of TCP, in Proc. of ACM SIGMETRICS, Annapolis, MD, USA, June 2008. • Wookyun Kho, Salman A. Baset, and Henning Schulzrinne, Skype Relay Calls: Measurements and Experiments, in Proc. of IEEE Global Internet Symposium, Phoenix, AZ, USA, April 2008. • Salman A. Baset and Henning Schulzrinne, An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol, in Proc. of IEEE INFOCOM, Barcelona, Spain, April 2006. • Kishore Dhara, Salman A. Baset, Venkatesh Krishnaswamy, Dynamic Peer-To-Peer Overlays for Voice Systems, in Proc. of 3rd IEEE Workshop on Mobile Peer-to-Peer Computing, Pisa, Italy, March 2006. Demo • Omer Boyaci, Andrea Forte, Salman A. Baset, and Henning Schulzrinne, vDelay: A Tool to Measure Capture-to-Display Latency and Frame Rate, in Proc. of International Symposium on Multimedia (ISM), San Diego, CA, USA, December 2009. • Salman A. Baset, Gaurav Gupta, and Henning Schulzrinne, OpenVoIP: An Open Peer-to-Peer VoIP and IM System, in Proc. of SIGCOMM (demo), Seattle, WA, August 2008. Poster • Salman A. Baset, Eli Brosh, Vishal Misra, Dan Rubenstein, and Henning Schulzrinne, Understanding the Behavior of TCP for Real-time Workloads, in Proc. of CoNEXT, Lisbon, Portugal, December 2006. Internet drafts • Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman A. Baset, and Henning Schulzrinne, Resource Location and Discovery (RELOAD), Internet Draft, draft-ietf-p2psip-base-11 (work-in-progress), October 2010. • Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman A. Baset, and Henning Schulzrinne, A SIP Usage for RELOAD, Internet Draft, draft-ietf-p2psip-sip-05 (work-in-progress), July 2010. • Salman A. Baset and Henning Schulzrinne, TCP-over-UDP, Internet Draft, draft-baset-tsvwg-tcp-over-udp-01 (work-in-progress), June 2009. • Salman A. Baset, Henning Schulzrinne, and Marcin Matuszewski, Peer-to-Peer Protocol (P2PP), Internet Draft, draft-baset-p2psip-p2pp-01, November 2007.

  38. References [Bryan06AAA] David A. Bryan, Bruce Lowekamp, and Cullen Jennings, SoSIMPLE: A SIP/SIMPLE based P2P VoIP and IM system, in Proc. of AAA workshop, Orlando, FL, USA, July 2005 [Godfrey06Sigcomm] P. Brighten Godfrey, Scott Shenker, and Ion Stoica, Minimizing churn in distributed systems, in Proc. of SIGCOMM, Pisa, Itlay, August 2006. [Leonard07ToN] Derek Leonard, Zhongmei Yao, Vivek Rai, and Dmitri Loguinov, On lifetime-based node failure and stochastic resilience of decentralized peer-to-peer networks, in IEEE/ACM Transactions on Networking, June 2007. [Nedevschi08Hotpower] Sergiu Nedevschi, Jitendra Padhye, and Sylvia Ratnasamy, Hot data centers vs. cool peers, in Proc. of HotPower, San Diego, CA, USA, December 2008. [Rhea05Sigcomm] Sean Rhea, OpenDHT: A publicly accessible DHT service, PhD thesis, University of California at Berkeley, Berkeley, CA, USA, 2005. [Singh06NOSSDAV] Kundan Singh and Henning Schulzrinne, Peer-to-peer Internet telephony using SIP, in Proc. of NOSSDAV, Stevenson, WA, USA, June 2005. [Valancius09CoNEXT] Vytautas Valancius, Nikolaos Laoutaris, Laurent Massoulie, Christophe Diot, and Pablo Rodriguez, Greening the Internet with nano data centers, in Proc. of CoNEXT, Rome, Italy, December 2009.

  39. Backup

  40. IP-based communication systems Client-server Peer-to-Peer • Basic services • establish voice, video, IM sessions • voicemail • Advanced services • conferencing, telepresence • voicemail to text

  41. Client-server IP communication system SIP registrar / proxy / presence server SIP registrar / proxy server IP-PSTN gateway REGISTER (ip addr) REGISTER (ip addr) (1) signaling (1) signaling (2) media (voice, video, IM) User agent User agent Utopian Internet No NATs or firewalls

  42. SIP registrar / proxy / presence / server media server NAT / firewall NAT / firewall User agent User agent Client-server IP communication system NAT packet packet Src-IP Dst-IP Pub-IP Dst-IP Network Src-IP Pr-IP Pub-IP Dst-IP aka server-reflexive address

  43. P2P: communication vs. file sharing • P2P file-sharing systems • tit-for-tat • open NAT ports • reduce download rate of files for nodes behind NATs • P2P communication systems • no tit-for-tat • opening NAT ports is a hassle • cannot reduce rate, will impact quality

  44. Percentage of VoIP calls in the Internet that need relaying? • the provider knows  • Some client-server VoIP providers relay all calls • 15-20% calls for a commercial client-server IM / VoIP application • Microsoft messenger ~ 40% • 341 relayed calls in 20 days for Skype [Suh05Infocom] ~17 per day for a super node (~50K super nodes) • NAT studies

  45. Protocol and system design

  46. Shared and different aspects Shared aspects • Connectivity • NAT traversal • bootstrap • Resilience • recovery from node churn • Request routing • recursive vs. iterative • parallel vs. sequential • Heterogeneity of nodes • mobile, desktop • super node vs. ordinary node • Security • Identity (user, nodes) • message confidentiality • Data model • addressing, storage, integrity • Message reliability • hop-by-hop, e2e Different aspects • Next-hop determination • depends on the overlay algorithm • Chord, Kademla, Gia, • proximity aware etc. • Methods for implementing the common aspects • Overlay algorithm defines components of specific methods Now part of RELOAD protocol being standardized in the IETF

  47. Peer-to-peer protocol (P2PP) • Now part of RELOAD protocol being standardized in the IETF • Not a new DHT or bit-encapsulation • Geared towards IP telephony but applicable to streaming, VoD etc. • A request / response binary protocol • Shared methods • Join, Leave, Publish, Lookup, KeepAlive etc • Overlay-specific methods • FindPeer, ExchangeTable • Support different overlay algorithms (Chord, Kademlia etc) • Application-level API • Security • enrollment server, X.509 certificates • TLS, DTLS for message confidentiality SIP API P2PP ICE TLS / SSL protocol stack of a node IETF P2PSIP working group

  48. Peer-to-peer protocol (P2PP) • Data model • key / value pairs • data integrity • Monitoring and diagnostics gathering • Node heterogeneity • peers (super nodes) and clients (ordinary nodes) • decision left to the system designer • use of peers as relays • NAT traversal built-in • a node exchanges its host, NAT, and a relay IP address in requests and responses • then uses ICE (interactive connectivity establishment) for NAT traversal • Message reliability • hop-by-hop, e2e

  49. Implementation design } app. pluggability { publish (key, value, callback) callback (resp) lookup (key, callback) Bootstrap Client KadPeer BambooPeer Diagnostic 406 1182 1019 869 630 208 Node 2803 211 Distance Routing table Parser / encoder 2921 Neighbor table Transactions 299 2566 BigInt 3400 NAT Data storage 1946 { Other 2771 multiplatform Sys Transport / timers 1177 821 DTLS TLS Non-DHT LoC 15783 UDP TCP

  50. Why not the ‘best’ DHT? • Is there any such thing as the ‘best’ DHT? • Chord widely cited but not widely deployed • DHTs are parameterized • base, hash algorithm • symmetric vs. asymmetric distance • Chord (modulo) vs. Kademlia • next-hop determination may be purely based on DHTs or a combination of DHT+proximity aware routing • debugging and deployment

More Related