Subject: [P2PSIP] Re: Peer definition in Concept draft

From: Philip Matthews <[email-masked]>
Date: Mon, 2 Apr 2007 14:15:47 -0400

On 31-Mar-07, at 05:58 , JiangXingFeng wrote:
> I have noticed that there are minor differences between version 03 and
> version 04.  I list them as follows:
> Version 3:
> Each P2PSIP Peer may or may not (NOT) be coupled to one or more  
> P2PSIP User
> Agents.
> Version 4:
> Each P2PSIP Peer may be coupled to one or more SIP entities.
>
> By comparing the difference, could we come to a conclusion that all  
> peers
> should speak SIP in the version 04?

No, that was not the intention.
Perhaps the sentence should read:

     Each P2PSIP Peer may optionally be coupled to one or more SIP  
entities.

Anyway, this is something that a peer may or may not do.

- Philip

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 2 Apr 2007 13:36:34 -0500

On Apr 2, 2007, at 1:15 PM, Philip Matthews wrote:

>> By comparing the difference, could we come to a conclusion that  
>> all peers

Another way to word this might be:

"Each P2PSIP Peer is coupled to zero or more SIP entities".

mathematics vs. english language conventions . . . we all lose.

--
Dean

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 03 Apr 2007 19:56:26 +0800

Hi, Dean and Philip:

>From your responses, I learned that P2PSIP peer may be not coupled to any
SIP entity. It also says that some P2PSIP peers will not recognize SIP
message. Is my understanding right? If it is, I have some comments on the
concept draft which are listed as follows:
1. In section 3, all peers in the reference model are coupled to SIP
entities except gateway Peer. In my opinion, gateway peers also have SIP
processing functionality because they should do translation between SIP
signaling and PSTN signaling. Does the reference model imply that all peers
have to speak SIP? If it is not the case, do we need add some peers which
don't speak SIP? 

Comments?

2. In the second option of using distributed database in section 5.2, if
Peer Z  could not parse SIP message, how does the Peer Z proxy the INVITE
message? If I don't make mistake, Peer Z at least rewrite the Request-URI of
the message, so it have to be able to recognize and parse the SIP message.

There are similar problems in option 3 and 4.

Comments?

3. In the section 5.5, some possible client behaviors are proposed. In terms
of third alternative, namely "a peer with bad memory", clients participate
in DHT algorithms and do not store any resource record. Here, I have a
question. For example, there is a chord overlay and there are a peer keyed
20, and a client keyed 19. If a resource keyed 18 want to be stored into the
overlay, a peer keyed 20 is responsible for key 18 according to the third
alternative. But if a normal chord algorithm is used, the client node keyed
19 should be the answer. IMHO, I think this alternative will break the
underlying DHT algorithm. Comments?

These are my individual ideas. If I miss something, please enlighten me!
What I really hope is to make the P2PSIP WG work further and reach consensus
as soon as possible? 

Regards!
--
Jiang XingFeng
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2007 2:37 AM
> To: Philip Matthews
> Cc: JiangXingFeng; [email-masked]
> Subject: Re: [P2PSIP] Re: Peer definition in Concept draft
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 3 Apr 2007 09:08:36 -0400

See in-line.
- Philip

> have to speak SIP? If it is not the case, do we need add some peers  

We could do that.
However, I think we need to decide on the rough format for the Peer  
Protocol first.
If the Peer Protocol uses SIP, either entirely like the dSIP proposal,
or partly like draft-matthews-p2psip-bootstrap-mechanisms-00
or draft-hautakorpi-p2psip-peer-protocol-00
then it might be reasonable to assume that all peers speak SIP.

However, if the Peer Protocol is completely independent of SIP,
then it is reasonable to assume that there are peers that do not  
speak SIP.

This plays a bit into the question of what we are trying to do in  
P2PSIP.
Are we working on a system which is independent of SIP,
or does the fact that we are the "P2PSIP" group imply that we assume
all peers support SIP?

> There are similar problems in option 3 and 4.

Why would peer Z be unable to parse the SIP message?

> underlying DHT algorithm. Comments?

Clearly, the DHT algorithm would have to be designed so that clients  
are not
expected to store data.

One way this might work was described by Eric Rescorla as follows:
	1. Clients understand the overlay network, they just don't
	   store data. To take a concrete example from Chord, there's
	   no reason you can't connect to a Chord node, suck down an
	   appropriate finger/routing table and then send messages
	   to other Chord nodes just as if you were a Peer. The
	   only thing you don't do is *register* with the network.
Other ways are probably possible.

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 04 Apr 2007 10:10:30 +0800

Please see inline.

--
Jiang XingFeng
--------------------------------------------------------------------
> or does the fact that we are the "P2PSIP" group imply that we assume
[JiangXingFeng] I also think this is a fundamental issue which will
influence work in P2PSIP greatly. Philip, would you please make it as an
open issue and ask for comments in the mailing list? 
> Why would peer Z be unable to parse the SIP message?
[JiangXingFeng] I mean that Peer Z may not speak SIP, so it is unable to
parse the SIP message.
> Other ways are probably possible.
[Jiang XingFeng] I figured out the Eric's idea which is to let the Clients
know the topology of the overlay and at the same time Peers in the overlay
do not know the clients' existence. So Clients could have routing table of
the overlay to routing the message by themselves. Is my understanding right?

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 3 Apr 2007 20:21:24 -0700

>Are we working on a system which is independent of SIP, or does the
fact >that we are the "P2PSIP" group imply that we assume all peers
support >SIP?

The numerous applications developed for the openDHT have proven the
usefulness of having an overlay that can support more than one
application (such as SIP only). The DHT without SIP is also useful for
bootstrapping and maybe TURN relays.

There is a good case for having an independent, multi-purpose DHT
overlay with a set of powerful APIs that support more than one single
application.

Let's have some I-Ds on this before trying to finalize this decision on
e-mail.

Thanks, Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:09 AM
To: JiangXingFeng
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: Peer definition in Concept draft

See in-line.
- Philip

We could do that.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Apr 2007 08:07:22 -0400

On 3-Apr-07, at 23:21 , Henry Sinnreich wrote:

>> or does the fact that we are the "P2PSIP" group imply
>> that we assume all peers support SIP?
>
> [snip]
>

I agree with Henry. Let's see some I-Ds on how this
might work before making a decision.

- Philip

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2007 16:07:46 -0500

> have to speak SIP? If it is not the case, do we need add some peers  

Whether a peer understands SIP or not depends greatly on its role.  
Since we started with P2PSIP, the roles we've though about the most  
involve handling SIP requests.

It's quite possible that the "Bootstrap peer" may not speak SIP.

Nothing in the current model requires peers to use SIP. However,  
there are proposals (such as dSIP) that would effectively require  
every peer to have at least some level of SIP knowledge.

Other proposals, if I understand what Jonathan and Philip appear to  
be thinking, require SIP only at nodes that also have traditional SIP  
roles -- basically, at UAs and at SIP-to-P2PSIP boundary nodes that  
would look like proxies or proxy/registrars to the SIP side.

This could probably be better demonstrated in the reference model.

> the message, so it have to be able to recognize and parse the SIP  

Imagine a model where the peer protocol is not SIP, but instead  
provides a means for carrying SIP requests in an "envelope" or  
wrapper provided by the peer protocol.

Peer Z would route the request along the P2PSIP Peer Protocol channel  
based on the Peer ID indicated in the request's envelope, without  
ever doing SIP-level parsing of the request.

This has some interesting advantages:

1) The SIP body could be completely protected cryptographically and  
not visible to intermediate peers.

2) Since the the request could be routed without parsing the text- 
formatted SIP message, there is the possibility that routing  
decisions could require substantially (perhaps an order of magnitude)  
less processing power than that required for conventional SIP  
proxies. This is further augmented by not having to decrypt/re- 
encrypt each request at every proxy when TLS is used.

> There are similar problems in option 3 and 4.

I believe similar logic applies therein.

> underlying DHT algorithm. Comments?

That'll have to be addressed by people who speak CHORD, but I suspect  
this mode, if deemed desirable, might influence the DHT selection  
process.

--
Dean

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 4 Apr 2007 20:54:11 -0400

> wrapper provided by the peer protocol.

I think this is an interesting model and agree with the advantages you mentioned.

Would there be any charter-related problems with pursuing such a model?  I ask because I think this model could easily become a generic transport service.  Would that be out-of-scope for us?  

If we say it's not a generic transport service, but really tied more to SIP then this model could also be viewed as defining an alternative transport for SIP.  Is that in scope?

Best Regards,

Eric.

---

From: Dean Willis <[email-masked]>
Date: Thu, 05 Apr 2007 00:19:31 -0500

> If we say it's not a generic transport service, but really tied more to SIP then this model could also be viewed as defining an alternative transport for SIP.  Is that in scope?

I hope the charter allows for this approach. It is certainly condidered 
in the -03 version of the Concepts and Terminology draft, and I believe 
still allowed for in -04.

--
Dean

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 6 Apr 2007 10:25:46 -0400

On 4/5/07, Dean Willis <[email-masked]> wrote:
> > Would there be any charter-related problems with pursuing such a
> model?  I ask because I think this model could easily become a generic
> transport service.  Would that be out-of-scope for us?
> >
> > If we say it's not a generic transport service, but really tied more to
> SIP then this model could also be viewed as defining an alternative
> transport for SIP.  Is that in scope?
> >
> > Best Regards,
> >
> > Eric.
> >
>

This 'transport' functionality is not one of the core functionalities of the
Peer Protocol or the Client Protocol as described in the current charter.
However, the charter cannot describe all the functionalities the protocols
can provide. So I believe there is a room for adopting such 'transport'
functionality into the protocols at least as far as the charter is
concerned. Well, probably we would need our AD's help in this discussion.

Anyway, other important questions are how useful the functionality is,  how
close/far this functionality is to/from the core functionalities of the
protocols, and whether it is better to put it in the protocols rather than
to separate it into a different protocol.

Thanks.

Eunsoo