[p2p-sip] What are we doing - question 1

[enrico.marocco at telecomitalia.it (Enrico Marocco)]

Philip Matthews wrote:
>> The problem for a node behind a NAT is not maintaining connection with
>> its fingers; instead, what is really difficult is being reachable from
>> any peer.  Unfortunately chord requires the latter.
> 
> Not true. If peers forward requests on to other peer, a individual peer
> only
> has to have connections to a very small subset of the entire peer
> population.
> 
> In other words, say peer A wants to reach peer Z. Say A does not have a
> direct
> connection to Z, but does have a direct connection to (say)  B and C. It
> picks
> the one that is closest to Z (say C), and forwards its message (say a
> SIP INVITE)
> to C. Peer C then looks at its finger table and discovers that it, too,
> does not have
> a direct connection to Z, but has a connection to D which is closer. So
> C forwards
> the message to D. And so on.

True.  However this does not hold for an iterative implementation of chord.

> Eric Cooper and I talked  about this in the Internet Draft that I presented
>  at the last P2PSIP ad-hoc in Dallas:
>    http://www.p2psip.org/drafts/draft-matthews-p2psip-nats-and-overlays-00.html
> See section 4.4.2.  Note that another problem with vanilla_Chord identified in
> this document is that it does not exhibit the "Symmetric Interest" property
> (see section 4.4.3). However, a fairly straight-forward modification does.

Without such a property, the number of connections each node needs for
keeping the complexity logarithmic is huge: at least logN (where N is
the number of nodes in the overlay, not the cardinality of the hash
function) from it toward its fingers and - I guess, but I'm not sure -
logN originated from nodes in the DHT which have it as a finger.  Do
these numbers agree with your analysis?

Enrico