Re: [P2PSIP] Peer protocol, DHT and running code

Philip Matthews <philip_matthews@magma.ca> Wed, 20 June 2007 18:38 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154H-0002fe-8A; Wed, 20 Jun 2007 14:38:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154G-0002fZ-RM for p2psip@ietf.org; Wed, 20 Jun 2007 14:38:12 -0400
Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I154G-0001fa-Gq for p2psip@ietf.org; Wed, 20 Jun 2007 14:38:12 -0400
Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from <philip_matthews@magma.ca>) id 1I154E-0005hG-31; Wed, 20 Jun 2007 14:38:11 -0400
In-Reply-To: <4678FED7.4040103@telecomitalia.it>
References: <4674F5ED.9070000@telecomitalia.it> <f40963db0706191517g71d341dcwcad156c0fbd7e906@mail.gmail.com> <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> <4678FED7.4040103@telecomitalia.it>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <71DB479B-70E1-4434-8F4A-EE70F8AFD9C8@magma.ca>
Content-Transfer-Encoding: 7bit
From: Philip Matthews <philip_matthews@magma.ca>
Subject: Re: [P2PSIP] Peer protocol, DHT and running code
Date: Wed, 20 Jun 2007 14:38:11 -0400
To: Enrico Marocco <enrico.marocco@telecomitalia.it>
X-Mailer: Apple Mail (2.752.2)
X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

On 20-Jun-07, at 06:17 , Enrico Marocco wrote:

> Philip Matthews wrote:
>> Furthermore, using a transport protocol other that TCP or UDP  
>> means that
>> we have to do all the work to define
>> how SIP and other protocols get transported over this transport
>> protocol. I don't think we should underestimate
>> how much time that would take.

First, a small correction.
SCTP transport of SIP has already been defined:  RFC 4168.

Now on to the main discussion...

>
> Actually, I don't think we really need to tunnel SIP over the peer
> protocol.  In the PCAN draft
> (http://tools.ietf.org/id/draft-marocco-p2psip-xpp-pcan-00.txt) we
> address the issue of NAT traversal the following way:
>
> 1) clients that need to do so would keep sip-outbound connections with
>    peers.
> 2) peers that handle sip-outbound flows for some clients would store
>    routing records containing the full path to the client.
>
> Here's an example: imagine client C registers with peer B and
> establishes an outbound flow with it. C's routing record (inserted in
> the overlay by B) will contain two hops: B's contact and C's
> contact/gruu.  In case B is also suffering restricted connectivity,  
> this
> would mean that it too would have an outbound flow with another peer,
> say A. In this case (which is pretty unlikely, because if B is
> restricted it probably won't be able to receive REGISTER requests form
> C), C's routing record would contain three hops.
>
> Having said that, it's probably worth noting that we have not yet
> decided whether this approach is better compared to routing SIP  
> messages
> inside the overlay. Both are easily implementable with XPP and XPP- 
> PCAN
> so I guess we'd need to discuss this further before we really made up
> our minds.

I assume that your peers have public IP addresses.
If so,  this is "superpeer" approach that is discussed in the "NATs  
and Overlays"  draft
and in my NAT traversal presentation in Prague. Dean has also suggested
a similar approach.

We have had some discussions of the pros and cons of this approach vs  
the approach
that Eric and I have been advocating of routing messages through a  
partial mesh of connections.

The whole goal of draft-matthews-p2psip-nats-and-overlays-01 is to  
discuss these two approaches
and their pros and cons.  Feedback on that draft would be much  
appreciated, and would help
the  WG decide on a direction.

- Philip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip