Shared Correspondence Administrations

0
0
1562 days ago, 701 views
PowerPoint PPT Presentation
Diagram. Research overviewConceptual frameworkFour phases of p2p systemsZeroconf: answer for bootstrappingOverview and examplez2z: Zeroconf-to-Zeroconf interconnectionOverview, configuration and implementationZeroconf for SIPMotivation and outline of the Internet DraftP2P frameworks for VoIPP2P-SIPBackground ideas and review of momentum proposalsNext stepDHT discoveryDHT introduction.

Presentation Transcript

Slide 1

Distributed Communication Services Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe

Slide 2

Outline Research diagram Conceptual system Four phases of p2p frameworks Zeroconf: answer for bootstrapping Overview and case z2z: Zeroconf-to-Zeroconf interconnection Overview, plan and execution Zeroconf for SIP Motivation and review of the Internet Draft P2P frameworks for VoIP P2P-SIP Background ideas and review of flow proposition Next stride DHT disclosure DHT instatement

Slide 3

Current results Conceptual structure: 4 phases of p2p frameworks Bootstrapping Interconnection Structure development Growth Zeroconf: answer for bootstrapping Detailed investigation of Bonjour, Apple's Zeroconf usage Internet Draft distributed on utilizing Zeroconf for SIP z2z: Zeroconf-to-Zeroconf Toolkit Interconnect Zeroconf systems utilizing OpenDHT C++ model for evidence of idea z2z v1.0: open-source Java usage on SourceForge Paper submitted to IEEE Globecom'07 Workshop on Service Discovery P2PP: bland P2P transport convention Next stride: DHT revelation and introduction How to find a current DHT? How to develop a DHT effectively starting with no outside help?

Slide 4

Four phases of element p2p frameworks Bootstrapping Formation of little private p2p islands Interconnection Connectivity and administration revelation between the p2p islands (each spoke to by a pioneer) Structure arrangement DHT development among the pioneers Growth Merger of various such DHTs

Slide 5

Zeroconf: answer for bootstrapping Three necessities for zero setup systems: IP address task without a DHCP server Host name determination without a DNS server Local administration disclosure with no meet server Solutions and executions: RFC3927: Link-nearby tending to standard for 1) DNS-SD/mDNS: Apple's convention for 2) & 3) Bonjour: DNS-SD/mDNS usage by Apple Avahi: DNS-SD/mDNS execution for Linux and BSD

Slide 6

DNS-SD/mDNS outline DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV utilizing 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 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 each host in a nearby connection Queries & answers are sent by means of multicast All record names end in ".neighborhood." 1:n mapping

Slide 7

z2z: Zeroconf-to-Zeroconf interconnection meet point - OpenDHT Import/trade administrations Import/send out administrations z2z Zeroconf subnet A Zeroconf subnet B

Slide 8

Demo: worldwide iTunes sharing Exporting iTunes shares under key "columbia": $ z2z - export:opendht _daap._tcp - key "columbia" Importing administrations put away under key "columbia": $ z2z - import:opendht - key "columbia"

Slide 9

OpenDHT Send peruse ask for (i.e., PTR inquiry) for administration sort: _daap._tcp Send resolve ask for (i.e., SRV, An, and TXT question) for every administration 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 functions (sending out)

Slide 10

OpenDHT Issue get call into OpenDHT Add "A" record into mDNS Import benefits by enrolling them (i.e., include PTR, SRV, TXT records to the nearby 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 functions (bringing in)

Slide 11

z2z execution C++ Prototype utilizing xmlrpc-c for OpenDHT get to Proof of idea Porting issue because of Bonjour and Cygwin incongruence z2z v1.0 discharged Rewritten in Java without any preparation Open-source (BSD permit) Available in SourceForge ( https://sourceforge.net/ventures/z2z ) Paper portraying outline and usage detail z2z: Discovering Zeroconf Services Beyond Local Link Lee, Schulzrinne, Kellerer, and Despotovic Submitted to IEEE Globecom'07 Workshop on Service Discovery

Slide 12

Zeroconf for SIP Enable SIP correspondence when intermediary and enlistment center are not accessible Good utilize case for z2z Fill in the crevice of P2P-SIP exertion: neighborhood & little scale (10s to 100s) high portability maintain a strategic distance from development of DHT Internet Draft distributed and displayed at IETF-68 SIP URI Service Discovery utilizing DNS-SD Lee, Schulzrinne, Kellerer, and Despotovic http://tools.ietf.org/html/draft-lee-taste dns-sd-uri-01

Slide 13

SIP URI promotion 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 5060 sways host.local. sip:bob@a.com._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:bob@bobs-host.local. Benefit case name: Instance.Service.Domain Instance = ( SIP-URI/SIPS-URI ) [ SP depiction ] Service = "_sipuri._udp"/"_sipuri._tcp"/"_sipuri._sctp" E.g.) sip:bob@example.com - PDA._sipuri._udp.local. Contact TXT record ascribe Similar to Contact SIP header aside from: It contains just a solitary URI Non-SIP URIs are not permitted UA abilities promoted through field parameters (RFC3840)

Slide 14

Next stride: DHT revelation and instatement DHT disclosure (forthcoming companion to overlay) How to find a current DHT to join Current instruments: Well-known bootstrap server Expanding ring multicast Server determination framework: overlay anycast, LoST Meta DHT introduction How to build a DHT effectively starting with no outside help first time or after real disturbance manage organize parcel? abstain from making numerous islands Comparison between various DHT structures Ring versus prefix-based Flat versus progressive Cost contemplations: time and system data transfer capacity Especially opportune with late Skype disappointment

Slide 15

P2P for Voice - Open Issues

Slide 16

VoIP works All subject to conveyance: call directing media server (blending, transcoding, acknowledgment) media stockpiling credentialing approval PSTN portal

Slide 17

Performance Look-up execution for N associates is O(log N) influences call setup delay e.g., Skype postpone much higher than C-S calls ==> utilize mix of companions and customers media for the most part not steered through overlay save limit => stronger to over-burden harder to make up for problem areas

Slide 18

Economics Operator saves money on transmission capacity insignificant for SIP flagging fascinating for media (TURN, hand-off, blending) servers single SIP server can deal with > 100,000 clients ==> $0.10/month aside from NAT traversal (pulse) with the exception of media preparing

Slide 19

Reliability CW: "P2P frameworks are more dependable" Catastrophic disappointment versus fractional disappointment single information thing versus entire framework Node unwavering quality associated disappointments of servers (power, get to, DOS) heaps of exceptionally untrustworthy servers (95%?) Natural versus incited replication of information things

Slide 20

Security & protection Security much harder client validation and credentialing as a rule now concentrated sybil assaults byzantine disappointments Privacy putting away client information on another person's machine Distributed nature doesn't help much one assault liable to work wherever CALEA?

Slide 21

OA&M No genuine shared administration frameworks framework stacking (CPU, transmission capacity) programmed part of problem areas client encounter (flagging postponement, information way) call disappointments P2PP adds component to question hubs for qualities Who assembles and assesses the general framework wellbeing?

Slide 22

Locality Most P2P frameworks area skeptic every "jump" most of the way over the globe Locality matters media servers, STUN servers, transfers, ... Taking a shot at area mindful frameworks keep successors in closeness AS-nearby STUN servers

Slide 23

Mobility Mobile hubs are poor companion competitors control utilization temperamental connections hilter kilter interfaces But no issue as customers

Slide 24

Peer-to-Peer Protocol (P2PP) Salman Abdul Baset, Henning Schulzrinne Columbia University

Slide 25

Overview Objective: key  (hazy) information circulated information structure with O(log N) or O(1) [rarely] Practical issues in distributed frameworks Peer-to-associate frameworks document sharing VoIP spilling P2PSIP engineering Peer-to-associate convention (P2PP) P2PP outline issues Implementation

Slide 26

Practical issues in distributed frameworks Bootstrap/benefit disclosure NAT and firewall traversal TCP or UDP? Directing table administration Operation amid stir Availability and replication Identity and trust administration

Slide 27

Peer-to-associate frameworks Service revelation High Data estimate NAT Data measure Replication NAT Performance affect/necessity Medium Replication Data measure Low NAT VoIP Streaming File sharing

Slide 28

P2PSIP: Concepts Decentralized SIP Replace SIP intermediary and enlistment center with p2p endpoints Supernode engineering P2PSIP peers take part in the p2p overlay P2PSIP customers utilize companions to find clients and assets

Slide 29

P2PSIP design [ Bootstrap/verification server ] alice@example.com Overlay2 SIP NAT Overlay1 P2P STUN TLS/SSL NAT A companion in P2PSIP bob@example.com A customer

Slide 30

Peer-to-Peer Protocol (P2PP) P2P applications have normal prerequisites, for example, disclosure, NAT traversal, transfer choice, replication, and agitate administration. Objectives A convention to conceivably actualize any organized or unstructured protoco

SPONSORS