Subject: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 26 Apr 2007 19:59:46 -0400

I was a little confused by the wording in the draft. It started by saying
that it doesn't make any assumptions about the p2p protocol (sip based or
other), but then states the OPTIONS and REGISTER methods for bootstrap peers
to join the bootstrap server. Wouldn't these operations be part of the p2p
protocol draft?
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Philip Matthews <[email-masked]>
Date: Sun, 29 Apr 2007 23:05:00 -0400

On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote:

> I was a little confused by the wording in the draft. It started by  
> saying that it doesn't make any assumptions about the p2p protocol  
> (sip based or other), but then states the OPTIONS and REGISTER  
> methods for bootstrap peers to join the bootstrap server. Wouldn't  
> these operations be part of the p2p protocol draft?

The draft makes no assumptions on the nature of the Peer Protocol.  
However, the draft assumes that SIP is used to signal Peer Protocol  
connections  -- SIP is a very good signaling protocol, so why not use  
it to set up Peer Protocol connections?

So the support of OPTIONS and REGISTER are for SIP when signaling  
Peer Protocol connections.  However, the Peer Protocol itself could  
be anything.

Does this help?

- Philip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 29 Apr 2007 23:27:39 -0400

Hi Philip,

I think the use of SIP with ICE is used to signal the control connection is
fine. Moreover its debatable whether it is SIP or ICE which should be the
control connection protocol. After reading the draft, it seems to me that
OPTIONS is used to locate the bootstrap peer and not establish a control
connection (in multicast domain) and REGISTER is used between bootstrap peer
and bootstrap server (and not to establish a control connection in a more
regular environment). It seems NAT traversal may not an issue in either
case.

Did I understand this correctly?

Medhavi.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 30 Apr 2007 07:39:31 -0400

Taking your points one-by--one:
- ICE is not a signaling protocol by itself, but (as currently  
defined) needs to ride on a signaling protocol that exchanges SDP  
messages. SIP is the premiere example of such a protocol. This is why  
the draft using SIP for signaling
- For the multicast case, a SIP OPTIONS message is used to _locate_  
bootstrap peers. In the Bootstrap Server Mechanism, a SIP REGISTER  
message is used to _register_ a bootstrap peer with a bootstrap  
server.  However, in both methods, a SIP INVITE transaction is used  
to establish the connection between the joining peer and the  
admitting peer.
- Not sure what you mean by the statement "NAT Traversal is not an  
issue", as  there was a lot of thought put into the draft to make it  
work in the presence of NATs.

Did I understand and answer your questions?

- Philip

On 29-Apr-07, at 23:27 , Medhavi Bhatia wrote:

> Hi Philip,
>
> I think the use of SIP with ICE is used to signal the control  
> connection is fine. Moreover its debatable whether it is SIP or ICE  
> which should be the control connection protocol. After reading the  
> draft, it seems to me that OPTIONS is used to locate the bootstrap  
> peer and not establish a control connection (in multicast domain)  
> and REGISTER is used between bootstrap peer and bootstrap server  
> (and not to establish a control connection in a more regular  
> environment). It seems NAT traversal may not an issue in either case.
>
> On 4/29/07, Philip Matthews <[email-masked] > wrote:
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 30 Apr 2007 11:24:38 -0400

Hi Philip,

NAT Traversal brings a lot of complexity to a P2P network. I think we need
to carefully identify what we are doing for traversing NAT from what we need
to get the P2P to work itself. I think if we keep in mind that another
offer-answer protocol (other than SIP) can be used with ICE to set up
control connections as well then things are easier to analyze at least.

The bootstrap server seems to have two roles. It helps location of a
bootstrap peer (P2P part) as well as act as a rendezvous point for
establishing a control connection to it (NAT Traversal part). The
functionality provided by SIP OPTIONS and REGISTER (mainly location of the
bootstrap peer) seems to be related to P2P part. So I think the draft seems
to have over specified since it is discussing the use of SIP to do that.

Medhavi.

On 4/30/07, Philip Matthews <[email-masked]> wrote:
>
> Taking your points one-by--one:- ICE is not a signaling protocol by
> itself, but (as currently defined) needs to ride on a signaling protocol
> that exchanges SDP messages. SIP is the premiere example of such a protocol.
> This is why the draft using SIP for signaling
> bootstrap peers. In the Bootstrap Server Mechanism, a SIP REGISTER message
> is used to _register_ a bootstrap peer with a bootstrap server.  However, in
> both methods, a SIP INVITE transaction is used to establish the connection
> between the joining peer and the admitting peer.
> - Not sure what you mean by the statement "NAT Traversal is not an issue",
> as  there was a lot of thought put into the draft to make it work in the
> presence of NATs.
>
> I think the use of SIP with ICE is used to signal the control connection
> is fine. Moreover its debatable whether it is SIP or ICE which should be the

---

From: Philip Matthews <[email-masked]>
Date: Mon, 30 Apr 2007 13:55:35 -0400

On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> NAT Traversal brings a lot of complexity to a P2P network. I think  
> we need to carefully identify what we are doing for traversing NAT  
> from what we need to get the P2P to work itself. I think if we keep  
> in mind that another offer-answer protocol (other than SIP) can be  
> used with ICE to set up control connections as well then things are  
> easier to analyze at least.

NAT traversal is complex. Unfortunately, it also seems integral to  
P2PSIP. What we do NOT want to do is to repeat the  SIP experience  
and design a P2PSIP system and then try to  add NAT Traversal as an  
afterthought.

>
> The bootstrap server seems to have two roles. It helps location of  
> a bootstrap peer (P2P part) as well as act as a rendezvous point  
> for establishing a control connection to it (NAT Traversal part).  
> The functionality provided by SIP OPTIONS and REGISTER (mainly  
> location of the bootstrap peer) seems to be related to P2P part. So  
> I think the draft seems to have over specified since it is  
> discussing the use of SIP to do that.

I agree that that the bootstrap server does a number of things.  
However, I don't see the distinction that you seem to be suggesting.  
Can you explain further?

- Philip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 30 Apr 2007 15:49:01 -0400

Hi Philip,

If I organize the tasks required to become part of the P2P network in the
following categories:

Step1: Determine which admitting peer to connect to (bootstrap
server/multicast/static config)
Step2: Form a control connection with the admitting peer (bootstrap server)
Step3: Run the P2P protocol to join the p2p network, register resources,
query, exchange routes etc.

I think the use of OPTIONS applies to step1. SIP/ICE or any connection
establishment protocol which works over NATS applies to steps 1 and 2.
However registering myself as a bootstrap peer seems to be part of Step3. I
assume that the bootstrap server is part of the p2p network.

I am just trying to put my head together on this one now ;).

Medhavi.