These are good questions, let me explain the connection process at a high level and hopefully it will help.
1. Assume nodes A and B are behind NATs and need to communicate with a direct link. They first exchange "connect-to-me" messages routed through the overlay - A sends B its list of URIs (e.g. UDP and TCP IP:port tuples) which it has learned from previous iterations and include the IP:port at the edge of the NAT. B does the same thing with its list of URIs. 2. Once A and B exchange URIs, they attempt to link by sending messages to each other's URIs. These poke holes in their NATs; eventually A and B receive each other's link messages and form a connection. David: yes, the larger delay is because we don't have a central rendez-vous server. The initial connect-to-me messages in 1. are routed through multiple hops in the overlay rather than going directly to a server. On Planetlab, these could take a few seconds. Henry: a difference here with respect to the approach you pointed out is that our system does not require an external infrastructure (server or DHT). OpenDHT uses a structured P2P system deployed on public nodes (nodes behind a NAT are clients only), while in our system the structured P2P system is integrated with the NAT traversal infrastructure as a single system; in our case the DHT can have its P2P nodes behind NATs and scales as new NATed nodes are added. Anyway, that's the main idea; here's a couple of disclaimers: - There is still room for optimizations and for fine-tuning system parameters which we believe could bring connection times down. For instance, taking network coordinates into account for overlay routing can decrease the time to exchange URIs and increasing the number of parallel linking attempts can decrease the time to link. We have so far been focusing more on the reliability of the system (e.g. dealing with network outages and symmetric NATs) rather than fine-tuning performance. - We have not made experiments recently to quantify connection times, I was quoting numbers from last year's paper, and the implementation has matured considerably; I hope we'll be able to take new measurements in the near future. Anyone interested in doing an experiment of this kind, let us know! Bests, --rf On Jan 21, 2008 6:12 PM, Henry Sinnreich <[EMAIL PROTECTED]> wrote: > I am also a little puzzled by the 10s setup delay. Nokia has recently > presented results from running P2PP mobile clients on the openDHT with > contact discovery of about 1s and call setup call setup times of about 4s. > > The report is attached here, but if it does not make it in the mail, I > have the authors to provide a link. > > Henry > > ________________________________________ > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of David Barrett > Sent: Monday, January 21, 2008 5:02 AM > To: [EMAIL PROTECTED] > Cc: theory and practice of decentralized computer networks > Subject: Re: [p2p-hackers] IP-over-P2P overlay with NAT traversal > > Ah, thanks for the information. As for the 10s setup time, I didn't follow > -- can you give a bit more detail on what factors into the time to set up? > > For example, in our system clients classify their NATs on startup, choose > either 1 or 2 addresses (LAN and NAT), and upload both to a rendezvous > service. Then when a connection needs to be set up, you simply ask the > rendezvous service for the other host's addresses (which in turn notifies > the other client that you're trying to connect to it), and then each client > attempts to connect to both LAN and NAT addresses in parallel. Generally the > connection is set up in the 500-1500ms timeframe. > > Can you summarize how your service works and why it takes so much longer? > I'm guessing it has something to do with the lack of a central rendezvous > service; can you walk me through it? > > Thanks! > > -david > > On Jan 19, 2008, at 3:57 PM, Renato Figueiredo wrote: > > > David, > > We don't have extensive measurements of pairwise NAT combinations; we've > had experience with cone NATs, particularly with NATs implemented by > different VMs (VMware, KVM, VirtualBox) and IPtables, and multi-level NATs ( > e.g. a VM NAT behind an ISP NAT). We have not done a focused quantitative > experiment on this yet, unfortunately - we'd like to. The experience we've > had so far is based on usage from people within our group (at home and on > the road) and casual users who run our software, our qualitative/empirical > evidence points to very good connectivity with cone NATs. The system deals > with symmetric NATs by discovering nodes to tunnel connections through. > > As for the time taken to traverse NATs; we have a paper presenting data > related to this question (HPDC 2006, can be found following one of the links > below). The time to traverse a NAT depends on the number of nodes in the > overlay (impacts routing time for connection setup messages) and NAT > characteristics (the number of translations a node records impacts number of > IP:port endpoints to attempt). Ballpark times for our current ~600-node > setup with ~500 planetlab nodes would be of the order of 10 seconds. > > --rf > On Jan 19, 2008 5:01 PM, David Barrett <[EMAIL PROTECTED]> wrote: > Cool! Regarding your NAT penetration, do you have any widespread > measurements indicating: > > - Peer connectivity success rate (ideally broken down by pairwise NAT > combinations) > - Direct connection establishment time (ie, time it takes to do all NAT > penetration and establish a link) > > I look forward to them! > > -david > > On Jan 19, 2008, at 1:18 PM, Renato Figueiredo wrote: > > Dear list members, > > I wanted to disseminate the availability of a couple of systems which > could be of interest to those in the list - the IPOP (IP-over-P2P) overlay > and the Brunet library. We have a few demonstrations of their applications > packaged as virtual machine "appliances" (NAT traversal appliance, and > virtual clusters running Condor and Hadoop) and a bootstrap overlay which > has been running on PlanetLab for several months. Together, these make it > very easy to try out the software; see the links and descriptions below for > additional information and downloads: > > http://ipop-project.org > http://grid-appliance.org > Brunet is a Free Software (GPL licensed) library for P2P networking > written in C# and developed using Mono, but it also runs on Microsoft's .Net > platform. Here are the basic features of Brunet: > - Network transports are abstracted as Edge objects. We have TCP, UDP and > TLS/SSL transports now. > - Completely distributed UDP NAT traversal (TCP NAT traversal is a to-do > item). > - Implementation of Chord/Kleinberg/Symphony type ring topology for > routing. > - DHT implementation. > - Both packet based and RPC based communication primitives. New protocols > are easy to add using one or the other of these approaches. > - XML-RPC bridge to allow calling or serving RPC methods with XML-RPC > clients or servers. We have examples of this using standard Python. > - Distributed tunneling system to maintain topology in the presence of > some routing difficulties (untraversable NATs, BGP outages, firewalls, > etc.). > > IPOP uses Brunet to create virtual IP networks; it features: > - Tunneling of IP packets picked from "tap" devices over TCP and UDP > overlay edges > - Creation of direct connections between virtual IP endpoints based on > traffic inspection > - An implementation of DHCP over DHT to automatically assign IP addresses > to tap interfaces > > We're looking forward to hearing from people interested in using or > developing around these systems. > > --rf > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > -- > Dr. Renato J. Figueiredo > Assistant Professor > ACIS Lab / Electrical and Computer Engineering > University of Florida > http://byron.acis.ufl.edu > ph: 352-392-6430 > > -- Dr. Renato J. Figueiredo Assistant Professor ACIS Lab / Electrical and Computer Engineering University of Florida http://byron.acis.ufl.edu ph: 352-392-6430
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
