Hi, rf:
I look forward to the paper. Before the paper published, I have more questions here: 1. Do you have some measurement data about how many average retransmissions happened in your system in order to ensure reliability? 2. How do you set the timeout value for the retransmission timer? 3. I am very interested in the additional routing and tunneling techniques you've mentioned. Could you please give me general descriptions here? Regards! -- Jiang XingFeng _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renato Figueiredo Sent: Tuesday, January 22, 2008 10:55 PM To: JiangXingFeng Cc: theory and practice of decentralized computer networks; Henry Sinnreich; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [p2p-hackers] IP-over-P2P overlay with NAT traversal 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 <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: <mailto:[EMAIL PROTECTED]> [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] <mailto:[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
