[p2p-sip] New I-D: The effect of NATs on P2P SIP Overlay Architecture

philip_matthews at magma.ca (Philip Matthews) Wed, 01 March 2006 14:44 UTC

From: "philip_matthews at magma.ca"
Date: Wed, 01 Mar 2006 09:44:37 -0500
Subject: [p2p-sip] New I-D: The effect of NATs on P2P SIP Overlay Architecture
In-Reply-To: <4404C388.9090408@cs.columbia.edu>
References: <E3C3A9D5-2639-4F80-8922-F9DDBE866F02@magma.ca> <4404C388.9090408@cs.columbia.edu>
Message-ID: <12A2E483-9001-4E6F-B996-0646604ED7EA@magma.ca>

Hi Kundan:

Thanks for your comments!
A few replies inline.

- Philip

On 28-Feb-06, at 16:41 , Kundan Singh wrote:

>
>> The plain text version of the draft is available at
>> http://www.ietf.org/internet-drafts/draft-matthews-p2psip-nats- 
>> and- overlays-00.txt
>
> I liked the analysis in the draft and agree with the conclusions.
Thanks!

>
> sec 4.4.3: I think Kademlia does symmetric that can fit the  
> description there.
Hmmm... I have the opposite impression, but I am not sure of my facts.
Certainly Kademlia has been very successful, so if it is symmetric,  
that would be a big plus.

>
> sec 4.4.2: I think the number 160 is misleading, since usually
> N << 2^160, and nodes will maintain only approx O(logN)  
> connections. For example, only 32 connections per peer for four  
> billion peers (2^32).
You are right. 160 is the theoretical maximum (assuming a 160-bit  
hash length), and the actual number is
about log N. This could be made clearer in the draft.

>
> sec 4.3: just to understand: is static connection == pointers in  
> DHT routing table? and dynamic == call setup? Otherwise, what does  
> static mean?

We see two types of connections.
The first type is used to maintain the overlay, do lookups, and for  
signaling. These follow the partial mesh
pattern described in the paper. We see these as static, meaning that  
they are long-lived (assuming
the peers at either end are long-lived) and do not change as calls  
are set up and torn down.
Since these are just a partial mesh, messages flowing over these may  
need a number of hops to reach
their destination.
The second type is used for the media in the call. These go from the  
calling peer to the called peer
and are dynamically set up when the call is established and torn down  
immediately afterwards.

It would be possible to have a third type. These would be set up when  
the called party receives the initial
Invite message and would be used for all the subsequent signaling  
messages. However, the cost to
set up a direct connection for the subsequent signaling messages  
seems to outweigh the benefits,
at least in my mind.

What section 4.3 discusses is the question of whether the first type  
of connections should be dynamic.
This is possible, but the overhead in setting up a connection seems  
to outweigh any advantages in
making the first type of connections dynamic.

Hope this makes things clear.