att

Document Sample
att Powered By Docstoc
					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
•   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
•   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’07 Workshop 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

1. Bootstrapping
  •   Formation of small private p2p islands
2. Interconnection
  •   Connectivity and service discovery between the
      p2p islands (each represented by a leader)
3. Structure formation
  •   DHT construction among the leaders
4. Growth
  •   Merger of multiple such DHTs
    Zeroconf: solution for bootstrapping

•    Three requirements for zero configuration networks:
     1) IP address assignment without a DHCP server
     2) Host name resolution without a DNS server
     3) 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
•    DNS-Based Service Discovery (DNS-SD) adds a
     level of indirection to SRV using PTR:
                                                            1:n mapping
     _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.”
z2z: Zeroconf-to-Zeroconf interconnection



           rendezvous point - OpenDHT

 Import/export                     Import/export
 services                          services


           z2z                    z2z




   Zeroconf subnet A       Zeroconf subnet B
      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)
                     OpenDHT                   1) Send browse request
put:                                              (i.e., PTR query) for
key=                                              service type: _daap._tcp
 z2z._daap._tcp.columbia
value=
 Tom’s Music                                   2) Send resolve request
                                                  (i.e., SRV, A, and TXT
 160.39.225.12:3689     z2z                       query) for each service
 Password=true
 ……
         Tom’s Music.       Joe’s Music.       3) Export them by putting
                                                  into OpenDHT
         _daap._tcp.local   _daap._tcp.local

        160.39.225.12         160.39.225.13
        Tom’s Computer        Joe’s Computer
        Password=true         Password=false
        ……                    ……
        How z2z works (importing)
                       OpenDHT                 1) Issue get call into
get:                                              OpenDHT
key=z2z._daap._tcp.columbia
value=Tom’s Music
        160.39.225.12:3689        “A” record for
        ……                        160.39.225.12 2) Add “A” record into
value=Joe’s Music                                  mDNS
        ……                  z2z      mDNS

                                               3) Import services by
                                                  registering them
             Tom’s Music._daap._tcp.local         (i.e., add PTR, SRV,
             _remote-160.39.225.12.local          TXT records to the local
             ……                                   mDNS)
 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
• 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
• 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

•   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 for Voice - Open Issues
VoIP functions
•   All subject to distribution:
•   call routing
•   media server (mixing, transcoding, recognition)
•   media storage
•   credentialing
•   authorization
•   PSTN gateway
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

• 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

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

• 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

• Mobile nodes are poor peer candidates
  – power consumption
  – unreliable links
  – asymmetric links
• But no problem as clients
Peer-to-Peer Protocol (P2PP)
  Salman Abdul Baset, Henning Schulzrinne
              Columbia University
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

• 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
Performance impact / requirement




                                                      Service discovery
                                     High    Data size      NAT           Data size
                                                         Replication        NAT

                                   Medium                                 Replication

                                            Replication
                                    Low       NAT          Data size



                                            File sharing     VoIP         Streaming
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
      [ Bootstrap / authentication server ]

                                   alice@example.com
                                       Overlay2
                                                             SIP
          NAT
                   Overlay1                            P2P        STUN

                                                         TLS / SSL
                               NAT
                                                       A peer in P2PSIP

bob@example.com                                        A client
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
        DHTs
                                             Lookup
                                                                Lookup
                            Distance       correctness
  DHT       Geometry                                          performance
                            function        (neighbor
                                                             (routing table)
                                              table)
                            Modulo
 Chord
               Ring         numeric        Successor list     Finger table
Accordion
                           difference
                        Prefix match. If
Tapestry,    Hybrid =     fails, then
 Pastry,                    modulo       Leaf-set (Pastry)   Routing table
Bamboo      Tree + Ring    numeric
                          difference

Kademlia       XOR       XOR of two IDs        None          Routing table
   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
                                                 Ring                Bamboo
                              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?
• 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 P2PP?
 DHT-independent               DHT-specific                   DHT-specific
                               Not restricted to
Bootstrapping
                               one DHT                        Bamboo      Chord
                               Lookup performance             Tapestry    Kademlia
Routing-table stabilization
                               Lookup correctness             Pastry      OneHop
Reactive vs. periodic
recovery                                                      Accordion
                                  Successor / leaf-set
Parallel requests                 Finger table / routing      Modulo addition
                                  table
Recursive routing                                             Prefix-match
                                  Routing-table size
Proximity neighbor selection                                  XOR
                                                                          Geometry
Proximity route selection
                               Updating routing-table                     Ring
                               from lookup requests
                                                                          Hybrid
                               Strict vs. surrogate routing               Tree
                               Routing-table exploration
        Chord
        (Strict routing-table management)



                                        id=x
                                            Neighbor table
                                            (successor)


                                                   Routing table
                                                             x+2i

Immediately                                                  x+2i+1
succeeds                                                     x+2i+2
routing-table id                                             x+2i+3




                                                             Node
       Chord
       (flexible routing-table management)


                                       id=x
                                             Neighbor table



                                                    Routing table
                                                              x+2i
                                                              x+2i+1
Any node in
the interval                                                  x+2i+2
                                                              x+2i+3




                                                              Node
Kademlia
(XOR)


           id=x   No neighbor
                  table



                  Routing table
                          2i
                          2i+1
                          2i+2
                          2i+3




                         Node
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 (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
     Join
JP                 BS                       P5                       P7           P9
      1. Query

      2. 200
 P5, P30, P2P-Options

       3+. STUN (ICE candidate gathering)

                   4. Join
                                                           5. Join

                                                           6. 200          JP
                   7. 200                             N(P9, P15)          (P10)
                 N(P9, P15)
                                                 8. Join

                                                 9. 200

                                                 10. Transfer

                                                 11. 200
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 (P2PP)
Peer-Info




 HT = host | NAT-address | relayed


P2P-Options
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
        Implementation
   insert (key, value, callback)
                                                        callback (resp)
   lookup (key, callback)


Bootstrap             Client       ChordPeer        KadPeer          OtherPeer



                                     Node

            Distance             Routing table        Parser / encoder

             BigInt             Neighbor table        Transactions


                  Sys          Transport / timers

                               UDP          TCP
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

• 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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:10/16/2011
language:English
pages:46
liaoxiuli2 liaoxiuli2
About