Jiang, We use recursive routing; our assumption is a large fraction of nodes could be behind NATs; and we apply additional routing and tunneling techniques to make routing resilient to connectivity failures due to route outages and NATs we cannot traverse. We're currently working on a paper describing those.
Regards, --rf On Jan 22, 2008 1:29 AM, JiangXingFeng <[EMAIL PROTECTED]> wrote: > Hi, all: > > IMO, Nodes behind NAT should be able to play the peer role, because most > of > nodes in the Internet are behind NAT. For "connect-to-me" message, routing > through the overlay will take more time due to overlay churn. > > Rf: could you tell me which routing mode do you use to route the > connect-to-me message? I mean recursive routing mode, iterative routing > mode > or semi-recursive routing mode? > > IMHO, semi-recursive routing mode is supposed to be the fastest one. But > its > trouble is how to make the response return the source peer which is behind > NAT. One viable option proposed in SEP > (http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) is to find > a > P2P message level relay to address this issue. > > BTW: I am interested in quantify the connection time, especially to > measure > the value in different routing modes. > > Regards! > -- > Jiang XingFeng > > ________________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Renato > Figueiredo > Sent: Tuesday, January 22, 2008 8:24 AM > To: Henry Sinnreich > Cc: [EMAIL PROTECTED]; theory and practice of decentralized > computer networks; [EMAIL PROTECTED] > Subject: Re: [p2p-hackers] IP-over-P2P overlay with NAT traversal > > 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 > > -- 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
