Peer to peer communication services project status presentation sep 18 2007
Download
1 / 34

Peer-to-peer Communication Services Project Status Presentation Sep 18, 2007 - PowerPoint PPT Presentation


  • 534 Views
  • Updated On :

Peer-to-peer Communication Services Project Status Presentation Sep 18, 2007. Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe. Outline. Research overview Initial proposal

Related searches for Peer-to-peer Communication Services Project Status Presentation Sep 18, 2007

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 Project Status Presentation Sep 18, 2007' - Solomon


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 project status presentation sep 18 2007 l.jpg

Peer-to-peer Communication ServicesProject Status PresentationSep 18, 2007

Henning Schulzrinne, Jae Woo Lee, Salman Baset

Columbia University

Wolfgang Kellerer, Zoran Despotovic

DoCoMo Communications Laboratories Europe


Outline l.jpg
Outline

  • Research overview

    • Initial proposal

    • Summary of current results

  • 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-SIP

    • Background concepts and overview of current proposals

  • Next step

    • DHT discovery

    • DHT initialization


Initial research proposal l.jpg
Initial research proposal

  • Investigate core problems related to p2p communication services

    • Transient p2p services

    • Adaptive p2p systems

    • Standardization of p2p elements


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

  • 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:bob@a.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local. sip:bob@a.com._sipuri._udp.local. SRV

    0 0 5060 bobs-host.local.

    sip:bob@a.com._sipuri._udp.local. TXT

    txtvers=1 name=Bob contact=sip:bob@bobs-host.local.

  • Service instance name: Instance.Service.Domain

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

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

    • E.g.) sip:bob@example.com - 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



P2p sip concepts l.jpg
P2P-SIP: Concepts

  • Decentralized SIP

    • Replace per-domain SIP proxy and registrar with instances running on p2p endpoints

    • largely maintain SIP functionality and protocol

    • P2P SIP working group in IETF

  • 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 ]

alice@example.com

Overlay2

SIP

NAT

Overlay1

P2P

STUN

TLS / SSL

NAT

A peer in P2PSIP

bob@example.com

A client


P2p sip current proposals l.jpg
P2P-SIP: Current proposals

  • Three competing proposals for peer protocol

    • Peer-to-Peer Protocol (P2PP)

      • S. Baset and H. Schulzrinne

      • Separation of SIP and P2P protocol

      • Separation of DHT algorithm and overlay maintenance

        • Pluggable DHT algorithms

    • REsource LOcation And Discovery (RELOAD)

      • D. Bryan, M. Zangrilli, and B. Lowekamp

      • Successor to dSIP, a SIP extension for P2P

      • RELOAD is now a binary protocol

    • Address Settlement by P2P (ASP)

      • C. Jennings, J. Rosenberg, and E. Rescorla

      • Focus on security and NAT traversal

      • Leaves DHT details unspecified


Peer to peer protocol p2pp l.jpg
Peer-to-peer protocol (P2PP)

  • Practical issues in peer-to-peer systems

  • Peer-to-peer systems

    • file sharing

    • VoIP

    • streaming

  • 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


Peer to peer protocol p2pp23 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



Slide25 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

  • Incorporate mechanisms for

    • discovery

    • NAT / firewall traversal

    • churn, identity and trust management

    • request routing (recursive / iterative / parallel)


How to design p2pp27 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 p2pp31 l.jpg
Peer-to-Peer Protocol (P2PP)

  • A binary protocol

  • Geared towards IP telephony but equally applicable to file sharing and streaming

  • Multiple DHT and unstructured p2p protocol support

  • Application API

  • NAT traversal

    • using STUN, TURN and ICE

  • Request routing

    • recursive, iterative, parallel

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

  • Multiple hash function support

    • SHA1, SHA256, MD4, MD5, ...

  • TCP or UDP


Peer to peer protocol p2pp32 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


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