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

From: Philip Matthews <[email-masked]>
Date: Tue, 1 May 2007 08:26:24 -0400

On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote:

> 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)
The way things are currently defined in the Concepts draft, the  
bootstrap server is logically distinct from the admitting peer.

> Step3: Run the P2P protocol to join the p2p network, register  
> resources, query, exchange routes etc.
>
> I think the use of OPTIONS applies to step 1.
If you use the Multicast method.

> SIP/ICE or any connection establishment protocol which works over  
> NATS applies to steps 1 and 2.
Yup.

> However registering myself as a bootstrap peer seems to be part of  
> Step3.
Sure.

> I assume that the bootstrap server is part of the p2p network.
As currently defined in the Concepts draft, the bootstrap server may  
or may not be part of the P2P overlay.
>
> I am just trying to put my head together on this one now ;).
Try reading the Concepts draft and see if this helps.

>
> Medhavi.
>
> On 4/30/07, Philip Matthews < [email-masked]> wrote:
>
> 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
>
>
>
>

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 1 May 2007 15:50:12 -0400

Hi Philip,

Thanks for the pointer.I think its important to realize that the bootstrap
server is only used as a SIP Proxy/Server in this draft and does not have
anything to do with the p2p protocol itself (more the reason to use a
separate term for introduction server in the p2p network). However, the
draft seems to assume that the p2p nodes speak REGISTER and OPTIONS as well.
I think it would help if we state this separately somewhere in the draft.

Here is one proposal:
I think the REGISTER could be replaced by a p2p primitive as another option.
This would simplify the p2p node requirements a little. With the current
assumptions in the draft, the p2p nodes are speaking ICE over SIP (the SIP
connection is discarded after the p2p control connection comes up), OPTIONS,
REGISTER and the p2p protocol itself (maybe a different protocol from SIP).

Medhavi.

On 5/1/07, Philip Matthews <[email-masked]> wrote:
> If I organize the tasks required to become part of the P2P network in the
> following categories:
>
> The way things are currently defined in the Concepts draft, the bootstrap
> server is logically distinct from the admitting peer.
>
> Step3: Run the P2P protocol to join the p2p network, register resources,
> query, exchange routes etc.
>
> SIP/ICE or any connection establishment protocol which works over NATS
> applies to steps 1 and 2.
>
> Yup.
>
> However registering myself as a bootstrap peer seems to be part of Step3.
>
> Sure.
>
> As currently defined in the Concepts draft, the bootstrap server may or
> may not be part of the P2P overlay.
>
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 1 May 2007 16:05:28 -0400

On 1-May-07, at 15:50 , Medhavi Bhatia wrote:

> Hi Philip,
>
> Thanks for the pointer.I think its important to realize that the  
> bootstrap server is only used as a SIP Proxy/Server in this draft  
> and does not have anything to do with the p2p protocol itself (more  
> the reason to use a separate term for introduction server in the  
> p2p network).
Yes, in this draft, a bootstrap server does not speak the peer protocol.

> However, the draft seems to assume that the p2p nodes speak  
> REGISTER and OPTIONS as well. I think it would help if we state  
> this separately somewhere in the draft.

The draft clearly states that SIP is used for signaling. REGISTER and  
OPTIONS are SIP methods, and are defined in 3261. What else should we  
say???

>> Step2: Form a control connection with the admitting peer  
>> (bootstrap server)
> As currently defined in the Concepts draft, the bootstrap server  
> may or may not be part of the P2P overlay.
>>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 1 May 2007 16:20:44 -0400

> OPTIONS are SIP methods, and are defined in 3261. What else should we say???
>

I think the draft creates a requirement for the p2p nodes to implement SIP
REGISTER and OPTIONS (which didn't exist previously). One suggestion is to
allow alternate protocols to do the same and focus on this draft more on the
process/method of bootstrapping and joining a p2p network (what the title
and abstract suggest).

On 5/1/07, Philip Matthews <[email-masked]> wrote:
> > If I organize the tasks required to become part of the P2P network in
> > the following categories:
> >

---

From: Philip Matthews <[email-masked]>
Date: Thu, 3 May 2007 12:53:34 -0400

On 1-May-07, at 16:20 , Medhavi Bhatia wrote:

>> The draft clearly states that SIP is used for signaling. REGISTER  
>> and OPTIONS are SIP methods, and are defined in 3261. What else  
>> should we say???

> I think the draft creates a requirement for the p2p nodes to  
> implement SIP REGISTER and OPTIONS (which didn't exist previously).  
> One suggestion is to allow alternate protocols to do the same and  
> focus on this draft more on the process/method of bootstrapping and  
> joining a p2p network (what the title and abstract suggest).
>

Well .... I agree that the initial discussion around this draft  
should focus around the general approach to bootstrapping, before  
concentrating on the details.

However, the point of this draft was to give all the details for one  
way of doing bootstrapping, because we have found that having details  
is usually necessary before people will think about the general case.

If the working group decides to stick with SIP as the protocol for  
signaling Peer Protocol connections, then I think the draft describes  
a very good way of doing this. There are some minor details that  
could be changed, but I think most of the details would stay the same.

- Philip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 3 May 2007 15:28:35 -0400

Hi Philip,

I think some of the content in this draft provides a very good foundation
and it also provides a good starting point. It is much better if we separate
mechanism out from the details since it can help nail down some additional
requirements for the P2P protocol.

For example, if someone wants to use the mechanisms in the draft for a P2P
gaming protocol, they would know what additional things to implement in the
gaming protocol.

One of the mechanisms used by the draft is SIP/Replaces approach. To me that
seems excessive specification again. I don't know why we need SIP on the new
P2P connection (besides that it may work if the control connection doesn't
get terminated by the BYE) and what benefits it brings to the table except
complexity.

I think the choice is between three things here: extend SIP for P2P, let SIP
and P2PP ride on the same connection (like this draft's approach) or devise
some new mechanism to refresh the connection on which P2PP rides.

I think in all of these cases the bootstrapping mechanism is still the
same...

---

From: Philip Matthews <[email-masked]>
Date: Mon, 7 May 2007 19:13:57 -0400

On 3-May-07, at 15:28 , Medhavi Bhatia wrote:

> Hi Philip,
>
> I think some of the content in this draft provides a very good  
> foundation and it also provides a good starting point. It is much  
> better if we separate mechanism out from the details since it can  
> help nail down some additional requirements for the P2P protocol.

I agree that it would be nice to have a high-level discussion of the  
mechanisms before delving into the details.
To start that off, I will note that four bootstrap mechanisms are  
listed in the Concepts draft,
and draft-matthews-p2psip-bootstrap-mechanisms-00 describes how to  
implement two of them using SIP.
(The other two are also implementable -- we only had time to work out  
the details for two of them).

We decided to use SIP as the signaling protocol in the draft because  
SIP is an existing protocol that allows the signaling and data  
channels to take different paths -- this property is used heavily in  
this draft and personally I don't see how to get around it.

>
> For example, if someone wants to use the mechanisms in the draft  
> for a P2P gaming protocol, they would know what additional things  
> to implement in the gaming protocol.
>
> One of the mechanisms used by the draft is SIP/Replaces approach.  
> To me that seems excessive specification again. I don't know why we  
> need SIP on the new P2P connection (besides that it may work if the  
> control connection doesn't get terminated by the BYE) and what  
> benefits it brings to the table except complexity.

First, a minor point -- the draft uses "mechanism" in a very specific  
way, so let's call the SIP/Replaces approach a "technique".
Second, I claim we need this SIP/Replaces technique, for otherwise  
the connection would go down if the bootstrap peer left the overlay.
Third, though it is not described in this draft, it turns out that  
there are other good reasons to want to run the signaling protocol
(SIP in this case) on the same connection as the peer protocol --  
take a look at draft-matthews-dsip-nat-traversal-00. This draft
shows how to leverage the joining peer's connection to the admitting  
peer into a network of connections.

>
> I think the choice is between three things here: extend SIP for  
> P2P, let SIP and P2PP ride on the same connection (like this  
> draft's approach) or devise some new mechanism to refresh the  
> connection on which P2PP rides.

I don't understand your third choice.
However, I see a fourth choice:  Use something other than SIP as the  
signaling protocol.

Part of the reason we wrote the draft was to show that the various  
pieces of the draft could be separated, so one could use, for  
example, SIP for one part and something else for a different part.

>
> I think in all of these cases the bootstrapping mechanism is still  
> the same...
>

You are right that the basic mechanisms could remain the same,  
assuming the signaling protocol allowed the signaling and data  
channels to take different paths.

Please understand that we are happy to consider other ways of doing  
bootstrapping -- we just wanted to get a draft out that showed in  
detail how to make one way work. As I said before, once people see  
one way of doing things, ideas for other ways often come out.

- Philip