Peer to peer communication services
Download
1 / 46

peer-to-peer communication services - PowerPoint PPT Presentation


  • 394 Views
  • Updated On :

Peer-to-peer Communication Services. Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe. Outline. Research overview Conceptual framework Four stages of p2p systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'peer-to-peer communication services' - Olivia


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Peer to peer communication services l.jpg

Peer-to-peer Communication Services

Henning Schulzrinne, Jae Woo Lee, Salman Baset

Columbia University

Wolfgang Kellerer, Zoran Despotovic

DoCoMo Communications Laboratories Europe


Outline l.jpg
Outline

  • Research overview

  • Conceptual framework

    • Four stages of p2p systems

  • Zeroconf: solution for bootstrapping

    • Overview and example

  • z2z: Zeroconf-to-Zeroconf interconnection

    • Overview, design and implementation

  • Zeroconf for SIP

    • Motivation and overview of the Internet Draft

  • P2P systems for VoIP

  • P2P-SIP

    • Background concepts and overview of current proposals

  • Next step

    • DHT discovery

    • DHT initialization


Current results l.jpg
Current results

  • Conceptual framework: 4 stages of p2p systems

    • Bootstrapping

    • Interconnection

    • Structure formation

    • Growth

  • Zeroconf: solution for bootstrapping

    • Detailed study of Bonjour, Apple’s Zeroconf implementation

    • Internet Draft published on using Zeroconf for SIP

  • z2z: Zeroconf-to-Zeroconf Toolkit

    • Interconnect Zeroconf networks using OpenDHT

    • C++ prototype for proof of concept

    • z2z v1.0: open-source Java implementation on SourceForge

    • Paper submitted to IEEE Globecom’07Workshop on Service Discovery

  • P2PP: generic P2P transport protocol

  • Next step: DHT discovery and initialization

    • How to discover an existing DHT?

    • How to construct a DHT efficiently from scratch?


Four stages of dynamic p2p systems l.jpg
Four stages of dynamic p2p systems

  • Bootstrapping

    • Formation of small private p2p islands

  • Interconnection

    • Connectivity and service discovery between the p2p islands (each represented by a leader)

  • Structure formation

    • DHT construction among the leaders

  • Growth

    • Merger of multiple such DHTs


Zeroconf solution for bootstrapping l.jpg
Zeroconf: solution for bootstrapping

  • Three requirements for zero configuration networks:

    • IP address assignment without a DHCP server

    • Host name resolution without a DNS server

    • Local service discovery without any rendezvous server

  • Solutions and implementations:

    • RFC3927: Link-local addressing standard for 1)

    • DNS-SD/mDNS: Apple’s protocol for 2) & 3)

    • Bonjour: DNS-SD/mDNS implementation by Apple

    • Avahi: DNS-SD/mDNS implementation for Linux and BSD


Dns sd mdns overview l.jpg
DNS-SD/mDNS overview

  • DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR:

    _daap._tcp.local. PTR Tom’s Music._daap._tcp.local.

    _daap._tcp.local. PTR Joe’s Music._daap._tcp.local.

    Tom’s Music._daap._tcp.local. SRV

    0 0 3689 Toms-machine.local.

    Tom’s Music._daap._tcp.local. TXT

    "Version=196613" "iTSh Version=196608"

    "Machine ID=6070CABB0585" "Password=true”

    Toms-machine.local. A 160.39.225.12

  • Multicast DNS (mDNS)

    • Run by every host in a local link

    • Queries & answers are sent via multicast

    • All record names end in “.local.”

1:n mapping


Z2z zeroconf to zeroconf interconnection l.jpg
z2z: Zeroconf-to-Zeroconf interconnection

rendezvous point - OpenDHT

Import/export

services

Import/export

services

z2z

z2z

Zeroconf subnet A

Zeroconf subnet B


Demo global itunes sharing l.jpg
Demo: global iTunes sharing

  • Exporting iTunes shares under key “columbia”:

    $ z2z --export:opendht _daap._tcp --key “columbia”

  • Importing services stored under key “columbia”:

    $ z2z --import:opendht --key “columbia”


How z2z works exporting l.jpg

OpenDHT

Send browse request (i.e., PTR query) for service type: _daap._tcp

Send resolve request (i.e., SRV, A, and TXT query) for each service

Export them by putting into OpenDHT

1)

2)

3)

put:

key=

z2z._daap._tcp.columbia

value=

Tom’s Music

160.39.225.12:3689

Password=true

……

z2z

Tom’s Music.

_daap._tcp.local

Joe’s Music.

_daap._tcp.local

160.39.225.12

Tom’s Computer

Password=true

……

160.39.225.13

Joe’s Computer

Password=false

……

How z2z works (exporting)


How z2z works importing l.jpg

OpenDHT

Issue get call into OpenDHT

Add “A” record into mDNS

Import services by registering them

(i.e., add PTR, SRV, TXT records to the local mDNS)

1)

2)

3)

get:

key=z2z._daap._tcp.columbia

value=Tom’s Music

160.39.225.12:3689

……

value=Joe’s Music

……

“A” record for 160.39.225.12

z2z

mDNS

Tom’s Music._daap._tcp.local

_remote-160.39.225.12.local

……

How z2z works (importing)


Z2z implementation l.jpg
z2z implementation

  • C++ Prototype using xmlrpc-c for OpenDHT access

    • Proof of concept

    • Porting problem due to Bonjour and Cygwin incompatibility

  • z2z v1.0 released

    • Rewritten in Java from scratch

    • Open-source (BSD license)

    • Available in SourceForge (https://sourceforge.net/projects/z2z)

  • Paper describing design and implementation detail

    • z2z: Discovering Zeroconf Services Beyond Local Link

      • Lee, Schulzrinne, Kellerer, and Despotovic

    • Submitted to IEEE Globecom’07 Workshop on Service Discovery


Zeroconf for sip l.jpg
Zeroconf for SIP

  • Enable SIP communication when proxy and registrar are not available

    • Good use case for z2z

    • Fill in the gap of P2P-SIP effort:

      • local & small scale (10s to 100s)

      • high mobility

      • avoid construction of DHT

  • Internet Draft published and presented at IETF-68

    • SIP URI Service Discovery using DNS-SD

      • Lee, Schulzrinne, Kellerer, and Despotovic

      • http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01


Sip uri advertisement l.jpg
SIP URI advertisement

  • Example

    _sipuri._udp.local. PTR sip:[email protected]_sipuri._udp.local. _sipuri._udp.local. PTR sip:[email protected]_sipuri._udp.local. sip:[email protected]_sipuri._udp.local. SRV

    0 0 5060 bobs-host.local.

    sip:[email protected]_sipuri._udp.local. TXT

    txtvers=1 name=Bob contact=sip:[email protected]

  • Service instance name: Instance.Service.Domain

    • Instance = ( SIP-URI / SIPS-URI ) [ SP description ]

    • Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”

    • E.g.) sip:[email protected] - PDA._sipuri._udp.local.

  • Contact TXT record attribute

    • Similar to Contact SIP header except:

      • It contains only a single URI

      • Non-SIP URIs are not allowed

    • UA capabilities advertised via field parameters (RFC3840)


Next step dht discovery and initialization l.jpg
Next step: DHT discovery and initialization

  • DHT discovery (prospective peer to overlay)

    • How to discover an existing DHT to join

    • Current mechanisms:

      • Well-known bootstrap server

      • Expanding ring multicast

      • Server selection infrastructure: overlay anycast, LoST

      • Meta-DHT

  • DHT initialization

    • How to construct a DHT efficiently from scratch

      • first time or after major disruption

      • deal with network partition?

      • avoid creating multiple islands

    • Comparison between different DHT architectures

      • Ring vs prefix-based

      • Flat vs hierarchical

    • Cost considerations: time and network bandwidth

    • Especially timely with recent Skype failure



Voip functions l.jpg
VoIP functions

  • All subject to distribution:

  • call routing

  • media server (mixing, transcoding, recognition)

  • media storage

  • credentialing

  • authorization

  • PSTN gateway


Performance l.jpg
Performance

  • Look-up performance for N peers is O(log N)

    • affects call setup delay

    • e.g., Skype delay much higher than C-S calls

  • ==> use combination of peers and clients

  • media generally not routed through overlay

  • spare capacity => more resilient to overload

  • harder to compensate for hot spots


Economics l.jpg
Economics

  • Operator saves on

    • bandwidth

      • minimal for SIP signaling

      • interesting for media (TURN, relay, mixing)

    • servers

      • single SIP server can handle > 100,000 users ==> $0.10/month

      • except for NAT traversal (heartbeat)

      • except for media processing


Reliability l.jpg
Reliability

  • CW: “P2P systems are more reliable”

  • Catastrophic failure vs. partial failure

    • single data item vs. whole system

  • Node reliability

    • correlated failures of servers (power, access, DOS)

    • lots of very unreliable servers (95%?)

  • Natural vs. induced replication of data items


Security privacy l.jpg
Security & privacy

  • Security much harder

    • user authentication and credentialing

      • usually now centralized

    • sybil attacks

    • byzantine failures

  • Privacy

    • storing user data on somebody else’s machine

  • Distributed nature doesn’t help much

    • one attack likely to work everywhere

  • CALEA?


Slide21 l.jpg
OA&M

  • No real peer-to-peer management systems

    • system loading (CPU, bandwidth)

      • automatic splitting of hot spots

    • user experience (signaling delay, data path)

    • call failures

  • P2PP adds mechanism to query nodes for characteristics

  • Who gathers and evaluates the overall system health?


Locality l.jpg
Locality

  • Most P2P systems location-agnostic

    • each “hop” half-way across the globe

  • Locality matters

    • media servers, STUN servers, relays, ...

  • Working on location-aware systems

    • keep successors in close proximity

    • AS-local STUN servers


Mobility l.jpg
Mobility

  • Mobile nodes are poor peer candidates

    • power consumption

    • unreliable links

    • asymmetric links

  • But no problem as clients


Peer to peer protocol p2pp l.jpg

Peer-to-Peer Protocol (P2PP)

Salman Abdul Baset, Henning Schulzrinne

Columbia University


Overview l.jpg
Overview

  • Objective: key  (opaque) data

    • distributed data structure with O(log N) or O(1) [rarely]

  • Practical issues in peer-to-peer systems

  • Peer-to-peer systems

    • file sharing

    • VoIP

    • streaming

  • P2PSIP architecture

  • Peer-to-peer protocol (P2PP)

  • P2PP design issues

  • Implementation


Practical issues in peer to peer systems l.jpg
Practical issues in peer-to-peer systems

  • Bootstrap / service discovery

  • NAT and firewall traversal

  • TCP or UDP?

  • Routing-table management

  • Operation during churn

  • Availability and replication

  • Identity and trust management


Peer to peer systems l.jpg
Peer-to-peer systems

Service discovery

High

Data size

NAT

Data size

Replication

NAT

Performance impact / requirement

Medium

Replication

Replication

Data size

Low

NAT

VoIP

Streaming

File sharing


P2psip concepts l.jpg
P2PSIP: Concepts

  • Decentralized SIP

    • Replace SIP proxy and registrar with p2p endpoints

  • Supernode architecture

    • P2PSIP peers

      • participate in the p2p overlay

    • P2PSIP clients

      • use peers to locate users and resources


P2psip architecture l.jpg
P2PSIP architecture

[ Bootstrap / authentication server ]

[email protected]

Overlay2

SIP

NAT

Overlay1

P2P

STUN

TLS / SSL

NAT

A peer in P2PSIP

[email protected]

A client


Peer to peer protocol p2pp30 l.jpg
Peer-to-Peer Protocol (P2PP)

  • P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management.

  • Goals

    • A protocol to potentially implement any structured or unstructured protocol.

    • Not dependent on a single DHT or p2p protocol

  • Not a new DHT!

  • It is hard!

    • Too many structured and unstructured p2p protocols

    • Too many design choices!

  • Lets consider DHTs



Slide32 l.jpg

Periodic recovery

Accordion

Routing-table stabilization

Finger table

Tree

Kademlia

Lookup correctness

Parallel requests

Prefix-match

Modulo addition

Routing-table size

OneHop

Leaf-set

Recursive routing

Pastry

Bootstrapping

Updating routing-table from lookup requests

Bamboo

Ring

Tapestry

XOR

Proximity neighbor selection

Lookup performance

Successor

Reactive recovery

Hybrid

Chord

Strict vs. surrogate routing

Proximity route selection

Routing-table exploration


How to design p2pp l.jpg
How to design P2PP?

  • Structured

    • Identify commonalities in DHTs

      • Routing table (finger table)

      • Neighbor table (successor list, leaf-set)

    • Separate core routing mechanisms from from DHT-independent issues.

  • Unstructured

    • may not always find all keys

  • Incorporate mechanisms for

    • discovery

    • NAT / firewall traversal

    • churn, identity and trust management

    • request routing (recursive / iterative / parallel)


How to design p2pp34 l.jpg

DHT-independent

Bootstrapping

Routing-table stabilization

Reactive vs. periodic recovery

Parallel requests

Recursive routing

Proximity neighbor selection

Proximity route selection

How to design P2PP?

DHT-specific Not restricted toone DHT

DHT-specific

Bamboo

Chord

Lookup performance

Tapestry

Kademlia

Lookup correctness

Pastry

OneHop

Accordion

Successor / leaf-set

Finger table / routingtable

Modulo addition

Prefix-match

Routing-table size

XOR

Geometry

Updating routing-table from lookup requests

Ring

Hybrid

Strict vs. surrogate routing

Tree

Routing-table exploration


Chord strict routing table management l.jpg
Chord (Strict routing-table management)

id=x

Neighbor table(successor)

Routing table

Immediately succeeds

routing-table id

Node


Chord flexible routing table management l.jpg
Chord (flexible routing-table management)

id=x

Neighbor table

Routing table

Any node inthe interval

Node


Kademlia xor l.jpg
Kademlia(XOR)

id=x

No neighbor table

Routing table

Node


Peer to peer protocol p2pp38 l.jpg
Peer-to-Peer Protocol (P2PP)

  • A binary protocol

  • Geared towards IP telephony but equally applicable to file sharing, streaming, and p2p-VoD

  • Multiple DHT and unstructured p2p protocol support

  • Application API

  • NAT traversal

    • using STUN, TURN and ICE

    • ICE encoding in P2PP

  • Request routing

    • recursive, iterative, parallel

    • per message

  • Supports hierarchy (super nodes [peers], ordinary nodes [clients])

  • Reliable or unreliable transport (TCP or UDP)


Peer to peer protocol p2pp39 l.jpg
Peer-to-Peer Protocol (P2PP)

  • Security

    • DTLS, TLS, signatures

  • Multiple hash function support

    • SHA1, SHA256, MD4, MD5

  • Diagnostics

    • churn rate, messages sent/received

  • Node capabilities

    • bw determination, CPU utilization, number of neighbors, mobility


Slide40 l.jpg
Join

JP

BS

P5

P7

P9

1. Query

2. 200

P5, P30, P2P-Options

3+. STUN (ICE candidate gathering)

4. Join

5. Join

JP

(P10)

6. 200

7. 200

N(P9, P15)

N(P9, P15)

8. Join

9. 200

10. Transfer

11. 200


Call establishment l.jpg
Call establishment

P1

P3

P5

P7

1. Lookup-Peer (P7)

2. Lookup-Peer (P7)

3. Lookup-Peer (P7)

4. 200 (P7 Peer-Info)

5. 200 (P7 Peer-Info)

6. 200 (P7 Peer-Info)

7. INVITE

8. 200 Ok

9. ACK

Media


Peer to peer protocol p2pp42 l.jpg
Peer-to-Peer Protocol (P2PP)

Peer-Info

HT = host | NAT-address | relayed

P2P-Options


Implementation l.jpg
Implementation

  • Chord, Kademlia, Bamboo (in-progress)

  • SHA1, SHA256, MD5, MD4

  • Windows, Linux

  • Integrated with OpenWengo (VoIP phone)

  • Available for download (Linux + Windows)

    http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html


Implementation44 l.jpg
Implementation

insert (key, value, callback)

callback (resp)

lookup (key, callback)

Bootstrap

Client

ChordPeer

KadPeer

OtherPeer

Node

Distance

Routing table

Parser / encoder

Neighbor table

BigInt

Transactions

Sys

Transport / timers

UDP

TCP


Screen snapshot l.jpg
Screen snapshot

  • Alice and Bob are part of Kademlia network

  • Alice calls Bob

  • The lookup is performed using P2PP

  • Call is established using SIP


Conclusion l.jpg
Conclusion

  • P2P techniques now becoming mainstream

    • motivated by low opex, ease of deployment

    • building block, rather than application

  • Many operational issues

    • interconnection: z2z

    • local peering: Bonjour for SIP

    • start-up and recovery: cf. Skype failure

  • P2PP: Common platform protocol

    • application-neutral

    • extensible mechanism


ad