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
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
